hudi iceberg - ghdrako/doc_snipets GitHub Wiki

Apache Hudi (Hadoop Upserts Deletes and Incrementals) is an open-source data lake framework that helps you manage large-scale data efficiently on top of distributed storage systems like HDFS, Amazon S3, Azure Blob Storage, or Google Cloud Storage.

It enables incremental data processing and provides features traditionally found in databases — such as upserts, deletes, and transactions — directly on your data lake.

Apache Hudi i Apache Iceberg mają ten sam cel:

Uczynić z data lake coś w rodzaju bazy danych — czyli dodać transakcyjność, wersjonowanie, upserty, time travel i spójność.
Bez nich, surowy S3/HDFS to tylko zbiór plików — a nie system danych.

Cecha	Apache Hudi	Apache Iceberg
🎯 Cel główny	Streaming + Incremental ingestion (real-time pipelines)	Batch analytics + dużej skali zapytania SQL
🧠 Architektura	Zarządza zarówno danymi, jak i zmianami (log + parquet)	Oddziela metadane od danych – czyste snapshoty
⚙️ Tryby przechowywania	Copy-on-Write (COW) i Merge-on-Read (MOR)	Snapshot-based (tylko „pełne wersje”)
🔁 Upserty / CDC	✅ Wbudowane wsparcie dla upsert/delete (idealne dla Kafki i CDC)	⚠️ Działa, ale nieco mniej wydajnie (trzeba przepisywać pliki)
⚡ Streaming (Flink/Spark)	Bardzo mocna integracja z Flink, Spark Structured Streaming	Wsparcie rośnie, ale dopiero się rozwija
🧾 Time travel / wersjonowanie	✅ Pełne	✅ Pełne
📊 Integracja z query engines	Hive, Spark, Flink, Presto, Trino, Athena	Spark, Flink, Trino, Snowflake, BigQuery, Athena, etc.
🧱 Metadane	Trzymane częściowo w .hoodie/ i w logach	Przechowywane w osobnym katalogu metadata/ z plikami manifestów
🔍 Performance przy czytaniu	Czasem wolniejsze (bo musi łączyć log + base files w MOR)	Bardzo szybkie – snapshot ma już gotową strukturę
🧰 Zastosowanie	ETL, streaming, incremental pipelines, CDC	Analytics, BI, data warehouse replacement
☁️ Adopcja	Uber, Amazon, Tencent, Alibaba, Bytedance	Netflix (twórca), Apple, Adobe, Airbnb, Snowflake

Apache Hudi:

👉 Myślisz w kategoriach ciągłego dopisywania i aktualizowania danych (np. dane z Kafki, upserty z bazy OLTP, eventy IoT)

Pipeline: Kafka → Spark/Flink → Hudi (S3) → Presto/Athena/Hive Kafka → Spark/Flink → Hudi (S3) → Presto/Athena/Hive

Piszesz często, czytasz często.
Chcesz aktualizować rekordy.
Hudi sam dba o to, które rekordy są aktualne.

Apache Iceberg:

👉 Myślisz w kategoriach czystych snapshotów tabel (np. duże wsady danych, raporty BI, batch analytics)

Pipeline:Spark/Flink → Iceberg (S3) → Trino/Snowflake/BigQuery

Rzadziej piszesz, ale za to chcesz szybkie zapytania analityczne.
Iceberg świetnie optymalizuje metadane i partycjonowanie.
Ma bardzo dobrą integrację z narzędziami BI (np. Snowflake, Dremio).

Jeśli chcesz...	Wybierz
Budować real-time pipeline (Kafka → S3)	🟢 Hudi
Robić CDC i upserty z baz relacyjnych	🟢 Hudi
Budować data lakehouse z dużymi wsadami danych	🟣 Iceberg
Skupić się na BI i analizie (np. z Trino/Snowflake)	🟣 Iceberg
Mieć minimalny narzut i prostą integrację	🟣 Iceberg
Mieć maksymalną elastyczność i streaming + batch w jednym	🟢 Hudi

Apache Hudi to w dużym skrócie warstwa zarządzania nad plikami Parquet, która:

kontroluje jak dane są zapisywane, aktualizowane i usuwane,
udostępnia interfejsy do odczytu, zapisu i przeglądania metadanych,
a wszystko to w sposób zgodny z narzędziami typu Spark, Flink, Presto, Hive czy Athena.

Zarządzanie plikami Parquet

Fizycznie dane nadal leżą jako pliki Parquet w S3 / HDFS / GCS.
Hudi tylko „nakłada” na nie logikę transakcji i wersjonowania.
Pliki Parquet nie są już surowe — są powiązane z metadanymi Hudi.

📂 Przykładowa struktura:

s3://my-bucket/hudi/users/
 ├── .hoodie/                     ← katalog z metadanymi i commit logami
 │    ├── commit_20251029_123456.json
 │    ├── timeline
 │    ├── schema
 │    └── auxiliary files
 ├── partition_date=2025-10-29/
 │    ├── 12345_20251029_123456.parquet
 │    └── 12345_20251029_123456.log.avro   ← dla Merge-on-Read

