Оптимизация для высокого уровня параллелизма с Azure Data Explorer

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

К вариантам использования относятся крупномасштабные панели мониторинга и оповещения. Примерами являются продукты и службы Майкрософт, такие как Azure Monitor и Playfab. Все эти службы используют Azure Data Explorer для обслуживания рабочих нагрузок с высокой степенью параллелизма. Azure Data Explorer — это быстрая и полностью управляемая служба для аналитики больших данных, позволяющая в реальном времени анализировать большой объем данных, поступающих из приложений, а также с веб-сайтов, устройств Интернета вещей и т. д.

Примечание.

Фактическое число запросов, которые могут выполняться одновременно в кластере, зависит от таких факторов, как номер SKU кластера, объем данных, сложность запросов и шаблоны использования.

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

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

Оптимизация данных

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

Используйте лучшие практики проектирования схем таблиц

Чтобы сократить использование ресурсов ЦП, прибегните к приведенным ниже рекомендациям по проектированию схемы таблиц.

  • Определите столбцы идентификаторов как строковые типы данных, даже если значения являются числовыми. Индексирование строковых столбцов является более сложным, чем для числовых столбцов и обеспечивает лучшую производительность фильтрации.
  • Подбирайте оптимальные типы данных в соответствии с фактическими данными, хранящимися в столбцах. Например, не храните значения даты и времени в строковом столбце.
  • Старайтесь не использовать большие разреженные таблицы с множеством столбцов и применяйте динамические столбцы для хранения разреженных свойств.
  • Храните часто используемые свойства в собственном столбце с нединамическим типом данных.
  • Выполняйте денормализацию данных, чтобы избежать объединений, требующих довольно много ресурсов ЦП.

Секционирование данных

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

Примечание.

Сам процесс секционирования также потребляет ресурсы ЦП. Однако сокращение загрузки ЦП во время выполнения запроса обычно перевешивает потребление ресурсов ЦП в целях секционирования.

Предварительное агрегирование данных с помощью материализованных представлений

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

Примечание.

Фоновый процесс агрегирования потребляет ресурсы ЦП. Однако сокращение загрузки ЦП во время выполнения запроса обычно перевешивает потребление ресурсов ЦП в целях агрегирования.

Настройка политики кэширования

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

Установите архитектурный шаблон "ведущий — ведомый"

Следящая база данных — это функция, позволяющая базе данных или набору таблиц подписываться на другую базу данных в кластере, расположенном в том же регионе. Вы можете получить доступ к этой функции с помощью Azure Data Share, API Azure Resource Manager и набора команд кластера.

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

Примечание.

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

Чтобы повысить производительность запросов в ведомом кластере, можно включить конфигурацию с предварительной выборкой экстентов . Используйте такую конфигурацию с осторожностью, так как она может повлиять на актуальность данных в базе данных-подписчике.

Оптимизация запросов

Используйте описанные ниже методы, чтобы оптимизировать запросы для высокой степени параллелизма.

Следуйте рекомендациям по запросам, чтобы обеспечить максимальную эффективность запросов.

Использование кэша результатов запроса

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

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

Настройка согласованности запросов

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

В приложениях с высокой параллелизмой управление запросами может привести к высокой загрузке ЦП узла администратора , а другие узлы менее заняты. Эта ситуация может привести к узким местам, где число одновременных запросов не может расти. Однако это узкое место может не отображаться в отчете ЦП кластера (портал Azure > {your_cluster} > Метрики > ЦП), который показывает среднее использование ЦП кластера.

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

Задайте режим согласованности в политике согласованности запросов группы рабочей нагрузки, в свойствах запроса клиента или в конфигурации источника данных Grafana.

Настройка политик кластера

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

Мониторинг кластеров Azure Data Explorer

Отслеживание работоспособности ресурсов кластера помогает создать план оптимизации с применением возможностей, описанных в предыдущих разделах. Azure Monitor для Azure Data Explorer дает полное представление о производительности, операциях, использовании и сбоях кластера. Чтобы получить полезные сведения о производительности запросов, параллельных запросах, регулируемых запросах и других метрики, выберите вкладку Аналитика (предварительная версия) в разделе Мониторинг кластера Azure Data Explorer на портале Azure.

Сведения о мониторинге кластеров см. в статье Azure Monitor для Azure Data Explorer.

  • Last updated on