Создание панели аналитики в реальном времени с использованием Azure Data Explorer

Введение

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

Azure Data Explorer (ADX) выступает в качестве ведущего решения, разработанного специально для этих требований. Он предлагает управляемые конвейеры приема, колоночное хранилище, оптимизированное для временных рядов и данных журнала, и мощный язык запросов Kusto (KQL) для преобразования необработанных событий в практические визуализации. Эта статья предоставляет практическое практическое руководство по созданию аналитической панели в реальном времени производственного уровня с использованием Azure Data Explorer и интеграции его с Power BI для интерактивной отчетности. Вы узнаете, как настроить кластер ADX, передавать данные из источников, таких как Event Hubs, писать эффективные запросы KQL, подключаться к Power BI и оптимизировать весь конвейер для обновлений с низкой задержкой.

Что такое Azure Data Explorer?

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

Ключевые функции, которые делают ADX идеальным для приборных панелей в реальном времени, включают:

ADX часто сравнивают с традиционными хранилищами данных, такими как Azure Synapse или Amazon Redshift, но он оптимизирован для высокой кардинальности (например, миллионы уникальных устройств) и , типичных для журналов и временных рядов. Для более глубокого понимания обратитесь к официальной документации Azure Data Explorer .

Создание окружающей среды

Создание кластера Azure Data Explorer

Для начала зайдите на портал Лазурного поля и создайте новый ресурс типа «Кластер Лазурного проводника данных». Выберите подписку, группу ресурсов и регион, который соответствует вашим источникам данных (желательно тот же регион, чтобы минимизировать задержку). Выберите вычислительный SKU на основе ожидаемой скорости приема и параллели запросов:

  • Dev/Test: Dev(Standard D13 v2) или Standard D14 v2 для небольших рабочих нагрузок.
  • Производство: Standard L8s v2, Standard L16s v2 или более новое семейство SKU с локальными твердотельными накопителями NVMe (например, Standard L8s v3) для высокой пропускной способности.
  • Высокая параллель: Кластеры с несколькими экземплярами, которые могут автоматически масштабироваться на основе процессора или нагрузки при приеме внутрь.

После развертывания кластера создайте базу данных внутри него. Используйте политики хранения и кэша по умолчанию изначально. Для панелей мониторинга в реальном времени вы можете установить политику кэша в течение нескольких дней (или недель), чтобы все последние данные подавались из памяти. Политика хранения должна быть достаточно долгой, чтобы покрыть ваши потребности в отчетности (например, 30-90 дней).

Конфигурация источников приема данных

Панели мониторинга в реальном времени зависят от потоковых данных. ADX поддерживает несколько подходов к приему пищи:

  • Event Hubs: Наиболее распространены для журналов и телеметрии. Создайте пространство имен Event Hubs и концентратор, затем настройте соединение данных в ADX, которое отображает события JSON или Avro на схему таблицы.
  • IoT Hub: Для устройств IoT IoT Hub обеспечивает аутентификацию устройства и маршрутизацию сообщений непосредственно в ADX.
  • Kafka: Используйте разъем ADX Kafka для приведения потоков из Apache Kafka или Confluent.
  • Blob Storage/Data Lake: Для пакетного или почти реального времени приема из файлов Parquet/CSV, хранящихся в Azure Blob или ADLS Gen2.

При настройке Event Hubs убедитесь, что количество разделов соответствует вашим потребностям пропускной способности. ADX может одновременно принимать данные из нескольких разделов. Для каждого соединения данных вы определите таблицу и картирование , которое преобразует поля JSON в столбцы ADX. Картирование также может обрабатывать преобразования типа данных (например, временные метки эпохи до даты).

Проглатывание данных в реальном времени

Создание таблиц и карт

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

.create table AppLogs (Timestamp: datetime, Level: string, Service: string, Message: string, CorrelationId: string)

