چگونه از AWS Glue به Snowflake dbt مهاجرت کردیم

امروز در مورد مهاجرت ETL خود از چسب AWS به شما خواهم گفت دانه برف و dbt پشته داده های مدرن ماموریت تیم من متمرکز کردن و اطمینان از قابلیت اطمینان داده ها از چندین حوزه تجاری است. ما یک پایه تحلیلی برای حمایت از تصمیم گیری تیم های محصول و استراتژی ایجاد می کنیم. به عنوان بخشی از این تلاش، ما ۲۸ مدل طلا را انتقال دادیم که ۱۳ محصول داده، از جمله داشبورد، ابزارهای پروفایل، و مطالعات تحلیلی را تامین می‌کنند. این مدل ها به عنوان سنگ بنای فعال کردن بینش های مبتنی بر داده عمل می کنند.

وضعیت اولیه: محیط کاری خراب

1. فقدان اسناد و مدارک و مدیریت، ثبت و ردیابی خطاها را دشوار می کرد. علاوه بر این، محیط توسعه مناسبی وجود نداشت: هر تغییری خطری برای تولید بود و منجر به استرس دائمی برای توسعه دهندگان می شد.
2. تبدیل داده ها بر روی انجام شد چسب AWS با Spark SQLکارهای پیچیده ای که برای راه اندازی به محیطی زمان بر نیاز دارند. این امر آزمایش کیفیت داده ها را در طول توسعه غیرممکن کرد.
3. همه کاربران بدون توجه به نقش آنها در سازمان، سطح دسترسی یکسانی به داده ها داشتند. این عدم کنترل دسترسی باعث شد مجوزهای مدیریت نامشخص باشد. اطمینان از امنیت اطلاعات کافی غیرممکن بود.

مهاجرت خوش آمدید

ما ترکیبی از داده ها را انتخاب کردیم dbt و دانه برف این راه حل محیط های سفارشی، تست کیفیت داده ها و مستندات یکپارچه را از طریق dbt به عنوان کد فراهم می کند. همچنین مدیریت داده ها را بهبود می بخشد. dbt چارچوبی برای تبدیل داده ها، کیفیت و مستندات است و Snowflake یک انبار داده مبتنی بر ابر است.

تاثیر بر کار روزانه مهندسان داده

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

تصمیم قبلی

هر تبدیل در یک مخزن Git ذخیره می شود و در AWS به عنوان کارهای چسب تکرار می شود. این کارهای پایتون از محیط Spark استفاده می‌کردند و در گردش‌های کاری AWS سازماندهی شدند. تمام داده های موجود در معماری مدالیون در کاتالوگ داده AWS Glue ذخیره شد.

برای آزمایش هر تبدیل، اسکریپت‌ها را مستقیماً بدون CI/CD اجرا کردم. هر توسعه دهنده باید نوت بوک Jupyter و هسته Glue PySpark را نصب می کرد، که حدود ۴۰ ثانیه طول کشید تا مقداردهی اولیه شود. این فرآیند تنها راه ما برای تکرار سریع و تأیید کامل بودن و دقت تبدیل داده ها بود. فقدان CI/CD مانع از پیدا کردن اشکالات قبل از استقرار تولید شد 😈

راه حل جدید

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

سرانجام، Snowflake کنترل منابع دقیق تری را از طریق خود به ما ارائه داد صورتحساب و مدیریت هزینه ابزاری که امکان بهینه سازی مصرف و هزینه ها را فراهم می کند. در مقایسه با چسب AWSکه می تواند منجر به هزینه های بالا به دلیل مقیاس خودکار شود، انتظار داریم هزینه های زیرساختی خود را کاهش دهیم.

آماده سازی: نقشه برداری و برنامه ریزی مهاجرت

مهاجرت ما با راه اندازی محیط های Snowflake و دسترسی شروع شد. ما مخزن dbt را ساختیم و دسترسی کاربران Snowflake را بر اساس نقش آنها اختصاص دادیم.

مهاجرت ایزوکارکردی محصولات داده

آیا همه آن را خراب کنم و دوباره بسازم؟ 🧐 چگونه مطمئن شویم که یک مدل داده واحد را فراموش نکرده ایم؟ 😱 چگونه می توانیم به جاستین اطمینان دهیم که داشبورد او هنوز قابل اعتماد است؟ چگونه به توماس توضیح دهیم که متریک کلیدی او اکنون در ۵ ضرب شده است؟

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

استراتژی ما:

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

برای مهاجرت هر شی، باید رفتار موجود را ضبط می‌کردیم و معادل مدل تکرار شده را با استفاده از استراتژی بازآفرینی Master Golden تأیید می‌کردیم. ما تحولات را با استفاده از مدل‌سازی داده‌ها مدولار کردیم: یک منبع عالی از مستندات که به ما در درک چالش‌های کار تحلیلی کمک کرد و به ما امکان داد کارها را سریع و کارآمد انجام دهیم.

ما با استفاده از اسکریپت های پایتون رونویسی کردیم Spark SQL ج Snowflake SQL مدل ها در dbt برای هر مدل، از یک اسکریپت 🏠 داخلی برای نظارت بر مهاجرت استفاده کردیم. این اسکریپت به ما این امکان را می دهد که داده های منتقل شده را با داده های منبع مقایسه کنیم. اسکریپت زیر به محیط های AWS و Snowflake متصل می شود و فریم ها را با داده ها مقایسه می کند!

