Ugrás a fő tartalomra

Data Warehouse VS Data Lake VS Data Lakehouse VS Data Mesh

 Data Warehouse VS  Data Lake VS Data Lakehouse VS  Data Mesh



Data Warehouse vs Data Lake vs Data Lakehouse vs Data MeshRészletes összefoglaló informatikus / adattárház-szakértő / adatelemző szemszögből
(Példákkal, architektúra-rajzokkal, előny-hátrány táblázattal, tipikus használati esetekkel)
1. Áttekintő táblázat (gyors összehasonlítás)
Tulajdonság
Data Warehouse (DWH)
Data Lake
Data Lakehouse
Data Mesh
Adat típusa
Strukturált (schema-on-write)
Nyers, strukturálatlan, fél-strukturált (schema-on-read)
Nyers + strukturált (schema-on-read + ACID)
Decentralizált, domain-specifikus adat termékek
Tárolás
Relációs RDBMS / MPP (Snowflake, Redshift, BigQuery)
Objektum tároló (S3, ADLS, GCS)
Objektum tároló + metaadatok, tranzakciós réteg (Delta Lake, Iceberg, Hudi)
Domain-orientált lake-ek / DWH-k
Séamakezelés
ETL → schema-on-write
ELT → schema-on-read
ELT + schema enforcement & evolution
Domain-csapatok felelősek a schema-ért
Tranzakciók (ACID)
Igen (natív)
Nem (külső réteg kell)
Igen (Delta, Iceberg, Hudi)
Domain-függő (általában lakehouse-alapon)
Kormányzás
Központi (enterprise governance)
Gyenge/központi (DataGov tools)
Központi + self-service
Decentralizált – domain owner-ek
Skálázhatóság
Vertikális/horizontális (drága)
Horizontális (olcsó)
Horizontális (olcsó) + ACID
Horizontális + szervezeti
Elsődleges felhasználók
BI elemzők, riportok
Adattudósok, ML
BI + ML + mérnökök
Domain szakértők, üzleti egységek
Költség
Magas (licenc + számítás)
Alacsony (tárolás)
Közepes (tárolás + metaadatok)
Változó (domain-függő)
Tipikus toolok
Snowflake, Redshift, BigQuery, Teradata
S3 + Hive/Presto, Databricks (lake)
Databricks (Delta), Snowflake (Iceberg), Dremio
Databricks + domain API-k, dbt, Great Expectations
2. Részletes leírások + példák
2.1 Data Warehouse (DWH)
"A strukturált, riport-kész adatbázisok klasszikusa"
Definíció
  • Schema-on-write: az adatbetöltés előtt definiálni kell a sémát (ETL).
  • Optimalizálva OLAP műveletekre (aggregáció, csillag/snowflake sémák).
  • Általában MPP (Massively Parallel Processing) vagy cloud-native DWH.
Architektúra (ASCII)
[Forrásrendszerek]
     ↓ (Extract)
[Staging Area]
     ↓ (Transform → ETL)
[Data Warehouse] ← Star/Snowflake schema
     ↓ (SQL)
[BI Tool] (Tableau, Power BI)
Előnyök
  • Teljesítmény: indexek, materialized view-k, columnar storage.
  • Adatminőség: szigorú validáció betöltéskor.
  • Egységes igazság: egy forrásból származó riportok.
Hátrányok
  • Rugalmasság ↓: új adatforrás = új ETL pipeline.
  • Költség ↑: számítás = tárolás (compute coupled).
  • Strukturálatlan adat kizárva.
Példa használati esetCég: Nagyvállalati pénzügyi controlling
Adat: SAP tranzakciók, Oracle GL, Excel budget
Eszköz: Snowflake + Fivetran (ETL) + dbt (transzform) + Looker
Kimutatás: havi P&L riport 30 mp alatt, drill-down költséghelyekre.
2.2 Data Lake
"Mindent tárolunk, később kitaláljuk"
Definíció
  • Schema-on-read: nyers adat landol, csak olvasáskor alkalmazzuk a sémát.
  • Objektum alapú tárolás (parquet, avro, json, csv, bináris).
  • ELT paradigma.
