Apache Hudi¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Область версий: Apache Hudi 1.0.2; Spark/Flink bundle должен соответствовать движку. Проверка источников: 2026-11-02.

1. Архитектура и модель данных¶

FACT. Lake table management связывает record keys, timeline commits и file groups. Copy-on-Write и Merge-on-Read — альтернативы обслуживания updates, а не разные уровни object durability. Baseline1.0.2 требует совместимого Spark/Flink bundle.

flowchart LR
  Writer --> Index[Record key index]
  Index --> Files[Base files or log files]
  Files --> Timeline[Completed timeline commit]
  Timeline --> Reader[Snapshot or read-optimized]
  Files --> Service[Compaction and cleaning]

2. Физическое хранение и путь записи¶

COW переписывает base files при updates; MOR пишет изменения в log files, compaction объединяет с base. Timeline содержит состояния requested/inflight/completed и metadata для согласованного чтения. Cleaning, compaction и clustering — разные services; нельзя чистить inflight inputs без safety horizon.

Источники механизма: документация 1.

3. Индексы и путь чтения¶

Index mapping record key→file group позволяет locating updates, а metadata table ускоряет listings/statistics в поддерживаемой конфигурации. Global/non-global index меняет uniqueness scope и стоимость. Record key и partition path определяют судьбу update при изменении partition; это не SQL unique constraint.

Источники механизма: документация 5.

4. Транзакции и consistency guarantees¶

Snapshot reader объединяет нужные committed base/log данные; read-optimized MOR может не видеть последние log updates. Incremental query имеет contract по timeline, не универсальный domain-event log. Concurrency mode и locks задаются явно; многопроцессный writer не становится безопасным от одного наличия S3.

Источники механизма: документация 1, документация 2.

5. Репликация, partitioning и sharding¶

Partition layout/file groups управляют данными, а distributed writers — engine. В 1.0.2 доступны разные concurrency schemes с ограничениями; основной пример использует single writer. Для OCC multiple writers нужен подходящий shared lock provider и согласование table services. Более новые/experimental modes не предполагаются автоматически.

Источники механизма: документация 2.

6. Конкурентная запись и конфликты¶

Record merger/order field определяет выбор competing versions; event time, source sequence и arrival time дают разные бизнес-результаты. Tie должен разрешаться детерминированно. Дубли внутри batch и между commits требуют согласованной key/index/merge policy. Precombine setting нельзя интерпретировать как вечную exactly-once гарантию.

Источники механизма: документация 4.

7. Отказы и восстановление¶

Rollback/restore timeline и failed-write cleanup восстанавливают допустимое состояние в рамках сохранённых files. Cleaner retention должен покрывать long readers и incremental consumption; compaction crash требует штатного recovery timeline, не ручного удаления случайных files. Backup включает timeline, metadata table и referenced data.

Источники механизма: документация 3.

8. Масштабирование и ограничения¶

Количество file groups, small files, index lookups и table-service backlog определяют scaling. MOR переносит стоимость с ingest на snapshot read/compaction; COW делает больше rewrite на write. Partition skew перегружает отдельные tasks и file groups.

9. Performance trade-offs¶

Для частых updates MOR может уменьшить immediate rewrite, увеличив read amplification и compaction obligation. Read-optimized дешевле, но свежее состояние может отсутствовать. COW упрощает read path ценой writes. Реальная стоимость зависит от update ratio, file size, retention и engine.

10. Мониторинг и эксплуатация¶

Мониторить commit duration/errors, inflight age, rollback/cleaner/compaction backlog, file sizes, index cost и timeline length. Проверять supported reader query type, incremental checkpoint age и availability lock provider. Table service успех не доказывает полноту business changes.

11. Сценарии FinTech и iGaming¶

INFERENCE. Upsert-heavy payment/betting analytical history, provider corrections и incremental downstream datasets. Нужны сохранённые source versions и reconciliation, чтобы late stale row не заменила settlement correction. Формат не реализует monetary invariant между несколькими счетами.

12. Когда не выбирать¶

Не выбирать без готовности управлять compaction/cleaning/concurrency. Read-optimized MOR не подходит читателю, которому обязательно нужны ещё не compacted updates. Не считать Hudi record key достаточным для глобальной uniqueness при любом index type.

13. Вопросы на собеседовании¶

Почему MOR читатели расходятся по freshness? Snapshot объединяет logs, read-optimized может читать только base.

Compaction и clustering одинаковы? Нет: объединение logs/base и изменение layout решают разные задачи.

Precombine решает все конфликты? Нет, нужна правильная merge/index/concurrency policy и deterministic ordering.

14. Практические SQL/config примеры¶

{"hoodie.table.name":"betting_events","hoodie.datasource.write.table.type":"COPY_ON_WRITE","hoodie.datasource.write.recordkey.field":"event_id","hoodie.datasource.write.partitionpath.field":"event_day","hoodie.datasource.write.precombine.field":"event_version","hoodie.record.merge.mode":"EVENT_TIME_ORDERING","hoodie.write.concurrency.mode":"single_writer"}

Writer options1.0.2; input schema обязана содержать перечисленные поля, merger semantics проверяют отдельно. JSON syntax проверен, Hudi runtime отсутствует. Практика: сравнить COW и MOR для late correction и long incremental reader.

15. Дополнительные источники¶

Типичные ошибки проектирования¶

Смешивать commit, видимость projection и backup; приписывать формату функции query engine; игнорировать версии и cleanup horizon. Product-specific ошибки и безопасные альтернативы разобраны в разделах 4–9.

Практические упражнения¶

Составьте журнал одной записи: какие файлы/metadata появляются до публикации, что увидит reader при сбое и какой cleanup безопасен. Затем предложите restore drill с проверкой итоговой полноты, включая поздние исправления.