Databricks Data Engineer Professional — Übungsfragen und Probeprüfung

Muster zum Flachlegen verschachtelter Daten: 1) Struct: df.select('order_id', 'customer.name', 'customer.email'). SQL: SELECT customer.name FROM orders. 2) Array: df.select('order_id', explode('items').alias('item')). SQL: SELECT EXPLODE(items) FROM orders. 3) Verschachteltes Array von Structs: df.select('order_id', explode('items').alias('item')).select('order_id', 'item.product', 'item.qty'). 4) Map: df.select('order_id', explode('metadata').alias('key', 'value')). 5) Star-Expansion: df.select('order_id', 'customer.*'). Erweitert das Struct zu einzelnen Spalten. 6) Rekursives Flattening: Schreibe für tief verschachtelte Strukturen eine rekursive Funktion, die das Schema durchläuft und die select-Ausdrücke generiert. 7) Zu beachten: Kardinalitätsexplosion — EXPLODE auf Arrays vervielfacht die Zeilenzahl. Nutze array_size(), um die Vergrößerung abzuschätzen. Bei Arrays mit hoher Kardinalität (100+ Elemente) solltest du eine Aggregation vor dem Flattening in Betracht ziehen.

Unity-Catalog-Namespace: 1) Dreistufig: catalog.schema.table. Catalog: organisatorische Grenze auf oberster Ebene. Schema: logische Gruppierung innerhalb eines Katalogs. Table/View/Function: Datenobjekte. 2) Katalogstrategien: pro Geschäftsbereich: finance_catalog, marketing_catalog. Pro Umgebung: dev_catalog, staging_catalog, prod_catalog. Pro Domäne: customers_catalog, orders_catalog. Hybrid: prod_finance, prod_marketing, dev_shared. 3) Delegation der Eigentümerschaft: Der Katalogeigentümer verwaltet seinen Katalog. Kann Schemas anlegen und Berechtigungen vergeben. Kann andere Kataloge nicht ändern. 4) Einheitliche Governance: Der Metastore-Admin legt fest: Standardberechtigungen. Aufbewahrung der Audit-Logs. Anforderungen an die Datenklassifizierung. Das gilt für alle Kataloge. 5) Migration: vom Hive Metastore: default (ein einzelner Katalog) → Migration auf mehrere Kataloge. SHOW DATABASES → wird zu Schemas in einem Katalog. 6) Grenzen: ein Metastore pro Region. Mehrere Kataloge pro Metastore. Hunderte Schemas pro Katalog. Millionen Tabellen pro Schema.

Standard-Python-UDFs in Spark serialisieren die Daten zeilenweise über die Grenze zwischen JVM und Python, was bei großen Datenmengen teuer ist. Pandas-UDFs (auch vektorisierte UDFs genannt) nutzen stattdessen Apache Arrow, um spaltenweise Batches zu übertragen, und führen pandas-Code auf Series oder DataFrames aus, wodurch sich die Serialisierung über viele Zeilen amortisiert. Anders als collect() halten sie die Arbeit über die Executor verteilt, und anders als die RDD API behalten sie die Catalyst-Planung bei. Für eigene Python-Logik, die sich nicht mit nativen Spark-Funktionen ausdrücken lässt, ist eine Pandas-UDF die empfohlene Variante mit hoher Performance. Native Spark-SQL-Funktionen bleiben die erste Wahl, wenn sich die Logik damit ausdrücken lässt. Prüfungstipp: Wenn eine Frage 'eigene Python-Logik' mit 'bester Performance' auf großen Datenmengen kombiniert, wähle die Pandas- bzw. vektorisierte UDF statt einer einfachen Python-UDF.

Bestandteile von Reverse ETL: 1) Quellabfrage: SELECT customer_id, total_orders, avg_order_value, churn_score FROM gold.customer_360 WHERE updated_at > last_sync_time. 2) Sync-Tracking: CREATE TABLE sync_status (record_id STRING, target STRING, last_synced TIMESTAMP, status STRING, error_message STRING). 3) API-Integration: for batch in batches: try: response = crm_api.upsert(batch). update_status(batch, 'synced'). except RateLimitError: sleep(backoff). retry. except APIError as e: update_status(batch, 'failed', str(e)). 4) Idempotenz: Upsert-API-Aufrufe verwenden (anlegen oder aktualisieren). Ein erneuter Lauf synchronisiert dieselben Datensätze ohne Duplikate. 5) Monitoring: Alarm, wenn die Fehlerrate der Synchronisation den Schwellwert überschreitet. Dashboard: synchronisierte Datensätze pro Lauf, Fehlerraten, Latenz. 6) Zeitplan: an den Aktualisierungsrhythmus der Gold-Tabelle anpassen. Wenn Gold täglich um 6 AM aktualisiert wird, synchronisiere um 7 AM mit dem CRM.