Поделиться через


Руководство по принятию решений 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 для сравнения текущих и предыдущих периодов, быстрого определения возникающих проблем или обеспечения геопространственного анализа наземных и морских маршрутов.