Come affrontare l’elaborazione di grandi volumi di dati?

Question

IT Interview Practice · Accepted Answer

**Parti dal risultato, dalla scadenza e dalle regole di correttezza prima di scegliere uno strumento big data.** Un dataset grande non richiede automaticamente un framework di elaborazione distribuita.

Supponiamo che ogni mattina servano i ricavi di ieri per commerciante. È diverso dal rilevare un pagamento sospetto prima di approvarlo. Entrambi possono coinvolgere molti record, ma il primo consente elaborazione pianificata mentre il secondo richiede una decisione tempestiva.

## 1. Definisci cosa elaborare

Chiarisci quanti dati esistono, quanto velocemente arrivano i nuovi, quali campi servono e per quanto conservarli. Per il report dei ricavi, concorda se i rimborsi modificano il giorno originale o quello del rimborso. Senza questa regola, una pipeline più veloce può comunque produrre il totale sbagliato.

Definisci anche la fonte di verità e la gestione dei record tardivi o corretti. Queste decisioni determinano se un risultato passato può essere definitivo o dovrà essere rivisto.

## 2. Riduci il lavoro prima di distribuirlo

Misura dove finiscono tempo e risorse: lettura dei file, query, calcolo, trasferimenti di rete o scrittura dei risultati. Poi filtra presto i record irrilevanti e leggi solo le colonne necessarie al report.

Elabora blocchi di dimensione limitata invece di caricare tutto in memoria. Se un worker termina entro la scadenza a un costo accettabile, può essere il sistema più semplice da gestire. Più macchine introducono costi di coordinamento e trasferimento: aggiungile per superare un limite osservato.

## 3. Scegli batch o streaming in base alla scadenza

| Esigenza | Approccio iniziale | Motivo e responsabilità |
|---|---|---|
| Report completo ogni mattina | Batch pianificato | Un input finito è più facile da riconciliare e rielaborare; deve terminare entro la scadenza |
| Dashboard aggiornata durante il giorno | Batch incrementali o streaming | Elabora più spesso i nuovi dati; definisci come le correzioni modificano i totali precedenti |
| Decisioni poco dopo ogni evento | Streaming | Riduce il ritardo gestendo duplicati, eventi tardivi e recupero |

Streaming significa elaborare continuamente i dati in arrivo, non presumere che ogni evento arrivi una sola volta e in ordine. Per il report giornaliero partirei da un batch, salvo una reale necessità di risultati più aggiornati.

## 4. Rendi sicuri i guasti parziali

Immagina che il worker scriva un totale e si arresti prima di registrare l'avanzamento. Al riavvio può elaborare gli stessi record. Se aggiunge di nuovo gli importi, i ricavi risultano sovrastimati.

Usa identificatori stabili e scritture ripetibili in sicurezza, oppure coordina output e avanzamento in una transazione dove supportato. Un checkpoint registra il progresso completato; salvarlo prima che l'output sia al sicuro può saltare lavoro dopo un arresto. Salvarlo dopo richiede di rielaborare in sicurezza quella finestra.

- Conserva la sorgente abbastanza a lungo da rielaborare il periodo necessario.
- Separa i record non validi per analizzarli invece di scartarli silenziosamente.
- Limita la velocità con cui i worker alimentano una destinazione più lenta. Questa backpressure evita buffer o code in crescita continua.

Il recupero fa parte del progetto, non è un'attività di pulizia dopo il primo guasto.

## 5. Distribuisci solo il lavoro che ne ha bisogno

Quando un worker non basta, dividi l'input in parti indipendenti. Controlla la distribuzione reale: un commerciante molto grande può tenere occupato un worker mentre gli altri finiscono presto.

Raggruppamenti e join possono richiedere trasferimenti tra worker, chiamati shuffle. Riduci prima i dati dove possibile e verifica che la destinazione accetti l'output complessivo. Spark offre tecniche rilevanti, ma la loro applicabilità dipende da query e versione; vedi la [guida alle prestazioni](https://spark.apache.org/docs/3.5.6/sql-performance-tuning.html).

Anche lo storage deve seguire gli accessi. File colonnari come Parquet possono essere adatti a scansioni analitiche su campi selezionati, mentre un database indicizzato può servire meglio le singole ricerche operative. Scegli in base agli accessi misurati, non solo alla dimensione dei file.

## 6. Dimostra insieme velocità e correttezza

Confronta il risultato con un piccolo dataset affidabile, controllando conteggi e totali aziendali. Includi duplicati, rimborsi, record tardivi e un arresto tra scrittura dell'output e salvataggio del progresso.

Poi prova volumi e squilibri realistici, misurando durata, picco di memoria, arretrato e costo. Per il report dei ricavi, successo significa un totale corretto e riproducibile entro la scadenza concordata. **Scegli la pipeline più semplice che rispetta queste condizioni e recupera senza perdere o contare due volte i dati.**

Esigenza	Approccio iniziale	Motivo e responsabilità
Report completo ogni mattina	Batch pianificato	Un input finito è più facile da riconciliare e rielaborare; deve terminare entro la scadenza
Dashboard aggiornata durante il giorno	Batch incrementali o streaming	Elabora più spesso i nuovi dati; definisci come le correzioni modificano i totali precedenti
Decisioni poco dopo ogni evento	Streaming	Riduce il ritardo gestendo duplicati, eventi tardivi e recupero

1. Definisci cosa elaborare

2. Riduci il lavoro prima di distribuirlo

3. Scegli batch o streaming in base alla scadenza

4. Rendi sicuri i guasti parziali

5. Distribuisci solo il lavoro che ne ha bisogno

6. Dimostra insieme velocità e correttezza

Domande correlate