لینک کوتاه مطلب : https://hsgar.com/?p=6886

مشکل جریان هوا – نوشته استفان بیلی

من یک پست کامل وبلاگ نوشتم سعی کردم آن را مشخص کنم چرا من جریان هوا را دوست ندارم. اما علی‌رغم توجیه‌های من، مثل یک نامه جدایی منتشر شد – خیلی شخصی:

جریان هوای عزیز،

من سعی کردم کار را انجام دهم، واقعاً انجام دادم. اما تو خیلی پیر شدی، انتزاعاتت درهم و برهم هستند، و به نظر من زشتی. بین ما تمام شد

خالصانه،

استفان

که خوب بود، با این تفاوت که می دانستم Airflow دقیقا چگونه پاسخ می دهد:

استیو – متاسفم که اینقدر طول کشید تا به شما برگردم، تقریباً 10000 بار در روز نصب می شود. مشکلی نیست: احساسات، LMK اگر نظر خود را تغییر دهید. -آ

واقعیت این است که Airflow یک دستاورد است: یک پروژه منبع باز که به میزان ناراحت کننده ای در روان داده ها نفوذ کرده است. آنچه را که می گوید انجام می دهد، که بیش از آن چیزی است که اکثر ابزارها می توانند ادعا کنند. تیم ها از آن در مقیاس استفاده می کنند و در سال 2022. یعنی وجود دارد this >> [offensive, obscene] >> python >> syntax … اما هر پروژه ای باید خوش شانس باشد که اینقدر دوست نداشتن، خسته کننده و اجتناب ناپذیر باشد.

بنابراین چرا نمی توانم آن را معده کنم؟

بعد متوجه شدم: مشکل من با جریان هوا نیست. مشکل از جریان هواست.

در اینجا یکی از اولین جملات در فایل README Airflow آمده است:

جریان هوا با جریان های کاری که عمدتا ثابت هستند و به آرامی در حال تغییر هستند، بهترین کار را دارد.

این یک طراحی عالی در سال 2015 بود، زمانی که Airflow منبع باز بود. این است هنوز برای اکثر تیم‌ها در سال 2022 به اندازه کافی خوب است – DAGهای آهسته، درشت و متمرکز، بیشتر ارزش داده‌های موجود را بیان می‌کنند، حتی اگر در سایر ابزارهای SaaS جدا شده باشند.

با این حال، دیدگاه من این است آینده ارزش از توانمندسازی تیم‌ها برای ایجاد جریان‌های کاری داده‌ای سریع‌تر، ساده‌تر و غیرمتمرکزتر ناشی می‌شود.

در واقع، در سالی که Airflow منبع باز شد، جف مگنوسون از StitchFix نوشت: «مهندسین داده نباید ETL بنویسند». و خواستار خروج رادیکال از مالکیت متمرکز خطوط لوله داده شد:[Our engineers] سازمان را برای بهره وری بهینه نمی کنیم، ما برای استقلال بهینه می کنیم.

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

با این حال Airflow هرگز به عنوان یک پلت فرم ناهمگن در نظر گرفته شده برای DAG های غیرمتمرکز در نظر گرفته نشده است. این یک موتور برنامه‌ریزی و پردازش کار است: حجم کاری یک تیم را در نظر بگیرید و آن را بر اساس یک برنامه، شبیه به سیستم مترو، هماهنگ کنید.

کار مهندسان داده امروزی بیشتر به مدیریت کل شبکه حمل و نقل شباهت دارد – مطمئناً مترو، اما همچنین خیابان ها، اتوبوس ها، خطوط دوچرخه. وقتی تیم رشد – آن احمق ها – 1000 اسکوتر را یک شبه در خیابان ها رها می کنند، مهندسان داده باید اطمینان حاصل کنند که آنها باعث تصادف یا کشته شدن افراد نمی شوند. که کار جدید است

در تصویر نیست: سیاست های IAM

چیزی که گیج کننده است این است که این تغییر در شرکت ها ظریف و ناسازگار بوده است. مسئولیت ها شبیه کسانی که در دنیای قدیم هستند، در حالی که نیاز به طرز فکرهای کاملاً متفاوتی دارند. در زیر سه نمونه برجسته از این تغییر وجود دارد.

Shift 1: “ما می دانیم اصل و نسب” به “ما می دانیم که به نام خدا چه اتفاقی می افتد”

در دنیای قدیم، اگر اصل و نسب داده را می فهمیدید، درک بسیار خوبی از پلت فرم داده خود داشتید. نشان دادن اینکه «اقدام تجاری A از داشبورد B می‌آید از نمای C آمده است از جدول D از CRM API E می‌آید» کار ساده‌ای نبود، اما به شما این امکان را می‌داد که نقاط شکسته را در نمودار شناسایی کنید و قبل از اجرای بعدی روزانه به آنها رسیدگی کنید. کار دسته ای

