Руководство по принятию решений Microsoft Fabric: выбор хранилища данных
Используйте это справочное руководство и примеры сценариев, которые помогут вам выбрать хранилище данных для рабочих нагрузок Microsoft Fabric.
Свойства хранилища данных
В этой таблице сравниваются хранилища данных, такие как хранилище, lakehouse, datamart и eventhouse на основе тома данных, типа, пользователя разработчика, набора навыков, операций. и другие возможности.
| Склад | Lakehouse | Power BI Datamart | Eventhouse | |
|---|---|---|---|---|
| Том данных | Не ограничено | Не ограничено | До 100 ГБ | Не ограничено |
| Тип данных | структурированные | Неструктурированные, полуструктурированные, структурированные | структурированные | Неструктурированные, полуструктурированные, структурированные |
| Основной пользователь разработчика | Разработчик хранилища данных, инженер SQL | Инженер данных, специалист по обработке и анализу данных | Разработчик гражданина | Специалист по обработке и анализу данных гражданина, инженер по обработке и анализу данных, специалист по обработке и анализу данных |
| Основной набор навыков разработчика | SQL | Spark(Scala, PySpark, Spark SQL, R) | Нет кода, SQL | Нет кода, KQL, SQL |
| Данные, упорядоченные по | Базы данных, схемы и таблицы | Папки и файлы, базы данных и таблицы | База данных, таблицы, запросы | Базы данных, схемы и таблицы |
| Операции чтения | T-SQL, Spark (поддерживает чтение из таблиц с помощью сочетаний клавиш, пока не поддерживает доступ к представлениям, хранимым процедурам, функциям и т. д.). | Spark, T-SQL | Spark, T-SQL, Power BI | KQL, T-SQL, Spark, Power BI |
| Операции записи | T-SQL | Spark(Scala, PySpark, Spark SQL, R) | Потоки данных, T-SQL | KQL, Spark, экосистема соединителей |
| Транзакции с несколькими таблицами | Да | No | No | Да, для приема нескольких таблиц. См . политику обновления. |
| Основной интерфейс разработки | Скрипты SQL | Записные книжки Spark, определения заданий Spark | Power BI | Набор запросов KQL, база данных KQL |
| Безопасность | Уровень объекта (таблица, представление, функция, хранимая процедура и т. д.), уровень столбца, уровень строки, DDL/DML, динамическое маскирование данных | Уровень строк, уровень столбца (для озера, доступ к который выполняется через конечную точку аналитики SQL), уровень таблицы (при использовании T-SQL), ни один из них для Spark | Встроенный редактор RLS | Безопасность на уровне строк |
| Доступ к данным с помощью сочетаний клавиш | Да, через лейкхаус с помощью трех частей имен | Да | No | Да |
| Может быть источником для сочетаний клавиш | Да (таблицы) | Да (файлы и таблицы) | No | Да |
| Запрос между элементами | Да, запрос между таблицами lakehouse и склада | Да, запрос между таблицами lakehouse и склада; запрос между lakehouses (включая сочетания клавиш с помощью Spark) | No | Да, запрос между базами данных KQL, lakehouses и хранилищами с сочетаниями клавиш |
Сценарии
Ознакомьтесь с этими сценариями, чтобы помочь в выборе хранилища данных в Fabric.
Сценарий 1
Сьюзан, профессиональный разработчик, является новым для Microsoft Fabric. Они готовы приступить к очистке, моделированию и анализу данных, но необходимо решить создать хранилище данных или озеро. После просмотра сведений в предыдущей таблице основные точки принятия решений являются доступным набором навыков и потребностью в много табличных транзакциях.
Сьюзан провел много лет в создании хранилищ данных на реляционных ядрах СУБД и знаком с синтаксисом и функциональностью SQL. Думая о более крупной команде, основные потребители этих данных также квалифицированы с помощью аналитических средств SQL и SQL. Сьюзан решает использовать хранилище данных, что позволяет команде взаимодействовать в основном с T-SQL, а также разрешать пользователям Spark в организации получать доступ к данным.
Susan создает новое озеро и обращается к возможностям хранилища данных с помощью конечной точки аналитики SQL Lakehouse. С помощью портала Fabric создаются ярлыки для внешних таблиц данных и их помещают в папку /Tables . Сьюзан теперь может записывать запросы T-SQL, ссылающиеся на сочетания клавиш для запроса данных Delta Lake в lakehouse. Ярлыки автоматически отображаются в виде таблиц в конечной точке аналитики SQL и могут запрашиваться с помощью T-SQL с помощью трех частей.
Сценарий 2
Роб, инженер данных, должен хранить и моделировать несколько терабайт данных в Fabric. Команда имеет сочетание навыков PySpark и T-SQL. Большинство команд, выполняющих запросы T-SQL, являются потребителями, поэтому не требуется записывать инструкции INSERT, UPDATE или DELETE. Остальные разработчики комфортно работают в записных книжках, и так как данные хранятся в Delta, они могут взаимодействовать с аналогичным синтаксисом SQL.
Роб решает использовать lakehouse, который позволяет команде разработчиков данных использовать свои разнообразные навыки против данных, позволяя членам группы, которые высоко квалифицированы в T-SQL использовать данные.
Сценарий 3
Эш, разработчик гражданина, является разработчиком Power BI. Они знакомы с Excel, Power BI и Office. Им необходимо создать продукт данных для бизнес-подразделения. Они знают, что у них нет навыков для создания хранилища данных или озера, и они выглядят слишком много для своих потребностей и объемов данных. Они просматривают сведения в предыдущей таблице и видят, что основные точки принятия решений являются их собственными навыками и их потребность в самообслуживании, отсутствие возможностей кода и объем данных в размере 100 ГБ.
Эш работает с бизнес-аналитиками, знакомыми с Power BI и Microsoft Office, и знает, что у них уже есть подписка на емкость Premium. По мере того как они думают о своей более крупной команде, они понимают, что основные потребители этих данных могут быть аналитиками, знакомыми с безкода и аналитическими инструментами SQL. Эш решает использовать datamart Power BI, который позволяет команде быстро создавать возможности, используя интерфейс без кода. Запросы можно выполнять с помощью Power BI и T-SQL, а также разрешать пользователям Spark в организации также получать доступ к данным.
Сценарий 4
Daisy является бизнес-аналитиком, опытным с помощью Power BI для анализа узких мест цепочки поставок для крупной глобальной розничной сети. Им необходимо создать масштабируемое решение данных, которое может обрабатывать миллиарды строк данных и использовать для создания панелей мониторинга и отчетов, которые можно использовать для принятия бизнес-решений. Данные поступают из растений, поставщиков, грузоотправителей и других источников в различных структурированных, полуструктурированных и неструктурированных форматах.
Daisy решает использовать хранилище событий из-за масштабируемости, времени быстрого отклика, расширенных возможностей аналитики, включая анализ временных рядов, геопространственные функции и режим быстрого прямого запроса в Power BI. Запросы можно выполнять с помощью Power BI и KQL для сравнения текущих и предыдущих периодов, быстрого определения возникающих проблем или обеспечения геопространственного анализа наземных и морских маршрутов.