Кэш метаданных

Кратко Когда Apache Doris выполняет запросы к Hive, Iceberg, Hudi или Paimon, большая часть общего времени может уходить на получение списков партиций, разбор манифестов и обращения к Hive Metastore. Кэш метаданных Apache Doris хранит всё это: схемы, значения партиций, списки файлов, записи манифестов Iceberg, снимки Paimon. Время хранения в кэшах ограничено TTL (по умолчанию: 24 часа для списков имён, 8 часов для партиций и файлов). Кэши могут обновляться по событиям Hive Metastore с задержкой в несколько секунд, а их содержимое можно явно сбросить с помощью REFRESH CATALOG. Для Iceberg и Paimon инвалидация учитывает особенности формата, поэтому неизменяемые манифесты остаются в кэше, пока на них существуют ссылки.

Зачем использовать кэш метаданных Apache Doris?

Кэш метаданных Apache Doris сокращает время планирования запросов к lakehouse с секунд до миллисекунд, устраняя повторные обращения к HMS, операции LIST в S3/HDFS и чтение манифестов Iceberg, на которые иначе приходится основная часть общего времени. При планировании запросов к lakehouse основное время занимает работа с метаданными, а не с данными. Для запроса к партиционированной таблице Hive необходимо:

• Обратиться к Hive Metastore за списком баз данных, списком таблиц, схемой столбцов и списком партиций.
• Выполнить операцию LIST в S3 или HDFS для каждого пути партиции, оставшейся после фильтрации, чтобы найти файлы данных.
• Для Iceberg прочитать metadata.json, затем список манифестов, затем N файлов манифестов (по одному удалённому чтению на каждый).
• Для Hudi получить временную шкалу, построить FileSystemView и определить, какие срезы файлов видимы на момент запроса.

Для Catalog с непрогретым кэшем и 10K партиций планирование может занимать больше времени, чем выполнение запроса. Типичные примеры:

• Дашборд с фильтрацией по дате каждую минуту заставляет планировщик заново запрашивать партиции, перегружая HMS вплоть до отказа.
• Для таблицы Iceberg с 30 манифестами каждый запрос требует 30 операций S3 GET для получения метаданных манифестов в дополнение к чтению данных.
• После развёртывания запускается новый FE, и первые запросы тратят секунды на getPartitionsByNames.

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

Что такое кэш метаданных Apache Doris?

Кэш метаданных Apache Doris хранит в памяти FE все сведения, которые может предоставить внешний Catalog, за исключением самих байтов файлов. Для каждого источника (Hive, Iceberg, Hudi, Paimon, JDBC) используется собственная реализация общего механизма, поэтому принципы работы для пользователя едины: TTL для каждого кэша, ограничение размера каждого кэша и небольшой набор операций обновления.

Основные термины

• Schema cache: списки столбцов, типы и идентификаторы таблиц. Ключ включает идентификатор таблицы и (для Iceberg/Paimon) ID схемы.
• Partition cache: список партиций таблицы Hive или Hudi, включая значения партиций и их расположение.
• File cache (FE-side): список файлов и основные метаданные файлов для пути партиции, полученные операцией LIST в S3/HDFS. Отличается от кэша данных на стороне BE.
• Manifest cache: разобранные записи манифестов Iceberg (списки файлов данных и файлов удаления для манифеста). Ограничен числом записей, а не TTL.
• HMS event listener: клиент, который опрашивает Hive Metastore, получает события уведомлений и по мере их поступления сбрасывает затронутые записи.

Как работает кэш метаданных Apache Doris?

Каждый запрос Apache Doris обращается к кэшу перед выполнением внешних RPC: поиск, вытеснение по TTL, вытеснение по размеру, инвалидация с учётом формата, опрос событий HMS и явный REFRESH вместе обеспечивают хранение часто используемых метаданных в памяти и удаление устаревших записей.

1. Поиск. Когда планировщику нужны схема, партиции или файлы таблицы, сначала проверяется кэш с помощью загрузчика на базе Caffeine. При промахе данные запрашиваются из исходного Catalog (вызов HMS по Thrift, чтение метаданных Iceberg, сканирование временной шкалы Hudi), а результат сохраняется в кэше.
2. Вытеснение по TTL. Каждый модуль кэша имеет собственный TTL. В версиях после 3.0.7 таймер сбрасывается при каждом обращении, поэтому часто используемая таблица остаётся в кэше, пока к ней выполняются запросы. По умолчанию заданы консервативные значения: TTL списков имён составляет 24 часа с обновлением каждые 10 минут, а TTL кэшей партиций и файлов составляет 8 часов.
3. Вытеснение по размеру. Кэши используют LRU с ограничением размера (max_external_schema_cache_num, max_external_file_cache_num и т. д.), поэтому множество редко используемых таблиц не может навсегда вытеснить часто используемые.
4. Инвалидация с учётом формата. Ключом записей кэша манифестов Iceberg служит путь манифеста, а TTL для них не задан: после разбора манифест остаётся корректным, пока на него ссылается хотя бы один снимок. Paimon кэширует ссылку на последний снимок и перезагружает её только при переходе таблицы к новому состоянию. Hive такой возможности не предоставляет, поэтому этот пробел восполняют события HMS.
5. Обновление по событиям HMS. Если включён enable_hms_events_incremental_sync, FE опрашивает журнал уведомлений Hive Metastore с интервалом hms_events_polling_interval_ms и последовательно применяет события CREATE / ALTER / DROP / INSERT. Затронутые записи сбрасываются в течение нескольких секунд без полной очистки кэша.
6. Явное обновление. REFRESH CATALOG, REFRESH DATABASE и REFRESH TABLE позволяют принудительно обновить кэш после записи в обход HMS (прямой загрузки файлов, коммитов Iceberg извне Apache Doris), а также используются при тестировании.

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

