En af de vitale færdigheder hos en dygtig dataprofessionel er effektiv håndtering af store datasæt, hvilket sikrer datakvalitet og pålidelighed. Data er den centrale og grundlæggende del af ethvert datasystem, og uanset hvilke gode færdigheder du har inden for andre aspekter af vores branche, er dette en, du ikke har råd til at overse.

I denne artikel udforsker jeg robuste teknikker til at udføre QA-tjek på store datasæt ved hjælp af Deequ-biblioteket og statistiske metoder. Ved at kombinere de tilgange, jeg forklarer nedenfor, vil du være i stand til at bevare dataintegriteten, forbedre din datahåndteringspraksis og forhindre potentielle problemer i downstream-applikationer.

QA-tjek ved hjælp af Deequ-biblioteket

Hvorfor Deequ?

At sikre datakvalitet i stor skala er en skræmmende opgave, især når man har at gøre med milliarder af rækker, der er gemt i distribuerede filsystemer eller datavarehuse. Deequ-biblioteket er en open source-dataprofilering og QA-ramme bygget på Spark, som er et moderne og alsidigt værktøj designet til at løse dette problem. Det, der adskiller det fra lignende værktøjer, er dets evne til at integrere problemfrit med Spark ved at udnytte distribueret processorkraft til effektiv håndtering af store datasæt.

Når du prøver det, vil du se, hvordan dets fleksibilitet giver dig mulighed for at definere komplekse valideringsregler, der er skræddersyet til dine specifikke krav, hvilket sikrer omfattende dækning. Derudover har Deequ omfattende metrikker og anomalidetektionsfunktioner, der vil hjælpe dig med at identificere og proaktivt løse problemer med datakvalitet. For dataprofessionelle, der arbejder med store og dynamiske datasæt, er Deequ en schweizisk knivløsning. Lad os se, hvordan vi kan bruge det.

Opsætning af Deequ

Flere detaljer om Deequ-bibliotekets opsætning og brugssager omkring dataprofilering er tilgængelige her . For nemheds skyld har vi i dette eksempel lige genereret et par legetøjsposter:

 val rdd = spark.sparkContext.parallelize(Seq( Item(1, "Thingy A", "awesome thing.", "high", 0), Item(2, "Thingy B", "available at http://thingb.com", null, 0), Item(3, null, null, "low", 5), Item(4, "Thingy D", "checkout https://thingd.ca", "low", 10), Item(5, "Thingy E", null, "high", 12))) val data = spark.createDataFrame(rdd)

Definition af dataantagelser

De fleste dataapplikationer kommer med implicitte antagelser om dataattributter, såsom ikke-NULL-værdier og unikhed. Med Deequ bliver disse antagelser eksplicitte gennem enhedstests. Her er nogle almindelige kontroller:

1. Rækketælling: Sørg for, at datasættet indeholder et bestemt antal rækker.

   
   

2. Attributtens fuldstændighed: Tjek, at attributter som id og produktnavn aldrig er NULL.

   
   

3. Attribut Uniqueness: Sørg for, at visse attributter, såsom id, er unikke.

   
   

4. Værdiinterval: Bekræft, at attributter som prioritet og numViews falder inden for forventede områder.

   
   

5. Mønstermatchning: Bekræft, at beskrivelser indeholder URL'er, når det forventes.

   
   

6. Statistiske egenskaber: Sørg for, at medianen af numeriske attributter opfylder specifikke kriterier.

