Domande da colloquio per Data Engineer

Approccio — Funzione finestra con ordinamento deterministico

Assegnerei un numero di riga con row_number() over (partition by event_id order by updated_at desc, ingestion_at desc, source_sequence desc) e conserverei il rango uno. L’ordinamento deve essere deterministico; updated_at da solo spesso non basta in caso di parità. Confermerei prima che event_id sia la chiave aziendale e che gli aggiornamenti successivi possano sostituire eventi precedenti. Per l’elaborazione incrementale, gestirei i dati tardivi mediante una finestra retrospettiva o MERGE e scriverei in modo idempotente. Misurerei duplicati, chiavi nulle e conflitti invece di eliminarli in silenzio.

Approccio — Attività valida → data → utenti univoci → partizione incrementale

Per prima cosa definirei quali eventi rappresentano attività e quali utenti di prova, bot o interni escludere. Normalizzerei poi event_at secondo fuso orario e data concordati e conterei gli user_id distinti per giorno. La trasformazione viene preparata per la produzione con scrittura partizionata per event_date, ripetizione idempotente, gestione degli eventi tardivi e controlli di qualità. Confronterei i volumi di origine e destinazione, monitorerei variazioni anomale e documenterei definizione e freschezza dei dati.

Approccio — Delimitare il cambiamento → piano di esecuzione → volume → join e filtri → risorse

Per prima cosa determinerei quando è iniziato il peggioramento e se sono cambiati codice, schema, volume, distribuzione, statistiche, partizioni o risorse del warehouse. Confronterei poi i piani di esecuzione cercando scansioni complete, strategie di join inefficienti, spill, skew o assenza di partition pruning. Esaminerei crescita delle righe, cardinalità e granularità dei join; un nuovo one-to-many può moltiplicare i dati. I miglioramenti possono includere filtri e aggregazioni anticipate, diverso ordine dei join, partizioni o clustering adeguati, statistiche aggiornate e più risorse. Misurerei tempo, byte letti, shuffle e costo prima e dopo.

Approccio — Processi aziendali → fatti → dimensioni → granularità → metriche

Partirei da navigazione, carrello, ordini, pagamenti, spedizioni, resi, rimborsi, inventario e attribuzione. I possibili fatti includono fact_orders per ordine, fact_order_items per riga, fact_payments, fact_refunds, fact_shipments e snapshot giornalieri dell’inventario. Le dimensioni comprendono cliente, prodotto, data, magazzino, canale e campagna. Definirei esplicitamente ogni granularità. I ricavi per categoria derivano dalle righe; il ciclo di vita da clienti o abbonamenti; l’inventario dagli snapshot. Considererei inoltre cambiamenti storici degli attributi, cancellazioni, sconti per ordine o riga, valute, imposte, acquisti come ospite e dati tardivi. Convaliderei rispetto a Finanza e ai sistemi di transazioni, pagamenti e magazzino.

Approccio — Tipo 1 o tipo 2 in base alla necessità della cronologia

Il tipo 1 sovrascrive i valori precedenti ed è adatto quando conta soltanto lo stato attuale. Il tipo 2 crea una nuova riga della dimensione per ogni cambiamento, con inizio validità, fine validità, current_flag e chiave surrogata. Se un cliente passa dalla regione Ovest alla regione Est, il tipo 1 riassegna anche i ricavi storici. Il tipo 2 conserva la regione corretta per ogni periodo e collega i fatti alla versione valida alla data dell’evento. Questo aggiunge complessità per chiavi, join temporali, fatti tardivi e viste attuali rispetto a quelle storiche. L’esigenza aziendale deve determinare l’approccio.

Approccio — Governance e flessibilità rispetto a semplicità e prestazioni delle query

