یکی از مهارت‌های حیاتی یک متخصص داده، مدیریت مؤثر مجموعه داده‌های بزرگ، تضمین کیفیت و قابلیت اطمینان داده‌ها است. داده ها بخش مرکزی و اساسی هر سیستم داده ای است، و هر مهارت خوبی که در سایر جنبه های تجارت ما دارید، این مهارتی است که نمی توانید نادیده بگیرید. در این مقاله، من تکنیک‌های قوی برای انجام بررسی‌های QA روی مجموعه داده‌های بزرگ با استفاده از کتابخانه Deequ و روش‌های آماری را بررسی می‌کنم. با ترکیب رویکردهایی که در زیر توضیح می‌دهم، می‌توانید یکپارچگی داده‌ها را حفظ کنید، شیوه‌های مدیریت داده‌های خود را ارتقا دهید و از مشکلات احتمالی در برنامه‌های پایین‌دستی جلوگیری کنید. بررسی QA با استفاده از کتابخانه 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 در محدوده های مورد انتظار قرار می گیرند. Value Range: بررسی کنید که توضیحات حاوی 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%) مقدار مشخصه توضیحات حاوی URL هستند. خوشبختانه، ما یک آزمایش انجام دادیم و خطاها را پیدا کردیم. کسی باید فوراً داده ها را اصلاح کند! چک های QA با روش های آماری در حالی که Deequ یک چارچوب قوی برای اعتبار سنجی داده ها ارائه می دهد، یکپارچه سازی روش های آماری می تواند بررسی های QA شما را بیشتر تقویت کند، به خصوص اگر با معیارهای جمع آوری یک مجموعه داده سر و کار دارید. بیایید ببینیم چگونه می توانید از روش های آماری برای نظارت و اطمینان از کیفیت داده ها استفاده کنید. ردیابی تعداد رکورد یک سناریوی تجاری را در نظر بگیرید که در آن یک فرآیند ETL (Extract, Transform, Load) N رکورد در یک کار برنامه ریزی شده روزانه تولید می کند. تیم‌های پشتیبانی ممکن است بخواهند در صورت وجود انحراف قابل‌توجه در شمارش رکورد، بررسی‌های QA را برای اعلام هشدار تنظیم کنند. به عنوان مثال، اگر فرآیند معمولاً بین 9500 تا 10500 رکورد روزانه در طی دو ماه تولید می کند، هر افزایش یا کاهش قابل توجهی می تواند نشان دهنده مشکل در داده های اساسی باشد. ما می‌توانیم از یک روش آماری برای تعریف این آستانه استفاده کنیم که در آن فرآیند باید یک هشدار برای تیم پشتیبانی ایجاد کند. در زیر تصویری از ردیابی تعداد رکورد در طول دو ماه آورده شده است: برای تجزیه و تحلیل این، می‌توانیم داده‌های شمارش رکورد را برای مشاهده تغییرات روزانه تغییر دهیم. این تغییرات به طور کلی حول صفر در نوسان هستند، همانطور که در نمودار زیر نشان داده شده است: وقتی این نرخ تغییر را با توزیع نرمال نشان می‌دهیم، منحنی زنگی را تشکیل می‌دهد که نشان می‌دهد داده‌ها به طور نرمال توزیع شده‌اند. تغییر مورد انتظار حدود 0٪ است، با انحراف استاندارد 2.63٪. این تجزیه و تحلیل نشان می دهد که تعداد رکوردها معمولاً در محدوده -5.26٪ تا +5.25٪ با اطمینان 90٪ قرار می گیرد. بر این اساس، می‌توانید قانونی ایجاد کنید تا در صورت انحراف تعداد رکورد از این محدوده، یک هشدار ایجاد کنید و از مداخله به موقع اطمینان حاصل کنید. ردیابی پوشش ویژگی e به نسبت مقادیر غیر NULL به تعداد کل رکورد برای یک عکس فوری مجموعه داده اشاره دارد. به عنوان مثال، اگر 8 رکورد از 100 رکورد دارای مقدار NULL برای یک ویژگی خاص باشد، پوشش آن ویژگی 92٪ است. پوشش ویژگی بیایید یک مورد تجاری دیگر را با یک فرآیند ETL که روزانه یک عکس از جدول محصول تولید می کند، مرور کنیم. ما می خواهیم پوشش ویژگی های توضیحات محصول را نظارت کنیم. اگر پوشش از یک آستانه معین پایین بیاید، باید برای تیم پشتیبانی هشدار داده شود. در زیر یک نمایش تصویری از پوشش ویژگی برای توضیحات محصول در طول دو ماه آورده شده است: با تجزیه و تحلیل تفاوت‌های روزانه مطلق در پوشش، مشاهده می‌کنیم که تغییرات حول صفر نوسان می‌کنند: نمایش این داده‌ها به‌عنوان یک توزیع نرمال نشان می‌دهد که معمولاً با تغییر انتظاری حدود 0 درصد و انحراف معیار 2.45 درصد توزیع می‌شود. همانطور که می بینیم، برای این مجموعه داده، پوشش ویژگی توصیف محصول معمولاً از -4.9٪ تا +4.9٪ با اطمینان 90٪ متغیر است. بر اساس این اندیکاتور، می‌توانیم قاعده‌ای تنظیم کنیم که در صورت انحراف پوشش فراتر از این محدوده، هشدار ایجاد کنیم. بررسی های QA با الگوریتم های سری زمانی اگر با مجموعه داده هایی کار می کنید که تغییرات قابل توجهی را به دلیل عواملی مانند فصلی یا روند نشان می دهند، روش های آماری سنتی ممکن است هشدارهای نادرست را ایجاد کنند. الگوریتم‌های سری زمانی رویکرد دقیق‌تری را ارائه می‌دهند که دقت و قابلیت اطمینان بررسی‌های QA شما را بهبود می‌بخشد. برای تولید هشدارهای معقول تر، می توانید از یکی از این دو استفاده کنید یا . مورد اول برای مجموعه داده‌های دارای روند به اندازه کافی خوب است، اما دومی به ما امکان می‌دهد با مجموعه داده‌ها هم با روند و هم با فصلی برخورد کنیم. این روش از مؤلفه‌هایی برای سطح، روند و فصلی استفاده می‌کند که به آن اجازه می‌دهد به طور انعطاف‌پذیری با تغییرات در طول زمان سازگار شود. میانگین متحرک یکپارچه خودرگرسیون (ARIMA) روش Holt-Winters بیایید مدل های ساختگی فروش روزانه را که هم الگوهای روند و هم الگوهای فصلی را با استفاده از 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 ارائه دهید. امیدوارم این مقاله به شما کمک کند تا به طور موثر بررسی های QA را برای مجموعه داده های بزرگ خود اجرا کنید. با استفاده از کتابخانه Deequ و یکپارچه‌سازی روش‌های آماری و الگوریتم‌های سری زمانی، می‌توانید از یکپارچگی و قابلیت اطمینان داده‌ها اطمینان حاصل کنید و در نهایت شیوه‌های مدیریت داده‌های خود را افزایش دهید. پیاده سازی تکنیک های توضیح داده شده در بالا به شما کمک می کند تا از مشکلات احتمالی در برنامه های پایین دستی جلوگیری کنید و کیفیت کلی گردش کار داده های خود را بهبود بخشید.
