Viena no pieredzējuša datu profesionāļa būtiskajām prasmēm ir efektīva lielu datu kopu apstrāde, nodrošinot datu kvalitāti un uzticamību. Dati ir jebkuras datu sistēmas centrālā un pamatelements, un neatkarīgi no jūsu labām iemaņām citos mūsu tirdzniecības aspektos, jūs nevarat atļauties to neievērot.

Šajā rakstā es izpētu spēcīgas metodes, lai veiktu QA pārbaudes lielām datu kopām, izmantojot Deequ bibliotēku un statistikas metodes. Apvienojot tālāk aprakstītās pieejas, jūs varēsit saglabāt datu integritāti, uzlabot datu pārvaldības praksi un novērst iespējamās problēmas pakārtotajās lietojumprogrammās.

QA pārbaudes, izmantojot Deequ bibliotēku

Kāpēc Deequ?

Datu kvalitātes nodrošināšana mērogā ir biedējošs uzdevums, jo īpaši, ja tiek risināti miljardiem rindu, kas glabājas sadalītās failu sistēmās vai datu noliktavās. Deequ bibliotēka ir atvērtā koda datu profilēšanas un kvalitātes nodrošināšanas sistēma, kas izveidota uz Spark, kas ir moderns un daudzpusīgs rīks, kas paredzēts šīs problēmas risināšanai. Tas, kas to atšķir no līdzīgiem rīkiem, ir tā spēja nemanāmi integrēties ar Spark, izmantojot sadalīto apstrādes jaudu efektīvai liela mēroga datu kopu apstrādei.

Izmēģinot to, jūs redzēsiet, kā tā elastība ļauj definēt sarežģītus validācijas noteikumus, kas pielāgoti jūsu īpašajām prasībām, nodrošinot visaptverošu pārklājumu. Turklāt Deequ piedāvā plašus rādītājus un anomāliju noteikšanas iespējas, kas palīdzēs identificēt un proaktīvi risināt datu kvalitātes problēmas. Datu profesionāļiem, kas strādā ar lielām un dinamiskām datu kopām, Deequ ir Šveices naža risinājums. Apskatīsim, kā mēs to varam izmantot.

Deequ iestatīšana

Plašāka informācija par Deequ bibliotēkas iestatīšanu un lietošanas gadījumiem saistībā ar datu profilēšanu ir pieejama šeit . Vienkāršības labad šajā piemērā mēs tikko izveidojām dažus rotaļlietu ierakstus:

 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)

Datu pieņēmumu definēšana

Lielākajai daļai datu lietojumprogrammu ir ietverti netieši pieņēmumi par datu atribūtiem, piemēram, vērtībām, kas nav NULL, un unikalitāti. Izmantojot Deequ, šie pieņēmumi kļūst skaidri, izmantojot vienību testus. Šeit ir dažas izplatītas pārbaudes:

1. Rindu skaits: pārliecinieties, vai datu kopā ir noteikts rindu skaits.

   
   

2. Atribūtu pilnīgums: pārbaudiet, vai tādi atribūti kā id un productName nekad nav NULL.

   
   

3. Atribūtu unikalitāte: pārliecinieties, ka noteikti atribūti, piemēram, id, ir unikāli.

   
   

4. Vērtību diapazons: pārbaudiet, vai atribūti, piemēram, prioritāte un numViews, ietilpst paredzētajos diapazonos.

   
   

5. Rakstu atbilstība: pārbaudiet, vai aprakstos ir ietverti vietrāži URL, kad tas paredzēts.

   
   

6. Statistiskās īpašības: pārliecinieties, ka skaitlisko atribūtu mediāna atbilst noteiktiem kritērijiem.

Lūk, kā veikt šīs pārbaudes, izmantojot 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()

Rezultātu tulkošana

Pēc šo pārbaužu veikšanas Deequ pārvērš tās Spark darbu sērijās, kuras tas izpilda, lai aprēķinātu datu metriku. Pēc tam tas izsauc jūsu apgalvojuma funkcijas (piem., _ == 5 izmēra pārbaudei) šajās metrikās, lai noskaidrotu, vai ierobežojumi attiecas uz datiem. Mēs varam pārbaudīt objektu "verificationResult", lai redzētu, vai testā nav atrastas kļūdas:

 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}") } }

Ja mēs izpildām piemēru, mēs iegūstam šādu izvadi:

 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!

Pārbaudē atklājās, ka mūsu pieņēmumi ir pārkāpti! Tikai 4 no 5 (80%) atribūta productName vērtībām nav nulles, un tikai 2 no 5 (ti, 40%) apraksta atribūta vērtībām saturēja URL. Par laimi, mēs veicām pārbaudi un atradām kļūdas; kādam nekavējoties jāsalabo dati!

QA pārbaudes ar statistikas metodēm

Lai gan Deequ piedāvā stabilu datu validācijas sistēmu, statistikas metožu integrēšana var vēl vairāk uzlabot jūsu kvalitātes nodrošināšanas pārbaudes, it īpaši, ja jums ir darīšana ar datu kopas apkopotu metriku. Apskatīsim, kā varat izmantot statistikas metodes, lai uzraudzītu un nodrošinātu datu kvalitāti.

