Архитектура корпоративной платформы данных содержит множество потенциальных точек отказа: проблема может возникнуть при получении данных из источника, во время их обработки и загрузки, на уровне инфраструктуры или BI.
Техническая доступность DWH еще не означает, что все работает корректно. Данные могут загружаться с задержкой или не в полном объеме, процессы выполняться дольше обычного, а производительность системы постепенно снижаться.
Поэтому при эксплуатации DWH используют инструменты мониторинга и логирования, которые позволяют контролировать состояние компонентов платформы, своевременно выявлять сбои и быстро определять их причины.
В первой части материала про мониторинг DWH разберем, что именно необходимо контролировать на каждом уровне DWH и какие сигналы помогают своевременно обнаружить проблемы.
Основные понятия Observability хранилища
Observability (наблюдаемость) — это подход, который позволяет по данным о работе системы понимать ее текущее состояние и находить причины возникающих проблем.
Для обеспечения наблюдаемости используются три основных типа телеметрии: метрики, логи и трассировки.
Мониторинг — это процесс непрерывного сбора и анализа метрик, которые характеризуют состояние системы. Для DWH мониторинг позволяет обнаруживать проблемы с инфраструктурой и процессами обработки данных до того, как они отразятся на работе аналитиков и бизнес-пользователей.
Логирование — процесс формирования логов — фиксации событий, происходящих внутри приложений, сервисов и компонентов. Существует несколько типов логов:
Application logs — фиксируют события приложений;
System logs — содержат события операционной системы и инфраструктуры;
Audit logs — фиксируют действия пользователей и сервисов и позволяют определить, кто, когда и какие операции выполнял;
Security logs — содержат события, связанные с безопасностью системы, например попытки авторизации или нарушения политик доступа.
Трассировка (трейсинг) — это метод отслеживания пути запроса через все компоненты и функции системы.
Классическая трассировка ориентирована прежде всего на микросервисные системы. В DWH процессы асинхронные, могут выполняться часами и связываться через ETL/ELT, брокеры сообщений или таблицы.
Поэтому вместо стандартной трассировки в DWH чаще используются механизмы:
Сквозной run_id – единый идентификатор запуска, который передается в логи, метрики и другие компоненты и позволяет восстановить историю конкретной загрузки.
Data Lineage – показывает зависимости между источниками, таблицами и витринами и помогает определить, какие объекты затронул сбой. Для сбора lineage-событий может использоваться OpenLineage, а для их анализа – DataHub или OpenMetadata.
Архитектура системы мониторинга DWH
Мониторинг DWH устроен следующим образом:
Приложения и инфраструктурные сервисы генерируют метрики, логи и трассировки.
Экспортеры и агенты собирают эту информацию, после чего она передается в централизованные системы хранения и анализа.
Поверх них работают визуализация, алертинг и инструменты диагностики.
Уровни мониторинга корпоративного хранилища
В DWH нет одной точки отказа, ошибка может возникнуть практически на любом участке data pipeline, поэтому важно контролировать состояние каждого компонента хранилища.
Инфраструктура
На уровне серверной инфраструктуры обычно контролируются:
CPU — загрузка процессора;
RAM — использование оперативной памяти;
Disk — свободное дисковое пространство, скорость операций чтения и записи;
Network — сетевой трафик, пропускная способность и задержки;
Latency — время выполнения операций или ответа сервиса;
доступность серверов и отдельных узлов кластера.
Что алертить: симптом или причину
На одном из DWH-проектов для крупного ритейлера мы столкнулись с ситуацией, когда система мониторинга прислала алерт о заполнении дисков кластера Greenplum на 90%. Объем занятого пространства продолжал расти до 95% и создавал риск остановки кластера. От получения алерта до подключения команды поддержки прошло около 30 минут.
Диагностика показала, что проблема была не в росте объема данных. Во время плановой перезагрузки сети primary и mirror сегменты Greenplum поменялись ролями, после чего один из primary сегментов стал недоступен. Mirror сегменты начали накапливать WAL-логи, которые быстро заполнили дисковое пространство. Таким образом, мониторинг дискового пространства сработал, но обнаружил уже следствие инцидента, а не его первопричину.
После инцидента специалисты Qlever Solutions углубили мониторинг дискового пространства Greenplum и добавили кастомные проверки, позволяющие выявлять подобные сбои раньше. Повторных проблем такого типа с тех пор не наблюдалось.
Этот пример показывает важный принцип проектирования мониторинга: для критичных компонентов недостаточно контролировать только последствия деградации — заполнение дисков, рост очередей или увеличение времени ответа.
Необходимо также отслеживать состояние компонентов, сбой которых может привести к этим последствиям: доступность узлов, состояние репликации и работу ключевых сервисов СУБД.
Так система мониторинга позволяет не только раньше обнаружить инцидент, но и быстрее локализовать его причину.
ETL/ELT и оркестрация
Для ETL/ELT-процессов отслеживаются:
статус выполнения пайплайнов и отдельных задач;
продолжительность выполнения;
количество ошибок и повторных запусков;
объем обработанных данных;
время последней успешной загрузки;
соблюдение расписания и заданных временных окон;
отклонение продолжительности выполнения от обычных значений.
Отдельно необходимо контролировать состояние оркестратора: работу планировщика (scheduler), исполнителей (workers), очереди задач и доступность его основных компонентов.
Обычно оркестраторы, такие как Apache Airflow, предоставляют встроенные механизмы логирования задач, сбора метрик, проверки состояния компонентов и уведомления об ошибках.
Кроме Airflow тот же набор задач решают Dagster (встроенное понятие ассета со сроком свежести), Prefect, Windmill, а для трансформаций - dbt, который после каждого запуска пишет артефакты run_results.json и manifest.json.
Как получить метрики оркестратора
Airflow отдает внутренние метрики по протоколу StatsD, чтобы они попали в Prometheus, между ними ставят statsd_exporter. Начиная с версии 2.7 Airflow умеет отправлять метрики через OpenTelemetry, что убирает лишнее звено, если в контуре уже есть OTel Collector.
Группы метрик, которые мы отслеживаем на проектах для контроля работы Airflow:
Состояние Scheduler — например, airflow_scheduler_heartbeat (жив ли планировщик), airflow_scheduler_scheduler_loop_duration (длительность scheduler loop), airflow_zombies_killed (убитые zombie tasks).
Executor и очереди — airflow_executor_open_slots (свободные слоты Executor), airflow_executor_queued_tasks (задачи в очереди Executor), airflow_pool_starving_tasks (задачи, ожидающие Pool).
DAG Run — airflow_dagrun_schedule_delay (задержка запуска относительно расписания), airflow_dagrun_duration_success (длительность успешного DAG Run), airflow_dagrun_duration_failed (длительность неуспешного DAG Run).
Task Instance — airflow_ti_successes и airflow_ti_failures (успешные и неуспешные Task Instance), airflow_task_duration (длительность выполнения task), airflow_task_queued_duration (время task в очереди).
Обработка DAG-файлов — airflow_dag_processing_* (метрики процесса обработки DAG-файлов), airflow_dag_file_processor_timeouts (таймауты обработки DAG-файлов), airflow_dagbag_size (размер DAG Bag).
Ресурсы задач — airflow_task_cpu_usage_percent (использование CPU task в процентах), airflow_task_memory_usage_percent (использование памяти task в процентах).
Качество данных (Data Quality)
Для мониторинга качества данных используются специализированные инструменты Data Quality. В зависимости от требований к конкретному набору данных могут контролироваться:
полнота (completeness) — наличие всех необходимых данных;
уникальность (uniqueness) — отсутствие недопустимых дубликатов, в том числе ключей;
валидность (validity) — соответствие значений установленным форматам, типам и допустимым диапазонам;
целостность (integrity) — корректность связей между данными, в том числе ссылочная целостность;
свежесть(freshness) — своевременность обновления данных;
количество записей и объем поступивших данных;
доля NULL в критичных полях;
соответствие установленным бизнес-правилам.
В DWH мониторинг качества данных особенно важен, так как влияет непосредственно на качество аналитику и работу пользователей. Например, если таблица ежедневно получает около 2 млн записей, а при очередной загрузке поступило только 150 тыс., ETL-пайплайн может технически завершиться успешно. Однако резкое изменение объема данных должно быть зафиксировано, отправлено в систему мониторинга и стать поводом для проверки источника и процесса загрузки.
Чем проверять качество данных
1. Проверки внутри пайплайна - срабатывают на каждой загрузке и умеют останавливать ее при провале.
dbt tests — если трансформации уже написаны на dbt, базовые проверки (unique, not_null, accepted_values, relationships) не требуют нового инструмента; пакеты dbt-utils и dbt-expectations расширяют набор;
Great Expectations — библиотека на Python с декларативным описанием ожиданий и автогенерацией отчетов, гибкая, но требует отдельной инфраструктуры и времени на освоение;
Soda Core — проверки описываются на YAML-подобном SodaCL, порог входа ниже.
2. Мониторинг качества и аномалий данных - дополняет проверки, выполняемые непосредственно в пайплайне. Анализирует состояние и изменение наборов данных, позволяет обнаруживать отклонения, которые сложно заранее описать фиксированными правилами.
Elementary — решение для Data Observability, тесно интегрированное с dbt. Использует результаты dbt-запусков и метаданные хранилища для мониторинга качества данных, freshness, объемов и других характеристик, а также обнаружения аномалий относительно исторического поведения данных.
Специализированные платформы Data Observability, например Monte Carlo, Datafold и Anomalo, решают более широкий набор задач мониторинга состояния данных и обнаружения аномалий и не требуют использования dbt как основы всего контура наблюдаемости.
3. Каталог и Data Lineage
DataHub и OpenMetadata хранят описания таблиц, владельцев и граф зависимостей. Для качества данных это нужно, чтобы у каждой проверки был ответственный, а у каждого инцидента — список пострадавших витрин.
Результаты проверок качества данных можно передавать в Prometheus и отображать вместе с техническими метриками в Grafana, чтобы у команды был единый интерфейс мониторинга. Для более детального анализа качества данных можно использовать собственный интерфейс Elementary - Observability Report.
BI и пользовательские запросы
На этом уровне отслеживаются доступность и производительность аналитических приложений:
время выполнения запросов, загрузки отчетов и дашбордов;
ошибки выполнения запросов и обновления отчетов;
нагрузка на BI-серверы;
доступность подключений к источникам данных;
частота и успешность обновления наборов данных;
время последнего успешного обновления;
использование вычислительных ресурсов BI-платформы;
количество одновременных пользователей и запросов.
Таким образом, мониторинг DWH охватывает несколько уровней: инфраструктуру, ETL/ELT-процессы, качество данных и взаимодействие с системами-потребителями.
Как собирать метрики и объединить их в единый контур мониторинга?
Во второй части материала о мониторинге DWH рассмотрим конкретные инструменты: Prometheus, Grafana, Zabbix, ELK Stack, OpenSearch, Loki. Расскажем про подходы к выбору стека для мониторинга DWH.
