Едно от жизненоважните умения на завършен професионалист в областта на данните е ефективното боравене с големи набори от данни, гарантирайки качество и надеждност на данните. Данните са централната и основна част от всяка система за данни и каквито и добри умения да имате в други аспекти на нашата търговия, това е нещо, което не можете да си позволите да пренебрегнете. В тази статия изследвам стабилни техники за извършване на проверки на качеството на големи набори от данни с помощта на библиотеката Deequ и статистически методи. Чрез комбиниране на подходите, които обяснявам по-долу, ще можете да поддържате целостта на данните, да подобрите практиките си за управление на данни и да предотвратите потенциални проблеми в приложенията надолу по веригата. 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 тези предположения стават изрични чрез единични тестове. Ето някои често срещани проверки: Уверете се, че наборът от данни съдържа определен брой редове. Брой редове: Проверете дали атрибути като id и productName никога не са NULL. Пълнота на атрибута: Уверете се, че определени атрибути, като id, са уникални. Уникалност на атрибута: Уверете се, че атрибути като priority и numViews попадат в очакваните диапазони. Диапазон на стойността: Проверете дали описанията съдържат URL адреси, когато се очаква. Съвпадение на шаблони: Уверете се, че медианата на числовите атрибути отговаря на конкретни критерии. Статистически свойства: Ето как можете да приложите тези проверки с помощта на 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%) стойности на атрибута description съдържат URL. За щастие проведохме тест и открихме грешките; някой трябва незабавно да коригира данните! QA проверки със статистически методи Докато Deequ предлага стабилна рамка за валидиране на данни, интегрирането на статистически методи може допълнително да подобри вашите проверки на качеството, особено ако имате работа с агрегирани показатели на набор от данни. Нека видим как можете да използвате статистически методи за наблюдение и гарантиране на качеството на данните. Проследяване на броя на записите Помислете за бизнес сценарий, при който ETL (Extract, Transform, Load) процес произвежда N записа за ежедневно планирано задание. Екипите за поддръжка може да поискат да настроят проверки на качеството, за да предупредят, ако има значително отклонение в броя на записите. Например, ако процесът обикновено генерира между 9 500 до 10 500 записа дневно в продължение на два месеца, всяко значително увеличение или намаление може да означава проблем с основните данни. Можем да използваме статистически метод, за да определим този праг, при който процесът трябва да уведоми екипа за поддръжка. По-долу е илюстрация на проследяване на броя на записите за два месеца: За да анализираме това, можем да трансформираме данните за броя на записите, за да наблюдаваме ежедневните промени. Тези промени обикновено се колебаят около нула, както е показано на следната диаграма: Когато представим тази скорост на промяна с нормално разпределение, тя образува камбановидна крива, което показва, че данните са разпределени нормално. Очакваната промяна е около 0%, със стандартно отклонение от 2,63%. Този анализ предполага, че броят на записите обикновено попада в диапазона от -5,26% до +5,25% с 90% сигурност. Въз основа на това можете да установите правило за подаване на предупреждение, ако броят на записите се отклони извън този диапазон, като гарантира навременна намеса. Проследяване на покритието на атрибутите се отнася до съотношението на не-NULL стойности към общия брой записи за моментна снимка на набор от данни. Например, ако 8 от 100 записа имат NULL стойност за определен атрибут, покритието за този атрибут е 92%. Покритието на атрибута Нека прегледаме друг бизнес случай с ETL процес, генериращ ежедневно моментна снимка на таблица с продукти. Искаме да наблюдаваме покритието на атрибутите за описание на продукта. Ако покритието падне под определен праг, трябва да се подаде сигнал за екипа за поддръжка. По-долу е визуално представяне на покритието на атрибути за описания на продукти за два месеца: Анализирайки абсолютните ежедневни разлики в покритието, наблюдаваме, че промените се колебаят около нула: Представянето на тези данни като нормално разпределение показва, че те са нормално разпределени с очаквана промяна от около 0% и стандартно отклонение от 2,45%. Както виждаме, за този набор от данни покритието на атрибута за описание на продукта обикновено варира от -4,9% до +4,9% с 90% сигурност. Въз основа на този индикатор можем да зададем правило, което да сигнализира, ако покритието се отклони извън този диапазон. QA проверки с алгоритми за времеви серии Ако работите с набори от данни, които показват значителни вариации поради фактори като сезонност или тенденции, традиционните статистически методи може да предизвикат фалшиви сигнали. Алгоритмите за времеви серии предлагат по-рафиниран подход, подобрявайки точността и надеждността на вашите проверки на качеството. За да създадете по-разумни сигнали, можете да използвате или или на . Първото е достатъчно добро за набори от данни с тенденции, но второто ни позволява да работим с набори от данни както с тенденция, така и със сезонност. Този метод използва компоненти за ниво, тенденция и сезонност, което му позволява да се адаптира гъвкаво към промените във времето. Авторегресивна интегрирана подвижна средна (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 и интегрирането на статистически методи и алгоритми за времеви редове можете да осигурите целостта и надеждността на данните, като в крайна сметка подобрите практиките си за управление на данни. Прилагането на описаните по-горе техники ще ви помогне да предотвратите потенциални проблеми в приложенията надолу по веригата и ще подобри цялостното качество на вашите работни потоци с данни.
