Open Table Formats Crash Course 
Delta Lake 
Iceberg
A modern lakehouse architektúra alapja nem csak a fájlformátum — hanem a táblaformátum. Ebben a kurzusban megnézzük a három legfontosabb nyílt forráskódú táblaformátumot: Delta Lake, Apache Iceberg és Apache Hudi.
WebShop Pro kontextus: A webshopunk rendelési adatait tároljuk data lake-ben. Parquet fájlokként elég bajos megoldani az ACID tranzakciókat, a séma változásokat és a time travel-t. A táblaformátumok pontosan ezeket a problémákat oldják meg.
Table format fogalom 📖 · Ryan Murray - Table Formats Explained 🎬
Table vs file format · Delta Lake vs Iceberg vs Hudi · Schema & partition evolution · ACID · Catalog · Vendor lock-in · Teljesítmény · Döntési útmutató
WebShop Pro rendelési adatok táblaformátum-összehasonlítása
Table format vs file format 
Parquet
A fájlformátum (Parquet, ORC, Avro) meghatározza, hogyan tárolódnak az adatok egyetlen fájlon belül — oszloposan, sorosan vagy keverten. A táblaformátum (Delta, Iceberg, Hudi) ezen felül egy logikai réteget biztosít, amely több fájl felett garantálja az adatok konzisztenciáját és kezelhetőségét.
Gondolj rá így: a fájlformátum az építőkocka, a táblaformátum pedig az építész. Egy Parquet fájl önmagában nem tudja garantálni, hogy két párhuzamos írás nem rontja el egymást, vagy hogy vissza lehessen állni egy korábbi állapotra. A táblaformátum pontosan ezeket a problémákat oldja meg:
- ACID tranzakciókat több fájl felett — az írás atomi: vagy teljesen megtörténik, vagy egyáltalán nem
- Séma verziózást és evolúciót — oszlopot adhatsz hozzá, nevezel át vagy módosítasz anélkül, hogy a meglévő adatokat újra kellene írni
- Time travel-t — a tábla korábbi állapotának lekérdezése, rollback lehetősége hibás írás esetén
- Concurrent write kezelést — optimista konkurencia-vezérlés (OCC) biztosítja, hogy két processz ne írja felül egymás módosításait
WebShop Pro: Ha a rendelési adatokat sima Parquet-ként tárolod, egy félresikerült ETL futás adatait manuálisan kell helyreállítani. Delta Lake vagy Iceberg használatával egyetlen RESTORE paranccsal visszaállhatsz a hiba előtti állapotra.
| Réteg | Példa | Funkció |
|---|---|---|
| Nyers tároló | S3, ADLS, GCS, MinIO | Object storage |
| Fájlformátum | Parquet, ORC, Avro, JSON | Oszlopos/soros tárolás egy fájlon belül |
| Táblaformátum | Delta Lake, Iceberg, Hudi | ACID, séma, time travel, több fájl felett |
| Catalog | Unity Catalog, Nessie, Glue | Névtér, jogosultság, felderítés |
# Pure Parquet: no ACID, no schema enforcement
# Ha két processz egyszerre ír, adatvesztés lehet
df.write.parquet("s3://webshop/orders/")
# Delta Lake: transaction log garantálja a konzisztenciát
df.write.format("delta").save("s3://webshop/orders-delta/")Parquet → azonnali írás, nincs tranzakció Delta → _delta_log/ mappa létrejön, ACID garantált
Delta Lake alapok Delta Lake 
Spark
A Delta Lake a Databricks nyílt forráskódú projektje. Parquet fájlokra épít, és egy _delta_log/ mappában tartja a tranzakciós naplót JSON formátumban.
WebShop Pro: Rendelési adatokat Delta táblába töltünk, így ACID tranzakcióval garantálható, hogy egyETL futás sem marad félkész.
from delta import DeltaTable
from pyspark.sql import SparkSession
spark = SparkSession.builder \
.appName("WebShop-Delta") \
.config("spark.jars.packages", "io.delta:delta-core_2.12:3.1.0") \
.getOrCreate()
# WebShop rendelések DataFrame
orders = spark.createDataFrame([
(1, "keyboard", 15000, "2024-01-15"),
(2, "monitor", 89000, "2024-01-15"),
(3, "mouse", 5500, "2024-01-16"),
], ["order_id", "product", "amount_ft", "date"])
# Mentés Delta formátumba
orders.write.format("delta").mode("overwrite").save("./data/webshop_orders")
# Time travel: előző verzió lekérdezése
dt = DeltaTable.forPath(spark, "./data/webshop_orders")
spark.read.format("delta").option("versionAsOf", 0).load("./data/webshop_orders").show()+--------+--------+----------+----+ |order_id| product|amount_ft|date| +--------+--------+----------+----+ | 1|keyboard| 15000|2024| | 2| monitor| 89000|2024| | 3| mouse| 5500|2024| +--------+--------+----------+----+
Apache Iceberg alapok Iceberg
Az Apache Iceberg a Netflix belső projektjeként indult, ma az egyik legdinamikusabban fejlődő táblaformátum. Fő erőssége a multi-engine támogatás: Spark, Flink, Trino, Presto, Dremio mind natívan olvassák.
Kulcskülönbség: Az Iceberg rejtett particionálást (hidden partitioning) használ — nem kell manuálisan particionáló oszlopot létrehozni.
from pyspark.sql import SparkSession
spark = SparkSession.builder \
.config("spark.sql.extensions", "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions") \
.config("spark.sql.catalog.webshop", "org.apache.iceberg.spark.SparkCatalog") \
.config("spark.sql.catalog.webshop.type", "hadoop") \
.config("spark.sql.catalog.webshop.warehouse", "./warehouse") \
.getOrCreate()
# Iceberg tábla létrehozása
spark.sql("""
CREATE TABLE webshop.orders (
order_id BIGINT,
product STRING,
amount_ft INT,
order_date DATE
) USING iceberg
PARTITIONED BY (months(order_date))
""")
print("Iceberg tábla létrehozva rejtett havi particionálással")Iceberg tábla létrehozva rejtett havi particionálással
Iceberg metadata fa Iceberg
Az Iceberg egyik legnagyobb innovációja a fat-alapú metadata struktúra, amely lényegesen hatékonyabbá teszi a nagy táblák lekérdezését, mint a hagyományos monolitikus tranzakciós napló megközelítés. A hierarchia négy szintből áll:
Szint 1: Metadata file (v1.metadata.json) — a tábla legfelső szintű metaadata: séma, particionálási specifikáció, sort order, és hivatkozás a jelenlegi snapshot-ra. Ez a belépési pont minden olvasó számára.
Szint 2: Manifest list (snap-12345.avro) — egy snapshot (verzió) összes manifest fájljának listája. Tartalmazza az egyes manifestek partíció-tartományát és sorainak számát, így a query engine gyorsan kiszűrheti az irreleváns manifesteket.
Szint 3: Manifest file (manifest-A.avro) — az egyes adatfájlok listája statisztikákkal (sorok száma, oszloponkénti min/max értékek, null értékek száma). Ez a szint teszi lehetővé a file skipping-et: ha egy query csak 2024 januári adatokat kér, a motor a manifest statisztikák alapján kihagyhatja a többi hónap fájljait.
Szint 4: Data files — maguk a Parquet vagy Avro adatfájlok, amelyekben a tényleges adatok tárolódnak.
Miért jobb ez, mint a Delta log? A Delta Lake egyetlen JSON-féle tranzakciós naplót használ, ami nagy tábláknál (több millió fájl) lassú lehet. Az Iceberg többszintű struktúrája lehetővé teszi, hogy egy query csak a releváns manifesteket és adatfájlokat olvassa, jelentősen csökkentve a tervezési időt.
# Iceberg metadata fa struktúra
#
# metadata/
# ├── v1.metadata.json ← tábla metaadat (séma, partition spec, sort order)
# ├── v2.metadata.json
# └── snap-12345.avro ← manifest list (snapshot)
# │
# ├── manifest-A.avro ← manifest file (data file-ok listája + stats)
# │ ├── data/file1.parquet (row_count=1000, min_id=1, max_id=1000)
# │ └── data/file2.parquet (row_count=800, min_id=1001, max_id=1800)
# │
# └── manifest-B.avro
# └── data/file3.parquet (row_count=500)
#
# Előny: egy query csak a releváns manifesteket + data fileokat olvassa
# A manifest file-ok statisztikákat tartalmaznak (min/max/value_count/null_count)
print("Iceberg metadata fa: metadata.json → manifest list → manifest → data files")Iceberg metadata fa: metadata.json → manifest list → manifest → data files
Apache Hudi alapok 
Hudi
Az Apache Hudi (Hadoop Upserts Deletes and Incrementals) az Uber belső projektje. Fő erőssége a streaming upsert és az inkrementális lekérdezés.
WebShop Pro: Ha valós időben érkeznek rendelés-frissítések (pl. státusz változás: "new" → "shipped" → "delivered"), a Hudi natívan támogatja az upsert-eket.
from pyspark.sql import SparkSession
spark = SparkSession.builder \
.config("spark.jars.packages", "org.apache.hudi:hudi-spark3-bundle_2.12:0.14.0") \
.config("spark.serializer", "org.apache.spark.serializer.KryoSerializer") \
.getOrCreate()
# Hudi tábla írása upsert-tel
hudi_options = {
"hoodie.table.name": "webshop_orders",
"hoodie.datasource.write.operation": "upsert",
"hoodie.datasource.write.recordkey.field": "order_id",
"hoodie.datasource.write.precombine.field": "updated_at",
"hoodie.datasource.write.table.type": "COPY_ON_WRITE",
}
orders.write.format("hudi").options(**hudi_options).mode("append").save("./data/webshop_hudi")Hudi tábla létrehozva COPY_ON_WRITE módban, upsert támogatással
Hudi táblatípusok: CoW vs MoR 
Hudi
A Hudi kétféle táblatípust támogat: Copy-on-Write (CoW) és Merge-on-Read (MoR). A választás jelentősen befolyásolja az írási és olvasási teljesítményt, és a use case-től függ, melyiket érdemes választani.
Copy-on-Write (CoW): Minden frissítés (update) egy teljesen új Parquet fájlt hoz létre — a régi és a módosított sorok egyaránt belekerülnek az új fájlba. Ez azt jelenti, hogy az írás lassabb (hiszen minden update-hez az egész fájl újraíródik), de az olvasás maximálisan gyors, mert közvetlenül Parquet-ből olvasható, nincs szükség merge-re. Olyan esetekben ideális, ahol ritkán frissülnek az adatok és a batch ETL dominál.
Merge-on-Read (MoR): A frissítések először egy gyors Avro log-fájlba íródnak (append-only), ami nagyon gyors. Az olvasáskor a motor a Parquet alapfájlokat és az Avro log-fájlokat menet közben összeolvassza (merge). A compaction folyamat időszakosan egyesíti a log-fájlokat új Parquet fájlokká. Ez a mód kiválóan alkalmas streaming forgatókönyvekhez, ahol gyakori, kis frissítések érkeznek.
WebShop Pro: Ha óránként jönnek rendelés-frissítések (státusz változások: "new" → "shipped" → "delivered"), a MoR táblatípus a jobb választás, mert a gyakori upsert-eket gyorsan elnyeli. Ha napi batch-et dolgozunk fel, ahol az adatok ritkán módosulnak, a CoW egyszerűbb és gyorsabb olvasást biztosít.
Tip: Ha bizonytalan vagy, kezdd MoR-rel — a Hudi automatikus compaction-je idővel optimalizálja a táblát, és az olvasási teljesítmény fokozatosan javul.
| Táblatípus | Írás | Olvasás | Használat |
|---|---|---|---|
| Copy-on-Write (CoW) | Lassabb (mindig új Parquet) | Gyors (direkt Parquet) | Batch ETL, ritka frissítés |
| Merge-on-Read (MoR) | Gyors (Avro log + Parquet base) | Lassabb (merge kell) | Streaming, gyakori upsert |
Ha óránként jönnek rendelés-frissítések → MoR. Ha napi batch-et dolgozunk fel → CoW.
Schema evolution Delta Lake Iceberg
A séma evolúció (schema evolution) kritikus képesség egy növekvő webshopnál, ahol folyamran változnak az üzleti igények. Például egy új funkció miatt hozzáadunk egy shipping_address mezőt a rendelésekhez, vagy átnevezzük az amount_ft oszlopot amount_huf-ra. Mindhárom formátum támogatja a séma evolúciót, de eltérő mélységben.
Delta Lake: Automatikus oszlop-hozzáadást támogat az overwriteSchema opcióval, és SQL ALTER TABLE paranccsal is módosítható a séma. Azonban típusváltoztatás (pl. INT → STRING) korlátozott, és oszlop-átnevezés csak Spark 3.4+ verziótól érhető el teljesen.
Apache Iceberg: A legteljesebb séma evolúciós támogatással rendelkezik. Oszlopot hozzáadni, eltávolítani, átnevezni, átrendezni és típusát megváltoztatni is lehet — mindezt anélkül, hogy a meglévő adatfájlokat újra kellene írni. Az Iceberg az egyes snapshotokban külön tárolja a sémát, így a korábbi verziók is lekérdezhetők a régi sémával.
Apache Hudi: Az upsert műveletek során automatikusan hozzáadja az új oszlopokat, ha a DataFrame tartalmaz extra mezőket. Ez kényelmes streaming esetén, de a tudatos tervezett séma-változtatások (átnevezés, típusmódosítás) kevésbé támogatottak, mint az Iceberg-nél.
WebShop Pro: Amikor a marketing csapat kér egy discount_code oszlopot a rendelésekhez, az Iceberg-nél ez egyetlen ALTER TABLE paranccsal megoldható, és a régi adatoknál a mező egyszerűen null lesz — nem kell migrációt futtatni.
# Delta Lake: automatikus séma evolúció
spark.sql("ALTER TABLE delta.`./data/webshop_orders` ADD COLUMN shipping_address STRING")
# Iceberg: teljes séma evolúció (add, rename, reorder, change type)
spark.sql("ALTER TABLE webshop.orders ADD COLUMN shipping_address STRING")
spark.sql("ALTER TABLE webshop.orders RENAME COLUMN amount_ft TO amount_huf")
# Hudi: séma evolúció upsert-kor automatikusan
# Ha az új DataFrame tartalmaz extra oszlopot, Hudi auto-addolja
print("Mindhárom formátum támogatja az oszlop hozzáadását")Mindhárom formátum támogatja az oszlop hozzáadását Iceberg: legteljesebb séma evolúció (rename, reorder, típus változás)
Partition evolution Iceberg
A particionálás evolúciója az egyik legfájdalmasabb művelet hagyományos data lake-ben. Ha rájössz, hogy a napi particionálás helyett havi particionálásra lenne szükség, a teljes adatmennyiséget át kell mozgatni — terabájtnyi adatnál ez órákig tart, és a pipeline-t le kell állítani közben.
Az Apache Iceberg rejtett particionálása (hidden partitioning) forradalmian megoldja ezt a problémát. A lényeg: a particionáló oszlop nem jelenik meg külön oszlopként az adatokban, és a query-k automatikusan használják a megfelelő particionálást anélkül, hogy a felhasználónak tudnia kellene róla. A months(order_date) transzformáció például havi particionálást hoz létre anélkül, hogy egy order_month oszlopot kellene hozzáadni.
Partition evolution: Az Iceberg-ben a particionálási stratégia verziózott. Ha heti particionálásról havira váltasz, az Iceberg egyszerűen új partition spec-et hoz létre. A régi adatok az eredeti particionálással, az új adatok az új particionálással maradnak, és a query engine mindkettőt átláthatóan kezeli — nem kell adatot mozgatni.
Összehasonlítás: A Delta Lake particionálás-evolúciója manuális REORGANIZE műveletet igényel. A Hudi particionálása a record key + precombine keyhez kötött, korlátozottan változtatható. Az Iceberg az egyetlen, amely teljesen automatikus, transzparens particionálás-evolúciót kínál.
| Formátum | Partition evolution | Rejtett particionálás |
|---|---|---|
| Delta Lake | Manuális REORGANIZE | Nem |
| Iceberg | Automatikus partition spec váltás | Igen (year/month/day/hour transforms) |
| Hudi | Korlátozott | Nem (record key + precombine key) |
Time travel összehasonlítás Delta Lake Iceberg
A time travel (időutazás) az egyik leghasznosabb funkció, amelyet a táblaformátumok biztosítanak. Lehetővé teszi a tábla korábbi állapotának lekérdezését — mintha egy git checkout parancsot adnál ki az adatokon. Audit célra, hibás írás rollback-re, reprodukálható ML kísérletekhez és adatváltozás nyomon követéséhez egyaránt elengedhetetlen.
Delta Lake: Verziószám alapján működik (versionAsOf). Minden írás egy új verziót hoz létre: 0, 1, 2 stb. A DESCRIBE HISTORY paranccsal láthatod az összes verziót, és bármelyiket lekérdezheted. Ez a legegyszerűbb megközelítés, de a verziószámok nem feltétlenül egyértelműek tábla-klónozás esetén.
Apache Iceberg: Snapshot ID alapján működik. Minden írás egy új snapshot-ot hoz létre egy egyedi azonosítóval. A snapshot-ok egymásra épülnek, és a tábla history tartalmazza az összeset. A snapshot ID globálisan egyedi, ami megkönnyíti a cross-engine konzisztenciát.
Apache Hudi: Timestamp alapján működik (as.of.instant). Megadhatod a pontos időpontot, és a Hudi visszaadja a tábla állapotát abban a pillanatban. Ez a legintuitívabb megközelítés az időutazás szempontjából.
WebShop Pro: Ha egy ETL hiba miatt rossz adatok kerültek a rendelési táblába, time travel-lel lekérdezheted a hiba előtti állapotot, ellenőrizheted a különbséget, és visszaállíthatod a helyes verziót.
# Delta Lake time travel
spark.read.format("delta") \
.option("versionAsOf", 0) \
.load("./data/webshop_orders").show()
# Iceberg time travel (snapshot ID alapján)
spark.read.format("iceberg") \
.option("snapshot-id", 123456789) \
.load("webshop.orders").show()
# Hudi time travel (timestamp alapján)
spark.read.format("hudi") \
.option("as.of.instant", "20240115120000") \
.load("./data/webshop_hudi").show()Delta: versionAsOf (0, 1, 2...) Iceberg: snapshot-id Hudi: as.of.instant (timestamp)
ACID tranzakciók Delta Lake Iceberg
Az ACID tranzakciók (Atomicity, Consistency, Isolation, Durability) a relációs adatbázisokból ismert garanciák, amelyeket a modern táblaformátumok a data lake-re is kiterjesztenek. Data lake-ben ezek kritikusak, ha több processz ír egyszerre ugyanarra a táblára — nélkülük adatvesztés, inkonzisztencia vagy sérült fájlok keletkezhetnek.
Atomicity (Atomiasság): Egy tranzakció vagy teljesen végrehajtódik, vagy egyáltalán nem. Ha egy ETL folyamat 100 fájlt akar írni, és a 73. fájlnál hiba történik, az eddig írt 72 fájl is visszavonásra kerül. A Delta Lake JSON log + CRC ellenőrzéssel, az Iceberg atomic snapshot swap-pel, a Hudi timeline commit-tal garantálja ezt.
Consistency (Konzisztencia): A tábla mindig érvényes állapotban van, a séma szabályait minden írás betartja. Nem fordulhat elő, hogy félig írt adat jelenik meg a táblában.
Isolation (Izoláció): Párhuzamos írók nem zavarják egymást. Mindhárom formátum optimista konkurencia-vezérlést (OCC) vagy MVCC-t használ: a conflict detektálás a commit pillanatában történik, és ha ütközés van, az egyik tranzakció újrapróbálkozik.
Durability (Tartósság): Egy sikeresen commitolt tranzakció eredménye tartósan tárolódik és túléli a rendszer-összeomlást. A Parquet adatfájlok és a tranzakciós napló együtt garantálják ezt.
| ACID tulajdonság | Delta | Iceberg | Hudi |
|---|---|---|---|
| Atomicity | JSON log + CRC | Atomic snapshot swap | Timeline commit |
| Consistency | Séma enforce | Séma + partition spec | Séma enforce |
| Isolation | Optimistic concurrency | Optimistic (OCC) | MVCC |
| Durability | Parquet + log | Parquet + manifest | Parquet + Avro log |
Catalog szerepe 
Catalog
A catalog a táblaformátumok ökoszisztémájának legfelső rétege. Felel a táblák felderítéséért (milyen táblák léteznek és hol találhatók), a névterek (database/séma) kezeléséért és a hozzáférés-szabályozásért. Nélküle csak fájlútvonalakkal (s3://bucket/path/to/table) hivatkozhatsz táblákra, ami nem skálázható.
Miért fontos? Egy production környezetben tucatnyi vagy száznyi tábla létezik. A catalog lehetővé teszi, hogy SELECT * FROM webshop.orders formátumban hivatkozz a táblára, ahelyett, hogy minden query-ben meg kellene adni a teljes fájlutat. Ezen felül jogosultságokat is kezel: ki olvashatja, ki írhatja a táblát.
Unity Catalog — a Databricks saját catalog-ja, szorosan integrálva a Delta Lake-et használó Databricks platformmal. Egységes hozzáférés-szabályozást biztosít táblák, view-k és ML modellek felett.
Project Nessie — nyílt forráskódú, Git-szerű verzionaló catalog, amely az Iceberg táblák branch-elését és merge-elését teszi lehetővé. Különösen hasznos adat- és ML engineering csapatok együttműködéséhez.
AWS Glue Catalog — az AWS natív catalog-ja, amely Iceberg és Hudi táblák metaadatait kezeli. Ha AWS-en fut a pipeline, ez a legkézenfekvőbb választás.
Polaris Catalog — a Snowflake által adományozott, nyílt forráskódú Iceberg catalog, amely a Snowflake és az open-source ökoszisztéma közötti hidat képezi.
WebShop Pro: Lokális fejlesztésre Nessie Docker konténert használunk, mert ingyenes és támogatja a Git-szerű munkafolyamatot. Felhőben Unity Catalog (Databricks) vagy Glue (AWS) a javasolt választás.
| Catalog | Formátum támogatás | Hálózat | Karbantartó |
|---|---|---|---|
| Unity Catalog | Delta (elsődlegesen) | Databricks | Databricks |
| Project Nessie | Iceberg (Git-like branching) | Nyílt forráskódú | Dremio / Community |
| AWS Glue Catalog | Iceberg, Hudi | AWS | Amazon |
| Polaris Catalog | Iceberg | Nyílt forráskódú | Snowflake (donated) |
Lokálisan: Nessie Docker konténer. Felhőben: Unity Catalog (Databricks) vagy Glue (AWS).
Vendor lock-in
A vendor lock-in (szállítói függőség) az egyik legfontosabb stratégiai kérdés a táblaformátum választásakor. Bár mindhárom formátum nyílt forráskódú, a mögöttük álló ökoszisztéma és a felhőszolgáltató integrációk szintje eltérő, ami befolyásolja a jövőbeli mozgásteret.
Delta Lake: Bár a Linux Foundation alatt nyílt forráskódú, a legjobb teljesítményt és funkciókat a Databricks platformon belül éri el. A Unity Catalog, a Photon engine és az OPTIMIZE/Z-ORDER műveletek mind Databricks-specifikusak. Ha ma Databricks-öt használsz, a Delta a legkényelmesebb választás, de a későbbi váltás más platformra többletmunkát igényel.
Apache Iceberg: A legkisebb vendor lock-in kockázattal rendelkezik. Az Apache Software Foundation projektje, amelyet az Apple, a Netflix és az AWS is támogat. Multi-engine támogatása (Spark, Flink, Trino, Presto, Dremio, Snowflake) garantálja, hogy nem kötsz ki egyetlen feldolgozó motorhoz vagy felhőszolgáltatóhoz sem.
Apache Hudi: Az Uber által indított, ma Apache projekt. Az Amazon és a Onehouse támogatja, de az ökoszisztéma szűkebb, mint az Iceberg-é vagy a Delta-é. A Hudi erőssége a streaming upsert, ami egy specifikus use case-hez köti.
Fontos megjegyzés: A formátum nyílt forráskódú, de a felhőszolgáltató vendor lock-in továbbra is létezik. Ha Delta Lake-et használsz a Databricks-ön, az Iceberg-et AWS/Snowflake-en, vagy a Hudit Amazon EMR-en — a szolgáltatói ökoszisztémából kilépni mindig komoly migrációs erőforrást igényel. A formátum hordozhatósága csak az adatok szintjén garantált, nem a teljes platform szintjén.
| Formátum | Nyílt forráskód? | Fő sponsor | Lock-in kockázat |
|---|---|---|---|
| Delta Lake | Igen (Linux Foundation) | Databricks | Alacsony (de Databricks optimalizált) |
| Iceberg | Igen (Apache) | Apple, Netflix, AWS | Nagyon alacsony (multi-engine) |
| Hudi | Igen (Apache) | Uber, Amazon, Onehouse | Alacsony |
A formátum nyílt forráskódú, de a CLOUD SZOLGÁLTATÓ vendor lock-in marad. Delta + Databricks, Iceberg + AWS/Snowflake, stb.
Teljesítmény összehasonlítás Spark
A teljesítmény összehasonlítása a három formátum között nem egyszerű, mert az eredmény erősen függ a query mintától (point lookup vs full scan vs aggregáció), az adatmérettől, a compaction stratégiától és a használt feldolgozó motortól. Nincs egyetlen "leggyorsabb" formátum — mindegyik másban jeleskedik.
Query tervezés: A Delta Lake a Spark Catalyst optimizerére támaszkodik, amely remekül optimalizál Spark-specifikus query-ket. Az Iceberg manifest-statisztikákat használ, amelyek motor-függetlenek — bármely engine (Spark, Trino, Flink) kihasználhatja őket. A Hudi indexeket és bloom filtereket használ a gyors point lookup-hoz.
File skipping: A Delta Lake Z-ORDER és data skipping technikákkal gyorsítja a query-ket — a Z-ORDER több oszlop alapján rendezi az adatokat, így a range query-k kevesebb fájlt olvasnak. Az Iceberg manifest-statisztikák (min/max per fájl) automatikus file skipping-et biztosítanak. A Hudi index-alapú megközelítése kis latenciájú lookup-ra optimalizált.
Compaction: A streaming írások sok kis fájlt hoznak létre ("small file problem"), ami lassítja az olvasást. A Delta Lake OPTIMIZE parancsa egyesíti a kis fájlokat. Az Iceberg Rewrite Data Files művelete hasonló, de granulárisabban vezérelhető. A Hudi automatikus compaction-je (főleg MoR módban) folyamatosan tartja karban a fájlokat.
WebShop Pro: A Spark-on futó batch query-k Delta Lake-kel a leggyorsabbak. Ha Trino-t is használsz ad-hoc elemzésre, az Iceberg jobban skáláz. A Hudi streaming upsert teljesítménye kiemelkedő a többiekhez képest.
| Metrika | Delta Lake | Iceberg | Hudi |
|---|---|---|---|
| Query tervezés | Catalyst (Spark) | Manifest stats (multi-engine) | Index + bloom filter |
| File skipping | Z-ORDER, data skipping | Min/max per file, partition pruning | Index alapú |
| Compaction | OPTIMIZE parancs | Rewrite Data Files | Auto compaction (MoR) |
| Streaming write | Közepes | Jó (Flink integration) | Kiváló (built-in upsert) |
| Concurrent writes | Optimistic locking | OCC | MVCC |
Döntési útmutató
A döntési útmutató segít kiválasztani a megfelelő formátumot a primary use case alapján. Nincs egyetlen "legjobb" formátum — a helyes választás a követelményektől, a meglévő infrastruktúrától és a csapat tapasztalatától függ.
Databricks környezetben: A Delta Lake a kézenfekvő választás. A Spark integráció a legszorosabb, a Unity Catalog egységes goverance-t biztosít, és az OPTIMIZE/Z-ORDER műveletekkel a legjobb Spark teljesítmény érhető el. Ha a csapat már Databricks-öt használ, nincs ok más formátumra váltani.
Multi-engine környezetben: Ha a pipeline-ben több feldolgozó motor dolgozik együtt (pl. Spark batch ETL + Trino ad-hoc query + Flink streaming), az Iceberg a legjobb választás. Az egyetlen formátum, amelyhez minden major engine natív támogatással rendelkezik.
Streaming upsert dominanciával: Ha az adatok folyamatosan frissülnek (pl. rendelés-státuszok, felhasználói profilok, IoT szenzoradatok), a Hudi natív upsert és inkrementális query támogatása páratlan. A CoW/MoR táblatípusok választásával finomhangolhatod az írási/olvasási teljesítményt.
Gyakran változó séma: Ha az üzleti igények miatt gyakran kell oszlopokat hozzáadni, átnevezni vagy típusukat módosítani, az Iceberg a legrugalmasabb. Teljes séma evolúciót támogat anélkül, hogy a meglévő adatokat érintené.
Felhő-független stratégia: Ha nem akarsz egyetlen felhőszolgáltatóhoz sem kötődni, az Iceberg a legjobb választás. AWS, GCP és Azure környezetben egyaránt kiválóan működik, és a multi-engine támogatás miatt nem kötsz ki egyetlen platformhoz sem.
WebShop Pro döntés: A helyi fejlesztésre Delta Lake-et használunk (mert a többi kurzus is azt használja, és a Spark integráció zökkenőmentes). Felhőben Iceberg a javasolt (multi-engine kompatibilitás). Streaming upsert forgatókönyvekhez Hudi a specialist.
| Ha... | Akkor válaszd... | Indok |
|---|---|---|
| Databricks-öt használsz | Delta Lake | Legjobb Spark integráció, Unity Catalog |
| Multi-engine kell (Spark + Trino + Flink) | Iceberg | Legjobb cross-engine kompatibilitás |
| Streaming upsert dominál | Hudi | Natív upsert, inkrementális query |
| Séma gyakran változik | Iceberg | Legteljesebb schema evolution |
| Maximális teljesítmény kell Spark-on | Delta Lake | Z-ORDER, OPTIMIZE tight integráció |
| Felhő-független akarsz lenni | Iceberg | Legjobb hordozhatóság |
Lokális fejlesztésre Delta Lake (mert a többi kurzus is azt használja). Felhőben Iceberg (mert multi-engine). Streaming upsert-re Hudi.
Összefoglalás
Gratulálunk! Ebben a kurzusban megismerted a három legfontosabb nyílt táblaformátumot — a Delta Lake, az Apache Iceberg és az Apache Hudi működését, erősségeit és gyengeségeit. Ezek az eszközök a modern lakehouse architektúra alapját képezik, és a választásuk komoly hatással van a projekt sikerére.
Főbb tanulságok: Megértetted a fájlformátum és táblaformátum közötti különbséget, és azt, hogy az utóbbi miért elengedhetetlen production környezetben. Megismerted a Delta Lake tranzakciós naplóját, az Iceberg metadata fáját és a Hudi CoW/MoR táblatípusait. Láttad, hogyan működik a séma és particionálás evolúció, a time travel és az ACID tranzakciók a három formátumban.
Gyakorlati tudás: A catalog-ok szerepe, a vendor lock-in kockázatok és a teljesítménybeli különbségek megértése felvértezet abban, hogy racionális döntést hozz a saját projektjeden. A döntési útmutató alapján képes vagy kiválasztani a megfelelő formátumot a use case-edhez.
Következő lépés: A Streaming Engineering kurzusban megtanulod, hogyan építs valós idejű adatfeldolgozó pipeline-t Kafka és Spark Structured Streaming segítségével, amely stream-ből Delta táblákba írja az adatokat — így a két kurzus tudása kéz a kézben jár.
| Megtanultuk | Következő |
|---|---|
| Table vs file format | Streaming Engineering (Kafka + Spark) |
| Delta / Iceberg / Hudi alapok | Real-time adatfeldolgozás |
| Schema & partition evolution | Stream-to-Delta pipeline |
| ACID, catalog, performance | Production streaming architektúra |
Streaming Engineering — ahol Kafka + Spark Structured Streaming pipeline-t építünk a WebShop Pro-hoz!