Una dintre abilitățile vitale ale unui profesionist desăvârșit în date este manipularea eficientă a seturilor mari de date, asigurând calitatea și fiabilitatea datelor. Datele sunt piesa centrală și fundamentală a oricărui sistem de date și, indiferent de abilitățile bune pe care le aveți în alte aspecte ale comerțului nostru, aceasta este una pe care nu vă puteți permite să o treceți cu vederea. În acest articol, explorez tehnici robuste pentru efectuarea verificărilor QA pe seturi mari de date folosind biblioteca Deequ și metodele statistice. Prin combinarea abordărilor pe care le explic mai jos, veți putea să mențineți integritatea datelor, să vă îmbunătățiți practicile de gestionare a datelor și să preveniți potențialele probleme în aplicațiile din aval. Verificări QA folosind biblioteca Deequ De ce Deequ? Asigurarea calității datelor la scară este o sarcină descurajantă, mai ales atunci când aveți de-a face cu miliarde de rânduri stocate în sisteme de fișiere distribuite sau depozite de date. Biblioteca Deequ este un cadru open-source de profilare a datelor și QA construit pe Spark, care este un instrument modern și versatil conceput pentru a rezolva această problemă. Ceea ce îl diferențiază de instrumentele similare este capacitatea sa de a se integra perfect cu Spark, valorificând puterea de procesare distribuită pentru gestionarea eficientă a seturilor de date la scară largă. Când îl încercați, veți vedea cum flexibilitatea acestuia vă permite să definiți reguli complexe de validare adaptate cerințelor dumneavoastră specifice, asigurând o acoperire cuprinzătoare. În plus, Deequ oferă măsurători extinse și capabilități de detectare a anomaliilor care vă vor ajuta să identificați și să abordați în mod proactiv problemele legate de calitatea datelor. Pentru profesioniștii de date care lucrează cu seturi de date mari și dinamice, Deequ este o soluție Swiss-knife. Să vedem cum îl putem folosi. Configurarea Deequ Mai multe detalii despre configurarea bibliotecii Deequ și cazurile de utilizare în jurul profilării datelor sunt accesibile . De dragul simplității, în acest exemplu, am generat doar câteva înregistrări de jucării: aici 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) Definirea ipotezelor de date Majoritatea aplicațiilor de date vin cu presupuneri implicite despre atributele datelor, cum ar fi valorile non-NULL și unicitatea. Cu Deequ, aceste ipoteze devin explicite prin teste unitare. Iată câteva verificări comune: asigurați-vă că setul de date conține un anumit număr de rânduri. Număr de rânduri: verificați dacă atributele precum id și productName nu sunt niciodată NULL. Completitudinea atributelor: asigurați-vă că anumite atribute, cum ar fi id, sunt unice. Unicitatea atributelor: validați că atribute precum priority și numViews se încadrează în intervalele așteptate. Interval de valori: verificați dacă descrierile conțin adrese URL atunci când vă așteptați. Potrivirea modelelor: Asigurați-vă că mediana atributelor numerice îndeplinește criterii specifice. Proprietăți statistice: Iată cum puteți implementa aceste verificări folosind 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() Interpretarea rezultatelor După rularea acestor verificări, Deequ le transpune într-o serie de joburi Spark, pe care le execută pentru a calcula valorile pe date. Ulterior, invocă funcțiile dvs. de afirmare (de exemplu, _ == 5 pentru verificarea dimensiunii) pe aceste valori pentru a vedea dacă constrângerile sunt valabile pentru date. Putem inspecta obiectul „verificationResult” pentru a vedea dacă testul a găsit erori: 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}") } } Dacă rulăm exemplul, obținem următoarea ieșire: 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! Testul a constatat că presupunerile noastre au fost încălcate! Doar 4 din 5 (80%) dintre valorile atributului productName sunt non-nule și doar 2 din 5 (adică, 40%) valori ale atributului descriere au conținut o adresă URL. Din fericire, am făcut un test și am găsit erorile; cineva ar trebui să repare imediat datele! Verificări QA cu metode statistice Deși Deequ oferă un cadru robust pentru validarea datelor, integrarea metodelor statistice vă poate îmbunătăți și mai mult verificările QA, mai ales dacă aveți de-a face cu metrici agregate ale unui set de date. Să vedem cum puteți folosi metode statistice pentru a monitoriza și asigura calitatea datelor. Urmărirea numărului de înregistrări Luați în considerare un scenariu de afaceri în care un proces ETL (Extract, Transform, Load) produce N înregistrări pentru o lucrare planificată zilnic. Echipele de asistență pot dori să configureze verificări QA pentru a genera o alertă dacă există o abatere semnificativă a numărului de înregistrări. De exemplu, dacă procesul generează de obicei între 9.500 și 10.500 de înregistrări zilnic în decurs de două luni, orice creștere sau scădere semnificativă ar putea indica o problemă cu datele de bază. Putem folosi o metodă statistică pentru a defini acest prag pe baza căruia proces ar trebui să ridice o alertă echipei de suport. Mai jos este o ilustrare a urmăririi numărului de recorduri pe parcursul a două luni: Pentru a analiza acest lucru, putem transforma datele de numărare a înregistrărilor pentru a observa schimbările de zi cu zi. Aceste modificări oscilează în general în jurul valorii de zero, așa cum se arată în următorul grafic: Când reprezentăm această rată de schimbare cu o distribuție normală, formează o curbă clopot, indicând faptul că datele sunt distribuite normal. Modificarea așteptată este în jur de 0%, cu o abatere standard de 2,63%. Această analiză sugerează că numărul înregistrărilor se încadrează de obicei în intervalul de la -5,26% la +5,25%, cu o încredere de 90%. Pe baza acesteia, puteți stabili o regulă pentru a declanșa o alertă dacă numărul de înregistrări se abate dincolo de acest interval, asigurând intervenția în timp util. Urmărirea acoperirii atributelor se referă la raportul dintre valorile non-NULL și numărul total de înregistrări pentru un instantaneu al unui set de date. De exemplu, dacă 8 din 100 de înregistrări au o valoare NULL pentru un anumit atribut, acoperirea pentru acel atribut este de 92%. Acoperirea atributelor Să revizuim un alt caz de afaceri cu un proces ETL care generează zilnic un instantaneu de tabel de produse. Dorim să monitorizăm acoperirea atributelor descrierii produsului. Dacă acoperirea scade sub un anumit prag, ar trebui să fie lansată o alertă pentru echipa de asistență. Mai jos este o reprezentare vizuală a acoperirii atributelor pentru descrierile produselor pe parcursul a două luni: Analizând diferențele absolute de zi cu zi în acoperire, observăm că modificările oscilează în jurul zero: Reprezentarea acestor date ca o distribuție normală arată că acestea sunt distribuite în mod normal, cu o modificare așteptată de aproximativ 0% și o abatere standard de 2,45%. După cum vedem, pentru acest set de date, acoperirea atributului de descriere a produsului variază de obicei de la -4,9% la +4,9%, cu o încredere de 90%. Pe baza acestui indicator, putem stabili o regulă pentru a genera o alertă dacă acoperirea se abate dincolo de acest interval. Verificări QA cu algoritmi de serie temporală Dacă lucrați cu seturi de date care arată variații semnificative din cauza unor factori precum sezonalitatea sau tendințele, metodele statistice tradiționale pot declanșa alerte false. Algoritmii serii temporale oferă o abordare mai rafinată, îmbunătățind acuratețea și fiabilitatea verificărilor dvs. de calitate. Pentru a produce alerte mai sensibile, puteți utiliza fie sau cel . Primul este suficient de bun pentru seturi de date cu tendințe, dar cel de-al doilea ne permite să ne ocupăm de seturi de date atât cu tendințe, cât și cu sezonalitate. Această metodă utilizează componente pentru nivel, tendință și sezonalitate, ceea ce îi permite să se adapteze flexibil la schimbările în timp. Medie mobilă integrată autoregresivă (ARIMA) Metoda Holt-Winters Să modelăm vânzările zilnice care prezintă atât modele de tendințe, cât și modele sezoniere folosind 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) Folosind această metodă, puteți detecta abateri semnificative care ar putea indica probleme de calitate a datelor, oferind o abordare mai nuanțată a verificărilor QA. Sper că acest articol vă va ajuta să implementați eficient verificările QA pentru seturile dvs. mari de date. Prin utilizarea bibliotecii Deequ și prin integrarea metodelor statistice și a algoritmilor serii de timp, puteți asigura integritatea și fiabilitatea datelor, îmbunătățind în cele din urmă practicile de gestionare a datelor. Implementarea tehnicilor descrise mai sus vă va ajuta să preveniți potențialele probleme în aplicațiile din aval și să îmbunătățiți calitatea generală a fluxurilor dvs. de lucru de date.
