Hvordan griber du behandling af store datamængder an?

Question

IT Interview Practice · Accepted Answer

**Begynd med resultatet, fristen og korrekthedsreglerne før valg af big-data-værktøj.** Store datamængder kræver ikke automatisk distribueret behandling.

Virksomheden behøver måske gårsdagens omsætning pr. sælger hver morgen. Det adskiller sig fra at opdage en mistænkelig betaling før godkendelse. Begge kan omfatte mange poster, men den ene tillader planlagt behandling, den anden kræver en hurtig beslutning.

## 1. Definér databehandlingen

Afklar eksisterende mængde, tilgangshastighed, nødvendige felter og opbevaringstid. Aftal for omsætningen, om refundering retter den oprindelige dag eller refunderingsdagen. Uden reglen kan en hurtigere pipeline stadig give forkert total.

Definér også sandhedskilden og behandling af forsinkede eller rettede poster. Det afgør, om tidligere resultater kan afsluttes eller senere skal revideres.

## 2. Reducér arbejdet før distribution

Mål tids- og ressourceforbrug: fillæsning, databaseforespørgsler, beregning, netværk eller resultatskrivning. Filtrér derefter irrelevante poster tidligt, og læs kun rapportens kolonner.

Behandl afgrænsede portioner i stedet for at hente alt i hukommelsen. Hvis én worker når fristen til rimelig pris, kan det være lettest at drive. Flere maskiner medfører koordinering og overførsel, så brug dem mod en observeret grænse.

## 3. Vælg batch eller streaming efter fristen

| Behov | Udgangspunkt | Begrundelse og ansvar |
|---|---|---|
| Fuld rapport hver morgen | Planlagt batch | Et endeligt input er lettere at afstemme og genkøre; det skal nå fristen |
| Dashboard opdateret i løbet af dagen | Inkrementelle batches eller streaming | Behandl nye data hyppigere; definér rettelser af tidligere totaler |
| Beslutning kort efter hver hændelse | Streaming | Mindre forsinkelse med håndtering af dubletter, sene hændelser og gendannelse |

Streaming betyder løbende behandling, ikke en antagelse om, at alt kommer én gang og i rækkefølge. For den daglige rapport ville jeg starte med batch, medmindre forretningen virkelig behøver friskere resultater.

## 4. Gør delvise fejl sikre

En worker kan skrive omsætningstotalen og bryde ned før registrering af fremdrift. Ved genstart kan de samme poster behandles igen. Simpel addition igen overvurderer omsætningen.

Brug stabile post-ID'er og sikkert gentagelige skrivninger, eller koordinér output og fremdrift transaktionelt, hvor muligt. Et checkpoint registrerer gennemført arbejde; gemmes det før sikkert output, kan genstart springe arbejde over. Gemmes det efter, kræver hullet sikker genafspilning.

- Bevar kildedata længe nok til at genafspille den nødvendige periode.
- Udskil ugyldige poster til undersøgelse frem for lydløst at smide dem væk.
- Begræns workers' hastighed mod en langsommere destination. Denne backpressure forhindrer uendeligt voksende hukommelsesbuffer eller kø.

Gendannelse er en del af designet, ikke oprydning efter første fejl.

## 5. Distribuér kun nødvendigt arbejde

Når én worker ikke er nok, opdeles input i uafhængige dele. Kontrollér den faktiske fordeling: én meget stor sælger kan holde én worker travl længe efter resten.

Gruppering og joins kan flytte poster mellem workers, kaldet shuffle. Reducér data før flytningen, hvor muligt, og kontrollér destinationens samlede skrivekapacitet. Spark tilbyder relevante teknikker, men anvendelsen afhænger af forespørgsel og version; se [ydelsesvejledningen](https://spark.apache.org/docs/3.5.6/sql-performance-tuning.html).

Lagring bør også følge adgangsmønstre. Kolonnefiler som Parquet kan passe til analytiske scanninger af udvalgte felter, mens en indekseret database passer bedre til enkelte driftsopslag. Vælg efter målte behov frem for filstørrelse alene.

## 6. Bevis hastighed og korrekthed sammen

Sammenlign med et lille troværdigt datasæt og kontrollér både antal og forretningstotaler. Medtag dubletter, refunderinger, sene poster og nedbrud mellem output og fremdriftslagring.

Test derefter realistisk volumen og skævhed med måling af køretid, maksimal hukommelse, ophobning og pris. Rapportens succes er en korrekt, reproducerbar total før fristen. **Vælg den enkleste pipeline, der opfylder kravene og gendanner uden tab eller dobbeltoptælling.**

Behov	Udgangspunkt	Begrundelse og ansvar
Fuld rapport hver morgen	Planlagt batch	Et endeligt input er lettere at afstemme og genkøre; det skal nå fristen
Dashboard opdateret i løbet af dagen	Inkrementelle batches eller streaming	Behandl nye data hyppigere; definér rettelser af tidligere totaler
Beslutning kort efter hver hændelse	Streaming	Mindre forsinkelse med håndtering af dubletter, sene hændelser og gendannelse

1. Definér databehandlingen

2. Reducér arbejdet før distribution

3. Vælg batch eller streaming efter fristen

4. Gør delvise fejl sikre

5. Distribuér kun nødvendigt arbejde

6. Bevis hastighed og korrekthed sammen

Relaterede spørgsmål