راهنمای مبتدی برای مهندسی داده ها - قسمت دوم

مدل سازی داده ها ، تقسیم بندی داده ها ، جریان هوا و بهترین روش های ETL

اعتبار تصویر: یک انبار مدرن تبدیل شده در Hangar 16، Madrid (Cortesía de Iñaqui Carnicero Arquitectura)

بازپرداخت

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

یکی از مهارتهای بسیار مورد نیاز مهندس داده توانایی طراحی ، ساخت و نگهداری انبارهای داده است. من تعریف کردم که ذخیره سازی داده چیست و سه بلوک ساختمان مشترک آن - Extract ، Transform و Load را که در آن نام ETL از کجا آمده است ، بحث کردم.

برای کسانی که جدید در فرآیندهای ETL هستند ، چند چارچوب محبوب منبع آزاد را که توسط شرکت هایی مانند LinkedIn ، Pinterest ، Spotify ساخته شده اند ، معرفی کردم و از ابزار منبع باز Airfnb خود ، Airflnb را برجسته کرده ام. سرانجام ، من استدلال كردم كه دانشمند داده می تواند مهندسی داده را بسیار مؤثرتر با پارادایم ETL مبتنی بر SQL بیاموزد.

قسمت دوم بررسی اجمالی

بحث در قسمت اول تا حدی سطح بالایی بود. در قسمت دوم (این پست) ، جزئیات فنی بیشتری در مورد نحوه ساخت خطوط لوله داده خوب و برجسته کردن بهترین روش های ETL به اشتراک می گذارم. در درجه اول ، من از Python ، Airflow و SQL برای بحث خود استفاده می کنم.

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

در بخش های بعدی ، آناتومی یک کار Airflow را جدا خواهم کرد. خوانندگان یاد می گیرند که چگونه از حسگرها ، اپراتورها و نقل و انتقالات استفاده کنند تا مفاهیم استخراج ، تغییر و بارگیری را عملیاتی کنند. ما بهترین روشهای ETL را برجسته خواهیم کرد و از نمونه های زندگی واقعی مانند Airbnb ، Stitch Fix ، Zymergen و موارد دیگر استفاده می کنیم.

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

مدل سازی داده ها

اعتبار تصویر: در صورت استفاده صحیح از طرحواره ستاره ، می تواند به همان اندازه آسمان واقعی زیبا باشد

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

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

مدل سازی داده ها ، نرمال سازی و طرحواره ستاره

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

از سوی دیگر ، اغلب پرس و جو از یک جدول بدون تغییر (مانند یک جدول گسترده) بسیار ساده تر است ، زیرا تمام معیارها و ابعاد از قبل پیوست شده اند. با این حال ، با توجه به اندازه های بزرگتر ، پردازش داده ها برای جداول گسترده کندتر است و وابستگی بیشتری به بالادست دارد. این امر تعمیر و نگهداری خطوط لوله ETL را دشوارتر می کند زیرا واحد کار به اندازه ماژولار نیست.

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

طرحواره ستارگان میزهایی را با الگوی ستاره مانند ، با یک جدول واقعیت در مرکز ، که با میزهای کم نور احاطه شده بود ، ترتیب می داد

جداول واقعیت و ابعاد

برای درک نحوه ساخت جداول غیرمترقبه از جداول حقایق و جداول ابعاد ، باید نقش های مربوط به آنها را با جزئیات بیشتری مورد بحث قرار دهیم:

  • جداول واقعیت معمولاً حاوی داده های معامله ای در زمان است. هر سطر در جدول می تواند بسیار ساده باشد و اغلب به عنوان واحد معامله نمایش داده می شود. به دلیل سادگی ، آنها اغلب منشأ جداول حقیقت هستند که از آنها معیارهای تجاری گرفته می شود. به عنوان مثال ، در Airbnb ، ما جداول حقایق مختلفی داریم که رویدادهای مشابه معاملات مانند رزرو ، رزرو ، تغییرات ، لغو و موارد دیگر را دنبال می کنیم.
  • جداول ابعادی معمولاً حاوی ویژگیهای آهسته متغیر موجودات خاص هستند و بعضی اوقات ویژگیها در یک ساختار سلسله مراتبی سازماندهی می شوند. این ویژگیها معمولاً "ابعاد" خوانده می شوند ، مادامی که یک کلید خارجی در جدول واقعیت موجود باشد ، می توانید با جداول واقعیت به آنها ملحق شوید. در Airbnb ، ما جدول های ابعادی مختلفی از قبیل کاربران ، لیست ها و بازارهایی ایجاد کردیم که به ما کمک می کند تا داده های خود را برش داده و تکه کنیم.