Затем создайте картографию приема пищи для формата, который использует ваш источник потоковой передачи. Для JSON из Event Hubs команда:

.create table AppLogs ingestion json mapping 'AppLogsJsonMapping' '[{"column":"Timestamp","datatype":"datetime","properties":{"path":"$.timestamp"}},{"column":"Level","datatype":"string","properties":{"path":"$.level"}},{"column":"Service","datatype":"string","properties":{"path":"$.service"}},{"column":"Message","datatype":"string","properties":{"path":"$.message"}},{"column":"CorrelationId","datatype":"string","properties":{"path":"$.correlationId"}}]'

Эти карты показывают ADX, как извлекать поля из каждого события.

Настройка подключения Event Hubs

На портале Azure перейдите в базу данных ADX, выберите «Подключения к данным» и добавьте соединение «Концентраторы событий». Предоставьте пространство имен Event Hubs, имя концентратора, группу потребителей (используйте специальную группу потребителей для ADX, чтобы избежать конфликтов) и название таблицы. Укажите ссылку на отображение, которую вы создали. ADX автоматически начнет потреблять события и сделает их доступными для запросов в течение нескольких секунд.

Для сценариев с высокой пропускной способностью рассмотрите возможность использования потокового приема внутрь (включается в кластер) вместо пакетного приема. Потоковое потребление записывает данные непосредственно в колонкурные степени без промежуточной постановки, обеспечивая задержки менее 10 секунд. Для большинства приборных панелей в реальном времени это предпочтительный режим. Пакетное потребление (по умолчанию) собирает данные в течение нескольких минут до завершения степени, которая может ввести 2-5 минут задержки.

Язык запросов Kusto (KQL)

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

Фильтрация и агрегация

Подсчитывать события ошибок за услугу за последний час в одноминутных корзинах:

AppLogs
| where Timestamp > ago(1h)
| where Level == "Error"
| summarize ErrorCount = count() by Service, bin(Timestamp, 1m)
| order by Timestamp asc

Это возвращает временную серию, готовую к линейному графику.

Процентные расчеты

Для метрик задержки вам могут понадобиться P50, P95 и P99:

ServiceLatency
| where Timestamp > ago(30m)
| summarize P50 = percentile(LatencyMs, 50), P95 = percentile(LatencyMs, 95), P99 = percentile(LatencyMs, 99) by Service

Присоединяйтесь к справочным данным

Часто приборным панелям необходимо обогатить события статичными данными поиска (например, местоположениями устройств). ADX поддерживает легкие соединения. Например, присоединитесь к потоку телеметрии с таблицей устройств:

Telemetry
| where Timestamp > ago(15m)
| lookup Devices on DeviceId
| project Timestamp, DeviceId, Region, MetricValue

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

Функции серии времени

ADX включает в себя мощные операции временных рядов, такие как для обнаружения аномалий, для сезонности и для анализа частоты. Пример: обнаружение аномалий в подсчетах ошибок HTTP:

AppLogs
| where Timestamp > ago(2h)
| make-series ErrorCount = count() on Timestamp step 1m
| extend anomalies = series_decompose(ErrorCount, -1, 2.0, 'ok')
| mv-expand Timestamp, ErrorCount, anomalies
| where anomalies[2] < 0 or anomalies[2] > 0

Такие запросы продвинуты, но могут напрямую подавать предупреждающие панели.

Для получения полной справки см. документацию Kusto Query Language .

Строить панель управления Power BI

Подключение Power BI к ADX

Azure Data Explorer интегрируется с Power BI через разъем Azure Data Explorer (Kusto).

  1. Open Power BI Desktop, нажмите «Get Data» > «Больше...»
  2. Найдите «Azure Data Explorer» и выберите разъем.
  3. Введите свой URL-адрес кластера (например, ) и имя базы данных.
  4. Выберите между Import (данные втягиваются в Power BI и периодически обновляются) или DirectQuery (запросы отправляются в ADX при каждом взаимодействии). Для приборных панелей в реальном времени используйте DirectQuery. Это гарантирует, что каждый фильтр, нарезка и визуальный триггер запускают запрос KQL против последних данных.