Быстрый старт

-- Inspect cache state.
SELECT * FROM information_schema.catalog_meta_cache_statistics
WHERE catalog_name = 'hive_ctl';

-- Refresh just the table whose partition you just added.
REFRESH TABLE hive_ctl.sales.orders;

-- For a fast-changing fact table, disable the file listing cache.
ALTER CATALOG hive_ctl SET PROPERTIES (
  "meta.cache.hive.file.ttl-second" = "0"
);

-- For seconds-level auto-refresh on Hive, turn on the HMS event listener
-- (FE config; restart required):
--   enable_hms_events_incremental_sync = true
--   hms_events_polling_interval_ms = 10000

Ожидаемый результат

+--------------+-------------+-----------+---------+----------+
| catalog_name | cache_name  | hit_count | miss_count | size  |
+--------------+-------------+-----------+---------+----------+
| hive_ctl     | schema      |     12480 |       7 |       42 |
| hive_ctl     | partition   |      9821 |      14 |       28 |
| hive_ctl     | file        |      9520 |      31 |      612 |
+--------------+-------------+-----------+---------+----------+

После прогрева доля попаданий в кэши схем и партиций превышает 99%. Промахи связаны с первым обращением к новым таблицам или с истечением срока хранения записей.

Когда следует использовать кэш метаданных Apache Doris?

Кэш метаданных Apache Doris включён по умолчанию для каждого внешнего Catalog. На практике нужно определить, как настроить его под конкретную нагрузку и в каких случаях полностью отключить.

Подходит

• Таблицы Hive со стабильными схемами и умеренной частотой записи. Используйте TTL по умолчанию вместе с обработчиком событий HMS, чтобы поддерживать актуальность с задержкой в несколько секунд.
• Таблицы Iceberg, Paimon и Hudi любого размера. Неизменяемость снимков позволяет хранить записи манифестов в кэше неограниченно долго; сбрасывать нужно только указатель на текущий снимок, что Apache Doris делает при каждом запросе.
• Многопользовательский lakehouse с тысячами Catalog и таблиц. Кэши схем и партиций обеспечивают быстрое планирование, даже когда множество редко используемых объектов не помещается в память: часто используемые остаются, а редко используемые вытесняются.
• Дашборды с большим числом одновременных запросов. Без кэша каждый параллельный запрос заново получал бы список тех же партиций; с кэшем список формируется один раз и используется совместно.

Не подходит

• Таблицы Hive, в которые данные записываются в обход HMS (hadoop fs -put, прямая загрузка в S3). HMS не видит изменений, поэтому обработчик событий их не обнаружит. Либо выполняйте запись через HMS, либо установите TTL кэша файлов равным 0, либо вызывайте REFRESH TABLE после каждого пакета данных.
• Таблицы, которые изменяются каждые несколько секунд и требуют строгой актуальности данных. Кэш на основе TTL для этого не подходит. Отключите соответствующий модуль кэша (ttl-second = 0) для такой таблицы или примите задержку обновления до N секунд при использовании обработчика событий.
• Catalog с миллионами таблиц при ограниченном объёме памяти. Слишком большое значение max_external_schema_cache_num, при котором кэш не помещается в кучу FE, может привести к OOM. Подберите подходящий лимит и следите за catalog_meta_cache_statistics.
• Работа с Iceberg как с Hive. Ежеминутный запуск REFRESH CATALOG для Iceberg удаляет полностью корректные записи неизменяемых манифестов. Положитесь на модель снимков и позвольте кэшу выполнять свою работу.

Дополнительные материалы

• Справочник по кэшу метаданных: TTL, ограничения размера и стратегии обновления для каждого модуля.
• Оператор REFRESH: синтаксис SQL для REFRESH CATALOG, REFRESH DATABASE и REFRESH TABLE, а также свойство invalid_cache.
• Catalog Hive: свойства meta.cache.* для отдельных кэшей и настройка обработчика событий HMS (enable_hms_events_incremental_sync).
• Catalog Iceberg: настройка кэша манифестов и инвалидация с учётом снимков.
• Кэш данных и кэш страниц: кэши хранения на уровне байтов, расположенные под кэшем метаданных.
• Оптимизация чтения Parquet: механизмы эффективного чтения файлов после того, как метаданные определили, какие файлы нужны.
• Создание lakehouse нового поколения (блог Apache Doris): обзор архитектуры, знакомящий с Meta Cache и обработчиком событий HMS.
• Iceberg: Catalog, для которого кэширование списка манифестов и метаданных снимков даёт наибольший выигрыш при работе с удалёнными объектными хранилищами.