Выбор хранилища аналитических данных в Azure

В архитектуре больших данных часто требуется аналитическое хранилище данных, которое обслуживает обработанные данные в структурированном формате, который можно запрашивать с помощью аналитических средств. Аналитические хранилища данных, поддерживающие запросы к данным горячего пути и холодного пути, совместно называются обслуживающим слоем или хранилищем данных.

Слой обслуживания обрабатывает данные из горячего пути и холодного пути. В Лямбда-архитектуре слой обслуживания разделен на два уровня. Уровень скорости обслуживания содержит добавочные обработанные данные. Слой пакетного обслуживания содержит пакетно обработанные выходные данные. Уровень обслуживания требует строгой поддержки случайных операций чтения с низкой задержкой. Хранилище данных для уровня скорости также должно поддерживать случайные записи, так как пакетная загрузка данных в это хранилище создает нежелательные задержки. Кроме того, хранилище данных для пакетного слоя должно поддерживать пакетную запись, а не случайные записи.

Для всех задач хранения данных нет единого оптимального выбора управления данными. Для разных задач оптимизированы разные решения управления данными. Большинство облачных приложений и процессов больших данных имеют различные требования к хранилищу данных и часто используют сочетание решений для хранения данных.

Современные аналитические решения, такие как Microsoft Fabric, предоставляют комплексную платформу, которая интегрирует различные службы данных и средства для удовлетворения различных аналитических потребностей. Fabric включает OneLake, который является единым, унифицированным, логическим озером данных для всей организации. OneLake предназначен для хранения, управления и защиты всех данных организации в одном расположении. Эта гибкость позволяет вашей организации решать широкий спектр требований к хранилищу данных и обработке.

Выбор хранилища аналитических данных

В Azure есть несколько вариантов для обслуживания данных, которые вы можете выбрать в зависимости от конкретных потребностей:

• Фабрик, в частности:
  • Fabric Lakehouse
  • Склад Fabric
  • Хранилище событий Fabric
  • Базы данных SQL Fabric
• Azure Databricks
• База данных SQL Azure
• SQL Server на виртуальной машине Azure;
• Azure Analysis Services;
• Azure Cosmos DB

Следующие модели баз данных оптимизированы для различных типов задач:

• Базы данных key-value хранят один сериализованный объект для каждого значения ключа. Они хорошо подходят для управления большими объемами данных при извлечении на основе определенного ключа без необходимости запрашивать другие свойства элемента.

• Базы данных документов — это базы данных с ключевым значением, в которых значения являются документами. В этом контексте документ представляет собой коллекцию именованных полей и значений. База данных обычно хранит данные в формате, например XML, YAML, JSON или двоичном формате JSON, но может использовать обычный текст. Базы данных документов могут запрашивать поля, отличные от ключей, и определять вторичные индексы для повышения эффективности запросов. Эта возможность делает базу данных документов более подходящей для приложений, которые должны извлекать данные на основе критериев, которые более сложны, чем значение ключа документа. Например, вы можете создать запрос по идентификаторам продуктов, идентификаторам клиентов или именам клиентов.

• Базы данных хранилища столбцов — это хранилища данных с ключевым значением, которые хранят каждый столбец отдельно на диске. База данных с широкими столбцами — это вид колонкового хранилища, в котором хранятся семейства столбцов, а не только отдельные столбцы. Например, база данных переписи может иметь отдельное семейство столбцов для каждого из следующих элементов:

  • Имя, отчество и фамилия человека

  • Адрес этого человека

  • Сведения профиля этого человека, такие как дата рождения или пол

  База данных может хранить каждое семейство столбцов в отдельном разделе, сохраняя все данные для одного человека, связанного с одним ключом. Приложение может считывать одно семейство столбцов без сканирования всех данных для сущности.

• Базы данных Graph хранят сведения в виде коллекции объектов и связей. База данных графов позволяет эффективно выполнять запросы в сети объектов и связей между ними. Например, в базе данных персонала объектами могут являться сотрудники и вам может потребоваться выполнить такой запрос, как "найти всех сотрудников, которые прямо или косвенно подчиняются Сергею".