KQL Queries в Power BI

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

AppLogs
| where Timestamp > ago(1h)
| summarize ErrorCount = count() by Service, bin(Timestamp, 1m)

После загрузки запроса используйте моделирование Power BI для определения мер, иерархий и отношений, если у вас есть несколько запросов. Избегайте загрузки полных журналов - как можно больше в KQL.

Настройка рефренов в реальном времени

В режиме DirectQuery визуальные эффекты автоматически запрашивают ADX при взаимодействии пользователей с отчетом (например, смене нарезки даты). Однако, чтобы сделать панель приборов автообновленной без взаимодействия с пользователем, вам необходимо установить функцию обновления автостраницы в службе Power BI:

  1. Опубликовать отчет в Рабочее пространство приложения с премиальной емкостью (или PPU).
  2. В настройках отчета в разделе «Запланированное обновление» установите интервал обновления DirectQuery — для приборных панелей в реальном времени используйте 1 или 2 минуты.
  3. В качестве альтернативы, используйте функцию автоматического обновления (предварительный просмотр), которая обновляет страницу с фиксированным интервалом (например, каждые 30 секунд).

Имейте в виду, что каждый автообновление будет выполнять все запросы KQL, лежащие в основе визуальных эффектов. Оптимизируйте ваши запросы, чтобы быстро вернуться (менее 5 секунд), чтобы избежать ожидания пользователя и чрезмерной нагрузки кластера.

Визуализация лучших практик

  • Используйте карточки визуальных эффектов для KPI (например, полные ошибки за последние 5 минут).
  • Линейные диаграммы для трендов временных рядов.
  • Барные диаграммы для разбивки поверх N (например, лучшие отказные службы).
  • Геопространственные карты, если у вас есть данные о местоположении.
  • Определяет , чтобы показать прогресс к пороговым значениям.

Поскольку DirectQuery отправляет запросы на каждое взаимодействие, избегайте использования пользовательских визуальных эффектов, которые генерируют много запросов.Кроме того, как можно раньше применяйте фильтры в KQL, чтобы уменьшить объем данных.

Оптимизация производительности для запросов в реальном времени

Кластеризация и индексная настройка

ADX автоматически создает и объединяет протяженности (осколок данных) с течением времени. Однако вы можете влиять на производительность:

  • Выбирая политику кластера , которая уравновешивает высокую пропускную способность при приеме внутрь с параллелизмом запросов. Для приборных панелей реального времени с множеством визуальных запросов, масштабируйте (добавьте экземпляры), а не масштабируйте.
  • Установка соответствующей политики кэша в базе данных или таблицах. Например, для сохранения последних 7 дней в горячем кэше:
  • Используя материализованные представления для предварительно агрегированных результатов, которые обновляются постепенно. Материализованный вид может вычислять почасовые или ежедневные резюме, которые затем мгновенно обслуживают панели инструментов высокого уровня.

Советы по оптимизации запросов

  • Фильтр ранний: Используйте пункты на столбце метки времени и размеры высокой сердечности для уменьшения отсканированных данных.
  • Минимизация присоединяется: Если возможно, денормализуйте данные во время приема внутрь, чтобы эталонные данные уже были встроены в события.
  • Избегайте в проектах: Явно перечислите необходимые столбцы для уменьшения пропускной способности и памяти.
  • Использовать для больших операций по распределению агрегации по узлам.
  • Ограничить результаты: Всегда используйте , или в запросах на разработку.В Power BI визуальные эффекты обычно имеют свои собственные фильтры top-N, но добавьте их и в KQL.

Мониторинг кластерного здоровья