Ierakstu skaita izsekošana

Apsveriet biznesa scenāriju, kurā ETL (izvilkšanas, pārveidošanas, ielādes) process katru dienu ieplānotā darbā rada N ierakstus. Atbalsta komandas var vēlēties iestatīt kvalitātes nodrošināšanas pārbaudes, lai brīdinātu, ja ierakstu skaitā ir būtiska novirze. Piemēram, ja process parasti ģenerē no 9500 līdz 10500 ierakstiem katru dienu divu mēnešu laikā, jebkurš ievērojams palielinājums vai samazinājums var norādīt uz problēmu ar pamatā esošajiem datiem.

Mēs varam izmantot statistikas metodi, lai definētu šo slieksni, par kuru procesam ir jārada brīdinājums atbalsta komandai. Tālāk ir parādīts rekordu skaita izsekošanas ilustrācija divu mēnešu laikā:

Lai to analizētu, mēs varam pārveidot ierakstu skaita datus, lai novērotu ikdienas izmaiņas. Šīs izmaiņas parasti svārstās ap nulli, kā parādīts šajā diagrammā:

Ja mēs attēlojam šo izmaiņu ātrumu ar normālu sadalījumu, tas veido zvana līkni, kas norāda, ka dati tiek sadalīti normāli. Paredzamās izmaiņas ir aptuveni 0%, ar standarta novirzi 2,63%.

Šī analīze liecina, ka rekordu skaits parasti ir diapazonā no -5,26% līdz +5,25% ar 90% ticamību. Pamatojoties uz to, varat izveidot kārtulu, lai brīdinātu, ja ierakstu skaits novirzās ārpus šī diapazona, nodrošinot savlaicīgu iejaukšanos.

Atribūtu pārklājuma izsekošana

Atribūtu pārklājums attiecas uz vērtību, kas nav NULL, attiecību pret kopējo ierakstu skaitu datu kopas momentuzņēmumam. Piemēram, ja 8 no 100 ierakstiem konkrētam atribūtam ir NULL vērtība, šī atribūta pārklājums ir 92%.

Apskatīsim citu biznesa gadījumu ar ETL procesu, kas katru dienu ģenerē produktu tabulas momentuzņēmumu. Mēs vēlamies uzraudzīt produkta apraksta atribūtu pārklājumu. Ja pārklājums nokrītas zem noteikta sliekšņa, atbalsta komanda ir jābrīdina. Tālāk ir vizuāli attēlots produktu aprakstu atribūtu pārklājums divu mēnešu laikā.

Analizējot absolūtās ikdienas pārklājuma atšķirības, mēs novērojam, ka izmaiņas svārstās ap nulli:

Šo datu attēlošana kā normāls sadalījums parāda, ka tie parasti ir sadalīti ar paredzamajām izmaiņām aptuveni 0% un standarta novirzi 2,45%.

Kā redzam, šai datu kopai produkta apraksta atribūta pārklājums parasti ir no -4,9% līdz +4,9% ar 90% ticamību. Pamatojoties uz šo rādītāju, mēs varam iestatīt kārtulu, lai brīdinātu, ja pārklājums novirzās ārpus šī diapazona.

QA pārbaudes ar laikrindu algoritmiem

Ja strādājat ar datu kopām, kurās ir būtiskas atšķirības tādu faktoru dēļ kā sezonalitāte vai tendences, tradicionālās statistikas metodes var izraisīt viltus brīdinājumus. Laikrindu algoritmi piedāvā izsmalcinātāku pieeju, uzlabojot jūsu kvalitātes nodrošināšanas pārbaužu precizitāti un uzticamību.

Lai radītu saprātīgākus brīdinājumus, varat izmantot vai nu Autoregresīvais integrētais mainīgais vidējais (ARIMA) vai Holta-Vintersa metode . Pirmais ir pietiekami labs datu kopām ar tendencēm, bet otrais ļauj mums apstrādāt datu kopās gan ar tendencēm, gan sezonalitāti. Šī metode izmanto līmeņa, tendences un sezonalitātes komponentus, kas ļauj elastīgi pielāgoties izmaiņām laika gaitā.

Izmantojot Holt-Winters, modelēsim ikdienas izpārdošanas, kurās ir gan tendence, gan sezonāli modeļi:

 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)

Izmantojot šo metodi, varat noteikt būtiskas novirzes, kas varētu norādīt uz datu kvalitātes problēmām, nodrošinot niansētāku pieeju kvalitātes nodrošināšanas pārbaudēm.

Ceru, ka šis raksts palīdzēs jums efektīvi ieviest kvalitātes nodrošināšanas pārbaudes lielajām datu kopām. Izmantojot Deequ bibliotēku un integrējot statistikas metodes un laikrindu algoritmus, varat nodrošināt datu integritāti un uzticamību, galu galā uzlabojot savu datu pārvaldības praksi.

Iepriekš aprakstīto paņēmienu ieviešana palīdzēs novērst iespējamās problēmas pakārtotajās lietojumprogrammās un uzlabot datu darbplūsmu vispārējo kvalitāti.