Индексная подсистема

В Уроке 02 мы видели, что и COW, и MOR начинают upsert с index lookup — определения, в каком FileGroup находится каждая запись. Этот шаг критичен: без индекса Hudi пришлось бы сканировать все base files во всех партициях для поиска каждой записи.

Hudi предлагает 6 типов индексов, включая новую систему secondary indexes в версии 1.0. Выбор индекса — одно из ключевых архитектурных решений при проектировании таблицы: он определяет скорость записи, потребление памяти, и поведение при upsert.

Зачем нужен индекс: проблема tagging

При upsert Hudi должен пометить (tag) каждую входящую запись: INSERT (новая) или UPDATE (существующая). Для UPDATE нужно знать конкретный FileGroup, чтобы записать данные в правильный файл:

Без индекса tagging потребует full table scan — чтение всех base files для поиска каждого record key. При таблице с 1B записей (1000 FileGroup × 1M записей) это 1000 Parquet-файлов на каждый upsert. Индекс сводит это к O(1) или O(log N) lookup.

Bloom Filter Index

Bloom Filter Index — индекс по умолчанию в Hudi. Использует Bloom filter, встроенный в footer каждого Parquet base file:

Характеристики Bloom Filter Index

# False Positive Probability (по умолчанию 0.000000001 — очень низкая)
hoodie.bloom.index.filter.type=DYNAMIC
hoodie.bloom.index.filter.dynamic.max.entries=100000
# Использовать min/max record key для доп. pruning
hoodie.bloom.index.use.metadata=true
# Параллелизм lookup
hoodie.bloom.index.parallelism=0

Simple Index

Simple Index — brute-force подход: читает все record keys из всех base files в нужных партициях и делает join с входящим батчем:

Когда Simple Index лучше Bloom

Simple Index выигрывает в двух сценариях:

1. Очень маленькие партиции (< 10 файлов): overhead Bloom pruning не окупается
2. High update ratio (> 50% записей — обновления): Bloom даёт много кандидатов, и приходится всё равно читать ключи

hoodie.index.type=SIMPLE

HFile Record Index

HFile Record Index использует HFile (формат HBase) для хранения маппинга record_key → FileGroup. Это точный индекс без false positives и без full scan:

Record-Level Index (Hudi 1.0)

Hudi 1.0 представил Record-Level Index — эволюцию HFile Record Index, хранимую в metadata table:

# Включить Record-Level Index (Hudi 1.0+)
hoodie.metadata.record.index.enable=true
hoodie.index.type=RECORD_INDEX

Bucket Index

Bucket Index — hash-based индекс, который распределяет записи по FileGroup на основе хэша record key:

Характеристики Bucket Index

hoodie.index.type=BUCKET
hoodie.bucket.index.num.buckets=256
hoodie.bucket.index.hash.field=record_key

Consistent Hashing Bucket (Hudi 1.0)

Hudi 1.0 добавил consistent hashing вариант bucket index, который поддерживает динамическое масштабирование — добавление и удаление bucket’ов без полной пересортировки:

hoodie.index.type=BUCKET
hoodie.index.bucket.engine=CONSISTENT_HASHING
hoodie.bucket.index.max.num.buckets=512
hoodie.bucket.index.min.num.buckets=32

Secondary Indexes (Hudi 1.0)

Hudi 1.0 представил систему secondary indexes — индексов по произвольным колонкам (не только record key). Это read-side оптимизация, в отличие от primary index (write-side):

Expression Indexes (Hudi 1.0)

Expression Index — подвид secondary index, где индексируется выражение над колонками, а не сами колонки:

-- Создание secondary index (Hudi 1.0+)
CREATE INDEX idx_status ON orders USING secondary_index(status);

-- Expression index
CREATE INDEX idx_event_month ON events USING expression_index(month(event_date));

-- Column stats index
CREATE INDEX idx_amount_stats ON orders USING column_stats(amount);

Гайд по выбору индекса

Сравнительная таблица индексов

Индекс и глобальная уникальность

По умолчанию Hudi-индекс — partition-scoped: он ищет record key только внутри одной партиции. Это значит, что одинаковый record key может существовать в разных партициях:

Когда нужен Global Index

Пример: таблица orders партиционирована по status (pending, processing, shipped). При обновлении заказа order_id=123 статус меняется с pending → shipped. С partition-scoped индексом:

• Hudi ищет order_id=123 в партиции shipped (целевой)
• Не находит (запись в pending)
• Считает INSERT → создаёт дубликат

С global индексом Hudi найдёт запись в pending и выполнит cross-partition update: удалит из pending, вставит в shipped.

# Включить global index
hoodie.index.type=GLOBAL_BLOOM
# или
hoodie.index.type=GLOBAL_SIMPLE
# Record Index в Hudi 1.0 — глобальный по умолчанию
hoodie.metadata.record.index.enable=true

Сравнение с Delta Lake и Iceberg

Итоги

• Index lookup (tagging) — обязательный шаг перед каждым upsert: определяет INSERT vs UPDATE и целевой FileGroup
• Bloom Filter Index (default): вероятностный, footer-based, достаточен для < 10M записей
• Simple Index: brute-force чтение ключей, без false positives, для маленьких партиций
• HFile Record Index: точный lookup через sorted key-value HFile, block cache
• Bucket Index: O(1) hash-based lookup, фиксированное N (или dynamic с consistent hashing в 1.0)
• Record-Level Index (Hudi 1.0): HFile в metadata table, автоматическое обслуживание, до 4x быстрее Bloom — рекомендуемый для production
• Secondary Indexes (1.0): read-side индексы по произвольным колонкам, expression indexes, column stats
• Global vs partition-scoped: global нужен только при миграции записей между партициями
• Рекомендуемая комбинация для Hudi 1.0: Record Index (write) + Column Stats (read) + Expression Index (custom predicates)

В следующем уроке мы разберём контроль конкурентности — как Hudi обеспечивает ACID при нескольких writer’ах, и что изменил NBCC-протокол в версии 1.0.