Uno schema a stella separa fatti e dimensioni. Favorisce dimensioni riutilizzabili, metriche coerenti, granularità chiara e analisi flessibili con minore duplicazione. Le tabelle ampie funzionano bene per dashboard molto usate, casi analitici specifici o feature di ML quando semplicità e velocità delle query sono prioritarie, ma possono duplicare dati e favorire definizioni contrastanti. Spesso la soluzione migliore combina fatti e dimensioni canonici con data mart o tabelle ampie per consumatori specifici. La scelta dipende da volume, utenti, strumento BI, costo, latenza e frequenza delle modifiche.

Approccio — Estrarre → salvare dati grezzi → trasformare → convalidare → pubblicare → monitorare

Chiarirei freschezza, volume, carico accettabile sull’origine, consumatori e correzioni successive. Estrarrei gli ordini in modo incrementale mediante updated_at o CDC, conserverei una copia immutabile in object storage o in una tabella raw, pulirei in staging e pubblicherei fact_orders e fact_order_items. Un orchestratore gestirebbe le dipendenze. I tentativi ripetuti devono essere deterministici tramite MERGE, sostituzione delle partizioni o scambio atomico. Una finestra retrospettiva acquisirebbe le modifiche tardive. I controlli comprenderebbero righe, chiavi nulle, ID duplicati, ricavi, stati, freschezza e riconciliazione con l’origine. Gli avvisi coprirebbero errori, volumi anomali, duplicati e ritardi; responsabili e dipendenze sarebbero documentati.

Approccio — Lo stesso input e la stessa ripetizione producono lo stesso output

Una pipeline idempotente può essere eseguita più volte con lo stesso input e produrre sempre lo stesso stato corretto, senza duplicati o effetti collaterali inattesi. È essenziale per tentativi ripetuti e backfill. Un processo non idempotente aggiungerebbe nuovamente gli ordini di ieri a ogni esecuzione. Una variante robusta sostituisce la partizione di destinazione, esegue MERGE sulla chiave primaria oppure scrive prima in una posizione temporanea e realizza uno scambio atomico. Servono chiavi univoche, partizioni adeguate, trasformazioni deterministiche ed effetti collaterali controllati.

Approccio — Rilevare → classificare → proteggere → comunicare → migrare

Rileverei le modifiche tramite un registry, controlli dei metadati, test di contratto o convalida dell’acquisizione e le classificherei come colonna aggiunta, eliminata o rinominata, modifica del tipo, della nullabilità o del significato. Una colonna nullable è spesso compatibile; rinomina, eliminazione o modifica del tipo possono interrompere i consumatori. I cambiamenti semantici sono particolarmente pericolosi perché lo schema può restare valido. Conserverei i dati grezzi e applicherei contratti e compatibilità alle fonti critiche. Davanti a una modifica incompatibile, coordinerei il responsabile dell’origine, versionerei lo schema, adatterei le trasformazioni, ricostruirei la cronologia se necessario e informerei i consumatori interessati in base al lineage.

Approccio — Latenza decisionale rispetto alla complessità

Lo streaming ha senso quando una bassa latenza produce valore reale, per esempio nel rilevamento delle frodi, negli avvisi operativi, nella personalizzazione, nell’aggiornamento dell’inventario o nelle funzioni basate su eventi recenti. Per report giornalieri, analisi storiche, riconciliazioni finanziarie e trasformazioni orarie, il batch è spesso più semplice, economico e facile da riprodurre. La decisione dipende da freschezza, volume, ordine, elaborazione con stato, tolleranza agli errori, esperienza del team, costo e consumatori. Lo streaming aggiunge lavoro per duplicati, eventi tardivi, checkpoint, schemi e monitoraggio. Sceglierei l’architettura più semplice che soddisfi l’esigenza aziendale.

Approccio — Eventi → flusso → arricchimento → regole o modello → azione → archiviazione → monitoraggio

