Метрики Doris: что измерять и как интерпретировать
Метрики выступают опорой для принятия решений в управлении Doris: они позволяют понять текущее состояние кластера, выявлять узкие места и прогнозировать проблемы до их влияния на бизнес-процессы. В рамках этой главы рассмотрены ключевые показатели архитектуры Doris, выполнения запросов, использования ресурсов и хранения данных, а также практики сбора, визуализации и реагирования на сигналы мониторинга. Особое внимание уделено тому, как трактовать сигналы метрик в контексте OLAP- workload и как выстроить циклы улучшения на основе конкретных чисел.
Метрики Doris состоят из нескольких уровней: архитектурные характеристики FE и BE, показатели выполнения запросов, состояние памяти и CPU, параметры хранения данных и показатели загрузки/инрегистрации изменений. Эффективная работа требует согласования этих слоёв: одни сигналы сигнализируют о проблемах с планированием или обработкой запроса, другие - о насыщении памяти, дискового ввода-вывода или недостатке емкости хранилища. В этой главе даются принципы выбора сигнатур для алертинга, методы интерпретации распределённых сигналов и практические подходы к коррекции конфигураций и архитектурных решений.
- Краткое содержание главы
- Архитектура метрик Doris: FE и BE, структура сбора и экспозиции
- Метрики выполнения запросов: латентности, сквозной пропускной способности и распределение задержек
- Ресурсы и память: использование CPU, памяти, кэширования и сборка мусора
- Хранение данных и загрузка: размер сегментов, компрессия, компакция и прогресс загрузок
- Инструменты мониторинга и практика интерпретации: Prometheus, Grafana, пороги и сценарии реагирования
Архитектура метрик Doris: FE и BE, структура сбора и экспозиции
Doris реализует встроенный механизм мониторинга, который охватывает основные компоненты кластера: Frontend (FE) и Backend (BE). FE обычно отвечает за управление конфигурацией, планирование запросов и маршрутизацию, BE - за выполнение сканов, агрегаций и доступа к данным на уровне хранения. Метрики собираются в рамках модулей каждого компонента и публикуются через интерфейсы, совместимые с Prometheus. Такой подход обеспечивает единый источник данных для горизонтально масштабируемого мониторинга и облегчает построение кросс-узловых панелей.
Ключевые концепции метрик в Doris включают:
- типы метрик: счетчики (counters), показатели состояния (gauges) и распределения задержек (histograms/summary);
- уровни агрегации: локальные метрики FE и BE, кластерные агрегаты, а также метрики на уровне запросов;
- методы экспозиции: HTTP-эндпоинты на FE и BE, совместимые с форматом Prometheus, позволящие интегрировать Doris в существующую экосистему мониторинга.
В рамках архитектуры важно понимать, какие сигналы относятся к FE и какие - к BE, и как они дополняют друг друга. FE-мониторинг чаще фокусируется на очередях планирования, времени обработки конфигураций и статистике запросов, тогда как BE-мониторинг концентрируется на выполнении сканов, обработке аггрегаций, обмене данными между узлами и использованию регионов хранения. Совокупность сигналов позволяет оценить влияние узкого звена, будь то задержки планирования на FE, перегрузка вычислительных узлов BE или проблемы в обмене данными между компонентами кластера.
Чтобы интерпретировать архитектурные сигналы корректно, следует учитывать:
- корреляцию между нагрузкой FE и временем планирования: растущие очереди и высокая планировочная задержка часто предшествуют ухудшению времени выполнения;
- связь между количеством активных BE и пропускной способностью кластера: рост числа запросов без соответствующей балансировки часто приводит к перегрузке конкретных узлов;
- влияние сетевых задержек: задержки передачи данных между FE и BE, а также между BE-узлами, существенно отражаются на общей латентности запросов.
Примечание: конкретные имена метрик и их маршруты зависят от версии Doris и конфигурации, поэтому ориентируйтесь на документацию вашей сборки и используйте единый каталог метрик в вашей Grafana-даше.
Метрики выполнения запросов: латентности, сквозной пропускной способности и распределение задержек
Ключ к пониманию производительности OLAP-покрытий - это детальная трактовка задержек по всему конвейеру запроса: от момента подачи запроса FE до выдачи результатов BE, включая планирование, сканирование столбцовых сегментов и агрегацию. В Doris широко применяются распределённые гистограммы задержек и метрики пропускной способности, что позволяет не только фиксировать средние значения, но и видеть пиковые нагрузки и вариации.
Основные метрики выполнения запросов включают:
- latency_p50, latency_p95, latency_p99: медианная, 95-й и 99-й перцентили задержки выполнения запроса; полезно для оценки пользовательского опыта и устойчивости к неожиданным пикам;
- qps (queries per second) и ритм поступления запросов: позволяют оценивать нагрузку и способность кластера обрабатывать пиковые волны;
- время планирования (planning_time_ms) и время выполнения (execution_time_ms): раздельная оценка предобработки и фактического вычисления;
- задержка в очереди на FE (enqueue_time или queue_time): сигнал о перегрузке таблиц планирования;
- количество операций ввода-вывода на стадии сканирования: чтение столбцовых данных, распаковка и декодирование словарей (dictionary decoding);
- дистрибуция времени на этапы конвейера: чтение данных, фильтрация, агрегация, сортировка, объединение;
- пропускная способность по объему обработанных строк/байтов (rows_per_sec, bytes_per_sec): полезна для диагностики узких мест в сканировании или агрегации;
- процент пропусков и ошибок на уровне выполнения (failed_queries и error_rate): сигнал об аномалиях во входных данных или конфигурации.
Интерпретация этих сигналов требует учета контекста конкретной задачи. Например:
- стабильный latency_p50 и рост latency_p95/p99 может указывать на рост конкуренции за ресурсы на BE или на ухудшение сетевого канала;
- рост qps без пропорционального роста latency может означать эффективную масштабируемость, но при сохранении разумного среднего времени отклика; резкое падение qps вместе с ростом latency - признак перегрузки или ограничений ввода-вывода;
- увеличение planning_time_ms при сохраненииExecution_time может говорить о сложности оптимизации плана, неупрощённости выполнения или неэффективной статистике колонок/диплоемких фильтров.
Детальная трактовка требует распределённых диаграмм и корреляций: например, сравнение latency по конкретной таблице/partitions, связь задержек с размером данных и количеством сканируемых строк, анализ влияния Bloom-фильтров и словарей на задержки фильтрации. Практика показывает, что полезно строить корреляционные панели: latency по типам запросов (AGG, JOIN, FILTER), latency по размеру набора данных, latency в зависимости от времени суток, а также зависимость между latency и использованием кешей.
Важно помнить: единичная метрика редко бывает достаточной. Комплексная картина строится через сочетание: latency, throughput, планирование и стадийность обработки, а также состояние кэширования и перекомпоновки данных.
Ресурсы и память: использование CPU, памяти, кэширования и сборка мусора
Управление ресурсами лежит в основе устойчивой производительности Doris. Метрики памяти и CPU позволяют оценить, как эффективно распределяются вычислительные ресурсы между FE и BE, и какие резервы остаются для пиковых нагрузок. В контексте Doris особое внимание уделяется не только текущему потреблению, но и динамике и прогнозированию.
К важным показателям относятся:
- использование CPU на FE и BE (cpu_usage, cpu_user_time, cpu_system_time): сигнализирует о насыщенности процессорами вычислительных узлов;
- потребление памяти (memory_used_bytes, heap_used_bytes для FE, native_memory_used_bytes для BE): критично на пике загрузки, особенно при больших объединённых агрегациях и многопользовательской параллельной обработке;
- сборка мусора (gc_time_ms, gc_count) на FE (если FE реализован на JVM): длительные паузы GC негативно влияют на задержку и предсказуемость отклика;
- кеши и их Hit/Miss ratios (dictionary_cache_hit_ratio, column_cache_hit_rate): указывают на эффективность использования словарного кэша и кэширования колонн, влияющих на скорость сканирования;
- использование OS-кеш-памяти (page_cache_hit_rate) и диск I/O задержки (read_iops, write_iops, io_wait_time_ms): важны для оценки влияния диска и операционной системы на производительность;
- количество активных потоков и заполненность пула задач (thread_pool_active_threads, queue_size): горизонтальная масштабируемость исполнения запросов.
Эти сигналы полезно рассматривать в связке:
- рост memory_used_bytes без пропорционального роста qps может указывать на утечки памяти, мемори-рост для некоторых рабочих наборов или неэффективное использование кешей;
- увеличение gc_time_ms при стабильной нагрузке или росте latency на FE говорит о необходимости настройки памяти JVM, размера Heap или частоты сборки мусора;
- снижение dictionary_cache_hit_ratio в сочетании с ростом latency может свидетельствовать о неэффективном кэшировании и необходимости адаптировать словари, размер словарей или политику кэширования.
Практика допускает настройку пределов и оповещений по базовым порогам, но важнее - связь порогов с рабочими сценариями. Например, в migratory workloads, где данные регулярно сдвигаются между сегментами, словари и кэш часто перестраиваются, и сигналы кэширования должны учитывать сезонность и типы запросов.
Важно помнить: сборка мусора и память — это не только техническая проблема, но и вопрос архитектурной конфигурации: размер JVM-heap, параметры GC, размер пула потоков, стратегия кэширования и принципы параллелизма должны подгоняться под конкретные типы нагрузок и данные.
Хранение данных и загрузка: размер сегментов, компрессия, компакция и прогресс загрузок
Хранение и загрузка данных в Doris напрямую связаны с эффективностью и стабильностью OLAP- workloads. Метрики хранения позволяют оценить эффективность компрессии, распределение данных по сегментам и динамику загрузок. Они также отражают качество балансировки данных между BE-узлами и состояние реплик.
Ключевые показатели в этой области включают:
- число сегментов/таблетов и их размер (segment_count, tablet_count, segment_size_bytes, compressed_size_bytes, uncompressed_size_bytes): позволяют оценить фрагментацию и загрузку диска;
- процент компрессии (compression_ratio): влияет на I/O и скорость сканирования; низкая компрессия может означать избыточный объем чтения;
- показатели компакции (compaction_pending_tasks, compaction_running, compaction_time_ms): сигналы о работе по оптимизации хранения; задержки в компакции приводят к неэффективной загрузке и перераспределению ресурсов;
- загрузочные сигналы (load_jobs_in_progress, rows_loaded_per_second, bytes_loaded_per_second): контроль прогресса загрузки данных, особенно при массовом накачивании данных;
- Health-метрики сегментов/таблетов (tablet_health, segment_health, replica_health): индикаторы доступности и целостности, включая задержки репликации и возможные ошибки чтения;
- кэширование на уровне сегментов (column_cache_hit_rate per segment) и Bloom-фильтры: указывают на эффективность фильтрации и снижают расход диска.
Интерпретация: если сегменты становятся слишком маленькими или состояний "множества сегментов" слишком велико, это может привести к оверхеду на управления и перераспределению данных. Низкая компрессия может сигнализировать о неэффективном кодировании данных, возможно, необходимо пересматривать схему колонок, типы данных или порядок столбцов. Прогрессы загрузки должны соответствовать SLAs по времени загрузки; задержки в загрузке могут указывать на перегрузку BE, узкие места в сети или проблемы с источником данных.
Компакция данных - важная часть эксплуатации: её задержки влияют на скорость сканирования и пропускную способность. Графики времени компакции и количество задач дают понятие о том, как часто данные сдвигаются в более эффективные структуры и как быстро система вернется к высокой производительности после изменения нагрузки.
При проектировании схемы хранения полезно поддерживать видимость по сегментам и репликам на каждом BE: сколько сегментов активны, как распределены данные, какая доля реплик доступна, и какие сегменты помечены как устаревшие или подлежащие удалению. Это способствует быстрому принятию решений по балансировке и переносу данных.
Инструменты мониторинга и практика интерпретации: Prometheus, Grafana, пороги и сценарии реагирования
Эффективная работа требует систематического подхода к сбору, визуализации и реагированию на сигналы. В Doris широко применяются open-source инструменты мониторинга, такие как Prometheus для сбора метрик и Grafana для визуализации. Важна не только настройка дашбордов, но и формирование рекомендаций по алертам и процессам реагирования.
Ключевые практики:
- стандартизированные дашборды FE и BE: ставки по latency, qps, memory, CPU, I/O, а также сигналы по конкретным таблицам/базам данных;
- базовые пороги и уровни алертинга: сигналы должны отличать «мезо-уровни» от критических событий; рекомендуется разделять алерты по функциональности (производительность, доступность, целостность);
- baseline и трендовая аналитика: хранение исторических данных и настройка порогов на основе долгосрочных трендов;
- корреляция сигналов: интрактивные панели для анализа взаимосвязей между latency, memory usage и IO; корреляция FE и BE-метрик позволяет оперативно идентифицировать узкие места;
- управление изменениями: внедрение изменений в конфигурацию, запуск тестов на стенде и мониторинг эффектов перед развёртыванием в продуктиве;
- политики capacity planning: прогнозирование растущей нагрузки и планирование масштабирования кластера; использование метрик загрузки, хранения и компакции для оценки потребности в новых нодах.
Типичные сценарии интерпретации:
- «медленная выдача» для типовых запросов: анализ latency_p95/p99 в сочетании с planning_time_ms и execution_time_ms; подозрение на неэффективный план или нехватку памяти при обработке больших агрегаций;
- «пиковая загрузка» в вечернее окно: рост qps и concurrent_queries, сопровождающийся увеличением IO и задержек; решение - масштабирование кластера или балансировка нагрузки;
- «падение компрессии» и рост reading_errors: переосмысление схемы хранения, изменение типов данных, пересмотр установки фильтров и Bloom-метрик;
- «постоянная нагрузка на FE» с высоким planning_time: оптимизация статистики, обновление сидов, подсветка необходимости увеличения кэшей планирования;
- «память растет» на BE: анализ операционной памяти, распределения памяти между запросами, возможная необходимость перераспределения пула или изменения размера cache.
Практическим итогом является создание набора согласованных процедур: какие метрики мониторить в течение суток, какие панели использовать для диагностики и какие корректирующие действия предпринять в зависимости от сигналов. Встроенная архитектура Doris облегчает внедрение таких практик благодаря тесной связке метрик FE и BE и возможности проводить cross-node анализ.
Key takeaways
- Метрики Doris охватывают архитектуру FE/BE, выполнение запросов, ресурсы и хранение; их совместная интерпретация необходима для точной диагностики.
- Для выполнения запросов критичны распределения задержек (p50/p95/p99), throughput и стадийность конвейера; они позволяют выявлять узкие места в планировании, сканировании или агрегации.
- Управление памятью и CPU требует анализа использования памяти, сборки мусора на FE и эффективности кэшей; сигналы должны трактоваться в контексте рабочих нагрузок.
- Метрики хранения и загрузки помогают понять компрессию, распределение сегментов и прогресс загрузок; неэффективность в этих сигналах часто связана с конфигурацией схемы хранения.
- Эффективный мониторинг строится на Prometheus/Grafana: цель - иметь базовые пороги, базовую корреляцию сигналов и понятные сценарии реагирования.
- Алерты должны соответствовать бизнес-целям и рабочим задачам; важно различать сигналы о краткосрочной аномалии и долгосрочных трендах.
- Построение процесса Capacity Planning и постоянное сравнение текущего состояния с baseline позволяют заранее предупреждать перегрузки и планировать масштабирование.
FAQ
- Какие метрики считаются наиболее критичными для OLAP- workload в Doris?
- Ключевые показатели - latency_p50/p95/p99 по типам запросов, qps, planning_time_ms и execution_time_ms, использование памяти и CPU, а также показатели IO и диск-активности. Дополнительно полезны метрики сегментов, количества таблетов и прогресс загрузок, чтобы увидеть влияние хранения на производительность.
- Как интерпретировать задержки p50, p95 и p99?
- p50 отражает среднюю задержку для типичных запросов; p95 и p99 показывают, как ведут себя крайние случаи. Резкое увеличение p95/p99 при стабильном p50 считается признаком появления дисбаланса ресурсов или изменений в рабочем наборе данных.
- Что делать, если метрика памяти постоянно растёт?
- Проверить распределение памяти между FE и BE, обратить внимание на GC-профили FE, кеш dictionary и column cache. Рассмотреть увеличение размера Heap, настройку пулов памяти, переспределение рабочих потоков или пересмотр схемы хранения и фильтров.
- Как понять, что узел перегружен из-за загрузки сети или диска?
- Анализируйте IO-параметры (read_iops/write_iops, io_wait_time_ms), сетевые показатели (network_throughput) и связку с latency. При перегрузке диска - рассмотреть балансировку данных, перераспределение сегментов и увеличение числа BE-узлов.
- Какие метрики указывают на проблемы с компрессией данных?
- Compression ratio, compressed_size_bytes vs uncompressed_size_bytes, и показатели производительности чтения из столбцов. Низкая компрессия может свидетельствовать о неэффективной кодировке или изменении типа данных.
- Как на практике настраивают алерты для Doris?
- Рекомендуется строить пороги на основе baseline и бизнес-целей: latency по p95/p99, memory usage, IO-подпорты, и прогресс загрузок. Важно иметь сигналы по FE и BE отдельно и кросс-узловую корреляцию для идентификации источника проблемы.
- Какие ограничения в мониторинге стоит учитывать?
- Взаимодействие между различными уровнями метрик может усложнить трактовку; необходима совместная визуализация FE/BE сигналы и контекст рабочей нагрузки. Также следует учитывать сезонность и характер загрузки: пиковые окна требуют адаптивной политики масштабирования.
- Как связать метрики Doris с другими инструментами в экосистеме?
- Doris поддерживает экспозицию метрик через форматы Prometheus; можно использовать Grafana для построения панелей, основанных на именованных сигналах FE/BE. Важно придерживаться единого стандарта именования метрик и согласованных источников данных.
- Какие примеры практической реакции на сигналы мониторинга можно привести?
- При росте latency/p95 оказать давление на планирование и перераспределение ресурсов, увеличить количество BE-узлов или изменить partitioning/partition pruning. При снижении компрессии - провести перерасчёт схемы хранения, поменять типы данных или порядок столбцов. При задержках загрузки - ускорить пайплайн загрузок, проверить источники данных и балансировку, чтобы минимизировать время простоя.