در زیر مثالی ساده از چگونگی جمع شدن جداول واقعیتها و جداول ابعادی (هر دو جدول عادی) با هم وجود دارد تا بتوانید به سؤال اصلی پایه تحلیلی مانند اینکه چه تعداد رزرو در هفته گذشته در هر بازار اتفاق افتاده است پاسخ دهید. کاربران خردمند همچنین می توانند تصور کنند که اگر معیارهای اضافی m_a ، m_b ، m_c و ابعاد dim_x ، dim_y ، dim_z در بند SELECT نهایی پیش بینی شده باشد ، می توان جداول تغییر شکل یافته را به راحتی از این جداول عادی ساخته کرد.

تقسیم بندی داده ها و داده های تاریخچه بازگشت مجدد داده ها

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

تقسیم بندی داده ها توسط Datestamp

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

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

به طور خاص ، یک کلید پارتیشن مشترک برای استفاده ، Datestamp (ds برای کوتاه) و به دلایل خوب است. اول ، در سیستم ذخیره سازی داده ها مانند S3 ، داده های خام اغلب توسط datestamp سازماندهی می شوند و در دایرکتوری هایی با برچسب زمان ذخیره می شوند. علاوه بر این ، واحد کار برای یک کار ETL دسته ای معمولاً یک روز است ، به این معنی که پارتیشن های تاریخ جدید برای هر بار اجرا در روز ایجاد می شوند. سرانجام ، بسیاری از سؤالات تحلیلی شامل شمارش رویدادهایی است که در یک بازه زمانی مشخص اتفاق افتاده است ، بنابراین پرس و جو از طریق datestamp یک الگوی بسیار رایج است. جای تعجبی ندارد که datestamp یک انتخاب محبوب برای پارتیشن بندی داده ها باشد!

برگشت داده های تاریخی

یکی دیگر از مزیت های مهم استفاده از datestamp به عنوان کلید پارتیشن ، سهولت استفاده مجدد داده ها است. هنگامی که خط لوله ETL ساخته شده است ، معیارها و ابعاد رو به جلو را محاسبه می کند ، نه به عقب. اغلب ، ما ممکن است مایل به تجدید نظر در روندها و جنبشهای تاریخی. در چنین مواردی ، نیاز به محاسبه متریک و ابعاد در گذشته داریم.

Backfilling آنقدر معمول است که Hive در عملکرد پارتیشن های پویا ساخته شده است ، ساختاری که همان عملیات SQL را بر روی بسیاری از پارتیشن ها انجام می دهد و چندین درج همزمان را انجام می دهد. برای نشان دادن چگونگی استفاده از پارتیشن های پویا ، می توانید یک کار را در نظر بگیرید که در آن باید تعداد رزروهای هر بازار برای داشبورد را دوباره پر کنیم ، از اولین مراحل ابتدایی تا آخرین_آخرها. ما ممکن است چنین کاری انجام دهیم:

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

ds اضافی را در بند SELECT و GROUP BY توجه کنید ، دامنه گسترش یافته در بند WHERE و نحوه تغییر نحو از PARTITION (ds = '{{ds}}') به PARTITION (ds). زیبایی پارتیشن های پویا این است که ما تمام کارهایی را که لازم است با یک GRUP BY ds انجام دهیم و نتایج را به یکباره در قسمت های مربوط به ds وارد می کنیم. این الگوی پرس و جو بسیار قدرتمند است و در بسیاری از خطوط لوله داده Airbnb مورد استفاده قرار می گیرد. در بخش بعد ، من نشان خواهم داد كه چگونه می توان یك كار Airflow نوشت كه منطق برگشت به کار را با استفاده از جریان كنترل Jinja وارد می كند.

آناتومی یک خط لوله جریان هوا

اکنون که درمورد مفهوم جداول حقایق ، جداول بعد ، تقسیم بندی تاریخ و اینکه منظور از انجام دوباره داده ها چیست ، یاد گرفته ایم ، بیایید این مفاهیم را تبلور دهیم و آنها را در یک کار واقعی Airflow ETL قرار دهیم.

تعریف نمودار مستقیم Acyclic (DAG)