Architektúra (ASCII)
[Források: log, IoT, clickstream, images]
     ↓ (Ingestion: Kafka, Flume, NiFi)
[S3/ADLS bucket] (zónák: raw → processed → curated)
     ↓ (SQL-on-files)
[Presto, Trino, Athena, Spark]
     ↓
[Adattudós / ML / BI]
Előnyök
  • Olcsó tárolás (S3 ~0.023 $/GB/hó).
  • Bármilyen adat (kép, videó, log).
  • Agilis: új kérdés = új SQL/Spark job.
Hátrányok
  • "Data Swamp" kockázat (nincs governance).
  • ACID hiány: konkurens írás = adatinkonzisztencia.
  • Teljesítmény: hideg fájlok → lassabb BI.
Példa használati esetCég: E-kereskedelmi clickstream analitika
Adat: 10 TB/nap JSON clickstream (Kafka → S3 raw)
Eszköz: AWS S3 + Glue Crawler + Athena + QuickSight
Kimutatás: valós idejű funnel elemzés Spark-on (adat tudós).
2.3 Data Lakehouse
"A legjobb mindkét világból: Lake rugalmassága + Warehouse megbízhatósága"
Definíció
  • Data Lake + tranzakciós réteg (ACID) + metaadat katalógus + schema enforcement & evolution.
  • Formátumok: Delta Lake, Apache Iceberg, Apache Hudi.
Architektúra (ASCII)
[Források]
     ↓ (Ingestion)
[S3/ADLS]
   |→ [Delta Lake / Iceberg table]
   |     ↓ (ACID, time-travel, schema evolution)
[Unity Catalog / Hive Metastore]
     ↓ (SQL)
[Databricks SQL, Trino, Spark]
     ↓
[BI + ML + Stream]
Kulcsfunkciók
Funkció
Delta Lake
Iceberg
Hudi
ACID
Igen
Igen
Igen
Time Travel
Igen
Igen
Igen
Schema Evolution
Igen (mergeSchema)
Igen
Igen
Partition Evolution
Korlátozott
Igen
Igen
Streaming + Batch
Igen
Igen
Igen (spec)
Előnyök
  • Egy platform mind BI, ML, stream.
  • Költséghatékony: compute és storage szétválasztható.
  • Adatminőség: schema enforcement + Great Expectations.
Hátrányok
  • Komplexitás ↑: metaadatréteg karbantartás.
  • Még fejlődik: nem minden tool támogatja (pl. Power BI natív Iceberg).
Példa használati esetCég: Telco valós idejű fraud detekció
Adat: CDR streamek (Kafka) → Delta Lake (bronze → silver → gold)
Eszköz: Databricks (Auto Loader + Delta Live Tables)
Kimutatás:
  • BI: havi ARPU dashboard (Databricks SQL)
  • ML: fraud modell újratanítása napi batch (MLflow)
  • Stream: Spark Structured Streaming → alert.
2.4 Data Mesh
"Adat mint termék – decentralizált felelősség"
Definíció (Zhamak Dehghani)4 alapelv:
  1. Domain-oriented decentralized data ownership
  2. Data as a product
  3. Self-service data platform
  4. Federated computational governance
Architektúra (ASCII)
[Domain A Team] → Data Product A (Delta Lake + API)
[Domain B Team] → Data Product B (Iceberg + GraphQL)
       ↓                ↓
   [Central Platform Team]
       ↓
[Self-service infra: Terraform, Unity Catalog, Collibra]
       ↓
[Consumer: BI, ML, App]
Kulcsfogalmak
Fogalom
Leírás
Data Product
Domain-specifikus, dokumentált, SLA-val rendelkező adatcsomag (pl. customer_360)
Domain Data Owner
Üzleti egység felel az adatminőségért, schema-ért
Interoperability
Közös standardok (Avro schema registry, OpenAPI)
Platform Team
Kubernetes, dbt Cloud, Great Expectations, Observability
Előnyök
  • Üzleti sebesség ↑: domain tudja, mit akar.
  • Skálázható szervezet: 100+ csapat is működhet.
  • Adatminőség javul (owner motivált).
