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

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

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

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

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

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

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

• Ткань
• Azure Synapse Analytics
• пулы Spark Azure Synapse Analytics
• Azure Databricks
• Обозреватель данных Azure
• База данных SQL Azure
• SQL Server на виртуальной машине Azure;
• Apache HBase и Apache Phoenix в Azure HDInsight
• Аналитическая обработка с низкой задержкой (LLAP) Apache Hive в Azure HDInsight
• Azure Analysis Services;
• Azure Cosmos DB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Собираются ли данные временных рядов? Вы используете данные, которые можно только добавлять?

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

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

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

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

[1] Настройка и масштабирование вручную.

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

[3] Поддерживается в качестве выходных данных Azure Stream Analytics.

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

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

[1] Требуется использовать присоединенный к домену кластер HDInsight.

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

[3] Только фильтрация предикатов. Дополнительные сведения см. в разделе "Безопасность на уровне строк".

[4] При использовании в виртуальной сети Azure. Дополнительные сведения см. в статье "Расширение HDInsight" с помощью виртуальной сети Azure.

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

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

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

• Варианты технологий для решений Azure
• Анализ операционных данных в MongoDB Atlas с помощью Azure Synapse Analytics
• Нереляционные данные и NoSQL