همانطور که در پست قبلی ذکر کردیم ، هر کار ETL ، در هسته خود ، در بالای سه بلوک ساختمان ساخته شده است: Extract ، Transform و Load. همانطور که به نظر می رسد به نظر مفهومی ساده ، مشاغل ETL در زندگی واقعی اغلب پیچیده هستند و شامل بسیاری از ترکیبات E ، T و L می شوند. در نتیجه ، اغلب تجسم جریان داده های پیچیده با استفاده از یک نمودار مفید است. از نظر بصری ، یک گره در یک نمودار یک کار را نشان می دهد ، و یک فلش نشانگر وابستگی یک کار به دیگری است. با توجه به اینکه داده ها فقط باید یک بار در یک کار معین محاسبه شوند و محاسبات سپس به جلو انجام شوند ، نمودار مستقیم و غیرقانونی است. به همین دلیل است که معمولاً مشاغل جریان هوا به عنوان "DAG" (کارگردانی Acyclic Graphs) خوانده می شوند.

منبع: تصویری از چارچوب گزارش دهی به تجربیات Airbnb DAG

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

عملگرها: سنسورها ، اپراتورها و نقل و انتقالات

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

  • سنسورها: منتظر زمان مشخص ، پرونده خارجی یا منبع داده بالادست هستند
  • عملگرها: اقدام خاصی را انجام می دهد (مثلاً اجرای یک دستور bash ، اجرای یک عملکرد پایتون یا اجرای یک جستجوی کندو و غیره)
  • انتقال: داده ها را از یک مکان به مکان دیگر منتقل می کند

خوانندگان شرور احتمالاً می توانند ببینند كه چگونه هر یك از این عملگرها با مراحل Extract ، Transform و Load كه قبلاً در مورد آنها صحبت كردیم مطابقت دارد. سنسورها جریان داده را پس از گذشت زمان معین یا هنگامی که داده های منبع داده بالادست در دسترس هستند ، انسداد می دهند. در Airbnb ، با توجه به اینکه بیشتر مشاغل ETL ما شامل نمایش داده شدگان Hive است ، ما اغلب از NamedHivePartitionSensors برای بررسی اینکه آیا جدیدترین پارتیشن یک میز Hive برای پردازش پایین دست در دسترس است استفاده کردیم.

اپراتورها دگرگونی های داده را تحریک می کنند ، که مربوط به مرحله Transform است. از آنجا که Airflow منبع باز است ، مشارکت کنندگان می توانند کلاس BaseOperator را گسترش دهند تا اپراتورهای سفارشی را مطابق آنچه که مناسب می بینند ایجاد کنند. در Airbnb ، متداولترین عملگر مورد استفاده ما HiveOperator است (برای اجرای نمایش داده شدگان کندو) ، اما ما همچنین از PythonOperator (مثلاً برای اجرای یک اسکریپت پایتون) و BashOperator (مثلاً برای اجرای یک اسکریپت bash یا حتی یک کار جادوگر Spancy) استفاده می کنیم. . امکانات اینجا بی پایان است!

سرانجام ، ما همچنین اپراتورهای ویژه ای داریم که داده ها را از یک مکان به مکان دیگر منتقل می کنند ، که اغلب به مرحله بار در ETL نقشه برداری می کنند. در Airbnb ، تقریباً اغلب از MySqlToHiveTransfer یا S3ToHiveTransfer استفاده می کنیم ، اما این تا حد زیادی به زیرساخت داده های شخصی و محل نگهداری انبار داده بستگی دارد.

یک مثال ساده

در زیر یک مثال ساده وجود دارد که نشان می دهد چگونه می توان یک فایل تعریف DAG را تعریف کرد ، یک DAG Airflow را فوری کرد ، و ساختار DAG مربوطه را با استفاده از اپراتورهای مختلفی که در بالا توضیح دادیم تعریف کرد.

هنگامی که DAG ارائه می شود ، نمای نمودار زیر را مشاهده می کنیم:

نمودار نمایش نمونه اسباب بازی DAG

بهترین روش های ETL که باید دنبال کنید

