A tapasztalt adatszakértők egyik létfontosságú készsége a nagy adathalmazok hatékony kezelése, amely biztosítja az adatok minőségét és megbízhatóságát. Az adatok minden adatrendszer központi és alapvető részét képezik, és bármilyen jó képességgel rendelkezik is kereskedésünk más területein, ezt nem engedheti meg magának, hogy figyelmen kívül hagyja.
Ebben a cikkben robusztus technikákat fedezek fel nagy adathalmazok minőségbiztosítási ellenőrzésének végrehajtására a Deequ könyvtár és statisztikai módszerek segítségével. Az alábbiakban ismertetett megközelítések kombinálásával megőrizheti az adatok integritását, javíthatja adatkezelési gyakorlatát, és megelőzheti az esetleges problémákat a későbbi alkalmazásokban.
A méretarányos adatminőség biztosítása ijesztő feladat, különösen akkor, ha elosztott fájlrendszerekben vagy adattárházakban tárolt sorok milliárdjaival kell foglalkozni. A Deequ könyvtár egy nyílt forráskódú adatprofilozó és minőségbiztosítási keretrendszer, amely a Sparkra épül, és egy modern és sokoldalú eszköz, amelyet ennek a problémának a megoldására terveztek. Ami megkülönbözteti a hasonló eszközöktől, az az, hogy zökkenőmentesen integrálható a Sparkba, kihasználva az elosztott feldolgozási teljesítményt a nagyméretű adatkészletek hatékony kezeléséhez.
Amikor kipróbálja, látni fogja, hogy rugalmassága hogyan teszi lehetővé az összetett érvényesítési szabályok meghatározását az Ön egyedi igényeihez igazítva, így biztosítva az átfogó lefedettséget. Ezenkívül a Deequ kiterjedt mérőszámokkal és anomália-észlelési képességekkel rendelkezik, amelyek segítenek azonosítani és proaktívan kezelni az adatminőségi problémákat. A nagy és dinamikus adatkészletekkel dolgozó adatszakértők számára a Deequ egy svájci késes megoldás. Lássuk, hogyan tudjuk használni.
További részletek a Deequ könyvtár beállításáról és az adatprofilozással kapcsolatos használati esetekről itt érhetők el. Az egyszerűség kedvéért ebben a példában csak néhány játékrekordot generáltunk:
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)
A legtöbb adatalkalmazás implicit feltételezéseket tartalmaz az adatattribútumokról, például a nem NULL értékekről és az egyediségről. A Deequ esetében ezek a feltételezések az egységteszteken keresztül egyértelművé válnak. Íme néhány gyakori ellenőrzés:
Sorok száma: Győződjön meg arról, hogy az adatkészlet meghatározott számú sort tartalmaz.
Az attribútumok teljessége: Ellenőrizze, hogy az olyan attribútumok, mint az id és a productName, soha ne legyenek NULL-ok.
Attribútumok egyedisége: Győződjön meg arról, hogy bizonyos attribútumok, például az id, egyediek.
Értéktartomány: Ellenőrizze, hogy az attribútumok, például a prioritás és a numViews a várt tartományokba esnek-e.
Mintaegyeztetés: Ellenőrizze, hogy a leírások tartalmaznak-e URL-eket, amikor elvárják.
Statisztikai tulajdonságok: Győződjön meg arról, hogy a numerikus attribútumok mediánja megfelel bizonyos kritériumoknak.
A következőképpen hajthatja végre ezeket az ellenőrzéseket a Deequ segítségével:
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()
Az ellenőrzések futtatása után a Deequ lefordítja őket Spark-feladatok sorozatává, amelyeket végrehajt az adatok metrikáinak kiszámításához. Ezt követően meghívja az állítási függvényeket (pl. _ == 5 a méretellenőrzéshez) ezeken a metrikákon, hogy megnézze, érvényesek-e a megszorítások az adatokra. Megvizsgálhatjuk a „verificationResult” objektumot, hogy lássuk, a teszt talált-e hibákat:
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}") } }
Ha futtatjuk a példát, a következő kimenetet kapjuk:
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!
A teszt megállapította, hogy a feltételezéseinket megsértették! A productName attribútum értékei közül 5-ből csak 4 (80%) nem nulla, és a description attribútum 5 értékéből csak 2 (azaz 40%) tartalmazott URL-t. Szerencsére lefuttattunk egy tesztet, és megtaláltuk a hibákat; valaki azonnal javítsa ki az adatokat!
Míg a Deequ robusztus keretrendszert kínál az adatok validálásához, a statisztikai módszerek integrálása tovább javíthatja a minőségbiztosítási ellenőrzéseket, különösen, ha egy adatkészlet összesített mérőszámairól van szó. Nézzük meg, hogyan lehet statisztikai módszereket alkalmazni az adatminőség ellenőrzésére és biztosítására.
Vegyünk egy olyan üzleti forgatókönyvet, amelyben egy ETL (Kibontás, átalakítás, betöltés) folyamat N rekordot állít elő egy napi ütemezett feladaton. Előfordulhat, hogy a támogató csoportok minőségbiztosítási ellenőrzéseket szeretnének beállítani, hogy riasztást adhassanak, ha jelentős eltérés van a rekordok számában. Például, ha a folyamat jellemzően napi 9500 és 10500 közötti rekordot generál két hónapon keresztül, minden jelentős növekedés vagy csökkenés a mögöttes adatokkal kapcsolatos problémára utalhat.
Statisztikai módszerrel meghatározhatjuk ezt a küszöböt, amelynél a folyamatnak riasztást kell küldenie a támogatási csoportnak. Az alábbiakban bemutatjuk a rekordszám nyomon követését két hónapon keresztül:
Ennek elemzéséhez átalakíthatjuk a rekordszámadatokat, hogy megfigyeljük a napi változásokat. Ezek a változások általában nulla körül ingadoznak, amint azt az alábbi diagram mutatja:
Ha ezt a változási sebességet normál eloszlással ábrázoljuk, az egy haranggörbét képez, jelezve, hogy az adatok normális eloszlásúak. A várható változás 0% körüli, 2,63%-os szórással.
Ez az elemzés azt sugallja, hogy a rekordszám általában a -5,26% és +5,25% közötti tartományba esik 90%-os megbízhatósággal. Ez alapján létrehozhat egy szabályt a riasztás indítására, ha a rekordok száma ezen a tartományon kívül esik, így biztosítva az időben történő beavatkozást.
Az attribútumlefedettség a nem NULL értékeknek az adatkészlet-pillanatkép teljes rekordszámához viszonyított arányára vonatkozik. Például, ha 100-ból 8 rekord NULL értékkel rendelkezik egy adott attribútumhoz, akkor az adott attribútum lefedettsége 92%.
Tekintsünk át egy másik üzleti esetet egy ETL-folyamattal, amely naponta készít terméktáblázat-pillanatképet. Figyelni akarjuk a termékleírás attribútumainak lefedettségét. Ha a lefedettség egy bizonyos küszöb alá esik, riasztást kell küldeni a támogató csapatnak. Az alábbiakban vizuálisan szemléltetjük a termékleírások jellemzőinek lefedettségét két hónapon keresztül:
A lefedettség abszolút napi különbségeit elemezve azt tapasztaljuk, hogy a változások nulla körül ingadoznak:
Ha ezt az adatot normál eloszlásként ábrázoljuk, az azt mutatja, hogy normális eloszlású, 0% körüli várható változással és 2,45%-os szórással.
Amint látjuk, ennél az adatkészletnél a termékleírás attribútum lefedettsége általában -4,9% és +4,9% között mozog 90%-os megbízhatósággal. Ez a mutató alapján beállíthatunk egy szabályt, amely figyelmeztetést ad, ha a lefedettség ezen a tartományon kívül esik.
Ha olyan adatkészletekkel dolgozik, amelyek jelentős eltéréseket mutatnak olyan tényezők miatt, mint a szezonalitás vagy a trendek, a hagyományos statisztikai módszerek téves riasztásokat válthatnak ki. Az idősoros algoritmusok kifinomultabb megközelítést kínálnak, javítva a minőségbiztosítási ellenőrzések pontosságát és megbízhatóságát.
Ésszerűbb riasztások létrehozásához használhatja a
A Holt-Winters segítségével modellezzük a napi eladásokat, amelyek trendi és szezonális mintákat is mutatnak:
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)
Ezzel a módszerrel olyan jelentős eltéréseket észlelhet, amelyek adatminőségi problémákra utalhatnak, így árnyaltabb megközelítést biztosít a minőségbiztosítási ellenőrzésekhez.
Remélem, hogy ez a cikk segít a minőségbiztosítási ellenőrzések hatékony végrehajtásában nagy adatkészleteinél. A Deequ könyvtár használatával, valamint a statisztikai módszerek és idősor-algoritmusok integrálásával biztosíthatja az adatok integritását és megbízhatóságát, végső soron javítva adatkezelési gyakorlatát.
A fent leírt technikák alkalmazása segít megelőzni a potenciális problémákat a későbbi alkalmazásokban, és javítja az adatmunkafolyamatok általános minőségét.