در چالش ها و راه حل های dbt عمیقاً غوطه ور شوید

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

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

به عنوان مثال، برای KPIهای جمع آوری شده هفتگی یا ماهانه، جداول تقویم ایجاد کردیم. این جداول موقت نیاز به بازنگری کامل داشتند، اما ویژگی‌های پیشرفته SQL Snowflake، مانند جستارهای بازگشتی، کار را بسیار آسان‌تر کرد.

نکات جدول تقویم بازگشتی با دانه برف SQL

جداسازی محیط های DEV و PROD

با توجه به عدم وجود محیط های جداگانه در معماری قدیمی، ما مجبور بودیم محیط های جداگانه ای برای توسعه و تولید ایجاد کنیم تا اطمینان حاصل کنیم که ویژگی های جدید بر راه حل تولید تأثیر نمی گذارد. برای رسیدن به این هدف، معماری Snowflake را از روی آن طراحی کردیم جداسازی محیط ها و اصلاح اشیاء آسیب دیدهمانند طرحواره ها، پایگاه های داده و انبارها. ما پایگاه‌های داده‌ای را برای هر وضعیت معماری مدالیون و هر محیط ایجاد کرده‌ایم: Silver، Silver DEV، Gold، Gold DEV.

با dbt ما اهداف را در آن تعریف کردیم profiles.yml فایل پیکربندی که اجازه می دهد تغییرات در محیط توسعه بدون تأثیر بر تولید یکپارچه شوند. CI/CD محیط تولید را با هدایت صریح رفتار برای PROD مدیریت می کند – ادغام.

برای خودکارسازی بیشتر اعتبارسنجی تأثیرات بر روی مدل‌های داده، ما معرفی کردیم create_volumetric_report کلان. این ماکرو یک گزارش جامع از معیارهای داده های کلیدی، شامل تعداد ردیف ها، مقادیر متمایز و درصد صفر، برای هر ستون در مدل تولید می کند. این به ما امکان می‌دهد تا تغییراتی را که می‌تواند بر کیفیت داده‌ها در همه محیط‌ها تأثیر بگذارد، به‌طور خودکار بررسی کنیم.

تست های کیفیت و مستندات

مهاجرت، آزمایش، مستندسازی: خیلی زیاد به نظر می رسید، اما ما آن را انجام دادیم!

ما با راه حلی شروع کردیم که هیچ آزمایشی نداشت و نیاز به شناسایی و ردیابی ناهنجاری ها داشت. اسناد dbt در فایل های پیکربندی yaml به کشف خطاهای دیده نشده قبلی کمک کرد. کیفیت داده ها را تا حد زیادی بهبود بخشید و اسناد را فعال کرد!

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

تست کیفیت داده ها و مستندسازی
هر مدل داده استفاده شده با یک فایل پیکربندی آزمایشی، مدیریت برچسب PII (اطلاعات قابل شناسایی شخصی) و اسنادی مانند این مرتبط است.

Dbt به ما اجازه می دهد تا با اجرای این تست ها برای هر تکامل پایگاه کد، کیفیت داده ها را کنترل کنیم. دستور اجرای منحصر به فرد است dbt test. تست های ناموفق ارزیابی، حل و فصل یا اولویت بندی می شوند تا از حفظ کیفیت داده ها اطمینان حاصل شود.

تست های واحد
Dbt تست‌های واحد امکان تست رفتار اسکریپت‌های SQL را به‌صورت مجزا با تمسخر داده‌های ورودی و خروجی و شبیه‌سازی رفتار اسکریپت می‌دهند.

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

تمام تست های سفارشی در فایل پیکربندی مدل فراخوانی می شوند. آزمون ingredient_is_valid_for_month بر روی یک مدل و ستون آن در فایل پیکربندی مدل yaml فراخوانی می شود. دنبال کردن مدل پیکربندی dim_actors تصویرسازی برای بررسی عمیق‌تر نظارت بر تست dbt با Elementary، این مقاله را توصیه می‌کنم: بررسی کیفیت داده‌ها را با dbt و Elementary Integration Explored افزایش دهید.

پلت فرم داده تغییر یافته ما

با Snowflake و dbt، نتایج فراتر از انتظارات ما بود. اکنون می توانیم یک مدل را به جای ۵ دقیقه و بدون تأثیر بر PROD در ۱۵ ثانیه توسعه و آزمایش کنیم! با ۴۷۵ تست کیفیت داده، شناسایی خطای داده را پنج برابر افزایش دادیم! 🍾

دگرگونی‌ها به روشی مدولار و قابل استفاده مجدد در dbt تنظیم می‌شوند و به توسعه‌دهندگان اجازه می‌دهند اسناد دقیق و درک روشنی از هر مدل داده داشته باشند. 🎉 اکنون می دانیم که چه کاری باید انجام دهیم: اولویت بندی، ثبت نام و رفع اشکالات.

آنچه از این مهاجرت آموختیم

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

و اگر مجبور بودیم دوباره این کار را انجام دهیم؟ در آینده، مدیریت نقش را با ایجاد یک نقش دانای کل برای توسعه دهندگان تقویت کرده و به هر توسعه دهنده پایگاه داده Snowflake اختصاص می دهیم. 😱

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

آیا می خواهید بیشتر بیاموزید یا از تجربه ما برای پروژه های مهاجرت خود بهره مند شوید؟ امروز با ما تماس بگیرید!