‏چطور متا سیستم جذب داده‌های اجتماعی‌اش رو در مقیاس عظیم مهاجرت داد

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

معماری قدیمی بر اساس پایپلاین‌های جداگانه‌ای بود که هر تیم خودش مدیریتشون می‌کرد. این روش در مقیاس کوچک خوب کار می‌کرد، ولی با بزرگ‌تر شدن عملیات، ناپایداری‌هایی پیدا کرد و دیگه جواب نمی‌داد. معماری جدید یه سرویس مرکزی self-managed هست که تیم‌ها نیازی به مدیریتش ندارن و در عین حال در hyperscale هم پایدار می‌مونه.

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

در فاز Reverse Shadow، نقش‌ها عوض می‌شدن: جاب جدید به جدول اصلی production می‌نوشت و جاب قدیمی به جدول shadow. این کار دو مزیت داشت — هم سیگنال‌های کیفیت داده ادامه پیدا می‌کردن، هم در صورت بروز مشکل می‌شد سریع rollback کرد بدون اینکه نیازی به بازسازی جاب قدیمی باشه. اگه در فاز سوم (Migration Cleanup) هم اختلافی دیده نمی‌شد، جاب قدیمی حذف می‌شد.

برای تشخیص سریع‌تر مشکلات، یه ابزار تحلیل کیفیت داده هم ساخته شد که هر ساعت لاگ‌های سیستم رو از Scuba (سیستم آنالیز real-time متا) می‌خوند، ردیف‌های مشکل‌دار رو پیدا می‌کرد و اطلاعات debug رو برای تیم ثبت می‌کرد. جالبه که این ابزار بعد از مهاجرت هم به‌عنوان بخشی از فرآیند release validation همچنان استفاده می‌شه.

هر دو سیستم قدیمی و جدید از تکنیک CDC (تغییر داده‌ها رو capture می‌کنه — Change Data Capture) برای انتقال افزایشی داده استفاده می‌کنن. این رویکرد به تیم اجازه داد rollout رو به‌صورت کنترل‌شده پیش ببره و در صورت لزوم به‌سرعت به سیستم قبلی برگرده.

نکات کلیدی:

• سیستم روزانه چند پتابایت داده از MySQL به انبار داده منتقل می‌کنه
• مهاجرت از پایپلاین‌های team-owned به یه سرویس مرکزی self-managed انجام شد
• سه فاز Shadow، Reverse Shadow، و Cleanup صحت داده رو در طول مهاجرت تضمین می‌کردن
• مقایسه‌ی row count و checksum در هر مرحله اجباری بود
• ابزار تحلیل کیفیت داده همچنان بعد از مهاجرت هم فعاله
• صد درصد جاب‌ها مهاجرت کردن و سیستم قدیمی کاملاً deprecated شد