Една од виталните вештини на остварениот професионалец за податоци е ефективно ракување со големи збирки на податоци, обезбедувајќи квалитет и доверливост на податоците. Податоците се централниот и фундаменталниот дел од секој систем на податоци, и без оглед на добрите вештини што ги имате во другите аспекти на нашата трговија, ова е она што не можете да си дозволите да го занемарите.

Во овој напис, истражувам робусни техники за вршење проверки на QA на големи збирки на податоци користејќи ја библиотеката Deequ и статистички методи. Со комбинирање на пристапите што ги објаснувам подолу, ќе можете да го одржите интегритетот на податоците, да ги подобрите практиките за управување со податоци и да спречите потенцијални проблеми во долните апликации.

ОК проверува користејќи ја библиотеката Deequ

Зошто Дику?

Обезбедувањето квалитет на податоците во обем е застрашувачка задача, особено кога се работи со милијарди редови складирани во дистрибуирани датотечни системи или складишта на податоци. Библиотеката Deequ е рамка за профилирање на податоци и QA со отворен код, изградена на Spark, која е модерна и разновидна алатка дизајнирана да го реши овој проблем. Она што го издвојува од слични алатки е неговата способност беспрекорно да се интегрира со Spark, искористувајќи ја дистрибуираната процесорска моќ за ефикасно ракување со сетови на податоци од големи размери.

Кога ќе го пробате, ќе видите како неговата флексибилност ви овозможува да дефинирате сложени правила за валидација прилагодени на вашите специфични барања, обезбедувајќи сеопфатна покриеност. Дополнително, Deequ располага со обемни метрики и способности за откривање аномалии кои ќе ви помогнат да ги идентификувате и проактивно да ги решавате проблемите со квалитетот на податоците. За професионалците за податоци кои работат со големи и динамични збирки на податоци, Deequ е решение со швајцарски нож. Ајде да видиме како можеме да го искористиме.

Поставување Deequ

Повеќе детали за поставувањето на библиотеката Deequ и случаите за употреба околу профилирањето на податоците се достапни овде . Заради едноставност, во овој пример, само генериравме неколку записи за играчки:

 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)

Дефинирање на претпоставки за податоци

Повеќето апликации за податоци доаѓаат со имплицитни претпоставки за атрибути на податоци, како што се не-NULL вредности и уникатност. Со Deequ, овие претпоставки стануваат експлицитни преку единечни тестови. Еве неколку вообичаени проверки:

1. Број на редови: проверете дали сетот содржи одреден број на редови.

   
   

2. Комплетност на атрибутот: проверете дали атрибутите како id и productName никогаш не се NULL.

   
   

3. Уникатност на атрибутот: Осигурете се дека одредени атрибути, како што е id, се единствени.

   
   

4. Опсег на вредности: Потврдете дека атрибутите како приоритет и numViews спаѓаат во очекуваните опсези.

   
   

5. Усогласување на шаблони: потврдете дека описите содржат URL-адреси кога се очекува.

   
   

6. Статистички својства: Осигурајте се дека медијаната на нумеричките атрибути ги исполнува специфичните критериуми.

Еве како можете да ги спроведете овие проверки користејќи 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()

Толкување на резултатите

Откако ќе ги изврши овие проверки, Deequ ги преведува во серија задачи на Spark, кои ги извршува за да ги пресмета метриките на податоците. Потоа, ги повикува вашите функции за тврдење (на пр. _ == 5 за проверка на големината) на овие метрики за да види дали ограничувањата држат за податоците. Можеме да го провериме објектот „verificationResult“ за да видиме дали тестот открил грешки:

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

Ако го извршиме примерот, го добиваме следниот излез:

 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!

Тестот покажа дека нашите претпоставки се прекршени! Само 4 од 5 (80%) од вредностите на атрибутот productName не се нула, а само 2 од 5 (т.е. 40%) вредности на атрибутот опис содржат URL. За среќа, извршивме тест и ги најдовме грешките; некој треба веднаш да ги поправи податоците!

ОК проверки со статистички методи

Додека Deequ нуди стабилна рамка за валидација на податоците, интегрирањето на статистички методи може дополнително да ги подобри вашите проверки за QA, особено ако се занимавате со збирни метрики на базата на податоци. Ајде да видиме како можете да користите статистички методи за следење и обезбедување на квалитетот на податоците.