امروزه تیم های پلت فرم روبه رو هستند همبستگی مشکلات نیز:

از ساعت 10:00 صبح تا 10:30 صبح، AWS us-east-1 قطع شد. Snowflake در طول این مدت غیرقابل دسترسی بود و روی تکرار داده‌ها، قابلیت مشاهده، تبدیل، ETL معکوس و ابزار داشبورد تأثیر گذاشت. چگونه فرآیندهای لازم را شناسایی و مجدداً راه اندازی می کنید؟

درک تأثیر دارایی های داده جدید، دارایی های داده بد، قطع سیستم در مجموعه گسترده ای از فرآیندها دشوار است و شبیه کار مهندسان قابلیت اطمینان سایت است. و با اضافه کردن کاربران، ابزارها و موارد استفاده بیشتر به پلتفرم، درد شدیدتر می شود – به عبارت دیگر، با ارزش افزایش می یابد.

Shift 2: “ما تحلیلگران را رفع انسداد می کنیم” به “ما همه را فعال می کنیم”

داده ها راهی پیدا می کنند، صرف نظر از بهترین نیت ما داده ها به خوبی در Snowflake جمع شده اند اراده البته در ابزارهای BI نشان داده می‌شود – اما همچنین ایمیل‌ها، Slack، CRMها، برنامه‌های Retool، مدل‌های ML، محصولات رو به رو با مشتری، ابزارهای تجزیه و تحلیل محصول، و هر چیزی که «برنامه‌های داده بومی» هستند.

این یک ویژگی، نه یک اشکال، داده است. و این وظیفه مهندسان داده است که روش پایدار استفاده از داده ها و ساده ترین روش استفاده از داده ها را یکسان و یکسان کنند. این چیزی است که dbt با «ایجاد جداول» کار کرده است و به تأثیر آن نگاه کنید: پروژه‌های dbt به چاه‌های گرانشی معنایی تبدیل می‌شوند و جداول جدید را برای انواع موارد استفاده جمع می‌کنند. جایی که نوپول ها و نخبگان دست و پا می زنند – بی شباهت به برخی از شهرهای بزرگ جهان، به هرج و مرج محدودی تبدیل می شود.

Shift 3: “ما DAG های خود را اشکال زدایی می کنیم” به “ما داده های خود را اشکال زدایی می کنیم”

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

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

پس مشکل من با جریان هوا چیست؟ مشکل من این است که Airflow برای رسیدگی به این مشکلات طراحی نشده است – آن جاه طلبی مورد نیاز ما را ندارد، حتی در حالی که پایه حیاتی را به عنوان موتور اجرایی اصلی اشغال می کند. ما به جریان هوای بهتر نیاز نداریم، اما به یک جریان سطح بالاتر نیاز داریم: سیستمی که به تیم‌های پلتفرم داده امکان می‌دهد تا فکر در سطح پلت فرم

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

اخترشناس خود را به عنوان «سرویس جریان هوا با مدیریت کامل آپاچی» معرفی می کند. اما اینطور نیست. ستاره شناس برای جریان هوا مانند Snowflake برای پایگاه داده است. این یک سیستم مدیریتی است و به ما نشان می دهد که آینده مهندسی داده واقعاً چگونه به نظر می رسد:

  • یک “هواپیما کنترل” سطح بالا که به شما امکان می دهد یک استقرار جریان هوا را در محیط Kubernetes خود بچرخانید.

  • هر استقرار Airflow دارای معیارهای سلامتی است که از طریق داشبورد Grafana و Prometheus قابل مشاهده است

  • ستاره شناس در سطح سازمان با سیستم های مدیریت هویت یکپارچه می شود

  • صفحه کنترل می تواند ابرداده را از سراسر فضاهای کاری از طریق a وارد کند سرویس جداگانه

  • ابزارهای کارآمدی توسعه‌دهنده، مانند اقدامات Github یکپارچه، مدیریت اسرار، و گردش‌های کاری تبلیغاتی ساده توسعه‌دهنده/مرحله‌ای/پروژه

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

dbt ارزش داشتن یک لایه انتزاعی معنایی در بالای پلتفرم های داده مدرن را ثابت کرده است. اما کافی نیست. حوزه‌ای از پشته وجود دارد که هنوز به آن پرداخته نشده است – یکی که نیاز به دانش Terraform، AWS، Kubernetes، CI/CD، شبکه و اصول امنیتی دارد – که همچنین باید ساده‌سازی شود و با نیازهای تیم‌های داده تطبیق داده شود. ابزار مهندسان داده برای موثر بودن در این دنیای جدید اسکریپت ها را اجرا نمی کند، بلکه سیستم ها را سازماندهی می کند.

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

لینک منبع

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.