Jedna od vitalnih vještina iskusnog stručnjaka za podatke je efikasno rukovanje velikim skupovima podataka, osiguravajući kvalitet i pouzdanost podataka. Podaci su centralni i fundamentalni dio svakog sistema podataka, a koje god dobre vještine imate u drugim aspektima naše trgovine, ovo je ono koje ne možete priuštiti da previdite. U ovom članku istražujem robusne tehnike za izvođenje QA provjera na velikim skupovima podataka koristeći Deequ biblioteku i statističke metode. Kombinovanjem pristupa koje objašnjavam u nastavku, moći ćete da održite integritet podataka, poboljšate svoje prakse upravljanja podacima i sprečite potencijalne probleme u nizvodnim aplikacijama. QA provjere pomoću Deequ biblioteke Zašto Deequ? Osiguravanje kvaliteta podataka u velikoj mjeri je zastrašujući zadatak, posebno kada se radi o milijardama redova pohranjenih u distribuiranim sistemima datoteka ili skladištima podataka. Deequ biblioteka je open-source profiliranje podataka i QA okvir izgrađen na Spark-u koji je moderan i svestran alat dizajniran da riješi ovaj problem. Ono što ga izdvaja od sličnih alata je njegova sposobnost da se neprimetno integriše sa Spark-om, koristeći distribuiranu procesorsku snagu za efikasno rukovanje velikim skupovima podataka. Kada ga isprobate, vidjet ćete kako vam njegova fleksibilnost omogućava definiranje složenih pravila validacije prilagođenih vašim specifičnim zahtjevima, osiguravajući sveobuhvatnu pokrivenost. Osim toga, Deequ ima opsežne metrike i mogućnosti otkrivanja anomalija koje će vam pomoći da identificirate i proaktivno rješavate probleme s kvalitetom podataka. Za profesionalce koji rade s velikim i dinamičnim skupovima podataka, Deequ je rješenje za švicarski nož. Da vidimo kako to možemo iskoristiti. Postavljanje Deequ Više detalja o postavci Deequ biblioteke i slučajevima korištenja oko profiliranja podataka dostupni su . Radi jednostavnosti, u ovom primjeru, upravo smo generirali nekoliko zapisa igračaka: ovdje 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) Definiranje pretpostavki podataka Većina aplikacija podataka dolazi sa implicitnim pretpostavkama o atributima podataka, kao što su vrijednosti koje nisu NULL i jedinstvenost. Sa Deequom, ove pretpostavke postaju eksplicitne kroz jedinične testove. Evo nekih uobičajenih provjera: Osigurajte da skup podataka sadrži određeni broj redova. Broj redova: Provjerite da atributi kao što su id i productName nikada nisu NULL. Kompletnost atributa: Osigurajte da su određeni atributi, kao što je id, jedinstveni. Jedinstvenost atributa: provjerite da li atributi poput prioriteta i numViews spadaju u očekivane raspone. Raspon vrijednosti: Provjerite da opisi sadrže URL-ove kada se to očekuje. Podudaranje uzorka: Osigurajte da medijana numeričkih atributa ispunjava specifične kriterije. Statistička svojstva: Evo kako možete implementirati ove provjere koristeći 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() Interpreting Results Nakon pokretanja ovih provjera, Deequ ih prevodi u niz Spark poslova, koje izvršava da bi izračunao metriku podataka. Nakon toga, poziva vaše funkcije tvrdnje (npr. _ == 5 za provjeru veličine) na ovim metrikama da bi vidio da li se ograničenja drže na podacima. Možemo pregledati objekat "verificationResult" da vidimo da li je test pronašao greške: 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}") } } Ako pokrenemo primjer, dobićemo sljedeći izlaz: 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! Test je pokazao da su naše pretpostavke prekršene! Samo 4 od 5 (80%) vrijednosti atributa productName nisu nulte, a samo 2 od 5 (tj. 40%) vrijednosti atributa description sadrže URL. Srećom, izvršili smo test i pronašli greške; neko treba odmah da popravi podatke! QA provjere sa statističkim metodama Dok Deequ nudi robustan okvir za provjeru valjanosti podataka, integracija statističkih metoda može dodatno poboljšati vaše QA provjere, posebno ako imate posla sa agregiranim metrikama skupa podataka. Hajde da vidimo kako možete koristiti statističke metode za praćenje i osiguranje kvaliteta podataka. Praćenje broja zapisa Razmislite o poslovnom scenariju u kojem ETL (Extract, Transform, Load) proces proizvodi N zapisa na dnevno planiranom poslu. Timovi za podršku će možda htjeti postaviti QA provjere kako bi podigli upozorenje ako postoji značajno odstupanje u broju zapisa. Na primjer, ako proces obično generiše između 9.500 i 10.500 zapisa dnevno tokom dva mjeseca, svako značajno povećanje ili smanjenje može ukazivati na problem s osnovnim podacima. Možemo koristiti statističku metodu da definišemo ovaj prag o tome koji proces treba da podnese upozorenje timu za podršku. Ispod je ilustracija praćenja broja zapisa tokom dva mjeseca: Da bismo ovo analizirali, možemo transformirati podatke o broju zapisa da bismo promatrali svakodnevne promjene. Ove promjene općenito osciliraju oko nule, kao što je prikazano na sljedećem grafikonu: Kada ovu stopu promjene predstavimo normalnom distribucijom, ona formira zvonastu krivulju, što ukazuje na to da su podaci normalno raspoređeni. Očekivana promjena je oko 0%, sa standardnom devijacijom od 2,63%. Ova analiza sugerira da broj rekorda obično pada u rasponu od -5,26% do +5,25% sa pouzdanošću od 90%. Na osnovu toga, možete uspostaviti pravilo za podizanje upozorenja ako broj zapisa odstupa izvan ovog raspona, osiguravajući pravovremenu intervenciju. Praćenje pokrivenosti atributa se odnosi na omjer vrijednosti koje nisu NULL i ukupnog broja zapisa za snimak skupa podataka. Na primjer, ako 8 od 100 zapisa ima NULL vrijednost za određeni atribut, pokrivenost za taj atribut je 92%. Pokrivenost atributa Pogledajmo još jedan poslovni slučaj sa ETL procesom koji svakodnevno generiše snimak tabele proizvoda. Želimo pratiti pokrivenost atributa opisa proizvoda. Ako pokrivenost padne ispod određenog praga, treba podići upozorenje za tim za podršku. Ispod je vizuelni prikaz pokrivenosti atributa za opise proizvoda tokom dva mjeseca: Analizirajući apsolutne svakodnevne razlike u pokrivenosti, uočavamo da promjene osciliraju oko nule: Predstavljanje ovih podataka kao normalne distribucije pokazuje da je normalno raspoređeno sa očekivanom promjenom od oko 0% i standardnom devijacijom od 2,45%. Kao što vidimo, za ovaj skup podataka pokrivenost atributa opisa proizvoda obično se kreće od -4,9% do +4,9% sa 90% pouzdanosti. Na osnovu ovog indikatora možemo postaviti pravilo za podizanje upozorenja ako pokrivenost odstupi izvan ovog raspona. QA provjere s algoritmima vremenske serije Ako radite sa skupovima podataka koji pokazuju značajne varijacije zbog faktora kao što su sezonalnost ili trendovi, tradicionalne statističke metode mogu pokrenuti lažna upozorenja. Algoritmi vremenskih serija nude profinjeniji pristup, poboljšavajući točnost i pouzdanost vaših QA provjera. Da biste proizveli razumnija upozorenja, možete koristiti bilo koju ili . Prvi je dovoljno dobar za skupove podataka sa trendovima, ali drugi nam omogućava da se bavimo skupovima podataka i sa trendom i sa sezonalnošću. Ova metoda koristi komponente za nivo, trend i sezonalnost, što joj omogućava da se fleksibilno prilagođava promjenama tokom vremena. Autoregresivni integrisani pokretni prosek (ARIMA) Holt-Winters metoda Hajde da se rugamo modelom dnevne prodaje koja pokazuje trendove i sezonske obrasce koristeći 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) Koristeći ovu metodu, možete otkriti značajna odstupanja koja bi mogla ukazivati na probleme s kvalitetom podataka, pružajući nijansiraniji pristup provjerama kvalitete. Nadam se da će vam ovaj članak pomoći da efikasno implementirate QA provjere za vaše velike skupove podataka. Koristeći Deequ biblioteku i integraciju statističkih metoda i algoritama vremenskih serija, možete osigurati integritet i pouzdanost podataka, u konačnici poboljšavajući svoje prakse upravljanja podacima. Implementacija gore opisanih tehnika pomoći će vam da spriječite potencijalne probleme u nizvodnim aplikacijama i poboljšate ukupni kvalitet vaših tokova rada podataka.
