تستر داده های بزرگ و کوچک: روندها، نظریه، داستان من

سلام به همه، نام من الکساندر است و من یک مهندس کیفیت داده هستم که داده ها را برای کیفیت آن بررسی می کنم. این مقاله در مورد چگونگی رسیدن من به این موضوع و اینکه چرا در سال 2020 این منطقه آزمایش بر روی تاج موج بود صحبت خواهد کرد.

تستر داده های بزرگ و کوچک: روندها، نظریه، داستان من

روند جهانی

دنیای امروز در حال تجربه یک انقلاب تکنولوژیکی دیگر است که یکی از جنبه‌های آن استفاده از داده‌های انباشته شده توسط انواع شرکت‌ها برای ارتقای چرخ لنگر فروش، سود و روابط عمومی است. به نظر می‌رسد وجود داده‌های خوب (با کیفیت) و همچنین مغزهای ماهری که می‌توانند از آن پول دربیاورند (به درستی پردازش، تجسم، ساخت مدل‌های یادگیری ماشین و غیره) کلید موفقیت بسیاری از افراد امروزی شده است. اگر 15 تا 20 سال پیش شرکت‌های بزرگ عمدتاً درگیر کار فشرده با انباشت داده‌ها و کسب درآمد بودند، امروز این سهم تقریباً همه افراد عاقل است.

در همین راستا، چندین سال پیش، تمام پورتال های اختصاص داده شده به جستجوی کار در سراسر جهان با جای خالی دانشمندان داده پر شدند، زیرا همه مطمئن بودند که با استخدام چنین متخصصی، می توان یک ابر مدل یادگیری ماشین ساخت. ، آینده را پیش بینی کنید و یک "جهش کوانتومی" برای شرکت انجام دهید. با گذشت زمان ، مردم متوجه شدند که این رویکرد تقریباً هرگز در هیچ کجا کار نمی کند ، زیرا همه داده هایی که به دست چنین متخصصانی می رسد برای مدل های آموزشی مناسب نیستند.

و درخواست‌های دانشمندان داده شروع شد: «بیایید داده‌های بیشتری از این و آن بخریم...»، «ما داده‌های کافی نداریم...»، «ما به مقداری داده بیشتر، ترجیحا با کیفیت بالا نیاز داریم...» . بر اساس این درخواست‌ها، تعاملات متعددی بین شرکت‌هایی که دارای مجموعه‌ای از داده‌ها هستند، شروع شد. طبیعتاً، این امر مستلزم سازماندهی فنی این فرآیند بود - اتصال به منبع داده، دانلود آن، بررسی بارگیری کامل آن و غیره. تعداد چنین فرآیندهایی شروع به افزایش کرد و امروز ما نیاز زیادی به نوع دیگری داریم. متخصصان - مهندسان کیفیت داده - کسانی که جریان داده ها را در سیستم (خطوط داده ها)، کیفیت داده ها در ورودی و خروجی را نظارت می کنند و در مورد کفایت، یکپارچگی و سایر ویژگی های آنها نتیجه گیری می کنند.

گرایش مهندسان کیفیت داده از ایالات متحده آمریکا به ما رسید، جایی که، در بحبوحه دوران خشمگین سرمایه داری، هیچ کس حاضر نیست نبرد برای داده ها را ببازد. در زیر تصاویری از دو تا از محبوب ترین سایت های کاریابی در ایالات متحده ارائه کرده ام: www.monster.com и www.dice.com - که داده‌های 17 مارس 2020 را در مورد تعداد پست‌های خالی دریافتی با استفاده از کلمات کلیدی: کیفیت داده و دانشمند داده نمایش می‌دهد.

www.monster.com

دانشمندان داده – 21416 شغل خالی
کیفیت داده ها – 41104 جای خالی

تستر داده های بزرگ و کوچک: روندها، نظریه، داستان من
تستر داده های بزرگ و کوچک: روندها، نظریه، داستان من

www.dice.com

دانشمندان داده – 404 جای خالی
کیفیت داده - مشاغل خالی 2020

