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