Следење на бројот на записи

Размислете за деловно сценарио каде што процесот ETL (Extract, Transform, Load) произведува N записи на дневно закажана работа. Тимовите за поддршка можеби ќе сакаат да постават проверки за ОК за да подигнат предупредување доколку има значително отстапување во бројот на записи. На пример, ако процесот обично генерира помеѓу 9.500 и 10.500 записи дневно во текот на два месеци, секое значително зголемување или намалување може да укаже на проблем со основните податоци.

Можеме да користиме статистички метод за да го дефинираме овој праг за кој процес треба да подигне предупредување до тимот за поддршка. Подолу е илустрација за следење на бројот на рекорди во текот на два месеци:

За да го анализираме ова, можеме да ги трансформираме податоците за бројот на записи за да ги набљудуваме секојдневните промени. Овие промени генерално осцилираат околу нула, како што е прикажано на следниот графикон:

Кога ја претставуваме оваа стапка на промена со нормална дистрибуција, таа формира крива на ѕвонче, што покажува дека податоците се распределени нормално. Очекуваната промена е околу 0%, со стандардна девијација од 2,63%.

Оваа анализа сугерира дека бројот на рекорди обично спаѓа во опсегот од -5,26% до +5,25% со 90% доверба. Врз основа на ова, можете да воспоставите правило за подигнување предупредување ако бројот на записи отстапува надвор од овој опсег, обезбедувајќи навремена интервенција.

Следење на покриеност на атрибути

Покриеноста на атрибутот e се однесува на односот на вредностите кои не се NULL со вкупниот број на записи за снимката на базата на податоци. На пример, ако 8 од 100 записи имаат NULL вредност за одреден атрибут, покриеноста за тој атрибут е 92%.

Ајде да разгледаме друг деловен случај со ETL процес кој генерира слика од табелата на производи секој ден. Сакаме да ја следиме покриеноста на атрибутите на описот на производот. Ако покриеноста падне под одреден праг, треба да се подигне предупредување за тимот за поддршка. Подолу е визуелен приказ на покриеноста на атрибутите за описите на производите во текот на два месеци:

Со анализа на апсолутните секојдневни разлики во покриеноста, забележуваме дека промените осцилираат околу нула:

Претставувањето на овие податоци како нормална дистрибуција покажува дека тој е нормално распределен со очекувана промена од околу 0% и стандардна девијација од 2,45%.

Како што гледаме, за оваа база на податоци, покриеноста на атрибутот на описот на производот обично се движи од -4,9% до +4,9% со 90% доверба. Врз основа на овој индикатор, можеме да поставиме правило за подигнување предупредување ако покриеноста отстапува надвор од овој опсег.

ОК проверки со алгоритми за временски серии

Ако работите со збирки на податоци кои покажуваат значителни варијации поради фактори како сезонската или трендовите, традиционалните статистички методи може да предизвикаат лажни предупредувања. Алгоритмите за временски серии нудат попрефинет пристап, подобрувајќи ја точноста и веродостојноста на вашите проверки за ОК.

За да произведете поразумни предупредувања, можете да ги користите или Авторегресивен интегриран движечки просек (ARIMA) или на Холт-Винтерсов метод . Првото е доволно добро за збирки на податоци со трендови, но второто ни овозможува да се справиме со збирките на податоци и со тренд и со сезонска. Овој метод користи компоненти за ниво, тренд и сезона, што му овозможува флексибилно да се прилагодува на промените со текот на времето.

Ајде да се потсмеваме на дневните продажби кои покажуваат и тренд и сезонски модели користејќи 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)

Користејќи го овој метод, можете да откриете значителни отстапувања што може да укажат на проблеми со квалитетот на податоците, обезбедувајќи поизразен пристап кон проверките на QA.

Се надевам дека овој напис ќе ви помогне ефикасно да ги спроведете проверките за ОК за вашите големи збирки податоци. Со користење на библиотеката Deequ и интегрирање на статистички методи и алгоритми за временски серии, можете да обезбедите интегритет и доверливост на податоците, што на крајот ќе ги подобри вашите практики за управување со податоци.

Спроведувањето на техниките опишани погоре ќе ви помогне да спречите потенцијални проблеми во долните апликации и да го подобрите севкупниот квалитет на работните текови на вашите податоци.