Једна од виталних вештина искусног стручњака за податке је ефикасно руковање великим скуповима података, обезбеђујући квалитет и поузданост података. Подаци су централни и фундаментални део сваког система података, и које год добре вештине имате у другим аспектима наше трговине, ово је оно које не можете да превидите. У овом чланку истражујем робусне технике за обављање КА провера на великим скуповима података користећи Дееку библиотеку и статистичке методе. Комбиновањем приступа које објашњавам у наставку, моћи ћете да одржите интегритет података, побољшате своје праксе управљања подацима и спречите потенцијалне проблеме у низводним апликацијама. КА провере користећи Дееку библиотеку Зашто Дееку? Обезбеђивање квалитета података у великим размерама је застрашујући задатак, посебно када се ради о милијардама редова ускладиштених у дистрибуираним системима датотека или складиштима података. Дееку библиотека је оквир за профилисање података отвореног кода и КА оквир изграђен на Спарк-у који је модеран и свестран алат дизајниран да реши овај проблем. Оно што га издваја од сличних алата је његова способност да се неприметно интегрише са Спарк-ом, користећи дистрибуирану процесорску снагу за ефикасно руковање великим скуповима података. Када га испробате, видећете како вам његова флексибилност омогућава да дефинишете сложена правила валидације прилагођена вашим специфичним захтевима, обезбеђујући свеобухватну покривеност. Поред тога, Дееку поседује опсежне метрике и могућности откривања аномалија које ће вам помоћи да идентификујете и проактивно решавате проблеме са квалитетом података. За професионалце који раде са великим и динамичним скуповима података, Дееку је решење за швајцарски нож. Хајде да видимо како то можемо користити. Подешавање Дееку Више детаља о подешавању Дееку библиотеке и случајевима коришћења око профилисања података доступно је . Ради једноставности, у овом примеру смо управо генерисали неколико записа играчака: овде 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) Дефинисање претпоставки података Већина апликација података долази са имплицитним претпоставкама о атрибутима података, као што су вредности које нису НУЛЛ и јединственост. Са Дееку-ом, ове претпоставке постају експлицитне кроз јединичне тестове. Ево неких уобичајених провера: Уверите се да скуп података садржи одређени број редова. Број редова: Проверите да атрибути као што су ид и продуцтНаме никада нису НУЛЛ. Комплетност атрибута: Уверите се да су одређени атрибути, као што је ид, јединствени. Јединственост атрибута: Потврдите да атрибути попут приоритета и нумВиевс спадају у очекиване опсеге. Опсег вредности: Проверите да описи садрже УРЛ-ове када се то очекује. Подударање обрасца: Осигурајте да медијана нумеричких атрибута испуњава специфичне критеријуме. Статистичка својства: Ево како можете да примените ове провере користећи Дееку: 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() Интерпретинг Ресултс Након покретања ових провера, Дееку их преводи у низ Спарк послова, које извршава да би израчунао метрику података. Након тога, он позива ваше функције тврдње (нпр. _ == 5 за проверу величине) на овим метрикама да би видео да ли се ограничења држе на подацима. Можемо да прегледамо објекат „верифицатионРесулт“ да видимо да ли је тест открио грешке: 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%) вредности атрибута продуцтНаме нису нулте, а само 2 од 5 (тј. 40%) вредности атрибута десцриптион садрже УРЛ. На срећу, извршили смо тест и пронашли грешке; неко треба одмах да поправи податке! КА провере помоћу статистичких метода Док Дееку нуди робустан оквир за валидацију података, интегрисање статистичких метода може додатно побољшати ваше провере квалитета, посебно ако имате посла са агрегираним метрикама скупа података. Хајде да видимо како можете користити статистичке методе за праћење и осигурање квалитета података. Праћење броја записа Размислите о пословном сценарију где ЕТЛ (Ектрацт, Трансформ, Лоад) процес производи Н записа на дневно планираном послу. Тимови за подршку ће можда желети да поставе провере квалитета како би подигли упозорење ако постоји значајно одступање у броју записа. На пример, ако процес обично генерише између 9.500 и 10.500 записа дневно током два месеца, свако значајно повећање или смањење може указивати на проблем са основним подацима. Можемо користити статистичку методу да дефинишемо овај праг о томе који процес треба да поднесе упозорење тиму за подршку. Испод је илустрација праћења броја записа током два месеца: Да бисмо ово анализирали, можемо да трансформишемо податке о броју записа да бисмо посматрали свакодневне промене. Ове промене генерално осцилирају око нуле, као што је приказано на следећем графикону: Када ову стопу промене представимо нормалном дистрибуцијом, она формира звонасту криву, што указује на то да су подаци нормално распоређени. Очекивана промена је око 0%, са стандардном девијацијом од 2,63%. Ова анализа сугерише да број рекорда обично пада у распону од -5,26% до +5,25% са поузданошћу од 90%. На основу тога, можете успоставити правило за подизање упозорења ако број записа одступи изван овог опсега, обезбеђујући благовремену интервенцију. Праћење покривености атрибута се односи на однос вредности које нису НУЛЛ и укупног броја записа за снимак скупа података. На пример, ако 8 од 100 записа има вредност НУЛЛ за одређени атрибут, покривеност тог атрибута је 92%. Покривеност атрибута Хајде да прегледамо још један пословни случај са ЕТЛ процесом који свакодневно генерише снимак табеле производа. Желимо да пратимо покривеност атрибута описа производа. Ако покривеност падне испод одређеног прага, тим за подршку треба да се подигне упозорење. Испод је визуелни приказ покривености атрибута за описе производа током два месеца: Анализирајући апсолутне свакодневне разлике у покривености, примећујемо да промене осцилирају око нуле: Представљање овог податка као нормалне дистрибуције показује да је нормално распоређено са очекиваном променом од око 0% и стандардном девијацијом од 2,45%. Као што видимо, за овај скуп података покривеност атрибута описа производа се обично креће од -4,9% до +4,9% са 90% поузданости. На основу овог индикатора, можемо поставити правило за подизање упозорења ако покривеност одступи од овог опсега. КА провере са алгоритмима временске серије Ако радите са скуповима података који показују значајне варијације због фактора као што су сезоналност или трендови, традиционалне статистичке методе могу покренути лажна упозорења. Алгоритми временских серија нуде префињенији приступ, побољшавајући тачност и поузданост провера квалитета. Да бисте произвели разумнија упозорења, можете да користите било које или тхе . Први је довољно добар за скупове података са трендовима, али други нам омогућава да се бавимо скуповима података и са трендом и са сезоналношћу. Овај метод користи компоненте за ниво, тренд и сезоналност, што му омогућава да се флексибилно прилагођава променама током времена. Ауторегресивни интегрисани покретни просек (АРИМА) Холт-Винтерс метод Хајде да се ругамо моделом дневне продаје која показује трендове и сезонске обрасце користећи Холт-Винтерс: 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) Користећи овај метод, можете открити значајна одступања која могу указивати на проблеме са квалитетом података, пружајући нијансиранији приступ проверама квалитета. Надам се да ће вам овај чланак помоћи да ефикасно примените провере квалитета за ваше велике скупове података. Коришћењем Дееку библиотеке и интеграцијом статистичких метода и алгоритама временских серија, можете осигурати интегритет и поузданост података, на крају побољшајући своје праксе управљања подацима. Примена горе описаних техника помоћи ће вам да спречите потенцијалне проблеме у низводним апликацијама и побољшате укупан квалитет токова рада података.
