Vienas iš svarbiausių patyrusio duomenų specialisto įgūdžių yra efektyvus didelių duomenų rinkinių tvarkymas, užtikrinantis duomenų kokybę ir patikimumą. Duomenys yra pagrindinė ir pagrindinė bet kurios duomenų sistemos dalis, ir kad ir kokius gerus įgūdžius turite kitose mūsų prekybos srityse, jūs negalite sau leisti to nepastebėti.

Šiame straipsnyje aš tyrinėju patikimus metodus, kaip atlikti didelių duomenų rinkinių kokybės užtikrinimo patikras naudojant Deequ biblioteką ir statistinius metodus. Derindami toliau paaiškintus metodus, galėsite išlaikyti duomenų vientisumą, pagerinti duomenų tvarkymo praktiką ir užkirsti kelią galimoms problemoms kitose programose.

QA patikrinimai naudojant Deequ biblioteką

Kodėl Deequ?

Didelės apimties duomenų kokybės užtikrinimas yra bauginanti užduotis, ypač kai susiduriama su milijardais eilučių, saugomų paskirstytose failų sistemose arba duomenų saugyklose. „Deequ“ biblioteka yra atvirojo kodo duomenų profiliavimo ir kokybės užtikrinimo sistema, sukurta naudojant „Spark“, kuri yra modernus ir universalus įrankis, skirtas išspręsti šią problemą. Iš panašių įrankių jis išsiskiria tuo, kad jis gali sklandžiai integruotis su „Spark“, išnaudojant paskirstytą apdorojimo galią, kad būtų galima efektyviai tvarkyti didelio masto duomenų rinkinius.

Išbandę pamatysite, kaip jo lankstumas leidžia apibrėžti sudėtingas patvirtinimo taisykles, pritaikytas jūsų specifiniams reikalavimams, užtikrinant visapusišką aprėptį. Be to, „Deequ“ turi plačias metrikas ir anomalijų aptikimo galimybes, kurios padės nustatyti ir aktyviai spręsti duomenų kokybės problemas. Duomenų profesionalams, dirbantiems su dideliais ir dinamiškais duomenų rinkiniais, „Deequ“ yra šveicariško peilio sprendimas. Pažiūrėkime, kaip galime tai panaudoti.

„Deequ“ nustatymas

Daugiau informacijos apie Deequ bibliotekos sąranką ir naudojimo atvejus, susijusius su duomenų profiliavimu, rasite čia . Paprastumo sumetimais šiame pavyzdyje mes ką tik sugeneravome keletą žaislų įrašų:

 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)

Duomenų prielaidų apibrėžimas

Daugumoje duomenų taikomųjų programų pateikiamos numanomos prielaidos dėl duomenų atributų, tokių kaip ne NULL reikšmės ir unikalumas. Naudojant Deequ, šios prielaidos tampa aiškios atliekant vienetų testus. Štai keletas įprastų patikrinimų:

1. Eilučių skaičius: įsitikinkite, kad duomenų rinkinyje yra konkretus eilučių skaičius.

   
   

2. Atributo užbaigtumas: patikrinkite, ar tokie atributai kaip id ir productName niekada nėra NULL.

   
   

3. Atributo unikalumas: įsitikinkite, kad tam tikri atributai, pvz., id, yra unikalūs.

   
   

4. Vertės diapazonas: patikrinkite, ar tokie atributai kaip prioritetas ir numViews patenka į numatytus diapazonus.

   
   

5. Šablonų atitikimas: patikrinkite, ar aprašymuose yra URL, kai tikimasi.

   
   

6. Statistinės savybės: įsitikinkite, kad skaitinių požymių mediana atitinka konkrečius kriterijus.

Štai kaip galite atlikti šiuos patikrinimus naudodami „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()

Rezultatų interpretavimas

Atlikusi šiuos patikrinimus, „Deequ“ paverčia juos „Spark“ užduočių serija, kurią atlieka, kad apskaičiuotų duomenų metriką. Vėliau ši metrika iškviečia tvirtinimo funkcijas (pvz., _ == 5 dydžio patikrai), kad sužinotų, ar apribojimai galioja duomenims. Galime patikrinti objektą „verificationResult“, kad pamatytume, ar testas aptiko klaidų:

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

Jei vykdysime pavyzdį, gausime tokią išvestį:

 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!

Testas parodė, kad mūsų prielaidos buvo pažeistos! Tik 4 iš 5 (80 %) atributo productName reikšmių yra nenulinės ir tik 2 iš 5 (ty 40 %) aprašymo atributo verčių turėjo URL. Laimei, atlikome testą ir nustatėme klaidas; kas nors turėtų nedelsiant sutvarkyti duomenis!

QA patikrinimai statistiniais metodais

Nors „Deequ“ siūlo tvirtą duomenų patvirtinimo sistemą, statistinių metodų integravimas gali dar labiau pagerinti jūsų kokybės užtikrinimo patikras, ypač jei dirbate su apibendrinta duomenų rinkinio metrika. Pažiūrėkime, kaip galite naudoti statistinius metodus duomenų kokybei stebėti ir užtikrinti.