اعتبار تصویر: ساختن کاردستی شما عملی است ، بنابراین پیروی از بهترین روشها عاقلانه است

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

  • جداول داده های پارتیشن: همانطور که قبلاً نیز اشاره کردیم ، تقسیم بندی داده ها می تواند در برخورد با جداول در اندازه های بزرگ با سابقه طولانی ، به ویژه مفید باشد. هنگامی که داده ها با استفاده از data data تقسیم می شوند ، می توانیم از پارتیشن های دینامیکی برای موازی کردن دوباره پردازش استفاده کنیم.
  • بارگیری داده ها به صورت افزایشی: این اصل ETL شما را به صورت مدولار و قابل کنترل تر می کند ، خصوصاً هنگام ساختن جداول ابعاد از جداول واقعیت. در هر اجرا ، فقط باید به جای اسکن کردن کل تاریخچه واقعی ، معاملات جدید را از پارتیشن تاریخ قبل اضافه کنیم.
  • Enforce Idempotency: بسیاری از دانشمندان داده ها برای انجام تحلیل های تاریخی به عکس های لحظه به لحظه اتکا می کنند. این بدان معنی است که جدول منبع زیربنایی نباید با پیشرفت زمان قابل تغییر باشد ، در غیر این صورت جواب متفاوتی می گیریم. خط لوله باید ساخته شود به طوری که همان پرس و جو ، هنگامی که در برابر همان منطق کسب و کار و محدوده زمانی اجرا می شود ، همان نتیجه را برمی گرداند. این ویژگی دارای نام فانتزی به نام Idempotency است.
  • پارامتر کردن گردش کار: دقیقاً مانند چگونگی ساده سازی قالب ها در صفحات HTML ، Jinja را می توان در رابطه با SQL استفاده کرد. همانطور که قبلاً نیز اشاره کردیم ، یکی از کاربردهای متداول از الگوی Jinja این است که منطق برگشت دوباره را در یک عبارت معمولی Hive وارد کنید. Stitch Fix یک مطلب بسیار زیبا دارد که خلاصه ای از نحوه استفاده آنها از این تکنیک برای ETL خود را نشان می دهد.
  • افزودن بررسی های اولیه و به موقع: هنگام پردازش داده ها ، نوشتن داده ها در جدول مرحله بندی ، بررسی کیفیت داده ها مفید است و تنها پس از آن جدول مرحله بندی با جدول تولید نهایی مبادله می شود. در Airbnb ، ما این را الگوی مرحله بررسی ارز می نامیم. بررسی در این الگوی 3 مرحله ای مکانیسم های دفاعی مهمی است - آنها می توانند چک ساده ای باشند مانند شمارش تعداد کل سوابق از 0 یا چیزی به اندازه یک سیستم تشخیص ناهنجاری که برای دسته های غیب یا موارد دور افتاده چک می کند.
  • ساخت هشدارهای مفید و سیستم مانیتورینگ: از آنجا که کارهای ETL اغلب می توانند مدت زمان طولانی را اجرا کنند ، افزودن هشدارها و نظارت بر آنها مفید است ، بنابراین لازم نیست دائماً مراقب پیشرفت DAG باشیم. شرکت های مختلف DAG ها را به روش های خلاقانه مانیتور می کنند - در Airbnb ، ما به طور مرتب از EmailOperators برای ارسال ایمیل های هشدار برای مشاغل مفقود SLA استفاده می کنیم. تیم های دیگر از هشدارها برای پرچم عدم تعادل آزمایش استفاده کرده اند. نمونه جالب دیگر از Zymergen است که در آن آنها معیارهای عملکرد مدل مانند R-مربع با SlackOperator را گزارش می دهند.

بسیاری از این اصول با ترکیبی از مکالمات با مهندسین داده های فصلی ، تجربه شخصی من در ساخت DAG های Airflow و خوانش هایی از بهترین روش های ETL با جرارد توونسترا با جریان هوا الهام گرفته شده است. برای خوانندگان کنجکاو ، این صحبت زیر را از Maxime اکیداً توصیه می کنم:

جمع بخش دوم

در پست دوم این مجموعه ، ما در جزئیات بیشتر درباره طرحواره ستاره ای و مدل سازی داده ها بحث کردیم. ما تمایز بین جداول واقعیت و ابعاد را یاد گرفتیم و مزایای استفاده از datestamps را به عنوان کلیدهای پارتیشن ، خصوصاً برای backfilling مشاهده کردیم. علاوه بر این ، ما آناتومی یک کار Airflow را جدا کردیم و اپراتورهای مختلف موجود در جریان هوا را تبلور دادیم. ما همچنین بهترین راهکارها برای ساخت ETL را برجسته کردیم و نشان دادیم که در صورت استفاده در رابطه با Jinja و SlackOperators ، چه کارهایی با جریان هوا قابل انعطاف است. امکانات بی پایان است!

در آخرین پست این سریال ، من در مورد چند الگوی پیشرفته مهندسی داده بحث خواهم کرد - به طور خاص ، نحوه رفتن از خطوط لوله سازی ساختمان به چارچوب های ساختمانی. من دوباره از چند چارچوب نمونه ای که در Airbnb استفاده کرده ایم به عنوان نمونه های انگیزشی استفاده می کنم.

اگر این پست را مفید یافتید ، لطفاً به قسمت اول مراجعه کرده و برای قسمت سوم با ما در ارتباط باشید.

می خواهم از جیسون گودمن و مایکل موسون به خاطر ارائه بازخورد ارزنده به من قدردانی کنم