Руководство по принятию решений Microsoft Fabric: выбор хранилища данных

Используйте это справочное руководство и примеры сценариев, которые помогут вам выбрать хранилище данных для рабочих нагрузок Microsoft Fabric.

Свойства хранилища данных

Используйте эту информацию для сравнения хранилищ данных Fabric, таких как склад, lakehouse, Eventhouse, база данных SQL и Power BI дата-март, на основе объема данных, типа, персоны разработчика, набора навыков, операций и других возможностей. Эти сравнения организованы в следующих двух таблицах:

* Spark поддерживает чтение из таблиц с помощью ярлыков, пока не поддерживает доступ к представлениям, хранимым процедурам, функциям и т. д.

** Безопасность на уровне столбцов, доступная в Lakehouse через конечную точку аналитики SQL, используя T-SQL.

Сценарии

Ознакомьтесь с этими сценариями, чтобы помочь в выборе хранилища данных в Fabric.

Сценарий 1

Сьюзан, профессиональный разработчик, новичок в Microsoft Fabric. Они готовы приступить к очистке, моделированию и анализу данных, но необходимо решить создать хранилище данных или озеро. После просмотра сведений в предыдущей таблице основными точками для принятия решений являются доступный набор навыков и потребность в многотабличных транзакциях.

Сьюзан провела много лет, создавая хранилища данных на реляционных СУБД, и знакома с синтаксисом и функциональностью SQL. Думая о более крупной команде, основные потребители этих данных также обладают навыками работы с SQL и аналитическими инструментами SQL. Сьюзан решает использовать склад Fabric, что позволяет команде взаимодействовать преимущественно с T-SQL, а также разрешая пользователям Spark из организации получать доступ к данным.

Сьюзан создает новое хранилище данных и взаимодействует с ним с помощью T-SQL так же, как и другие базы данных SQL Server. Большая часть существующего кода T-SQL, написанного для создания своего хранилища на SQL Server, будет работать в хранилище данных Fabric, что упрощает переход. Если она решит, она может даже использовать те же средства, которые работают с другими базами данных, например SQL Server Management Studio. Используя редактор SQL на портале Fabric, Сьюзан и другие члены команды пишут аналитические запросы, ссылающиеся на другие хранилища данных и таблицы Delta в хранилищах данных озера, просто используя трехуровневую нотацию для выполнения межбазовых запросов.

Сценарий 2

Роб, инженер данных, должен хранить и моделировать несколько терабайт данных в Fabric. Команда имеет сочетание навыков PySpark и T-SQL. Большинство команд, выполняющих запросы T-SQL, являются потребителями, поэтому не требуется записывать инструкции INSERT, UPDATE или DELETE. Остальные разработчики комфортно работают в записных книжках, и так как данные хранятся в Delta, они могут взаимодействовать с аналогичным синтаксисом SQL.

Роб решает использовать лейкхаус, что позволяет команде инженеров данных применять свои разносторонние навыки при работе с данными, позволяя членам команды, которые высоко квалифицированы в T-SQL, использовать данные.

Сценарий 3

Daisy — бизнес-аналитик с опытом использования Power BI для анализа узких мест в цепочках поставок крупной международной розничной сети. Им необходимо создать масштабируемое решение данных, которое может обрабатывать миллиарды строк данных и использовать для создания панелей мониторинга и отчетов, которые можно использовать для принятия бизнес-решений. Данные поступают из предприятий, поставщиков, грузоотправителей и других источников в различных структурированных, полуструктурированных и неструктурированных форматах.

Daisy решает использовать Eventhouse из-за масштабируемости, быстрого отклика, расширенных возможностей аналитики, включая анализ временных рядов, геопространственные функции и режим быстрого прямого запроса в Power BI. Запросы можно выполнять с помощью Power BI и KQL для сравнения текущих и предыдущих периодов, быстрого определения возникающих проблем или обеспечения геопространственного анализа наземных и морских маршрутов.

Сценарий 4

Кирби является архитектором приложений, опытным в разработке приложений .NET для операционных данных. Им нужна база данных с высоким уровнем параллелизма, полным соблюдением транзакций ACID и строго обеспечиваемыми внешними ключами для реляционной целостности. Кирби хочет воспользоваться преимуществами автоматической настройки производительности, чтобы упростить ежедневное управление базами данных.

Кирби выбирает базу данных SQL в Fabricс таким же движком базы данных SQL, как Azure SQL Database. Базы данных SQL в Fabric автоматически масштабируются в соответствии с нагрузкой в течение рабочего дня. Они имеют полную возможность транзакционных таблиц и гибкость уровней изоляции транзакций от сериализуемого к считываемому моментальному снимку. База данных SQL в Fabric автоматически создает и удаляет некластеризованные индексы на основе сильных сигналов от планов выполнения, наблюдаемых с течением времени.

В сценарии Кирби данные из операционного приложения должны быть присоединены к другим данным в системе Fabric: в Spark, в базе данных и из событий в режиме реального времени в Eventhouse. Каждая база данных Fabric включает конечную точку аналитики SQL, чтобы можно было получать доступ к данным в режиме реального времени из Spark или посредством запросов Power BI, используя режим DirectLake. Эти решения для создания отчетов освобождают основную операционную базу данных от нагрузки аналитических рабочих процессов и избегают денормализации. Кирби также имеет существующие операционные данные в других базах данных SQL и должен импортировать эти данные без преобразования. Чтобы импортировать существующие операционные данные без преобразования типов данных, Кирби создает конвейеры данных с фабрикой данных Fabric для импорта данных в базу данных SQL Fabric.

Связанное содержимое

• создание озера в Microsoft Fabric
• Создание хранилища в Microsoft Fabric
• Создайте эвентхаус
• создание базы данных SQL на портале Fabric
• datamart Power BI