Руководство по принятию решений Microsoft Fabric: выбор хранилища данных
Используйте это справочное руководство и примеры сценариев, которые помогут вам выбрать хранилище данных для рабочих нагрузок Microsoft Fabric.
Свойства хранилища данных
Используйте эти сведения для сравнения хранилищ данных Fabric, таких как хранилище, lakehouse, Eventhouse, база данных SQL и datamart Power BI на основе тома данных, типа, пользователя разработчика, набора навыков, операций и других возможностей. Эти сравнения организованы в следующих двух таблицах:
| Lakehouse | Склад | Eventhouse | |
|---|---|---|---|
| Том данных | Не ограничено | Не ограничено | Не ограничено |
| Тип данных | Неструктурированный полуструктурированный, Структурированные данные |
структурированные | Неструктурированный полуструктурированный, Структурированные данные |
| Основной пользователь разработчика | Инженер данных, специалист по обработке и анализу данных | Разработчик хранилища данных, архитектор данных, разработчик базы данных | Разработчик приложений, специалист по обработке и анализу данных, инженер по обработке и анализу данных |
| Основной навык разработки | Spark (Scala, PySpark, Spark SQL, R) | SQL | Нет кода, KQL, SQL |
| Данные, упорядоченные по | Папки и файлы, базы данных и таблицы | Базы данных, схемы и таблицы | Базы данных, схемы и таблицы |
| Операции чтения | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Операции записи | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, экосистема соединителей |
| Транзакции с несколькими таблицами | No | Да | Да, для приема нескольких таблиц |
| Основной интерфейс разработки | Записные книжки Spark, определения заданий Spark | Скрипты SQL | Набор запросов KQL, база данных KQL |
| Безопасность | RLS, CLS**, уровень таблицы (T-SQL), нет для Spark | Уровень объектов, RLS, CLS, DDL/DML, динамическое маскирование данных | RLS |
| Доступ к данным с помощью сочетаний клавиш | Да | Да | Да |
| Может быть источником для сочетаний клавиш | Да (файлы и таблицы) | Да (таблицы) | Да |
| Запрос между элементами | Да | Да | Да |
| Расширенная аналитика | Интерфейс для крупномасштабной обработки данных, встроенного параллелизма данных и отказоустойчивости | Интерфейс для крупномасштабной обработки данных, встроенного параллелизма данных и отказоустойчивости | Собственные элементы временных рядов, полные возможности геопространства и запросов |
| Расширенная поддержка форматирования | Таблицы, определенные с помощью PARQUET, CSV, AVRO, JSON и любого совместимого формата файла Apache Hive | Таблицы, определенные с помощью PARQUET, CSV, AVRO, JSON и любого совместимого формата файла Apache Hive | Полное индексирование для бесплатных текстовых и полуструктурированных данных, таких как JSON |
| Задержка приема | Доступно мгновенно для запроса | Доступно мгновенно для запроса | Прием в очереди, прием потоковой передачи имеет пару секунд задержки |
* Spark поддерживает чтение из таблиц с помощью ярлыков, пока не поддерживает доступ к представлениям, хранимым процедурам, функциям и т. д.
| База данных SQL Fabric | Power BI Datamart | |
|---|---|---|
| Том данных | 4 ТБ | До 100 ГБ |
| Тип данных | Структурированный полуструктурированный, неструктурированный |
структурированные |
| Основной пользователь разработчика | Разработчик ИИ, разработчик приложений, разработчик базы данных, администратор базы данных | Специалист по обработке и анализу данных |
| Основной навык разработки | SQL | Нет кода, SQL |
| Данные, упорядоченные по | Базы данных, схемы, таблицы | База данных, таблицы, запросы |
| Операции чтения | T-SQL | Spark, T-SQL |
| Операции записи | T-SQL | Потоки данных, T-SQL |
| Транзакции с несколькими таблицами | Да, полное соответствие ACID | No |
| Основной интерфейс разработки | Скрипты SQL | Power BI |
| Безопасность | Уровень объектов, RLS, CLS, DDL/DML, динамическое маскирование данных | Встроенный редактор RLS |
| Доступ к данным с помощью сочетаний клавиш | Да | Нет |
| Может быть источником для сочетаний клавиш | Да (таблицы) | No |
| Запрос между элементами | Да | Нет |
| Расширенная аналитика | Аналитические возможности T-SQL, данные, реплицированные в разностный parquet в OneLake для аналитики | Интерфейс для обработки данных с автоматической настройкой производительности |
| Расширенная поддержка форматирования | Поддержка таблиц для OLTP, JSON, вектора, графа, XML, пространственного, ключевого значения | Таблицы, определенные с помощью PARQUET, CSV, AVRO, JSON и любого совместимого формата файла Apache Hive |
| Задержка приема | Доступно мгновенно для запроса | Доступно мгновенно для запроса |
** Безопасность на уровне столбцов, доступная в Lakehouse через конечную точку аналитики SQL, используя T-SQL.
Сценарии
Ознакомьтесь с этими сценариями, чтобы помочь в выборе хранилища данных в Fabric.
Сценарий 1
Сьюзан, профессиональный разработчик, является новым для Microsoft Fabric. Они готовы приступить к очистке, моделированию и анализу данных, но необходимо решить создать хранилище данных или озеро. После просмотра сведений в предыдущей таблице основные точки принятия решений являются доступным набором навыков и потребностью в много табличных транзакциях.
Сьюзан провел много лет в создании хранилищ данных на реляционных ядрах СУБД и знаком с синтаксисом и функциональностью SQL. Думая о более крупной команде, основные потребители этих данных также квалифицированы с помощью аналитических средств SQL и SQL. Сьюзан решает использовать хранилище Fabric, которое позволяет команде взаимодействовать в основном с T-SQL, а также разрешать пользователям Spark в организации получать доступ к данным.
Сьюзан создает новое озеро и обращается к возможностям хранилища данных с помощью конечной точки аналитики 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 решает использовать eventhouse из-за его масштабируемости, быстрого отклика, расширенных возможностей аналитики, включая анализ временных рядов, геопространственные функции и режим быстрого прямого запроса в Power BI. Запросы можно выполнять с помощью Power BI и KQL для сравнения текущих и предыдущих периодов, быстрого определения возникающих проблем или обеспечения геопространственного анализа наземных и морских маршрутов.
Сценарий 5
Кирби является архитектором приложений, опытным в разработке приложений .NET для операционных данных. Они нуждаются в базе данных высокого параллелизма с полным соответствием транзакций ACID и строго применяют внешние ключи для реляционной целостности. Кирби хочет воспользоваться преимуществами автоматической настройки производительности, чтобы упростить ежедневное управление базами данных.
Кирби решает базу данных SQL в Fabric с тем же ядром База данных SQL, что и База данных SQL Azure. Базы данных SQL в Fabric автоматически масштабируется в соответствии с требованиями в течение рабочего дня. Они имеют полную возможность транзакционных таблиц и гибкость уровней изоляции транзакций от сериализуемого к считываемому моментальному снимку. База данных SQL в Fabric автоматически создает и удаляет некластеризованные индексы на основе сильных сигналов от планов выполнения, наблюдаемых с течением времени.
В сценарии Кирби данные из операционного приложения должны быть присоединены к другим данным в Fabric: в Spark, в хранилище и из событий в режиме реального времени в Хранилище событий. Каждая база данных Fabric включает конечную точку аналитики SQL, поэтому доступ к данным в режиме Реального времени из Spark или с помощью запросов Power BI с помощью режима DirectLake. Эти решения для создания отчетов пощадят основную операционную базу данных из затрат на аналитические рабочие нагрузки и избегают денормализации. Кирби также имеет существующие операционные данные в других базах данных SQL и должен импортировать эти данные без преобразования. Чтобы импортировать существующие операционные данные без преобразования типов данных, Кирби создает конвейеры данных с фабрикой данных Fabric для импорта данных в базу данных SQL Fabric.