تستر داده های بزرگ و کوچک: روندها، نظریه، داستان من
تستر داده های بزرگ و کوچک: روندها، نظریه، داستان من

بدیهی است که این حرفه ها به هیچ وجه قابل رقابت با یکدیگر نیستند. با اسکرین شات‌ها، من فقط می‌خواستم وضعیت فعلی بازار کار را از نظر درخواست‌ها برای مهندسان کیفیت داده، که در حال حاضر بسیار بیشتر از دانشمندان داده مورد نیاز هستند، نشان دهم.

در ژوئن 2019، EPAM، در پاسخ به نیازهای بازار مدرن فناوری اطلاعات، کیفیت داده را به یک عمل جداگانه تقسیم کرد. مهندسان کیفیت داده در طول کار روزانه خود، داده ها را مدیریت می کنند، رفتار آن را در شرایط و سیستم های جدید بررسی می کنند، ارتباط داده ها، کفایت و مرتبط بودن آنها را نظارت می کنند. با همه اینها، از نظر عملی، مهندسان کیفیت داده واقعاً زمان کمی را به آزمایش های عملکردی کلاسیک اختصاص می دهند. اما این تا حد زیادی به پروژه بستگی دارد (من یک مثال در زیر خواهم آورد).

مسئولیت‌های یک مهندس کیفیت داده‌ها فقط به بررسی‌های دستی/خودکار معمول برای «تهی، شمارش و مبالغ» در جداول پایگاه داده محدود نمی‌شود، بلکه نیازمند درک عمیق نیازهای تجاری مشتری و بر این اساس، توانایی تبدیل داده‌های موجود به اطلاعات مفید تجاری

تئوری کیفیت داده

تستر داده های بزرگ و کوچک: روندها، نظریه، داستان من

برای تصور کاملتر نقش چنین مهندس، بیایید بفهمیم که کیفیت داده در تئوری چیست.

کیفیت داده — یکی از مراحل مدیریت داده ها (یک دنیای کامل که ما آن را برای شما می گذاریم تا خودتان مطالعه کنید) و وظیفه تجزیه و تحلیل داده ها را بر اساس معیارهای زیر بر عهده دارد:

تستر داده های بزرگ و کوچک: روندها، نظریه، داستان من
من فکر می کنم نیازی به رمزگشایی هر یک از نقاط نیست (در تئوری آنها را "ابعاد داده" می نامند)، آنها به خوبی در تصویر توضیح داده شده اند. اما فرآیند آزمایش به خودی خود به معنای کپی دقیق این ویژگی ها در موارد آزمایشی و بررسی آنها نیست. در کیفیت داده، مانند هر نوع آزمایش دیگری، ابتدا لازم است بر اساس الزامات کیفیت داده که با شرکت کنندگان پروژه که تصمیمات تجاری را می گیرند، توافق شده است.

بسته به پروژه کیفیت داده، یک مهندس می‌تواند عملکردهای مختلفی را انجام دهد: از یک آزمایش‌کننده اتوماسیون معمولی با ارزیابی سطحی کیفیت داده‌ها، تا شخصی که پروفایل‌های عمیق داده‌ها را بر اساس معیارهای بالا انجام می‌دهد.

شرح بسیار دقیقی از مدیریت داده ها، کیفیت داده ها و فرآیندهای مربوطه به خوبی در کتابی به نام توضیح داده شده است "DAMA-DMBOK: مجموعه دانش مدیریت داده: ویرایش دوم". من این کتاب را به عنوان مقدمه ای برای این موضوع به شدت توصیه می کنم (لینک آن را در انتهای مقاله خواهید یافت).

داستان من

در صنعت IT، من از یک آزمایش‌کننده جوان در شرکت‌های تولیدی به یک مهندس ارشد کیفیت داده در EPAM رسیدم. پس از حدود دو سال کار به عنوان یک تستر، من این باور راسخ داشتم که کاملاً همه انواع تست ها را انجام داده ام: رگرسیون، عملکردی، استرس، ثبات، امنیت، رابط کاربری و غیره - و تعداد زیادی ابزار تست را امتحان کردم. همزمان در سه زبان برنامه نویسی جاوا، اسکالا، پایتون کار کرد.

