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

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

Схема руководства по выбору идеального хранилища данных в Microsoft Fabric.

На схеме показано руководство по выбору хранилища данных Fabric. Для потоковой передачи данных событий и интерактивной аналитики с высокой степенью детализации используйте хранилище событий. Для ИИ, NoSQL и векторного поиска используйте Cosmos DB в Fabric. Для рабочих нагрузок транзакций (OLTP) используйте базу данных SQL в Fabric. Для корпоративного хранилища данных, SQL-ориентированного бизнес-анализа, OLAP и поддержки всех транзакций SQL используйте систему управления данными. Для работы с большими данными и машинного обучения, работающего с неструктурированными или полуструктурированными данными, а также проектированием данных, используйте lakehouse. Все хранилища данных доступны в OneLake в формате открытой таблицы по умолчанию.

Идеальный вариант использования Рабочая нагрузка Microsoft Fabric Данные, доступные в OneLake в формате открытой таблицы по умолчанию
Потоковая передача данных о событиях с высокой детализацией (по времени, пространству, детализации — JSON/Text) для интерактивной аналитики. Eventhouse Да
ИИ, NoSQL и векторный поиск Cosmos DB в Fabric Да
Операционная база данных транзакций, база данных OLTP База данных SQL в Fabric Да
Корпоративное хранилище данных, бизнес-аналитика SQL, OLAP, полная поддержка транзакций SQL Хранилище данных Да
Большие данные и машинное обучение, не/полуструктурированные данные, проектирование данных Озёрный Дом Да

Образы и наборы навыков

Рабочая нагрузка Microsoft Fabric Основные образы разработчиков Основные наборы навыков, инструменты Основные языки
Eventhouse Разработчик приложений, специалист по обработке и анализу данных, инженер данных Нет кода, KQL, SQL KQL (язык запросов Kusto), T-SQL
Cosmos DB в Fabric Разработчик ИИ, разработчик приложений Основные понятия NoSQL, REST API, аналогичные Azure Cosmos DB Интеграция REST API с помощью JavaScript/TypeScript, Python, C#, Java и других
База данных SQL в Fabric Разработчик ИИ, разработчик приложений, разработчик базы данных, администратор базы данных Администрирование и разработка баз данных, аналогичные средствам запросов, совместимым с Базой данных SQL Azure, SSMS, VS Code и SQL Server T-SQL
Хранилище данных Fabric Разработчик хранилища данных, архитектор данных, инженер данных, разработчик базы данных Основные понятия хранения данных, структура базы данных схемы звезды, SSMS, VS Code и средства запросов, совместимые с SQL Server T-SQL, без кода
Озёрный Дом Инженер данных, специалист по обработке и анализу данных PySpark, Delta Lake, записные книжки Spark (Scala, PySpark, Spark SQL, R)

Сценарии

Ознакомьтесь с этими сценариями, чтобы помочь в выборе хранилища данных в 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, как База данных SQL Azure. Базы данных SQL в Fabric автоматически масштабируются в соответствии с нагрузкой в течение рабочего дня. Они имеют полную возможность транзакционных таблиц и гибкость уровней изоляции транзакций от сериализуемого к считываемому моментальному снимку. База данных SQL в Fabric автоматически создает и удаляет некластеризованные индексы на основе сильных сигналов от планов выполнения, наблюдаемых с течением времени.

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

Следующий шаг