Sådan kan du implementere disse kontroller ved hjælp af Deequ:

 import com.amazon.deequ.VerificationSuite import com.amazon.deequ.checks.{Check, CheckLevel, CheckStatus} val verificationResult = VerificationSuite() .onData(data) .addCheck( Check(CheckLevel.Error, "unit testing my data") .hasSize(_ == 5) // we expect 5 rows .isComplete("id") // should never be NULL .isUnique("id") // should not contain duplicates .isComplete("productName") // should never be NULL // should only contain the values "high" and "low" .isContainedIn("priority", Array("high", "low")) .isNonNegative("numViews") // should not contain negative values // at least half of the descriptions should contain a url .containsURL("description", _ >= 0.5) // half of the items should have less than 10 views .hasApproxQuantile("numViews", 0.5, _ <= 10)) .run()

Fortolkning af resultater

Efter at have kørt disse kontroller, oversætter Deequ dem til en række Spark-job, som den udfører for at beregne metrics på dataene. Bagefter påkalder den dine påstandsfunktioner (f.eks. _ == 5 for størrelseskontrollen) på disse metrics for at se, om begrænsningerne holder på dataene. Vi kan inspicere objektet "verificationResult" for at se, om testen fandt fejl:

 import com.amazon.deequ.constraints.ConstraintStatus if (verificationResult.status == CheckStatus.Success) { println("The data passed the test, everything is fine!") } else { println("We found errors in the data:\n") val resultsForAllConstraints = verificationResult.checkResults .flatMap { case (_, checkResult) => checkResult.constraintResults } resultsForAllConstraints .filter { _.status != ConstraintStatus.Success } .foreach { result => println(s"${result.constraint}: ${result.message.get}") } }

Hvis vi kører eksemplet, får vi følgende output:

 We found errors in the data: CompletenessConstraint(Completeness(productName)): Value: 0.8 does not meet the requirement! PatternConstraint(containsURL(description)): Value: 0.4 does not meet the requirement!

Testen viste, at vores antagelser blev overtrådt! Kun 4 ud af 5 (80 %) af værdierne for attributten productName er ikke-null, og kun 2 ud af 5 (dvs. 40 %) værdier af attributten description indeholdt en URL. Heldigvis kørte vi en test og fandt fejlene; nogen bør straks rette op på dataene!

QA-tjek med statistiske metoder

Mens Deequ tilbyder en robust ramme for datavalidering, kan integration af statistiske metoder yderligere forbedre dine QA-tjek, især hvis du har at gøre med aggregerede metrics af et datasæt. Lad os se, hvordan du kan anvende statistiske metoder til at overvåge og sikre datakvalitet.

Sporing af rekordtælling

Overvej et forretningsscenarie, hvor en ETL-proces (Extract, Transform, Load) producerer N poster på et dagligt planlagt job. Supportteams ønsker måske at opsætte QA-tjek for at give en advarsel, hvis der er en væsentlig afvigelse i registreringsantallet. For eksempel, hvis processen typisk genererer mellem 9.500 til 10.500 registreringer dagligt over to måneder, kan enhver væsentlig stigning eller fald indikere et problem med de underliggende data.

Vi kan bruge en statistisk metode til at definere denne tærskel for, hvilken proces der skal give en advarsel til supportteamet. Nedenfor er en illustration af rekordoptælling over to måneder:

For at analysere dette kan vi transformere registreringsdataene for at observere de daglige ændringer. Disse ændringer svinger generelt omkring nul, som vist i følgende diagram:

Når vi repræsenterer denne ændringshastighed med en normalfordeling, danner den en klokkekurve, der indikerer, at dataene er normalfordelt. Den forventede ændring er omkring 0 % med en standardafvigelse på 2,63 %.

Denne analyse tyder på, at rekordtallet typisk falder inden for intervallet -5,26 % til +5,25 % med 90 % konfidens. Baseret på dette kan du etablere en regel for at udløse en alarm, hvis registreringsantallet afviger ud over dette interval, hvilket sikrer rettidig indgriben.

Sporing af attributdækning

Attributdækning refererer til forholdet mellem ikke-NULL-værdier og det samlede registreringsantal for et datasæt-øjebliksbillede. For eksempel, hvis 8 ud af 100 poster har en NULL-værdi for en bestemt attribut, er dækningen for den attribut 92 %.

Lad os gennemgå en anden business case med en ETL-proces, der genererer et øjebliksbillede af produkttabel dagligt. Vi ønsker at overvåge dækningen af produktbeskrivelsesattributter. Hvis dækningen falder under en vis tærskel, bør der udløses en advarsel til supportteamet. Nedenfor er en visuel repræsentation af attributdækning for produktbeskrivelser over to måneder:

Ved at analysere de absolutte dag-til-dag forskelle i dækning, observerer vi, at ændringerne svinger omkring nul:

At repræsentere disse data som en normalfordeling viser, at de er normalfordelt med en forventet ændring på omkring 0 % og en standardafvigelse på 2,45 %.

Som vi ser, for dette datasæt, varierer produktbeskrivelsens attributdækning typisk fra -4,9 % til +4,9 % med 90 % sikkerhed. Baseret på denne indikator kan vi indstille en regel for at give en alarm, hvis dækningen afviger ud over dette interval.

QA-tjek med tidsseriealgoritmer

Hvis du arbejder med datasæt, der viser betydelige variationer på grund af faktorer som sæsonbestemt eller tendenser, kan traditionelle statistiske metoder udløse falske advarsler. Tidsseriealgoritmer tilbyder en mere raffineret tilgang, der forbedrer nøjagtigheden og pålideligheden af dine QA-tjek.

For at producere mere fornuftige advarsler kan du bruge enten Autoregressive Integrated Moving Average (ARIMA) eller den Holt-vintre metode . Førstnævnte er god nok til datasæt med trends, men sidstnævnte lader os beskæftige os med datasæt med både trend og sæsonbestemte. Denne metode bruger komponenter til niveau, trend og sæsonbestemthed, hvilket gør det muligt for den at tilpasse sig fleksibelt til ændringer over tid.

Lad os modellere daglige salg, der viser både trend- og sæsonmønstre ved hjælp af Holt-Winters:

 import pandas as pd from statsmodels.tsa.holtwinters import ExponentialSmoothing # Load and preprocess the dataset data = pd.read_csv('sales_data.csv', index_col='date', parse_dates=True) data = data.asfreq('D').fillna(method='ffill') # Fit the Holt-Winters model model = ExponentialSmoothing(data, trend='add', seasonal='add', seasonal_periods=365) fit = model.fit() # Forecast and detect anomalies forecast = fit.fittedvalues residuals = data - forecast threshold = 3 * residuals.std() anomalies = residuals[abs(residuals) > threshold] print("Anomalies detected:") print(anomalies)

Ved at bruge denne metode kan du opdage betydelige afvigelser, der kan indikere datakvalitetsproblemer, hvilket giver en mere nuanceret tilgang til kvalitetskontrol.

Jeg håber, at denne artikel vil hjælpe dig med effektivt at implementere QA-tjek for dine store datasæt. Ved at bruge Deequ-biblioteket og integrere statistiske metoder og tidsseriealgoritmer kan du sikre dataintegritet og pålidelighed, hvilket i sidste ende forbedrer din datahåndteringspraksis.

Implementering af teknikkerne beskrevet ovenfor vil hjælpe dig med at forhindre potentielle problemer i downstream-applikationer og forbedre den overordnede kvalitet af dine dataarbejdsgange.