با نگاهی به گذشته، می‌دانم که چرا مجموعه مهارت‌های من بسیار متنوع بود—من در پروژه‌های داده محور، بزرگ و کوچک شرکت داشتم. این چیزی است که من را وارد دنیایی با ابزارها و فرصت‌های رشد کرد.

برای درک تنوع ابزارها و فرصت‌ها برای کسب دانش و مهارت‌های جدید، کافی است به تصویر زیر نگاه کنید، که محبوب‌ترین ابزارها را در دنیای «داده و هوش مصنوعی» نشان می‌دهد.

تستر داده های بزرگ و کوچک: روندها، نظریه، داستان من
این نوع تصویر سالانه توسط یکی از سرمایه گذاران مخاطره آمیز معروف مت تورک که از توسعه نرم افزار می آید گردآوری می شود. اینجا پیوند به وبلاگش و شرکت سرمایه گذاری خطرپذیر، جایی که به عنوان شریک کار می کند.

من به‌ویژه زمانی که تنها آزمایش‌کننده پروژه بودم، یا حداقل در ابتدای پروژه، از نظر حرفه‌ای رشد کردم. در چنین لحظه ای است که شما باید مسئولیت کل فرآیند آزمایش را بر عهده بگیرید و فرصتی برای عقب نشینی ندارید، فقط به جلو. در ابتدا ترسناک بود، اما اکنون تمام مزایای چنین آزمایشی برای من آشکار است:

  • شما شروع به برقراری ارتباط با کل تیم می کنید مانند قبل، زیرا هیچ پروکسی برای ارتباط وجود ندارد: نه مدیر آزمون و نه همکاران آزمایش کننده.
  • غوطه ور شدن در پروژه به طرز باورنکردنی عمیق می شود و شما اطلاعاتی در مورد همه اجزا، چه به طور کلی و چه به صورت جزئی دارید.
  • توسعه‌دهندگان به شما به‌عنوان «کسی که آزمایش می‌کند که نمی‌داند چه کار می‌کند» نگاه نمی‌کنند، بلکه به‌عنوان یک فرد برابر که با آزمایش‌های خودکار خود و پیش‌بینی اشکال‌هایی که در یک جزء خاص ظاهر می‌شوند، مزایای باورنکردنی برای تیم ایجاد می‌کنند، نگاه نمی‌کنند. تولید - محصول.
  • در نتیجه، شما مؤثرتر، واجد شرایط تر و تقاضای شما بیشتر است.

با رشد پروژه، در 100% موارد من مربی آزمایش کنندگان جدید شدم، به آنها آموزش می دادم و دانشی را که خودم آموخته بودم منتقل می کردم. در عین حال، بسته به پروژه، همیشه بالاترین سطح متخصصان تست خودکار را از مدیریت دریافت نمی‌کردم و نیاز به آموزش اتوماسیون (برای علاقه‌مندان) یا ایجاد ابزارهایی برای استفاده در فعالیت‌های روزمره (ابزار) بود. برای تولید داده و بارگذاری آن در سیستم، ابزاری برای انجام تست بار / تست پایداری "سریع" و غیره).

نمونه ای از یک پروژه خاص

متأسفانه، به دلیل تعهدات عدم افشا، نمی توانم در مورد پروژه هایی که روی آنها کار کرده ام با جزئیات صحبت کنم، اما نمونه هایی از وظایف معمولی یک مهندس کیفیت داده در یکی از پروژه ها را بیان می کنم.

