Share via

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

  • Статья

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

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

Примечание

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

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

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

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

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

Рекомендации по проектированию схемы таблиц

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

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

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

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

Примечание

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

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

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

Примечание

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

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

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

Использование модели "ведущий — ведомый"

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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