Hátrányok
  • Kezdeti befektetés ↑ (platform, kultúra).
  • Duplikáció kockázata (ha nincs federated governance).
  • Komplexitás a fogyasztóknak (több API).
Példa használati esetCég: Globális bank (Retail, Corporate, Risk domain-ek)
Data Product:
  • retail_customer_profile (Delta Lake, REST API)
  • corporate_exposure (Iceberg, GraphQL)
    Platform: Azure + Databricks + Collibra + GitOps
    Fogyasztó:
  • Risk team: cross-domain join retail + corporate → stressz teszt
  • Marketing: customer_360 → kampány.
3. Döntési mátrix – Mikor melyiket?
Döntési szempont
Data Warehouse
Data Lake
Data Lakehouse
Data Mesh
Strukturált riportok, szigorú SLA
Igen
Nem
Igen
Domain-függő
Nyers IoT, log, kép
Nem
Igen
Igen
Igen (domain lake)
BI + ML egy platformon
Korlátozott
Igen (de ACID nélkül)
Igen
Igen
Kisvállalat (<50 fő)
Igen
Igen
Igen
Nem (túl komplex)
Nagyvállalat (>10 domain)
Korlátozott
Igen
Igen
Igen
Költségérzékeny
Nem
Igen
Igen
Platform költség
4. Gyakorlati kódpéldák (Databricks / Delta Lake)4.1 Bronze → Silver (Delta Live Tables)
python
@dlt.table
def bronze_iot():
    return spark.readStream.format("kafka")...

@dlt.table
def silver_iot():
    return (dlt.read("bronze_iot")
            .withColumn("json", from_json(col("value"), schema))
            .select("json.*")
            .withColumn("ingest_ts", current_timestamp()))
4.2 Schema Evolution + Merge (UPSERT)
sql
MERGE INTO prod.customer_silver t
USING changes.customer_updates s
ON t.customer_id = s.customer_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
4.3 Time Travel BI query
sql
SELECT * FROM prod.sales VERSION AS OF 12345
WHERE region = 'EMEA'
5. Ajánlás lépésről lépésre (migráció)
Lépés
Teendő
Eszköz
1.
Adatleltár készítése
DataHub / Amundsen
2.
Zónás lake (raw/processed/curated)
S3 + Glue
3.
Delta Lake bevezetése (curated)
Databricks
4.
BI átállás DWH → Lakehouse SQL
Databricks SQL
5.
Domain catalog (Unity Catalog)
Databricks
6.
Data Mesh pilot (1 domain)
Data Product API
7.
Governance (Collibra/Great Expectations)
Automatizált tesztek
6. Összefoglaló 1 oldalas cheat-sheet
┌─────────────────────┬─────────────────────┬─────────────────────┬─────────────────────┐
│   DATA WAREHOUSE    │    DATA LAKE        │   DATA LAKEHOUSE    │     DATA MESH       │
├─────────────────────┼─────────────────────┼─────────────────────┼─────────────────────┤
│ Schema-on-write     │ Schema-on-read      │ Schema-on-read+ACID │ Domain product      │
│ ETL                 │ ELT                 │ ELT + ACID          │ ELT + API           │
│ MPP RDBMS           │ S3/ADLS             │ Delta/Iceberg/Hudi  │ Több lakehouse      │
│ BI riportok         │ ML, log, kép        │ BI+ML+Stream        │ Üzleti sebesség     │
│ Központi gov        │ Swamp kockázat      │ Központi+self-serve │ Decentralizált gov  │
└─────────────────────┴─────────────────────┴─────────────────────┴─────────────────────┘
Záró gondolat:
  • Kis- és középvállalat → Data Lakehouse (Databricks/Snowflake).
  • Nagyvállalat, sok üzleti egység → Data Mesh + Lakehouse alapokon.
  • Legacy BI → fokozatos migráció DWH → Lakehouse.








Megjegyzések

Megjegyzés küldése