Įrašų skaičiaus stebėjimas

Apsvarstykite verslo scenarijų, kai ETL (ištraukimo, transformavimo, įkėlimo) procesas sukuria N įrašų kasdienėje suplanuotoje užduotyje. Palaikymo komandos gali norėti nustatyti kokybės užtikrinimo patikras, kad gautų įspėjimą, jei yra reikšmingas įrašų skaičiaus nuokrypis. Pavyzdžiui, jei procesas paprastai sukuria nuo 9 500 iki 10 500 įrašų kasdien per du mėnesius, bet koks reikšmingas padidėjimas ar sumažėjimas gali rodyti pagrindinių duomenų problemą.

Galime naudoti statistinį metodą, kad apibrėžtume šią ribą, dėl kurios procesas turėtų įspėti palaikymo komandą. Žemiau pateikiama rekordinio skaičiaus stebėjimo per du mėnesius iliustracija:

Norėdami tai išanalizuoti, galime transformuoti įrašų skaičiaus duomenis, kad būtų galima stebėti kasdienius pokyčius. Šie pokyčiai paprastai svyruoja apie nulį, kaip parodyta šioje diagramoje:

Kai parodome šį pokyčio greitį normaliu pasiskirstymu, susidaro varpelio kreivė, rodanti, kad duomenys paskirstomi normaliai. Numatomas pokytis yra apie 0%, standartinis nuokrypis – 2,63%.

Ši analizė rodo, kad rekordinis skaičius paprastai yra nuo -5,26% iki +5,25% su 90% patikimumu. Remdamiesi tuo, galite nustatyti taisyklę, kaip įspėti, jei įrašų skaičius nukrypsta už šio diapazono, užtikrinant savalaikį įsikišimą.

Atributo aprėpties stebėjimas

Atributo aprėptis reiškia ne NULL verčių santykį su bendru duomenų rinkinio momentinės nuotraukos įrašų skaičiumi. Pavyzdžiui, jei 8 iš 100 įrašų tam tikram atributui turi NULL reikšmę, to atributo aprėptis yra 92%.

Peržiūrėkime kitą verslo atvejį su ETL procesu, kasdien generuojančiu produktų lentelės momentinę nuotrauką. Norime stebėti produkto aprašymo atributų aprėptį. Jei aprėptis nukrenta žemiau tam tikros ribos, palaikymo komanda turėtų būti įspėta. Toliau pateikiamas vaizdinis produktų aprašymų atributų aprėpties vaizdas per du mėnesius:

Analizuodami absoliučius kasdienius aprėpties skirtumus, pastebime, kad pokyčiai svyruoja apie nulį:

Pateikus šiuos duomenis kaip normalųjį pasiskirstymą, matyti, kad jie paprastai pasiskirsto su numatomu maždaug 0 % pokyčiu ir 2,45 % standartiniu nuokrypiu.

Kaip matome, šio duomenų rinkinio produkto aprašymo atributo aprėptis paprastai svyruoja nuo -4,9% iki +4,9% su 90% patikimumu. Remdamiesi šiuo rodikliu, galime nustatyti taisyklę, kuri padidintų įspėjimą, jei aprėptis nukrypsta už šio diapazono.

QA tikrina naudojant laiko eilučių algoritmus

Jei dirbate su duomenų rinkiniais, kuriuose rodomi dideli skirtumai dėl tokių veiksnių kaip sezoniškumas ar tendencijos, tradiciniai statistiniai metodai gali suaktyvinti klaidingus įspėjimus. Laiko eilučių algoritmai siūlo patobulintą metodą, pagerindami kokybės užtikrinimo patikrų tikslumą ir patikimumą.

Norėdami pateikti protingesnius įspėjimus, galite naudoti bet kurį Autoregresyvus integruotas slenkamasis vidurkis (ARIMA) arba Holto-Winterso metodas . Pirmasis yra pakankamai geras duomenų rinkiniams su tendencijomis, tačiau pastarasis leidžia mums tvarkyti duomenų rinkinius, susijusius su tendencija ir sezoniškumu. Šis metodas naudoja lygio, tendencijos ir sezoniškumo komponentus, o tai leidžia lanksčiai prisitaikyti prie pokyčių laikui bėgant.

Su Holt-Winters modeliuokime kasdienius pardavimus, kuriuose atsispindi tendencijos ir sezoniniai modeliai:

 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)

Naudodami šį metodą galite aptikti reikšmingus nukrypimus, kurie gali reikšti duomenų kokybės problemas, o tai suteikia niuansų kokybės užtikrinimo patikroms.

Tikiuosi, kad šis straipsnis padės efektyviai atlikti didelių duomenų rinkinių kokybės užtikrinimo patikras. Naudodami Deequ biblioteką ir integruodami statistinius metodus bei laiko eilučių algoritmus, galite užtikrinti duomenų vientisumą ir patikimumą, o tai galiausiai pagerins duomenų valdymo praktiką.

Aukščiau aprašytų metodų įgyvendinimas padės išvengti galimų problemų tolesniuose programose ir pagerins bendrą duomenų darbo eigos kokybę.