• Данные телеметрии и базы данных временных рядов представляют собой коллекцию объектов только для добавления. Базы данных телеметрии эффективно индексируют данные в различных столбцовых хранилищах и структурах в памяти. Эта возможность делает их оптимальным выбором для хранения и анализа большого количества данных телеметрии и временных рядов.

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

Основные критерии выбора

Чтобы уточнить процесс выбора, рассмотрите следующие критерии:

• Вам нужно хранилище, которое может служить горячим путем для ваших данных? Если да, исключите варианты, которые не оптимизированы для уровня быстрого обслуживания.

• Требуется ли поддержка массовой параллельной обработки, где запросы автоматически распределяются между несколькими процессами или узлами? Если да, выберите параметр, поддерживающий горизонтальное масштабирование запросов.

• Намерены ли вы использовать реляционное хранилище данных? Если это сделать, сузите параметры до тех, которые имеют реляционную модель базы данных. Однако некоторые нереляционные хранилища поддерживают синтаксис SQL для запроса, а такие средства, как конечная точка SQL, можно использовать для запроса нереляционных хранилищ данных, таких как OneLake.

• Собираются ли данные временных рядов? Вы используете данные, которые можно только добавлять? Fabric OneLake поддерживает несколько аналитических подсистем, включая службы Analysis Services, T-SQL и Apache Spark. Fabric Eventhouse делает его подходящим для различных потребностей обработки и запросов данных временных рядов.

Матрица возможностей

В следующих таблицах приведены основные различия в возможностях в этих управляемых службах.

Общие возможности

[1] T-SQL через конечную точку аналитики SQL.

[2] KQL поддерживает частичный язык T-SQL.

[3] Поддерживает прием в очереди и прием потоковой передачи.

[4] Поддерживает точность транзакций с доступом с низкой задержкой и обновлениями в режиме реального времени.

[5] Использование оптимизированных для памяти таблиц и хэш-индексов или некластеризованных индексов.

Масштабируемость

[1] Конечные точки SQL направляются через глобальные диспетчеры трафика, но данные всегда обрабатываются в назначенном регионе емкости Fabric.

[2] Lakehouse и Warehouse хранят данные в OneLake с помощью формата Delta Parquet, который поддерживает запросы и репликацию между ядрами.

[3] Lakehouse поддерживает горизонтальное масштабирование на основе Spark для неструктурированных и структурированных данных.

[4] Хранилище использует T-SQL и поддерживает транзакции с несколькими таблицами, управление автономными рабочими нагрузками и распределенную обработку запросов (DQP). DQP действует как диспетчер кластеров, динамически распределив вычислительные ресурсы на основе сложности запросов.

[5] Eventhouse поддерживает KQL и федерацию SQL, позволяя аналитику в режиме реального времени в нескольких источниках, а также масштабировать вычислительные ресурсы, если использование горячего кэша превышает ~95%.

[6] Интеллектуальный кэш для заданий Spark, кэширование в памяти, кэширование результирующих наборов для конечных точек аналитики SQL.

[7] Часто используемые данные хранятся в горячем кэше, который включает в себя оперативную память и SSD-хранилище.

Возможности системы безопасности

[1] Требуется использовать прозрачное шифрование данных для их шифрования и расшифровки в состоянии покоя.

[2] Закрытые ссылки и условный доступ Entra можно использовать для ограничения доступа к ресурсам Fabric.

[3] Хранилище событий Fabric и рабочие нагрузки аналитики Real-Time могут получать данные из безопасных источников, таких как Kafka, Центры событий Azure и AMQP, с маршрутизацией через безопасные конечные точки.

[4] Его можно применить на уровне конечной точки SQL Fabric

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

• Мохит Агарвал | Главный архитектор облачных решений

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

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

• Перенос данных в OneLake с помощью Lakehouse
• Создать склад Fabric
• Создание дома событий
• Анализ данных в реляционном хранилище данных
• Создание одной базы данных в базе данных SQL
• Создайте рабочую область Azure Databricks.
• Изучение баз данных Azure и служб аналитики
• Запрос Azure Cosmos DB с помощью API для NoSQL

Связанные ресурсы

• Руководство по принятию решений Fabric: выбор хранилища данных
• Запрос конечной точки аналитики SQL или хранилища в Microsoft Fabric
• Варианты технологий для решений Azure
• Нереляционные данные и NoSQL