Azure Data Explorer предоставляет встроенные диагностические журналы и метрики через Azure Monitor.

  • Задержка приема: Среднее время от создания события до его запроса.
  • Задержка запроса: Время выполнения P50 и P99.
  • Использование процессора и памяти: Если последовательно высокий, рассмотрите масштабирование.
  • Скорость приема: Убедитесь, что вы не дросселируете; разделите потоки на более разделы, если это необходимо.

Настройте оповещения в Azure Monitor для того, чтобы вы могли проактивно настраивать время ожидания запроса, превышающее пороговое значение (например, P99 > 10 секунд).

Оповещение и автоматизация в реальном времени

Панель мониторинга в реальном времени наиболее мощна в сочетании с автоматическими ответами. Azure Data Explorer предлагает несколько точек интеграции:

Azure Monitor от ADX

Вы можете создавать запланированные запросы в ADX, которые выполняются по расписанию (например, каждые 5 минут) и отправлять результаты в Azure Monitor. Затем определять правила оповещения, которые загораются при выполнении условий (например, количество ошибок > 100 в 5-минутном окне).

  • Отправка электронной почты или SMS через группы действий.
  • Приложения Azure Logic для запуска рабочих процессов (например, перезапуск службы, создание билета на инцидент).
  • Вызов веб-хуков для уведомления внешних систем.

Azure Logic Apps и Microsoft Power Automate

Используйте Logic Apps с разъемом «Execute Kusto Query» для получения данных из ADX, а затем примите меры. Например, если запрос обнаруживает всплеск использования процессора на виртуальных машинах, Logic App может запустить блок запуска Azure Automation для масштабирования VMSS. Это замыкает петлю между мониторингом и исправлением.

Потоковая аналитика и ADX как Sink

Для еще более низких оповещений о задержке маршрутизация потоковых данных через Azure Stream Analytics, которая может одновременно применять временные окна и продвигать события оповещения к ADX (для исторического анализа) и абоненту Event Hubs для немедленного оповещения.

Используйте примеры и примеры из реального мира

  • Панель мониторинга DevOps: Совокупные журналы, метрики и следы от микросервисов в кластерах Kubernetes. ADX глотает из Fluentd/Logstash Azure Event Hubs, а панель мониторинга Power BI показывает частоту запросов, ответы на ошибки и задержки хвоста.
  • Мониторинг флота IoT: Подключите IoT-хаб к ADX для телеметрии транспортных средств (местоположение, скорость, состояние батареи). Визуальная карта в реальном времени в обновлениях Power BI по мере поступления сообщений о транспортных средствах.
  • Обнаружение финансового мошенничества: Поток транзакций через Event Hubs в ADX. Панели мониторинга показывают объемы транзакций по регионам и баллы аномалий; предупреждения запускают блок-списки при нарушении порогов.
  • Анализ потоков кликов: Активность пользователей с веб-сайтов попадает в ADX. Панель приборов отслеживает активных пользователей, просмотры страниц в секунду и воронки конверсии, обновляемые каждую минуту.

Заключение

Создание панели аналитики в реальном времени с Azure Data Explorer и Power BI - это надежный, масштабируемый подход, который удовлетворяет растущий спрос на мгновенные идеи. Используя потоковое потребление ADX, мощные возможности серии времени KQL и соединения DirectQuery в Power BI, вы можете создавать панели инструментов, которые обновляются каждые несколько секунд и обрабатывают терабайты входящих данных. Ключ к успеху заключается в тщательном планировании емкости, продуманном дизайне запросов и постоянном мониторинге производительности.

Начните с малого с одного потока телеметрии, итерируйте запросы и постепенно расширяйтесь до большего количества источников данных. По мере роста потребностей вашей организации в реальном времени эластичность ADX гарантирует, что ваша панель приборов масштабируется без ущерба для скорости. Для получения дополнительной информации изучите руководство по приему внутрь ADX Event Hubs и Power BI to Azure Data Explorer документации разъема .