Databricks Lakehouse 
Databricks 
Unity Catalog
A Databricks egy felhő-native adatplatform, amely egyesíti a data lake rugalmasságát a data warehouse teljesítményével — ezt az architektúrát nevezik lakehouse-nak. A platform három pilléren nyugszik: a Delta Lake biztosítja a megbízható tárolást ACID tranzakciókkal, az Apache Spark a nagy teljesítményű feldolgozást, és az MLflow a gépi tanulási workflow-k kezelését. A Databricks lényegében egy „all-in-one" megoldás, ahol az adatbetöltés, a transzformáció, az analitika és a gépi tanulás egyetlen integrált környezetben történik.
Miért fontos a lakehouse architektúra? A hagyományos data lake-ek olcsó tárolást kínáltak, de nem biztosítottak adatminőséget, tranzakciókonszenzust vagy séma-érvényesítést. A data warehouse-ok ezekkel rendelkeztek, de drágák voltak és nem tudták kezelni a strukturálatlan adatokat. A lakehouse a kettő előnyeit ötvözi: nyílt formátumú fájlokat használ (Parquet + Delta Lake tranzakciós napló), támogatja az ACID tranzakciókat, és lehetővé teszi a batch és streaming feldolgozást egyaránt.
Ebben a kurzusban a WebShop Pro projekt lakehouse architektúráját építjük fel a Databricks platformon. Bronze/Silver/Gold rétegekkel dolgozunk, megismerjük a Unity Catalog goverance megoldást, a Delta Live Tables deklaratív pipeline-okat, az MLflow kísérletkezelést, és a Databricks Jobs ütemezést. A kurzus végére egy production-ready adatplatformod lesz.
Tip: A Databricks-nak van egy ingyenes Community Edition-je, amely tökéletes tanulásra. Bár korlátozott (nincs Unity Catalog, nincs auto-scaling), a Spark, a Delta Lake és a notebook funkciók teljesen használhatók. Regisztrálj a community.cloud.databricks.com oldalon.
Notebooks, Jobs, Unity Catalog, Delta Live Tables, MLflow, workflow-k
Databricks-alapú lakehouse pipeline bronze/silver/gold rétegekkel
Delta Lake · DLT · Medallion
Databricks workspace
A Databricks workspace a platform központi felülete: egy webes IDE, amelyben notebook-eket írhatsz, klasztereket kezelhetsz, jobokat ütemezhetsz, és a Unity Catalog segítségével az adatgoverance-t adminisztrálhatod. A workspace ötvözi a fejlesztői élményt (notebook-ok, Git-integráció, version control) az üzemeltetési képességekkel (auto-scaling klaszterek, monitoring, alerting).
A workspace hat fő komponenst foglal magában. A Cluster a Spark compute egység: virtuális gépek egy csoontja, amely a feldolgozást végzi. A klaszterek lehetnek all-purpose (interaktív munkához) vagy job klaszterek (ütemezett feladatokhoz, amelyek leállnak a futás után). A Jobs a pipeline-ok orkesztrálását végzik: notebook-ok, Python scriptek és SQL lekérdezések sorrendben történő futtatásával. Az SQL Warehouse a BI eszközök számára optimalizált lekérdezési végpont.
A példa egy klaszter definíciót mutat: a webshop-etl nevű klaszter 3 worker node-dal rendelkezik, 30 perc inaktivitás után automatikusan leáll. Ez fontos költségoptimalizálási beállítás — a felhőben a compute a legdrágább komponens, és a felejtett klaszterek komoly számlát eredményezhetnek. A spark_version meghatározza a futtatott Spark verzióját, a node_type_id pedig a gépméretet.
Tip: Használd az auto-termination beállítást mindig (minimum 15-30 perc). Production klasztereknél érdemes auto-scaling-ot is bekapcsolni, hogy a rendszer automatikusan alkalmazkodjon a terheléshez. A Databricks Serverless opció tovább csökkenti a management terhét.
| Komponens | Leírás |
|---|---|
| Workspace | Notebook-ek és fájlok |
| Cluster | Spark compute |
| Jobs | Ütemezett pipeline-ok |
| Unity Catalog | Governance és security |
| SQL Warehouse | SQL analytics |
| Model Registry | ML model kezelés |
# Create cluster
cluster = {
'cluster_name': 'webshop-etl',
'spark_version': '14.3.x-scala2.12',
'node_type_id': 'i3.xlarge',
'num_workers': 3,
'autotermination_minutes': 30
}Cluster 'webshop-etl' created Spark 14.3, 3 workers, auto-terminate 30min
Notebook alapok
A Databricks notebook-ok a platform alapvető fejlesztői egységei: cellákra osztott dokumentumok, amelyekben Python, SQL, Scala vagy R nyelven írhatsz kódot. A notebook-ok hasonlóak a Jupyter notebook-okhoz, de Databricks-specifikus funkciókkal rendelkeznek: beépített vizualizáció (a display() függvény interaktív táblázatot és diagramokat rajzol), Spark integráció (a spark objektum automatikusan elérhető), és közös szerkesztési lehetőség (több felhasználó egyszerre dolgozhat ugyanazon a notebook-on).
A példa bemutatja az adatbeolvasás alapjait: a spark.read.format('delta') paranccsal Delta Lake formátumú adatokat olvasunk be az S3-ból. A Delta Lake a Databricks alapértelmezett tárolási formátuma, amely Parquet fájlokra épül, de kiegészíti azokat egy tranzakciós naplóval (_delta_log). Ez biztosítja az ACID tulajdonságokat, a séma-érvényesítést és a time travel képességet. A df.display() hívás egy interaktív táblázatban jeleníti meg az adatokat, rendezési és szűrési lehetőséggel.
A notebook cellák végrehajthatók egyesével (Shift+Enter) vagy az egész notebook futtatható egyszerre (Run All). Az eredmények (táblázatok, diagramok, szöveges kimenetek) közvetlenül a cella alatt jelennek meg. A notebook-ok támogatják a Markdown cellákat is dokumentáció céljából, és a változók megosztódnak a cellák között — az egyik cellában definiált DataFrame a következőben is elérhető.
Tip: Használd a display(df) függvényt a print(df) helyett — az interaktív táblázat sokkal jobban áttekinthető. Használd a dbutils.widgets segédprogramot paraméteres notebook-ok készítéséhez, amelyek így újrahasználhatók különböző környezetekben.
# Databricks notebook cell
# Read from S3
df = spark.read.format('delta').load('s3://webshop/bronze/orders')
print(f'Loaded {df.count()} orders')
df.display() # Pretty display in DatabricksLoaded 1420 orders [Interactive table with sorting and filtering]
Unity Catalog Unity Catalog
A Unity Catalog a Databricks egységes governance megoldása: egy hierarchikus engedélykezelési rendszer, amely a katalógus-séma-tábla háromszinten szervezi az adatokat, és minden szinten definiálhatók hozzáférési szabályok. Ez az első olyan megoldás a Databricks ökoszisztémában, amely egyetlen felületről kezeli a teljes adathozzáférést — korábban az engedélyek szétszórtan, különböző szinteken voltak kezelve.
A hierarchia felülről lefelé épül: a Catalog a legfelső szintű névtér (pl. webshop), a Schema a katalóguson belüli logikai csoportosítás (pl. bronze, silver, gold), és a Table a konkrét adattábla. Az engedélyek öröklődnek: ha valaki SELECT jogot kap egy sémára, az összes tábláját olvashatja. A példában a data-engineers csoport kap olvasási és írási jogot a bronze sémára, míg az analysts csak olvashatja a gold sémát — ez a separation of duties elve.
A Unity Catalog nemcsak engedélykezelést, hanem audit loggingot, data lineage-t (származáskövetést), és data classification-t (bizalmas adatok címkézését) is biztosít. Ezek a funkciók kritikusak a compliance (GDPR, HIPAA) és a belső ellenőrzések szempontjából. A GRANT/REVOKE SQL parancsok mellett a Databricks UI-ból is kezelheted az engedélyeket.
Tip: Tervezd meg az engedélyezési modellt a projekt kezdetén. A Bronze/Silver/Gold rétegekhez különböző hozzáférési szintek javasoltak: a data engineering csapat teljes hozzáférést kap, az analysts csak a Gold réteget olvashatja, és a Bronze soha ne legyen közvetlenül elérhető az analitikusok számára.
-- SQL: Create catalog and schema CREATE CATALOG IF NOT EXISTS webshop; USE CATALOG webshop; CREATE SCHEMA IF NOT EXISTS bronze; CREATE SCHEMA IF NOT EXISTS silver; CREATE SCHEMA IF NOT EXISTS gold; -- Grant permissions GRANT USE CATALOG ON CATALOG webshop TO `data-engineers`; GRANT CREATE TABLE ON SCHEMA webshop.bronze TO `data-engineers`; GRANT SELECT ON SCHEMA webshop.gold TO `analysts`;
Catalog: webshop created Schemas: bronze, silver, gold Permissions: data-engineers (read/write), analysts (read-only)
Bronze réteg: adatbetöltés
Az Auto Loader a Databricks intelligens adatbetöltő eszköze, amely automatikusan felfedezi az új fájlokat a felhőtárhelyen, kikövetkezteti a sémát, és inkrementálisan betölti az adatokat a Bronze rétegbe. Nem kell manuálisan megadnod a fájlneveket vagy a sémát — az Auto Loader mindezt automatikusan kezeli, ami különösen hasznos, ha a forrásrendszer folyamatosan hoz létre új fájlokat (pl. óránként egy új CSV a rendelésekből).
A példa egy streaming lekérdezést mutat: a spark.readStream.format('cloudFiles') hívás inicializálja az Auto Loadert, amely a megadott S3 könyvtárat figyeli. A cloudFiles.schemaLocation paraméter határozza meg, hova mentse a kikövetkeztetett sémát — ha egy új fájl tartalmaz egy új oszlopot, az Auto Loader automatikusan hozzáadja a sémához. A checkpointLocation biztosítja, hogy a már feldolgozott fájlokat ne töltse be újra, a trigger(once=True) pedig egyszeri futtatást jelent (batch mód).
Amit a háttérben történik: az Auto Loader nyomon követi, mely fájlokat dolgozta már fel (a checkpoint könyvtárban), és minden futtatáskor csak az újakat olvassa be. A séma-inferencia az első fájlok alapján történik, de a cloudFiles.schemaHints opcióval finomhangolhatod a típusokat. A kimenet Delta Lake formátumú, amely azonnal lekérdezhető a Silver réteg transzformációihoz.
Tip: Használd az Auto Loadert minden structured streaming forráshoz a manuális fájlkezelés helyett. A trigger(once=True) batch feldolgozásra alkalmas, de ha valós idejű feldolgozásra van szükséged, használd a trigger(processingTime='30 seconds') beállítást, amely félpercenként ellenőrzi az új fájlokat.
# Auto Loader: incremental file ingestion
query = (spark.readStream.format('cloudFiles')
.option('cloudFiles.format', 'csv')
.option('cloudFiles.schemaLocation', 's3://webshop/schema/orders')
.option('header', True)
.load('s3://webshop/raw/orders/')
.writeStream
.format('delta')
.option('checkpointLocation', 's3://webshop/checkpoints/orders')
.trigger(once=True)
.toTable('webshop.bronze.orders'))Auto Loader: processed 15 new files Loaded 1420 rows into webshop.bronze.orders
Silver réteg: tisztítás
A Silver réteg a Bronze-ból érkező nyers adatok tisztításáért, deduplikációjáért és típuskonverziójáért felel. Itt történik az adatok „emberről olvashatóvá" tétele: a stringként beolvasott dátumok timestamp-é konvertálódnak, a negatív összegek korrigálódnak, a hiányzó kötelező mezőkkel rendelkező sorok kiszűrésre kerülnek. A Silver a Medallion architektúra „single source of truth" rétege — minden lefelé irányuló elemzés ebből a tisztított adathalmazból indul ki.
A példa egy SQL-alapú transzformációt mutat: a CREATE OR REPLACE TABLE parancs felülírja a webshop.silver.orders táblát a tisztított adatokkal. A CAST függvény típuskonverziót végez, az ABS biztosítja, hogy az összegek pozitívak legyenek, a WHERE feltételek pedig kiszűrik az érvénytelen rekordokat (null státusz, nem pozitív összeg, hiányzó rendelésszám). A loaded_at oszlopot megtartjuk a lineage és az audit trail érdekében.
A deduplikáció ebben a példában implicit (a WHERE szűri a rossz adatokat), de nagyobb rendszerekben explicit deduplikációra is szükség lehet. Ha a forrásrendszer duplikált rendeléseket küld (pl. újrapróbálkozás miatt), a DROPDuplicates vagy egy window függvény (ROW_NUMBER) alapján kell eltávolítani az ismétlődéseket. A Silver réteg a megfelelő hely erre, mert itt biztosítjuk az adatok egyediségét, mielőtt azok a Gold rétegbe kerülnének.
Tip: A Silver réteg transzformációi legyenek idempotensek — bármennyiszer lefuttatva ugyanazt az eredményt kell produkálniuk. A CREATE OR REPLACE TABLE ezt garantálja, de ha inkrementális feldolgozást használsz, ügyelj a merge logikára.
-- SQL: Silver transformation
CREATE OR REPLACE TABLE webshop.silver.orders AS
SELECT
order_id,
customer_id,
CAST(order_date AS TIMESTAMP) as ordered_at,
ABS(amount) as amount,
status,
loaded_at
FROM webshop.bronze.orders
WHERE status IS NOT NULL
AND amount > 0
AND order_id IS NOT NULL;Silver: 1380 rows (removed 40 invalid records) Data types validated
Gold réteg: analytics
A Gold réteg a lakehouse architektúra csúcsa: itt találhatók a business-ready aggregációk, dimenzió táblák (dim_) és fact táblák (fct_), amelyeket a BI eszközök (Power BI, Tableau, Looker) és az adatelemzők közvetlenül használnak. A Gold réteg modellek általában kis méretűek (néhány tucattól néhány ezer sorig), de gyakran frissülnek, és optimalizáltak a lekérdezési teljesítményre.
A példa egy havi bevételi fact táblát hoz létre: a Silver réteg rendeléseit joinolja a Gold dimenzió táblákkal (dim_products, dim_customers), és havi szintre aggregálja a bevételt kategória és szegmens szerint. A COUNT DISTINCT egyedi rendeléseket számol, a SUM a teljes bevételt. Ez a fajta aggregáció tipikusan az, amit egy BI dashboard-on megjelenítenek — a Gold réteg pontosan ilyen lekérdezés-optimalizált táblákat készít.
A Gold réteg tervezése a business felhasználókkal közösen történik: milyen kérdésekre akarnak választ kapni? „Hány rendelés volt múlt hónapban kategóriánként?" „Melyik ügyfélszegmens hozza a legtöbb bevételt?" Ezek a kérdések határozzák meg, milyen Gold táblákra van szükség. A dimenzió táblák (ügyfelek, termékek, régiók) biztosítják a szűrési és csoportosítási lehetőségeket, a fact táblák pedig a mérőszámokat (bevétel, rendelésszám, átlag).
Tip: A Gold réteg táblákat materializáld fizikai táblaként (nem view-ként), és rendszeresen frissítsd őket (naponta vagy óránként). Használj OPTIMIZE és ZORDER parancsokat a lekérdezési teljesítmény javítására a gyakran szűrt oszlopokon.
-- SQL: Gold mart tables
CREATE OR REPLACE TABLE webshop.gold.fct_monthly_revenue AS
SELECT
DATE_TRUNC('MONTH', ordered_at) as month,
p.category,
c.segment,
COUNT(DISTINCT o.order_id) as order_count,
SUM(o.amount) as revenue
FROM webshop.silver.orders o
JOIN webshop.gold.dim_products p ON o.product_id = p.product_id
JOIN webshop.gold.dim_customers c ON o.customer_id = c.customer_id
GROUP BY 1, 2, 3;Gold: fct_monthly_revenue created with 48 rows Ready for BI dashboards
Delta Live Tables (DLT)
A Delta Live Tables (DLT) a Databricks deklaratív pipeline-keretrendszere, amelyben nem parancssori utasításokkal irányítod az adatáramlást, hanem Python dekorátorokkal vagy SQL definíciókkal leírod, milyen táblákra és nézetekre van szükséged, és a rendszer automatikusan felépíti a függőségi gráfot. A DLT a háttérben kezeli a klaszter létrehozását, a restart-after-failure logikát, az adatminőség-ellenőrzést és a checkpointing-et — olyan feladatokat, amelyeket egyébként manuálisan kellene kódolnod.
Miért hasznos a DLT? A hagyományos ETL notebook-okban a fejlesztőnek magának kell gondoskodnia a hibakezelésről, az újrapróbálkozásokról, a schema evoluciónról és a táblák közötti függőségek sorrendjéről. A DLT ezt egy deklaratív modellbe sűríti: a @dlt.table dekorátor jelzi, hogy egy függvény egy tábla definíciója, a @dlt.expect sorok pedig adatminőségi szabályokat határoznak meg. Ha egy expect megsértődik, a DLT naplózza a hibát, és a beállításoktól függően vagy eldobja a sort, vagy megjelöli a sort quarentine-ként, vagy leállítja a pipeline-t.
A példa egy streaming Silver táblát definiál: a @dlt.table dekorátor megadja a tábla nevét és leírását, az @dlt.expect sorok két adatminőségi szabályt határoznak meg (az összeg pozitív, a rendelésszó nem null), és a függvény törzse a Bronze táblából olvasva szűri és transzformálja az adatokat. A DLT automatikusan felismeri, hogy a silver_orders tábla a bronze_orders táblától függ, és a megfelelő sorrendben futtatja a lépéseket.
Tip: Használd az @dlt.expect_all() dekorátort, ha több szabályt is definiálni akarsz, és meg akarod adni, mi történjen a szabályt sértő sorokkal (drop, fail vagy quarantine). A DLT UI-ban valós időben láthatod a pipeline DAG-ot és az egyes táblák állapotát.
import dlt
@dlt.table(
name='silver_orders',
comment='Cleaned orders'
)
@dlt.expect('valid_amount', 'amount > 0')
@dlt.expect('not_null_id', 'order_id IS NOT NULL')
def silver_orders():
return (spark.readStream.table('webshop.bronze.orders')
.filter('status IS NOT NULL')
.withColumn('amount', F.abs('amount')))DLT Pipeline: webshop_dlt Tables: bronze_orders -> silver_orders -> gold_marts Data quality: 2 expectations defined
Databricks Jobs
A Databricks Jobs a platform orkesztrációs rétege: segítségével notebook-okat, Python scripteket, SQL lekérdezéseket és Delta Live Tables pipeline-okat futtathatsz meghatározott sorrendben, ütemezés szerint vagy eseményvezérelten. A Jobs a Databricks „production-ready" motorja — amíg a notebook-ok interaktív fejlesztésre valók, a Jobs automatizálja az üzemeltetést.
Minden Job egy vagy több task-ból áll, amelyek között függőségeket (depends_on) definiálhatsz. A példában a bronze task először betölti a nyers adatokat, a silver task (amely függ a bronze-tól) megtisztítja őket, a gold task (amely függ a silver-től) elkészíti az aggregációkat, és végül a quality task ellenőrzi az adatminőséget. Ez a DAG (Directed Acyclic Graph) modell biztosítja, hogy a feladatok a megfelelő sorrendben fussanak, és ha egy task elbukik, a tőle függők ne induljanak el.
A schedule mező cron-kifejezéssel adja meg az ütemezést: a '0 6 * * *' minden nap 6:00 UTC-kor futtatja a Job-ot. Emellett létezik trigger-alapú indítás is (pl. új fájl érkezése a felhőtárhelyre), vagy manuális indítás az UI-ból vagy API-n keresztül. A Job minden futtatásáról részletes naplózás készül: mennyi ideig tartott, hány sort dolgozott fel, volt-e hiba. A sikertelen futtatásokhoz alerteket (e-mail, Slack, PagerDuty) kapcsolhatsz.
Tip: Használj job klasztereket all-purpose klaszterek helyett — a job klaszterek automatikusan elindulnak a feladat kezdete előtt és leállnak utána, ami jelentős költségmegtakarítást eredményez. Állíts be retry logikát (max_retries) az átmeneti hibák kezelésére, és használj alerting-et, hogy azonnal értesülj a sikertelen futtatásokról.
# Job definition
job = {
'name': 'webshop-daily-etl',
'schedule': '0 6 * * *',
'tasks': [
{'task_key': 'bronze', 'notebook_task': {'notebook_path': '/etl/01_bronze'}},
{'task_key': 'silver', 'depends_on': ['bronze'], 'notebook_task': {'notebook_path': '/etl/02_silver'}},
{'task_key': 'gold', 'depends_on': ['silver'], 'notebook_task': {'notebook_path': '/etl/03_gold'}},
{'task_key': 'quality', 'depends_on': ['gold'], 'notebook_task': {'notebook_path': '/etl/04_quality'}},
]
}Job: webshop-daily-etl scheduled at 06:00 UTC bronze -> silver -> gold -> quality
Delta Lake haladó
A Delta Lake haladó funkciói a lakehouse teljesítményének és karbantarthatóságának kulcsai. Az OPTIMIZE parancs kistömbű fájlokat egyesít nagyobbakká, a ZORDER oszlopalapú rendezést biztosít a gyakran szűrt mezőkön, a VACUUM eltávolítja a régi fájlverziókat, a time travel lehetővé teszi az adatok múltbeli állapotának lekérdezését, és a Change Data Feed (CDF) inkrementális változáskövetést biztosít a downstream rendszerek számára.
Az OPTIMIZE parancs a leggyakrabban használt karbantartási művelet: a gyakori kis fájlokat (amelyek a streaming betöltés vagy a sok apró batch miatt keletkeznek) egyesíti néhány nagyobbá. A ZORDER BY ezen felül oszlopalapú rendezést alkalmaz, ami drasztikusan felgyorsítja a szűrő lekérdezéseket — ha a WHERE feltétel a customer_id és order_date oszlopokra szűr, a ZORDER biztosítja, hogy a releváns adatok kevesebb fájlban legyenek. A példa 50 kis fájlt 8 nagyobbá optimalizál, ami hatszoros fájlméret-csökkenést és jelentős lekérdezési gyorsulást eredményez.
A time travel a Delta Lake egyik legszembetűnőbb képessége: a VERSION AS OF vagy TIMESTAMP AS OF klauzulával bármelyik múltbeli állapotot lekérdezheted. Ez hasznos audit célra, hibakeresésre („mi volt az adat állapota tegnap 6-kor?"), és rollback-re (ha egy rossz transzformáció tönkretette az adatokat, visszaállíthatod az előző verziót). A VACUUM takarítja fel a régi verziókat — alapértelmezetten 7 napnál régebbi fájlokat töröl, de a RETAIN paraméterrel módosítható. A CDF végül lehetővé teszi, hogy a downstream rendszerek (pl. egy másik pipeline vagy egy ML feature store) csak a változott sorokat kapják meg, nem kell minden alkalommal teljes táblát beolvasni.
Tip: Futtass OPTIMIZE + ZORDER parancsokat rendszeresen a Gold rétegen (pl. a napi Job végén), a VACUUM-ot pedig heti rendszerességgel. A time travel nem ingyenes — minden verzió tárolódik, amíg VACUUM el nem távolítja. A CDF engedélyezd azon táblákon, amelyeket más pipeline-ok inkrementálisan olvasnak.
-- Optimize table performance OPTIMIZE webshop.gold.fct_orders ZORDER BY (customer_id, order_date); -- Time travel SELECT * FROM webshop.silver.orders VERSION AS OF 42; SELECT * FROM webshop.silver.orders TIMESTAMP AS OF '2024-05-01 06:00:00'; -- Clean old versions VACUUM webshop.silver.orders RETAIN 168 HOURS; -- Change Data Feed ALTER TABLE webshop.silver.orders SET TBLPROPERTIES (delta.enableChangeDataFeed = true);
OPTIMIZE: 50 files -> 8 files (6x smaller) Time travel: queried version 42 VACUUM: removed 35 old files CDF: enabled
MLflow integráció 
MLflow
Az MLflow a Databricks beépített gépi tanulási platformja, amely az ML kísérletek teljes életciklusát kezeli: a paraméterek és metrikák naplózását (experiment tracking), a modellek verziózott tárolását (model registry), és a modellek élesítését (serving). A Databricks-ben az MLflow szorosan integrálva van a notebook környezettel — nem kell külön szervert telepíteni, minden a workspace-en belül elérhető.
A kísérletkövetés (experiment tracking) a leggyakrabban használt funkció: az mlflow.start_run() kontextuskezelőn belül minden paramétert (log_param), metrikát (log_metric) és modellt (log_model) automatikusan naplóz a rendszer. Ez azt jelenti, hogy ha öt különböző hyperparaméter-kombinációt próbálsz ki, mindegyik futtatáshoz rendszerezetten visszakeresheted az eredményeket — nem kell külön Excel táblázatban vezetni, melyik konfiguráció milyen accuracy-t ért el.
A példa egy Random Forest osztályozót mutat: a churn prediction (ügyfél-lemorzsolódás előrejelzés) modellt a Gold réteg tisztított adataira tanítjuk. Az mlflow.set_experiment() meghatározza a kísérlet helyét, a with mlflow.start_run() blokkon belül naplózzuk a modellparamétereket és az accuracy metrikát, a log_model() pedig elmenti a tanított modellt. A Databricks UI-ban egy táblázatos felületen hasonlíthatod össze a futtatások eredményeit, és kiválaszthatod a legjobbat.
Tip: Használd az autolog funkciót (mlflow.sklearn.autolog()) a manuális naplózás helyett — az automatikusan naplózza az összes modellparamétert és metrikát. A Model Registry-ben regisztrált modellek staging és production státuszba helyezhetők, ami lehetővé teszi a CI/CD-szerű modell-élesítési workflow-t.
import mlflow
from sklearn.ensemble import RandomForestClassifier
mlflow.set_experiment('/webshop/churn-prediction')
with mlflow.start_run():
model = RandomForestClassifier(n_estimators=100, max_depth=10)
model.fit(X_train, y_train)
accuracy = model.score(X_test, y_test)
mlflow.log_param('n_estimators', 100)
mlflow.log_metric('accuracy', accuracy)
mlflow.sklearn.log_model(model, 'model')
print(f'Accuracy: {accuracy:.3f}')Experiment: /webshop/churn-prediction Run ID: abc123 Accuracy: 0.923 Model registered: churn-predictor-v1
Spark SQL analytics
A Spark SQL analytics a Databricks SQL Warehouse szolgáltatásának központi eleme: lehetővé teszi, hogy közvetlenül SQL nyelven futtass lekérdezéseket a Delta Lake táblákon, anélkül, hogy Python vagy Spark API-t használnál. A Databricks SQL Warehouse egy önálló, SQL-re optimalizált compute erőforrás, amelyet BI eszközök (Power BI, Tableau, Looker, Metabase) és JDBC/ODBC kliensek kapcsolnak meg — függetlenül a Spark klaszterektől.
A példa egy dashboard nézetet (view) hoz létre, amely a havi bevételi adatokat kategória szerint bontja, és két haladó SQL ablakfüggvényt használ: a LAG() függvény hónapról hónapra történő változást (mom_change) számít, a SUM() OVER pedig futó összeget (cumulative) képez. Ezek az ablakfüggvények (window functions) a BI analitika alapvető eszközei — trendeket, növekedési ütemet és cumulative metrikákat lehet velük számolni egyetlen lekérdezésben.
A BI integráció egyszerű: a Databricks SQL Warehouse ad egy JDBC/ODBC végpontot (host, port, HTTP path), amelyet a BI eszközök data source beállításaiban meg kell adni. A Power BI DirectQuery módban valós időben kérdezi le a Databricks táblákat, a Tableau élő kapcsolatot (live connection) használ, és a Looker LookerML-ben hivatkozhat a Databricks nézetekre. Így az adatmérnökök által elkészített Gold réteg táblák közvetlenül megjelennek a dashboardokon.
Tip: Hozz létre dedikált SQL Warehouse-ot a BI eszközök számára, külön a Spark klaszterektől. Használj view-kat a komplex lekérdezések egységesítésére, de a teljesítménykritikus dashboard-okhoz fizikai táblákat ajánlott használni. A Serverless SQL Warehouse a legkényelmesebb opció, mert másodpercek alatt indul és automatikusan skálázódik.
-- SQL Analytics on Databricks
CREATE OR REPLACE VIEW webshop.gold.vw_dashboard AS
SELECT
month,
category,
revenue,
revenue - LAG(revenue) OVER (PARTITION BY category ORDER BY month) as mom_change,
SUM(revenue) OVER (PARTITION BY category ORDER BY month) as cumulative
FROM webshop.gold.fct_monthly_revenue;
-- Connect BI tools
-- Power BI, Tableau, Looker via Databricks SQL WarehouseView created: webshop.gold.vw_dashboard BI tools connected via SQL Warehouse endpoint
Medallion architektúra minta
A Medallion architektúra a lakehouse adatfinomítás szervezési mintája, amely három rétegben dolgozza fel az adatokat: Bronze (nyers), Silver (tisztított) és Gold (analytics-ready). A név onnan ered, hogy minden réteg „értékesebb" az előzőnél — ahogy a fémeknél a bronz az alap, az ezüst a finomított, és az arany a végtermék. Ez a minta nem technológia, hanem szervezési elv: bármilyen adatplatformon alkalmazható, de a Databricks Delta Lake-jével különösen jól működik.
A Bronze réteg a forrásrendszerek másolata: a nyers adatok a lehető legkevesebb transzformációval kerülnek ide (append-only, séma on-the-fly). A cél, hogy semmit se veszítsünk az eredeti adatokból — ha később kiderül, hogy egy korábban kiszűrt „hibás" rekord mégis érdekes, a Bronze-ból elő lehet hozni. A Silver réteg a tisztítás és deduplikáció színtere: itt típuskonvertálunk, szűrünk, deduplikálunk, és az adatokat „emberről olvashatóvá" tesszük. A Gold réteg végül a business-facing aggregációk, dimenzió- és fact táblák helye, amelyeket a BI eszközök és elemzők használnak.
A példa egy egyszerű lekérdezéssel mutatja a rétegek áttekintését: a Bronze 5 táblát tartalmaz (rendelések, termékek, ügyfelek, kategóriák, események), a Silver szintén 5 tisztított táblát, és a Gold 8 aggregált táblát és nézetet. A növekedés a Gold rétegben normális: egyetlen Silver táblából több Gold aggregáció is készülhet (napi, heti, havi bontásban, különböző dimenziók szerint).
Tip: Ne ugorj át rétegeket — soha ne írj a Bronze-ból közvetlenül a Gold-ba. A Silver réteg a single source of truth: ha bármelyik Gold aggregációt újra kell számolni, a Silver-ből indul ki. Tartsd a Bronze-ot olcsó tárolón (S3 Standard), a Gold-ot pedig optimalizált táblaként (OPTIMIZE, ZORDER).
Nyers adatok, séma on-the-fly, append-only
Tisztított, deduplikált, tipizált adatok
Business aggregációk, dimenziók, fact táblák
-- Full medallion overview SELECT 'bronze' as layer, COUNT(*) as tables FROM webshop.bronze UNION ALL SELECT 'silver', COUNT(*) FROM webshop.silver UNION ALL SELECT 'gold', COUNT(*) FROM webshop.gold;
layer | tables -------+-------- bronze | 5 silver | 5 gold | 8
Streaming analytics
A Structured Streaming a Spark beépített stream-feldolgozó motorja, amely mikro-batch (vagy continuous) módon dolgozza fel az adatokat közel valós időben. A Databricks-ben a Structured Streaming szorosan integrálva van a Delta Lake-kel: a stream forrás lehet Kafka, cloud storage (Auto Loader), vagy Delta tábla, és a cél is Delta tábla lehet — így a streaming és a batch feldolgozás ugyanazon a táblán osztozik.
A példa egy Kafka forrásból olvasó stream-et mutat: a Kafka egy elosztott üzenetküldő rendszer, amelybe a forrásalkalmazások (pl. a WebShop Pro webshop motor) eseményeket küldenek (új rendelés, státuszváltozás, kattintás). A spark.readStream.format('kafka') hívás Kafka consumer-ként csatlakozik a megadott topic-hoz, és folyamatosan fogadja az üzeneteket. A from_json() függvény a JSON-formátumú üzenettörzseket strukturált Spark oszlopokká alakítja a megadott séma alapján.
A stream kimenete Delta Lake táblába íródik: a writeStream.format('delta') biztosítja, hogy az adatok tranzakciós biztonsággal (ACID) kerülnek a Bronze rétegbe. A checkpointLocation nyomon követi, mely Kafka offset-eket dolgozta már fel a stream, így újraindítás után onnan folytatja, ahol abbahagyta. A outputMode('append') azt jelenti, hogy csak új sorokat ad hozzá — a meglévőket nem módosítja. Ha frissítéseket is kezelni kell (pl. rendelés státuszváltozás), akkor a merge (upsert) output módot kell használni a Delta Lake change data feed-del kombinálva.
Tip: A Structured Streaming alapértelmezetten mikro-batch módban fut, ami másodperces késleltetést jelent. Ha valósában miliszekundumos késleltetésre van szükséged, használd a continuous trigger-t, de ez korlátozottabb funkciókkal rendelkezik. A checkpoint könyvtárat soha ne töröld manuálisan — az a stream folytonosságát biztosítja.
from pyspark.sql import functions as F
# Stream from Kafka
stream = (spark.readStream
.format('kafka')
.option('kafka.bootstrap.servers', 'kafka:9092')
.option('subscribe', 'webshop.orders')
.load())
# Parse and write to Delta
(stream
.select(F.from_json(F.col('value').cast('string'), schema).alias('data'))
.select('data.*')
.writeStream
.format('delta')
.outputMode('append')
.option('checkpointLocation', '/checkpoint/stream')
.toTable('webshop.bronze.orders_stream'))Streaming query started Processing ~100 events/second Writing to webshop.bronze.orders_stream
Serverless SQL Warehouse
A Serverless SQL Warehouse a Databricks fully-managed SQL végrehajtási környezete: a Databricks kezeli az infrastruktúrát, te csak a lekérdezéseket írod. A hagyományos SQL Warehouse (pro és classic) esetében virtuális gépeket kell lefoglalni és várni az indulásukat (akár több percig), a Serverless viszont másodpercek alatt elindul, automatikusan skálázódik a lekérdezési terhelés alapján, és leáll, ha nincs rá szükség — mindez pay-per-query alapú árazással.
Miért fontos a Serverless? A hagyományos SQL Warehouse-oknál a legnagyobb probléma a cold start: ha egy analitikus reggel 8-kor megnyitja a Power BI-t, a lekérdezésnek meg kell várnia, amíg a Warehouse elindul (2-5 perc). A Serverless warm pool-ból indul, ami 5 másodpercen belül válaszkésszé válik. A skálázás is automatikus: ha 10 analitikus egyszerre futtat lekérdezést, a Serverless Warehouse automatikusan kibővül, ha csak egy van, összehúzódik.
A példa egy Serverless SQL Warehouse definíciót mutat: az enable_serverless_compute: True beállítás aktiválja a serverless módot, az auto_stop_mins: 5 biztosítja, hogy 5 perc inaktivitás után automatikusan leálljon, és a cluster_size meghatározza a maximális méretet. A kapcsolódás standard JDBC/ODBC protokollon keresztül történik — bármely SQL kliens vagy BI eszköz csatlakozhat a megadott host, port és HTTP path paraméterekkel.
Tip: A Serverless SQL Warehouse a legjobb választás BI dashboard-ok és ad-hoc lekérdezések számára, ahol a gyors válaszidő kritikus. Az árazás query-alapú, ami költséghatékony a kisebb terhelésű munkaterheléseknél. Nagy volume-ú ETL munkákhoz viszont a klasszikus SQL Warehouse vagy Spark klaszter lehet gazdaságosabb.
# Create serverless SQL warehouse
warehouse = {
'name': 'webshop-analytics',
'cluster_size': '2X-Small',
'enable_serverless_compute': True,
'auto_stop_mins': 5,
'channel': {'name': 'CHANNEL_NAME_CURRENT'}
}
# Connect from any SQL client
# Host: xxx.databricks.com
# Port: 443
# HTTP Path: /sql/1.0/warehouses/abc123Serverless SQL Warehouse: webshop-analytics Start time: 5 seconds Auto-stop: 5 minutes Cost: pay-per-query
CI/CD Databricks pipeline
A CI/CD (Continuous Integration / Continuous Deployment) a Databricks pipeline-ok élesítésének iparági standardja: a kód (notebook-ok, DLT definíciók, Job konfigurációk) verziókezelése Git-ben történik, és minden push automatikusan teszteli és telepíti a változásokat. A Databricks dbx CLI eszköze (Databricks eXtensions) biztosítja a hidat a Git repository és a Databricks workspace között.
Miért szükséges a CI/CD? Interaktív notebook-fejlesztésnél (ahogy a korábbi szekciókban láttuk) könnyű elfelejteni, melyik verzió fut élesben, ki módosított mit, és mi történt a múlt héten. A CI/CD ezt szisztematizálja: a kód a Git-ben van (version control), a CI pipeline lefuttatja a teszteket (lint, unit test, integration test), és ha minden zöld, a CD automatikusan telepíti a változásokat a Databricks workspace-be.
A példa egy GitHub Actions workflow-t mutat: a push esemény indítja el, és két lépésből áll. Az első (dbx deploy) feltölti a notebook-okat és frissíti a Job definíciót a Databricks workspace-ben. A második (dbx launch) elindítja a telepített Job-ot integration test-ként — ha a Job sikeresen lefut, a telepítés jóváhagyott. Ha bármelyik lépés elbukik, a pipeline leáll, és a régi verzió marad élesben (rollback nélkül, hiszen nem is módosult).
Tip: Használd a Databricks Git integrációt a notebook-ok szinkronizálására — a workspace-ben közvetlenül klónozhatod a Git repository-t, és push/pull műveletekkel tarthatod szinkronban a kódot. A dbx mellett létezik DABs (Databricks Asset Bundles) is, a Databricks újabb, deklaratívabb CI/CD eszköze, amely YAML-alapú konfigurációval dolgozik.
# .github/workflows/databricks-ci.yml
name: Databricks CI
on: [push]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Deploy notebooks
run: |
dbx deploy --jobs=webshop-daily-etl
- name: Run integration test
run: |
dbx launch --job=webshop-daily-etl --as-run-submissionCI/CD Pipeline: Lint -> Test -> Deploy -> Integration Test All green!
Governance és security
A Governance és security a lakehouse enterprise-grade üzemeltetésének alapja: a Unity Catalog biztosítja a hozzáférés-vezérlést (ki melyik adatot láthatja), az audit logging nyomon követi minden hozzáférést (ki, mikor, mit csinált), és a data classification címkézi a bizalmas adatokat (PII, PHI, pénzügyi). A Databricks-ben ezek a funkciók nem opcionális kiegészítők, hanem beépített képességek, amelyeket a projekt kezdetétől érdemes használni.
A row-level security (RLS) lehetővé teszi, hogy ugyanaz a tábla különböző felhasználóknak más-más sorokat mutasson — anélkül, hogy külön táblákat kellene fenntartani. A példában a region_filter függvény ellenőrzi, hogy a felhasználó régiója megegyezik-e a sor régiójával: egy kelet-magyarországi regionális menedzser csak a kelet-magyarországi adatokat látja, míg a központi vezetőség mindent. A column masking hasonló elven működik: az email oszlop értéke „maszkírozva" jelenik meg azok számára, akiknek nincs explicit jogosultságuk a teljes e-mail cím megtekintésére (pl. „j***@email.com").
Az audit logging minden adathozzáférést rögzít: ki futtatott SELECT lekérdezést, ki módosított táblát, ki kapott új engedélyt. Ez kritikus a compliance (GDPR, HIPAA, SOX) és a belső ellenőrzések szempontjából. A Databricks UI-ban vagy a system tables segítségével lekérdezhetők az audit események. A data classification funkcióval címkézheted a bizalmas oszlopokat (pl. „SSN", „credit_card", „email"), és a rendszer figyelmeztet, ha egy lekérdezés ilyen oszlopokat ér el.
Tip: Implementáld a governance-t a projekt legelején, ne utólag. A row-level security és column masking Unity Catalog SQL függvényekkel definiálhatók, és a meglévő táblákhoz utólag is hozzáadhatók. Használj szolgáltatásneveket (service principals) a Job-ok futtatásához, ne személyes felhasználói fiókokat — így a jogosultságok függetlenek lesznek a személyektől.
-- Row-level security
CREATE FUNCTION webshop.region_filter(region STRING)
RETURNS BOOLEAN
RETURN region = current_user_metadata('region');
-- Apply to table
ALTER TABLE webshop.gold.fct_revenue
SET ROW FILTER webshop.region_filter ON (region);
-- Column masking
ALTER TABLE webshop.gold.dim_customers
ALTER COLUMN email SET MASK email_mask;Row-level security: applied Column masking: email column masked Audit log: tracking all access
Összefoglalás
Gratulálunk! Ebben a kurzusban felépítetted a WebShop Pro projekt Databricks Lakehouse architektúráját a legalapoktól. Megtanultad, hogyan hozd létre a workspace-t és a klasztereket, hogyan definiálj Unity Catalog katalógusokat és sémákat, hogyan építs Bronze/Silver/Gold (Medallion) rétegeket notebook-okkal és SQL-lel, és hogyan automatizáld az egészet Databricks Jobs és Delta Live Tables segítségével.
A kurzus során megismerkedtél a Delta Lake haladó funkcióival (OPTIMIZE, ZORDER, VACUUM, time travel, Change Data Feed), amelyek a lakehouse teljesítményének és megbízhatóságának kulcsai. Az MLflow integráció megmutatta, hogyan kösd össze az adatmérnöki munkát a gépi tanulással — a kísérletkövetéstől a modellregisztrációig. A Spark SQL analytics és a Serverless SQL Warehouse biztosítja, hogy a BI eszközök (Power BI, Tableau) gördülékenyen csatlakozzanak az adatokhoz.
Az utolsó szekciók a production-ready üzemeltetést fedték le: a CI/CD pipeline (dbx, GitHub Actions) automatizálja a tesztelést és telepítést, a governance és security (row-level security, column masking, audit logging) pedig biztosítja, hogy az adatok védettek legyenek és a hozzáférés nyomon követhető legyen. Ezek a képességek különbséget tesznek egy tanulási projekt és egy valós vállalati adatplatform között.
A következő lépés az AI Data Engineer kurzus, ahol a lakehouse-ra építve feature store-t, adatminőség-keretrendszert és valós idejű ML pipeline-t fogsz építeni. A Medallion architektúra, az MLflow és a streaming ismeretei egyenesen átvezetnek oda — az alapokat most már ismered.
| Megtanultuk | Következő |
|---|---|
| Unity Catalog, DLT | AI Data Engineer kurzus |
| Medallion architektúra | Feature store építés |
| MLflow, Streaming | Valós idejű ML pipeline |
| Serverless, CI/CD | Production deployment |
AI Data Engineer - feature store és data quality!