ماهیت این پروژه پیاده‌سازی بستری برای آماده‌سازی داده‌ها برای آموزش مدل‌های یادگیری ماشین بر اساس آن است. مشتری یک شرکت بزرگ دارویی از ایالات متحده آمریکا بود. از نظر فنی یک خوشه بود کوبرنیتس، افزایش به AWS EC2 نمونه هایی با چندین میکروسرویس و پروژه منبع باز زیربنایی EPAM - لژیون، مطابق با نیازهای یک مشتری خاص (اکنون این پروژه دوباره متولد شده است اوداهو). فرآیندهای ETL با استفاده از سازماندهی شدند جریان هوای آپاچی و داده ها را از نیروی فروش سیستم های مشتری در AWS S3 سطل. در مرحله بعد، یک تصویر Docker از یک مدل یادگیری ماشین روی پلتفرم مستقر شد که بر روی داده‌های تازه آموزش داده شد و با استفاده از رابط REST API، پیش‌بینی‌هایی را تولید کرد که مورد علاقه کسب‌وکار بود و مشکلات خاصی را حل کرد.

از نظر بصری، همه چیز چیزی شبیه به این بود:

تستر داده های بزرگ و کوچک: روندها، نظریه، داستان من
آزمایش‌های عملکردی زیادی روی این پروژه انجام شد، و با توجه به سرعت توسعه ویژگی‌ها و نیاز به حفظ سرعت چرخه انتشار (دو هفته سرعت)، لازم بود فوراً به فکر آزمایش خودکار حیاتی‌ترین مؤلفه‌ها باشیم. سیستم. بیشتر پلتفرم مبتنی بر Kubernetes توسط تست‌های خودکار اجرا شده در آن پوشش داده شد چارچوب ربات + پایتون، اما حمایت و گسترش آنها نیز ضروری بود. علاوه بر این، برای راحتی مشتری، یک رابط کاربری گرافیکی برای مدیریت مدل‌های یادگیری ماشین مستقر در خوشه، و همچنین توانایی تعیین مکان و مکان انتقال داده‌ها برای آموزش مدل‌ها ایجاد شد. این افزوده گسترده مستلزم گسترش تست عملکردی خودکار بود که بیشتر از طریق تماس‌های REST API و تعداد کمی از تست‌های UI پایانی ۲ انجام می‌شد. در حوالی خط استوای تمام این حرکت، یک تستر دستی به ما ملحق شد که با تست پذیرش نسخه های محصول و برقراری ارتباط با مشتری در مورد پذیرش نسخه بعدی، کار بسیار خوبی انجام داد. علاوه بر این، به دلیل ورود یک متخصص جدید، ما توانستیم کار خود را مستندسازی کنیم و چندین چک دستی بسیار مهم را اضافه کنیم که خودکار کردن آنها بلافاصله دشوار بود.

و در نهایت، پس از اینکه از پلتفرم و افزونه رابط کاربری گرافیکی بر روی آن به ثبات رسیدیم، شروع به ساخت خطوط لوله ETL با استفاده از Apache Airflow DAGها کردیم. بررسی خودکار کیفیت داده ها با نوشتن DAG های جریان هوای ویژه ای انجام شد که داده ها را بر اساس نتایج فرآیند ETL بررسی می کرد. به عنوان بخشی از این پروژه، ما خوش شانس بودیم و مشتری به ما امکان دسترسی به مجموعه داده های ناشناس را داد که روی آنها آزمایش کردیم. ما داده‌ها را خط به خط برای مطابقت با انواع، وجود داده‌های شکسته، تعداد کل رکوردهای قبل و بعد، مقایسه تبدیل‌های انجام شده توسط فرآیند ETL برای تجمیع، تغییر نام ستون‌ها و موارد دیگر بررسی کردیم. علاوه بر این، این بررسی ها به منابع داده های مختلف، به عنوان مثال، علاوه بر SalesForce، همچنین به MySQL مقیاس شدند.

بررسی‌های کیفیت نهایی داده‌ها قبلاً در سطح S3 انجام شده بود، جایی که آنها ذخیره می‌شدند و برای آموزش مدل‌های یادگیری ماشین آماده استفاده بودند. برای به دست آوردن اطلاعات از فایل CSV نهایی واقع در سطل S3 و اعتبارسنجی آن، کد با استفاده از آن نوشته شد مشتریان boto3.

