Databricks Data Engineer Professional — Questions d'entraînement et examen blanc

Modèles d'aplatissement des données imbriquées : 1) Struct : df.select('order_id', 'customer.name', 'customer.email'). SQL : SELECT customer.name FROM orders. 2) Tableau : df.select('order_id', explode('items').alias('item')). SQL : SELECT EXPLODE(items) FROM orders. 3) Tableau imbriqué de 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) Expansion par étoile : df.select('order_id', 'customer.*'). Développe le struct en colonnes individuelles. 6) Aplatissement récursif : pour les structures très imbriquées, écris une fonction récursive qui parcourt le schéma et génère les expressions select. 7) Points de vigilance : explosion de la cardinalité — EXPLODE sur des tableaux multiplie le nombre de lignes. Utilise array_size() pour estimer l'expansion. Pour les tableaux à forte cardinalité (100+ éléments), envisage une agrégation avant l'aplatissement.

Namespace d'Unity Catalog : 1) Trois niveaux : catalog.schema.table. Catalog : frontière organisationnelle de plus haut niveau. Schema : regroupement logique au sein d'un catalogue. Table/View/Function : objets de données. 2) Stratégies de catalogue : par business unit : finance_catalog, marketing_catalog. Par environnement : dev_catalog, staging_catalog, prod_catalog. Par domaine : customers_catalog, orders_catalog. Hybride : prod_finance, prod_marketing, dev_shared. 3) Délégation de la propriété : le propriétaire du catalogue gère son catalogue. Il peut créer des schémas et accorder des permissions. Il ne peut pas modifier les autres catalogues. 4) Cohérence de la gouvernance : l'admin du metastore définit : les permissions par défaut. La rétention des audit logs. Les exigences de classification des données. Cela s'applique à tous les catalogues. 5) Migration : depuis le metastore Hive : default (catalogue unique) → migration vers plusieurs catalogues. SHOW DATABASES → devient des schémas dans un catalogue. 6) Limites : un metastore par région. Plusieurs catalogues par metastore. Des centaines de schémas par catalogue. Des millions de tables par schéma.

Les UDF Python standard de Spark sérialisent les données ligne par ligne à la frontière entre la JVM et Python, ce qui coûte cher à grande échelle. Les UDF Pandas (aussi appelées UDF vectorisées) utilisent à la place Apache Arrow pour transférer des batches en colonnes et exécuter du code pandas sur des Series ou des DataFrames, ce qui amortit la sérialisation sur de nombreuses lignes. Contrairement à collect(), elles gardent le travail distribué sur les executors, et contrairement à l'API RDD, elles conservent la planification Catalyst. Pour une logique Python personnalisée qui ne peut pas s'exprimer avec les fonctions natives de Spark, l'UDF Pandas est le choix haute performance recommandé. Les fonctions natives de Spark SQL restent préférables lorsque la logique peut s'exprimer avec elles. Astuce d'examen : quand une question associe 'logique Python personnalisée' et 'meilleures performances' sur de gros volumes, choisis l'UDF Pandas/vectorisée plutôt qu'une simple UDF Python.

Composants du reverse ETL : 1) Requête source : SELECT customer_id, total_orders, avg_order_value, churn_score FROM gold.customer_360 WHERE updated_at > last_sync_time. 2) Suivi de la synchronisation : CREATE TABLE sync_status (record_id STRING, target STRING, last_synced TIMESTAMP, status STRING, error_message STRING). 3) Intégration API : 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) Idempotence : utiliser des appels d'API upsert (créer ou mettre à jour). Une nouvelle exécution synchronise les mêmes enregistrements sans doublons. 5) Monitoring : alerter quand le taux d'échec de synchronisation dépasse le seuil. Dashboard : enregistrements synchronisés par exécution, taux d'erreur, latence. 6) Planification : l'aligner sur la cadence de rafraîchissement de la table gold. Si gold est rafraîchie chaque jour à 6 AM, synchronise vers le CRM à 7 AM.