Chiarirei volume, obiettivo di latenza, tipo di decisione, falsi positivi tollerabili e se una transazione vada bloccata o esaminata. Gli eventi di pagamento entrerebbero in Kafka o Kinesis. Un processore convaliderebbe lo schema, deduplicherebbe per event_id, aggiungerebbe attributi di utente, dispositivo, esercente e velocità e applicherebbe regole o un modello. Un rischio elevato provocherebbe blocco, autenticazione aggiuntiva o revisione manuale. Eventi e decisioni verrebbero salvati per audit e training. Sono fondamentali ordine, duplicati, freschezza delle feature, dimensione dello stato, backpressure, dead-letter queue, replay, latenza e versionamento. Codici esplicativi, monitoraggio dei falsi positivi e rollback proteggono clienti e operations.

Approccio — Ridistribuzione dei dati tra partizioni

Uno shuffle si verifica quando Spark ridistribuisce i dati tra le partizioni per groupBy, join, distinct, orderBy o repartition. Richiede trasferimento di rete, serializzazione, I/O su disco e coordinamento. Un risultato intermedio grande o una chiave molto frequente può rallentare alcune attività o esaurire la memoria. Ridimensionerei gli shuffle con filtri anticipati, soltanto le colonne necessarie, preaggregazione, broadcast join per tabelle piccole, partizioni adeguate, salting in presenza di skew ed evitando distinct o orderBy inutili. Nella Spark UI esaminerei stage, shuffle read e write, spill, durata delle attività e memoria degli executor.

Approccio — Localizzare lo stage → ridurre i dati → correggere lo skew → regolare le partizioni → eliminare operazioni problematiche

Userei Spark UI e i log per localizzare stage, operazione, partizione ed executor. Le cause possono essere skew, join grandi, collect(), partizioni eccessive, UDF inefficienti o troppi dati in cache. Filtrerei e proietterei in anticipo, userei partition pruning, esaminerei i broadcast join, applicherei salting alle chiavi frequenti e regolerei il numero di partizioni. Sostituirei collect() grandi e UDF Python quando bastano funzioni native e manterrei in cache soltanto dati riutilizzati. Aumentare la memoria può aiutare, ma migliorare la distribuzione e il piano è più sostenibile che ampliare il cluster senza criterio.

Approccio — Formato colonnare, schema, compressione e predicate pushdown

Parquet archivia per colonne, conserva tipi e schema, comprime in modo efficiente e consente column pruning e predicate pushdown. Poiché le query analitiche leggono spesso poche colonne, esaminano meno dati. CSV è testo portabile, ma non dispone di tipi, occupa più spazio, è più lento e presenta problemi di delimitatori ed escape. Può essere adatto a piccole esportazioni e scambi, ma Parquet è di solito più rapido ed economico come formato principale in data lake o warehouse.

Approccio — Freschezza → completezza → unicità → validità → riconciliazione

Verificherei freschezza, volume delle righe, valori nulli nelle chiavi primarie, transazioni duplicate, stati e valute validi, importi e date ammissibili e integrità referenziale tra ordini, pagamenti, rimborsi e clienti. Riconcilierei inoltre i ricavi con il sistema dei pagamenti o Finanza e monitorerei gli scostamenti rispetto al giorno e alla settimana precedenti, tenendo conto della stagionalità. Le regole devono escludere test e cancellazioni, sottrarre i rimborsi dai ricavi netti e convertire correttamente le valute. Ogni avviso richiede responsabile, azione, tabella interessata, gravità, impatto downstream e runbook.

Approccio — Valutare l’impatto → confrontare le versioni → seguire il lineage → mitigare → correggere la causa

Per prima cosa chiarirei dashboard, metrica, utenti, periodo e decisioni interessate e se il nuovo valore sia errato oppure corregga un errore precedente. Confronterei output precedente e nuovo per tabella, partizione, righe, valori univoci, totali e segmenti e seguirei le modifiche attraverso il lineage. Esaminerei codice, schema, filtri, join, deduplicazione e date. Se il valore fosse errato, ripristinerei la trasformazione o la versione della tabella, disattiverei o etichetterei la vista e ricostruirei poi i dati corretti. Comunicherei impatto, grado di certezza, tempo stimato e se le decisioni precedenti vadano riviste.