همچنین مشتری باید بخشی از داده ها را در یک S3 Bucket و بخشی را در دیگری ذخیره کند. این همچنین مستلزم نوشتن بررسی‌های اضافی برای بررسی قابلیت اطمینان چنین مرتب‌سازی بود.

تجربه عمومی از پروژه های دیگر

نمونه ای از کلی ترین لیست فعالیت های یک مهندس کیفیت داده ها:

  • داده های آزمایشی (معتبر نامعتبر بزرگ کوچک) را از طریق یک ابزار خودکار آماده کنید.
  • مجموعه داده های آماده شده را در منبع اصلی آپلود کنید و بررسی کنید که برای استفاده آماده است.
  • فرآیندهای ETL را برای پردازش مجموعه‌ای از داده‌ها از منبع ذخیره‌سازی منبع تا ذخیره‌سازی نهایی یا میانی با استفاده از مجموعه‌ای از تنظیمات راه‌اندازی کنید (در صورت امکان، پارامترهای قابل تنظیم را برای وظیفه ETL تنظیم کنید).
  • داده های پردازش شده توسط فرآیند ETL را برای کیفیت و مطابقت با الزامات تجاری تأیید کنید.

در عین حال، تمرکز اصلی بررسی ها نه تنها باید بر این واقعیت باشد که جریان داده در سیستم، در اصل، کار کرده و به اتمام رسیده است (که بخشی از آزمایش عملکردی است)، بلکه بیشتر بر بررسی و اعتبارسنجی داده ها برای انطباق با الزامات مورد انتظار، شناسایی ناهنجاری ها و موارد دیگر.

ابزارهای

یکی از تکنیک های چنین کنترل داده ها می تواند سازماندهی بررسی های زنجیره ای در هر مرحله از پردازش داده ها باشد که در ادبیات به اصطلاح "زنجیره داده" نامیده می شود - کنترل داده ها از منبع تا نقطه استفاده نهایی. این نوع چک ها اغلب با نوشتن پرس و جوهای بررسی SQL اجرا می شوند. واضح است که چنین پرس و جوهایی باید تا حد امکان سبک باشند و تکه های تک تک کیفیت داده ها را بررسی کنند (فراداده جداول، خطوط خالی، NULL ها، خطاها در نحو - سایر ویژگی های مورد نیاز برای بررسی).

در مورد تست رگرسیون، که از مجموعه داده های آماده (غیر قابل تغییر، کمی قابل تغییر) استفاده می کند، کد تست خودکار می تواند الگوهای آماده را برای بررسی انطباق داده ها با کیفیت ذخیره کند (توضیحات ابرداده جدول مورد انتظار؛ اشیاء نمونه ردیفی که می توانند به طور تصادفی در طول آزمون و غیره انتخاب شده است).

همچنین، در طول آزمایش، شما باید فرآیندهای تست ETL را با استفاده از چارچوب هایی مانند Apache Airflow بنویسید. جرقه آپاچی یا حتی یک ابزار از نوع ابر جعبه سیاه GCP Dataprep, GCP Dataflow و غیره. این شرایط مهندس آزمایش را وادار می کند تا خود را در اصول عملکرد ابزارهای فوق غوطه ور کند و حتی به طور مؤثرتری هم آزمایش عملکردی (مثلاً فرآیندهای ETL موجود در یک پروژه) را انجام دهد و هم از آنها برای بررسی داده ها استفاده کند. به طور خاص، Apache Airflow دارای اپراتورهای آماده ای برای کار با پایگاه داده های تحلیلی محبوب است GCP BigQuery. ابتدایی ترین مثال استفاده از آن قبلاً بیان شده است اینجا، بنابراین من خودم را تکرار نمی کنم.

به غیر از راه حل های آماده، هیچ کس شما را از اجرای تکنیک ها و ابزارهای خود منع نمی کند. این نه تنها برای پروژه، بلکه برای خود مهندس کیفیت داده نیز مفید خواهد بود، که بدین وسیله افق های فنی و مهارت های کدنویسی خود را بهبود می بخشد.

چگونه در یک پروژه واقعی کار می کند

