| 👀 خبر در یک نگاه:
پینترست پلتفرم داده‌ای خود را از هدوپ به سیستم Moka مبتنی بر کوبرنتیز روی AWS EKS منتقل کرد. این تغییر با بهبود ایزوله‌سازی، پشتیبانی از ARM و زمان‌بندی پیشرفته، هزینه‌های زیرساخت را کاهش و کارایی اجرای وظایف داده‌ای را بهبود بخشید. |
پینترست به‌تازگی پلتفرم داده‌محور مبتنی بر هدوپ خود را با «Moka» جایگزین کرده است. Moka یک سیستم بومی کوبرنتیز است که اسپارک را روی AWS EKS اجرا می‌کند. همچنین امکان ایزوله‌سازی وظایف در کانتینرها را فراهم می‌کند، از ماشین‌های مبتنی بر ARM پشتیبانی می‌کند، زمان‌بندی را بهبود می‌دهد و فرایند استقرار را ساده می‌سازد. این تغییر باعث کاهش هزینه زیرساخت و افزایش بهره‌وری در وظایف مربوط به پردازش داده شده است.
مهاجرت زیرساختی پینترست
پینترست تصمیمی استراتژیک گرفت تا از معماری قدیمی مبتنی بر هدوپ به مدل اسپارک روی کوبرنتیز مهاجرت کند تا با زیرساخت‌های مدرن هم‌راستا شود. این شرکت کوبرنتیز را به‌دلیل پشتیبانی بومی از مدیریت هماهنگ کانتینرها، قابلیت‌های امنیتی و همچنین انعطاف‌پذیری در استقرار روی انواع مختلف ماشین‌ها مانند ARM و x86 انتخاب کرد.
مهندسان پینترست اعلام کردند:
«با در نظر گرفتن این نیازها، در سال ۲۰۲۲ ارزیابی جامعی برای اجرای اسپارک روی پلتفرم‌های مختلف انجام دادیم. در نهایت به سمت فریم‌ورک‌هایی متمایل شدیم که بر پایه کوبرنتیز طراحی شده بودند، به‌دلیل مزایایی که ارائه می‌دادند: ایزوله‌سازی و امنیت مبتنی بر کانتینر به‌عنوان قابلیت‌های پایه پلتفرم، سهولت در استقرار، وجود فریم‌ورک‌های داخلی و گزینه‌های تنظیم عملکرد.»
چرا Moka؟
Moka بهبودهای مهمی در هزینه و بهره‌وری نسبت به پلتفرم قدیمی به همراه داشت. با استفاده از ایزوله‌سازی مبتنی بر کانتینر، پینترست توانست وظایف با نیازهای امنیتی متفاوت را روی کلاسترهای مشترک اجرا کند و در نتیجه، نیاز به چندین کلاستر مجزا را کاهش دهد.
مهندسان پینترست همچنین اضافه کردند:
«سیستم مبتنی بر کانتینر ایزوله‌سازی بیشتری فراهم کرد. این باعث شد محیط‌های اختصاصی هدوپ که کم‌استفاده بودند، حذف شوند. حالا می‌توان وظایف با نیازهای امنیتی مختلف را روی یک کلاستر مشترک Moka اجرا کرد.»
پشتیبانی این پلتفرم از ماشین‌های مبتنی بر ARM و قابلیت افزایش مقیاس کلاسترها در ساعات کم‌ترافیک باعث صرفه‌جویی در هزینه‌های زیرساخت شده است.
قابلیت‌های جدید توسعه‌داده‌شده در پینترست
جایگزینی هدوپ نیازمند بازطراحی چندین مولفه حیاتی مرتبط با ارسال وظایف، زمان‌بندی، ذخیره‌سازی و قابلیت مشاهده بود. طبق گفته مهندسان:
«در طول سال‌ها، هدوپ و Monarch (پلتفرم هدوپ پینترست) حجم عظیمی از قابلیت‌ها را در خود جای داده بودند. ساخت یک جایگزین به‌معنای توسعه نسخه‌های جدید از این قابلیت‌هاست…»
از سرویس‌های جدیدی که پینترست در این پروسه توسعه داد، می‌توان به این موارد اشاره کرد:
- Archer برای ارسال وظایف
- Apache YuniKorn برای زمان‌بندی صف‌محور
- مهاجرت ذخیره‌سازی از HDFS به S3
- یکپارچه‌سازی سرویس Apache Celeborn برای مدیریت انتقال داده‌ها (Shuffle) از راه دور، به‌منظور حفظ عملکرد در مقیاس بالا.
Archer
در طراحی اولیه Moka، سیستم هماهنگ‌سازی Pinterest به‌نام Spinner (بر پایه Airflow) جریان‌های کاری زمان‌بندی‌شده را به وظایف جداگانه تقسیم کرده و آن‌ها را به Archer ارسال می‌کند. Archer هر وظیفه (Job) را به یک منبع سفارشی (Custom Resource) کوبرنتیز تبدیل کرده و به یک کلاستر EKS که از اسپارک پشتیبانی می‌کند، ارسال می‌کند. Archer مسئول صف‌بندی وظایف، پیگیری وضعیت آن‌ها و یکپارچگی با API کوبرنتیز است. این قابلیت‌ها باعث استقرار قابل‌اعتماد و مسیردهی بهینه منابع در کلاسترها می‌شود، در حالی که همچنان با ورک‌فلوهای فعلی سازگار باقی می‌ماند.
Apache YuniKorn
مهندسان پینترست تصمیم گرفتند برای اجرای بومی اسپارک روی کوبرنتیز از Spark Operator و برای زمان‌بندی دسته‌ای از Apache YuniKorn استفاده کنند. اپراتور اسپارک اجازه می‌دهد اپلیکیشن‌های اسپارک را به‌صورت اعلانی و از طریق یک منبع سفارشی به نام SparkApplication تعریف کنید و مدیریت ارسال وظایف را خودش بر عهده می‌گیرد. در داخل سیستم، Spark Operator همچنان از دستور اصلی spark-submit برای اجرای وظایف استفاده می‌کند.
قابلیت‌های یونی‌کورن به پینترست کمک می‌کنند تا منابع را بین تیم‌ها ایزوله کرده و وظایف را بر اساس میزان بار کاری و اولویت‌های تجاری اولویت‌بندی کند.
مهاجرت ذخیره‌سازی از HDFS به S3
پس از زمان‌بندی وظایف توسط یونی‌کورن، وظایف SparkSQL به Hive Metastore متصل می‌شوند و بار کاری با استفاده از ایمیج‌های کانتینر از AWS ECR اجرا می‌شود. در حین اجرا، Archer وضعیت کارها را پیگیری می‌کند و سیستم لاگ‌ها را به S3 و متریک‌ها را به داشبوردهای داخلی آپلود می‌کند.
Spark History Server
کاربران می‌توانند به رابط کاربری وظایف در حال اجرا از طریق پراکسی شبکه دسترسی داشته باشند و لاگ‌های تاریخی را از طریق Spark History Server بازیابی کنند. همه این موارد از طریق رابط کاربری Read-only Moka نمایش داده می‌شود.
منبع: infoq.com
دیدگاهتان را بنویسید