Zapis danych (Write path)

Hudi kontroluje zapisy poprzez własne API lub integrację ze Spark/Flink:

Możesz wykonać:

insert
upsert (insert lub update)
delete
bulk_insert

Każda operacja tworzy nowy commit (.hoodie/commit_*.json),który zapisuje:

listę zmodyfikowanych plików,
wersję schematu,
timestamp,
status transakcji.

🧩 To sprawia, że masz pełną historię wersji tabeli i możesz robić time travel (czyli np. zapytanie „pokaż dane z wczoraj”).

Odczyt danych (Read path)

Hudi udostępnia dane przez standardowe silniki, ale sam decyduje które pliki Parquet i logi Avro należy scalić, by pokazać najnowszą wersję rekordów.

Tryby odczytu:

Snapshot Query → pokazuje najnowszy stan tabeli.
Incremental Query → zwraca tylko dane od danego commita (np. „co się zmieniło od wczoraj”).
Read Optimized Query → czyta tylko Parquet (bez logów, szybciej, ale bez najnowszych zmian).

📘 W Spark możesz to zrobić tak:

df = spark.read.format("hudi") \
    .option("hoodie.datasource.query.type", "snapshot") \
    .load("s3://my-bucket/hudi/users/")

Metadane (Metadata management)

8 Hudi utrzymuje timeline — sekwencję commitów z metainformacjami:

Każdy commit zawiera:

ID i timestamp (instantTime)
Typ operacji (insert, upsert, compaction, rollback)
Pliki, które się zmieniły
Schemat tabeli (jeśli się zmienił)
Statystyki zapisów

Dzięki temu:

można robić time travel (as.of.instant = ...)
można szybko pobrać listę zmian (dla incremental ETL)
można zbudować metadane w Hive lub Glue Catalog automatycznie

5️⃣ Integracja z katalogami metadanych (Hive / Glue / AWS Athena)

Hudi potrafi automatycznie rejestrować tabele i partycje w:

Hive Metastore
AWS Glue Catalog
Databricks Unity Catalog (częściowo)

Dzięki temu Athena czy Presto widzą tabelę Hudi tak samo, jak zwykłą tabelę Hive:

SELECT * FROM users_hudi WHERE partition_date='2025-10-29';

Architektura Apache Hudi w GCP

   Pub/Sub / Cloud SQL / BigQuery Export
                 ↓
       Dataflow (Flink) / Dataproc (Spark)
                 ↓
         Apache Hudi (na GCS)
                 ↓
     BigQuery / Dataplex / Looker / Spark SQL

Komponent	Rola w GCP	Kompatybilność
Hudi on GCS	Warstwa danych (storage + metadane)	✅ Pełna
Dataproc (Spark)	ETL / batch processing	✅ Pełna
Dataflow (Flink)	Streaming / CDC	✅ Pełna
BigQuery / BigLake	Analityka	⚠️ Snapshot-level
Dataplex / Data Catalog	Zarządzanie metadanymi	✅ Możliwa integracja

Hudi dodaje warstwę:

metadanych (co się zmieniło, które pliki należą do której wersji danych)
zarządzania plikami (jak scalać i kompresować dane)
transakcji i wersjonowania (ACID commits, rollback, time travel)
interfejsu odczytu (snapshot, incremental, read-optimized)

Dzięki temu twój data lake zachowuje się jak baza danych – z możliwością upsertów, wersjonowania i odczytu z dowolnego momentu w czasie.

╔══════════════════════════════════════════════╗
║            Apache Hudi Logical Layer         ║
║  (zarządza metadanymi, transakcjami, wersjami) ║
╚══════════════════════════════════════════════╝
                 ↓
╔══════════════════════════════════════════════╗
║   Silniki obliczeniowe: Spark / Flink / Hive ║
╚══════════════════════════════════════════════╝
                 ↓
╔══════════════════════════════════════════════╗
║   Fizyczne przechowywanie: S3 / GCS / HDFS   ║
║   (pliki Parquet + metadane .hoodie)         ║
╚══════════════════════════════════════════════╝

Hudi dostarcza 3 kluczowe rzeczy

Warstwa danych (Data Layer)

Dane są zapisane w Parquet + Avro
Hudi dba o strukturę katalogów, partycje i pliki
Fizyczny storage to np. GCS, S3, HDFS

2️. Warstwa metadanych (Metadata Layer)

Przechowuje: Commit log (timeline) Schematy danych Indeksy rekordów (np. Bloom filters) Statystyki Zazwyczaj w katalogu .hoodie/

To pozwala Hudi rozumieć, co się dzieje z plikami, bez konieczności ich pełnego skanowania (czyli duża optymalizacja).

Warstwa dostępu (Access Layer)

Ujednolicony interfejs dla:
- Spark SQL (.format("hudi"))
- Flink SQL (CREATE TABLE ... WITH ('connector' = 'hudi'))
- Presto, Trino, Hive, Athena (czytają snapshot)