یک تصویر خوب از آخرین پاراگراف ها در مورد "زنجیره داده"، ETL و بررسی های همه جا حاضر فرآیند زیر از یکی از پروژه های واقعی است:

تستر داده های بزرگ و کوچک: روندها، نظریه، داستان من

در اینجا، داده های مختلف (به طور طبیعی، تهیه شده توسط ما) وارد "قیف" ورودی سیستم ما می شود: معتبر، نامعتبر، مختلط و غیره، سپس فیلتر می شوند و به یک ذخیره سازی میانی ختم می شوند، سپس دوباره تحت یک سری تغییرات قرار می گیرند. و در ذخیره‌سازی نهایی قرار می‌گیرند، که به نوبه خود، تجزیه و تحلیل، ساخت و ساز داده‌ها و جستجوی بینش تجاری از آن انجام خواهد شد. در چنین سیستمی، بدون بررسی عملکردی عملکرد فرآیندهای ETL، ما بر کیفیت داده‌ها قبل و بعد از تبدیل و همچنین بر روی خروجی به تجزیه و تحلیل تمرکز می‌کنیم.

برای خلاصه کردن موارد فوق، صرف نظر از مکان‌هایی که در آن کار می‌کردم، همه جا درگیر پروژه‌های Data بودم که ویژگی‌های زیر را به اشتراک می‌گذاشتند:

  • فقط از طریق اتوماسیون می توانید برخی موارد را آزمایش کنید و به چرخه انتشار قابل قبول برای تجارت برسید.
  • آزمایش کننده در چنین پروژه ای یکی از محترم ترین اعضای تیم است، زیرا مزایای زیادی برای هر یک از شرکت کنندگان به همراه دارد (تسریع در آزمایش، داده های خوب از دانشمند داده، شناسایی نقص در مراحل اولیه).
  • فرقی نمی‌کند که روی سخت‌افزار خود کار می‌کنید یا در فضای ابری - همه منابع در یک کلاستر مانند Hortonworks، Cloudera، Mesos، Kubernetes و غیره انتزاع می‌شوند.
  • پروژه ها بر اساس رویکرد میکروسرویس ساخته می شوند، محاسبات توزیع شده و موازی غالب است.

من می خواهم توجه داشته باشم که هنگام انجام تست در زمینه کیفیت داده ها، یک متخصص تست تمرکز حرفه ای خود را روی کد محصول و ابزارهای مورد استفاده قرار می دهد.

ویژگی های متمایز تست کیفیت داده ها

علاوه بر این، برای خودم، ویژگی‌های متمایز آزمایش در پروژه‌های داده (سیستم‌ها) و سایر حوزه‌ها را شناسایی کرده‌ام (فوراً رزرو می‌کنم که آنها بسیار کلی و کاملاً ذهنی هستند):

تستر داده های بزرگ و کوچک: روندها، نظریه، داستان من

لینک های مفید

  1. تئوری: DAMA-DMBOK: مجموعه دانش مدیریت داده: ویرایش دوم.
  2. مرکز آموزش EPAM 
  3. مواد توصیه شده برای یک مهندس کیفیت داده مبتدی:
    1. دوره رایگان استپیک: مقدمه ای بر پایگاه های داده
    2. دوره آموزشی لینکدین: مبانی علم داده: مهندسی داده.
    3. مقالات:
    4. ویدئو:

نتیجه

کیفیت داده یک مسیر نویدبخش بسیار جوان است که بخشی از آن به معنای عضویت در یک استارتاپ است. هنگامی که به کیفیت داده ها دست پیدا کنید، در تعداد زیادی از فناوری های مدرن و مورد تقاضا غوطه ور خواهید شد، اما مهمتر از همه، فرصت های عظیمی برای تولید و اجرای ایده های خود برای شما باز خواهد شد. شما قادر خواهید بود از رویکرد بهبود مستمر نه تنها در پروژه، بلکه برای خود نیز استفاده کنید و به عنوان یک متخصص به طور مداوم در حال توسعه باشید.

منبع: www.habr.com

اضافه کردن نظر