Una de les habilitats vitals d'un professional de dades excel·lent és el maneig eficaç de grans conjunts de dades, garantint la qualitat i la fiabilitat de les dades. Les dades són la peça central i fonamental de qualsevol sistema de dades, i qualsevol que siguin les bones habilitats que tingueu en altres aspectes del nostre comerç, aquesta és una que no podeu passar per alt. En aquest article, exploro tècniques sòlides per realitzar comprovacions de control de qualitat en grans conjunts de dades mitjançant la biblioteca Deequ i els mètodes estadístics. En combinar els enfocaments que explico a continuació, podreu mantenir la integritat de les dades, millorar les vostres pràctiques de gestió de dades i prevenir possibles problemes a les aplicacions posteriors. Comprovacions de control de qualitat mitjançant la biblioteca Deequ Per què Deequ? Garantir la qualitat de les dades a escala és una tasca descoratjadora, especialment quan es tracta de milers de milions de files emmagatzemades en sistemes de fitxers distribuïts o magatzems de dades. La biblioteca Deequ és un marc de control de qualitat i perfils de dades de codi obert construït a Spark que és una eina moderna i versàtil dissenyada per resoldre aquest problema. El que el diferencia d'eines similars és la seva capacitat d'integrar-se perfectament amb Spark, aprofitant la potència de processament distribuïda per a un maneig eficient de conjunts de dades a gran escala. Quan ho proveu, veureu com la seva flexibilitat us permet definir regles de validació complexes adaptades als vostres requisits específics, garantint una cobertura completa. A més, Deequ inclou mètriques àmplies i capacitats de detecció d'anomalies que us ajudaran a identificar i abordar de manera proactiva els problemes de qualitat de les dades. Per als professionals de les dades que treballen amb conjunts de dades grans i dinàmics, Deequ és una solució de ganivet suís. A veure com el podem utilitzar. Configuració de Deequ Més detalls sobre la configuració de la biblioteca Deequ i els casos d'ús al voltant del perfil de dades es poden consultar . Per simplificar, en aquest exemple, acabem de generar uns quants registres de joguines: aquí 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) Definició de supòsits de dades La majoria de les aplicacions de dades inclouen suposicions implícites sobre els atributs de les dades, com ara els valors no NULL i la singularitat. Amb Deequ, aquestes hipòtesis es fan explícites mitjançant proves unitàries. Aquí hi ha algunes comprovacions habituals: assegureu-vos que el conjunt de dades contingui un nombre específic de files. Recompte de files: comproveu que els atributs com id i productName mai siguin NULL. Atribut complet: assegureu-vos que determinats atributs, com ara id, siguin únics. Unicitat de l'atribut: valideu que atributs com priority i numViews estiguin dins dels intervals esperats. Interval de valors: comproveu que les descripcions continguin URL quan s'espera. Concordança de patró: Assegureu-vos que la mediana dels atributs numèrics compleix uns criteris específics. Propietats estadístiques: A continuació, es mostra com podeu implementar aquestes comprovacions mitjançant 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() Interpretació de resultats Després d'executar aquestes comprovacions, Deequ les tradueix en una sèrie de treballs Spark, que executa per calcular mètriques de les dades. Després, invoca les vostres funcions d'afirmació (per exemple, _ == 5 per a la comprovació de la mida) en aquestes mètriques per veure si les restriccions es mantenen a les dades. Podem inspeccionar l'objecte "verificationResult" per veure si la prova ha trobat errors: 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}") } } Si executem l'exemple, obtenim la següent sortida: 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! La prova va trobar que les nostres hipòtesis es van violar! Només 4 de cada 5 (80%) dels valors de l'atribut productName no són nuls i només 2 de cada 5 (és a dir, el 40%) dels valors de l'atribut de descripció contenien un URL. Afortunadament, vam fer una prova i vam trobar els errors; algú hauria d'arreglar immediatament les dades! Comprovacions de control de qualitat amb mètodes estadístics Tot i que Deequ ofereix un marc sòlid per a la validació de dades, la integració de mètodes estadístics pot millorar encara més les vostres comprovacions de control de qualitat, especialment si esteu tractant amb mètriques agregades d'un conjunt de dades. Vegem com podeu utilitzar mètodes estadístics per controlar i garantir la qualitat de les dades. Seguiment del recompte de registres Penseu en un escenari empresarial on un procés ETL (Extracte, Transformació, Carrega) produeix N registres en un treball programat diari. És possible que els equips d'assistència vulguin configurar comprovacions de control de qualitat per generar una alerta si hi ha una desviació significativa en el recompte de registres. Per exemple, si el procés normalment genera entre 9.500 i 10.500 registres diaris durant dos mesos, qualsevol augment o disminució important podria indicar un problema amb les dades subjacents. Podem utilitzar un mètode estadístic per definir aquest llindar sobre quin procés hauria de generar una alerta a l'equip de suport. A continuació es mostra una il·lustració del seguiment del recompte de registres durant dos mesos: Per analitzar-ho, podem transformar les dades del recompte de registres per observar els canvis del dia a dia. Aquests canvis generalment oscil·len al voltant de zero, tal com es mostra al gràfic següent: Quan representem aquesta taxa de canvi amb una distribució normal, forma una corba de campana, que indica que les dades es distribueixen amb normalitat. El canvi previst se situa al voltant del 0%, amb una desviació estàndard del 2,63%. Aquesta anàlisi suggereix que el recompte de registres normalment es troba entre -5,26% i +5,25% amb un 90% de confiança. A partir d'això, podeu establir una regla per activar una alerta si el recompte de registres es desvia més enllà d'aquest rang, garantint una intervenció oportuna. Seguiment de cobertura d'atributs es refereix a la proporció de valors que no són NULL i el recompte total de registres per a una instantània de conjunt de dades. Per exemple, si 8 de cada 100 registres tenen un valor NULL per a un atribut concret, la cobertura d'aquest atribut és del 92%. La cobertura d'atributs Revisem un altre cas de negoci amb un procés ETL que genera una instantània de la taula de productes diàriament. Volem controlar la cobertura dels atributs de descripció del producte. Si la cobertura cau per sota d'un determinat llindar, s'hauria d'enviar una alerta per a l'equip de suport. A continuació es mostra una representació visual de la cobertura d'atributs per a descripcions de productes durant dos mesos: Analitzant les diferències absolutes en la cobertura del dia a dia, observem que els canvis oscil·len al voltant de zero: La representació d'aquestes dades com a distribució normal mostra que es distribueix normalment amb un canvi esperat al voltant del 0% i una desviació estàndard del 2,45%. Com veiem, per a aquest conjunt de dades, la cobertura de l'atribut de descripció del producte normalment oscil·la entre -4,9% i +4,9% amb un 90% de confiança. A partir d'aquest indicador, podem establir una regla per activar una alerta si la cobertura es desvia més enllà d'aquest rang. Comprovacions de control de qualitat amb algorismes de sèries temporals Si treballeu amb conjunts de dades que mostren variacions significatives a causa de factors com l'estacionalitat o les tendències, els mètodes estadístics tradicionals poden activar alertes falses. Els algorismes de sèries temporals ofereixen un enfocament més refinat, millorant la precisió i la fiabilitat de les vostres comprovacions de control de qualitat. Per produir alertes més sensibles, podeu utilitzar qualsevol de les opcions o el . El primer és prou bo per a conjunts de dades amb tendències, però el segon ens permet tractar conjunts de dades amb tendència i estacionalitat. Aquest mètode utilitza components per nivell, tendència i estacionalitat, cosa que li permet adaptar-se de manera flexible als canvis al llarg del temps. Mitjana mòbil integrada autoregressiva (ARIMA) Mètode Holt-Winters Fem un model de vendes diàries que mostren patrons de tendències i estacions amb 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) Amb aquest mètode, podeu detectar desviacions significatives que poden indicar problemes de qualitat de les dades, proporcionant un enfocament més matisat a les comprovacions de control de qualitat. Espero que aquest article us ajudi a implementar de manera eficient les comprovacions de control de qualitat per als vostres grans conjunts de dades. Mitjançant l'ús de la biblioteca Deequ i la integració de mètodes estadístics i algorismes de sèries temporals, podeu garantir la integritat i la fiabilitat de les dades, millorant en última instància les vostres pràctiques de gestió de dades. La implementació de les tècniques descrites anteriorment us ajudarà a prevenir possibles problemes a les aplicacions posteriors i a millorar la qualitat general dels vostres fluxos de treball de dades.