Approccio — Strumentazione → acquisizione → archiviazione → elaborazione → modellazione → serving → governance

Chiarirei volume, latenza, consumatori, conservazione, evoluzione dello schema, privacy e affidabilità. I client invierebbero eventi tipizzati tramite un SDK con event_name, ID utente e sessione, timestamp, proprietà, versione dell’applicazione e piattaforma. Un collector scriverebbe su un flusso durevole e salverebbe gli eventi grezzi in object storage per il replay e in un warehouse o lakehouse per l’analisi. L’elaborazione convaliderebbe gli schemi, deduplicherebbe, filtrerebbe bot e utenti interni, creerebbe sessioni e risolverebbe le identità. Da qui nascerebbero fact_events, fact_sessions, dim_users e data mart. Contratti, schema registry, regole su PII e consenso, lineage, responsabili e avvisi di freschezza e volume proteggerebbero la piattaforma. Il serving comprenderebbe BI, esperimenti, reverse ETL e feature store.

Approccio — Coerenza offline/online → definizioni → freschezza → serving → monitoraggio

Un feature store offre feature riutilizzabili e affidabili per training e serving. Le feature offline vengono archiviate per data ed entità nel warehouse o lakehouse; quelle online in un archivio chiave-valore a bassa latenza. Un registry documenta nome, responsabile, chiave dell’entità, trasformazione, SLA di freschezza, fonti e descrizione. La point-in-time correctness impedisce che il training usi informazioni future. Le trasformazioni online e offline devono condividere la logica o essere confrontate con test rigorosi. Il monitoraggio copre freschezza, valori nulli, drift della distribuzione, latenza di serving, training-serving skew e impatto del modello; la governance controlla PII, lineage, autorizzazioni e dismissione.

Approccio — Impatto → triage → mitigazione → causa → prevenzione

Sceglierei un incidente con impatto reale: dati mancanti, metriche errate, duplicati, una dashboard non funzionante o una funzione interessata. Spiegherei prima chi ne ha risentito e perché era importante. Descriverei poi il triage tramite log, orchestratore, freschezza delle fonti, deployment, schemi, righe, partizioni e lineage e la mitigazione tramite nuovo tentativo, rollback, correzione, backfill o avviso. La risposta più solida termina con la prevenzione: controlli di qualità, avvisi, contratti, scritture idempotenti, runbook, lineage o deployment più sicuri. Deve dimostrare responsabilità e comunicazione, non cercare colpevoli.

Approccio — Chiarire → riprodurre → seguire il lineage → risolvere → documentare

Preciserei metrica, tabella, periodo, filtri, valore atteso e ragionamento aziendale. Riprodurrei poi la query ed esaminerei granularità, filtri, join, fuso orario, freschezza, definizione e modifiche recenti lungo il lineage. Se i dati fossero errati, li correggerei e comunicherei l’impatto. Se fossero tecnicamente corretti ma la definizione differisse, concorderemmo la definizione aziendale e la documenteremmo. Se l’incertezza persistesse, spiegherei cosa sappiamo, cosa stiamo verificando e quando risponderemo. Risposte tempestive e basate sulle prove generano fiducia.

Approccio — Impatto → affidabilità → urgenza → dipendenze → effetto moltiplicatore

Stabilirei la priorità in base a impatto aziendale, rischio di affidabilità, urgenza, dipendenze downstream ed effetto moltiplicatore. Una pipeline dei ricavi non funzionante o un rischio di conformità viene prima di un modello facoltativo; un miglioramento della piattaforma può produrre più valore di molte richieste isolate. Separerei incidenti, lavoro strategico sulla piattaforma, richieste, debito tecnico e carico operativo. Un processo equilibrato usa responsabili, SLA, gravità, roadmap e compromessi trasparenti e chiarisce cosa viene rinviato e quale rischio comporta.