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

  • Статья

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

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

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

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

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

Эти варианты предоставляют разные модели баз данных, оптимизированные для разных типов задач.

  • В базах данных для пар "ключ-значение" хранится один сериализованный объект для каждого значения ключа. Они хорошо подходят для хранения больших объемов данных, которые нужно извлекать по одному элементу с известным значением ключа, если при этом совершенно не требуются запросы по другим свойствам элемента.
  • Базы данных документов, по сути, являются базами данных для пар "ключ-значение", в которых значениями являются документы. Под документами здесь подразумеваются любые коллекции именованных полей и значений. Обычно в таких базах данные хранятся в специальных форматах, например XML, YAML, BSON и (или) JSON. Но можно использовать и обычный текст. Базы данных документов позволяют применять запросы по полям, не являющимся ключами, а также определять дополнительные индексы для повышения эффективности таких запросов. Благодаря этому базы данных документов больше подходят для приложений, в которых нужно извлекать данные по более сложным критериям, чем одиночное значение ключа документа. Например, вы можете создать запрос по идентификаторам продуктов, идентификаторам клиентов или именам клиентов.
  • Базы данных хранилища столбцов — это хранилища данных key/value, которые хранят каждый столбец отдельно на диске. База данных хранилища столбцов — это тип базы данных хранилища столбцов , в которой хранятся семейства столбцов, а не только отдельные столбцы. Например, в базе данных переписи может быть семейство столбцов для имени человека (первого, среднего, последнего), семьи для адреса человека и семьи для сведений профиля человека (дата рождения, пол). База данных может хранить каждое семейство столбцов в отдельном разделе, сохраняя все данные для одного человека, связанного с одним ключом. Тогда приложение сможет считывать одно семейство столбцов отдельно от остальных данных для одной и той же сущности.
  • В базе данных графов сведения хранятся в виде коллекции объектов и отношений. База данных графов позволяет эффективно выполнять запросы в сети объектов и связей между ними. Например, в базе данных персонала объектами могут являться сотрудники и вам может потребоваться выполнить такой запрос, как "найти всех сотрудников, которые прямо или косвенно подчиняются Сергею".
  • Базы данных телеметрии и временных рядов — это коллекция объектов, которая доступна только для добавления. Базы данных телеметрии эффективно индексируют данные в различных хранилищах столбцов и структурах в памяти, что делает их оптимальным выбором для хранения и анализа огромных количеств данных телеметрии и временных рядов.

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

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

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

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

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

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

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

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

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

Возможность База данных SQL Пул Azure Synapse SQL Пул Azure Synapse Spark Обозреватель данных Azure HBase/Phoenix в HDInsight Hive LLAP в HDInsight Azure Analysis Services Azure Cosmos DB
Является управляемой службой Да Да Да Да Да 1 Да 1 Да Да
Модель базы данных-источника Реляционный (формат хранилища столбцов при использовании индексов columnstore) Реляционные таблицы с хранилищем столбцов Хранилище широких столбцов Реляционное хранилище (хранилище столбцов) данных телеметрии и временных рядов Хранилище широких столбцов Hive (с выполнением в памяти) Табличные семантические модели Хранилище документов, граф, хранилище пар "ключ-значение", хранилище широких столбцов
Поддержка языка SQL Да Да Да Да Да (с помощью драйвера Phoenix JDBC) Да Нет Да
Оптимизация для уровня быстрого обслуживания Да 2 Да 3 Да Да Да Да Нет Да

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

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

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

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

Возможность База данных SQL Пул Azure Synapse SQL Пул Azure Synapse Spark Обозреватель данных Azure HBase/Phoenix в HDInsight Hive LLAP в HDInsight Azure Analysis Services Azure Cosmos DB
Избыточные региональные серверы для высокого уровня доступности Да No No Да Да Нет Да Да
Поддерживает горизонтальное масштабирование запросов No Да Да Да Да Да Да Да
Динамическая масштабируемость (увеличение масштаба) Да Да Да Да No No Да Да
Выполняющееся в памяти кэширование данных Да Да Да Да Нет Да Да No

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

Возможность База данных SQL Azure Synapse Обозреватель данных Azure HBase/Phoenix в HDInsight Hive LLAP в HDInsight Azure Analysis Services Azure Cosmos DB
Проверка подлинности SQL / Идентификатор Microsoft Entra SQL / Идентификатор Microsoft Entra Microsoft Entra ID local / Microsoft Entra ID 1 local / Microsoft Entra ID 1 Microsoft Entra ID пользователи базы данных / Идентификатор Microsoft Entra с помощью управления доступом (IAM)
Шифрование неактивных данных Да 2 Да 2 Да Да 1 Да 1 Да Да
Безопасность на уровне строк Да Да 3 Да Да 1 Да 1 Да No
Поддержка брандмауэров Да Да Да Да 4 Да 4 Да Да
Динамическое маскирование данных Да Да Да Да 1 Да No No

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

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

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

[4] При использовании в виртуальной сети Azure. См. статью Расширение возможностей HDInsight с помощью виртуальной сети Azure.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Автор субъекта:

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