Databricks Data Engineer Professional — Questões de prática e simulado

Padrões para achatar dados aninhados: 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) Array aninhado 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) Expansão com estrela: df.select('order_id', 'customer.*'). Expande o struct em colunas individuais. 6) Achatamento recursivo: para estruturas muito aninhadas, escreva uma função recursiva que percorra o schema e gere as expressões select. 7) Considerações: explosão de cardinalidade — EXPLODE em arrays multiplica a quantidade de linhas. Use array_size() para estimar a expansão. Para arrays de alta cardinalidade (100+ elementos), considere agregar antes de achatar.

Namespace do Unity Catalog: 1) Três níveis: catalog.schema.table. Catalog: fronteira organizacional de nível superior. Schema: agrupamento lógico dentro de um catálogo. Table/View/Function: objetos de dados. 2) Estratégias de catálogo: por unidade de negócio: finance_catalog, marketing_catalog. Por ambiente: dev_catalog, staging_catalog, prod_catalog. Por domínio: customers_catalog, orders_catalog. Híbrida: prod_finance, prod_marketing, dev_shared. 3) Delegação de propriedade: o dono do catálogo gerencia o próprio catálogo. Pode criar schemas e conceder permissões. Não pode modificar outros catálogos. 4) Consistência da governança: o admin do metastore define: permissões padrão. Retenção dos audit logs. Requisitos de classificação de dados. Isso vale para todos os catálogos. 5) Migração: a partir do metastore Hive: default (catálogo único) → migrar para múltiplos catálogos. SHOW DATABASES → passa a ser schemas dentro de um catálogo. 6) Limites: um metastore por região. Múltiplos catálogos por metastore. Centenas de schemas por catálogo. Milhões de tabelas por schema.

As UDFs Python padrão no Spark serializam os dados uma linha por vez na fronteira entre a JVM e o Python, o que fica caro em escala. As UDFs de Pandas (também chamadas de UDFs vetorizadas) usam o Apache Arrow para mover batches colunares e executar código pandas sobre Series ou DataFrames, amortizando a serialização entre muitas linhas. Diferente de collect(), elas mantêm o trabalho distribuído entre os executors e, diferente da API de RDD, preservam o planejamento do Catalyst. Para lógica Python personalizada que não pode ser expressa com funções nativas do Spark, uma UDF de Pandas é a escolha recomendada de alto desempenho. As funções nativas do Spark SQL continuam preferíveis quando a lógica pode ser expressa com elas. Dica de prova: quando uma questão combina 'lógica Python personalizada' com 'melhor desempenho' em grandes volumes de dados, escolha a UDF de Pandas/vetorizada em vez de uma UDF Python comum.

Componentes do reverse ETL: 1) Consulta de origem: SELECT customer_id, total_orders, avg_order_value, churn_score FROM gold.customer_360 WHERE updated_at > last_sync_time. 2) Acompanhamento da sincronização: CREATE TABLE sync_status (record_id STRING, target STRING, last_synced TIMESTAMP, status STRING, error_message STRING). 3) Integração com a 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) Idempotência: usar chamadas de upsert na API (criar ou atualizar). Reexecutar sincroniza os mesmos registros sem duplicatas. 5) Monitoramento: alertar quando a taxa de falhas de sincronização ultrapassar o limite. Dashboard: registros sincronizados por execução, taxas de erro, latência. 6) Agendamento: alinhar com a cadência de atualização da tabela gold. Se a gold é atualizada diariamente às 6 AM, sincronize com o CRM às 7 AM.