DI

دوستان عزیز

سلام

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

مهمترین دغدغه‌ی در طراحی کلاستر جدید، دستیابی به مقیاس پذیری خطی بود تا با افزودن منابع محاسباتی و ذخیره‌سازی بتوان بدون محدود ظرفیت کلاستر را توسعه داد. برای رسیدن به این هدف و عملکرد بهتر سیستم ملزم به بازنویسی بخش بسیار زیادی از کد‌های قدیمی شدیم. در این فرآیند تعداد پروژه‌های تیم DI از ۲ به ۱۴ رسید و تمامی کدها به جز Queryی ریپورت‌ها از ابتدا توسعه یافت. ماحصل این بازنویسی‌ها و طراحی مجدد، دستیابی به کارایی چند برابری، High Availability و یکپارچگی تمام داده‌هاست. 

ویژگی‌ها

استریم / کافکا

• با راه‌اندازی سرویس پردازش استریم تپسی (Kafka + Combine) امکان ذخیره‌سازی انواع‌داده با نرخ تولید بسیار بالا فراهم شد. این ویژگی به حذف دیتابیس‌های لاگ (مانند Location) و ذخیره‌سازی فشرده‌تر اطلاعات کمک کرده‌است. به طور مثال از تاریخ -۲۵ اردیبهشت- شروع استریم Driver Locations تا به‌حال بیش از ۲۳ میلیارد رکورد در کلاستر ذخیره‌ شده‌است. فشرده‌سازی این اطلاعات امکان ذخیره این حجم از داده‌ در ۶۴۰GB بدون افزونگی و ۱.۶TB با در نظر گرفتن افزونگی را فراهم کرده است.
• Schema Inference: قابلیت استنتاج خودکار مدل داده بر اساس اولین Batch از داده‌های دریافتی و Versioning داده‌ها، باعث حذف پیچیدگی‌‌های حاصل از دریافت داده با مدل جدید شده‌است.

سینک

• بازنویسی کامل ماژول سینک به‌گونه‌ای که برخلاف ورژن قبلی آن، دارای قابلیت مقایس‌پذیری و اجرای همزمان بر روی تمام نودهای کلاستر است. نتیجه این بازنویسی به افزایش چشم‌گیر کارایی فرآیند سینک انجامید. 

ریپورت و Mid Table

• بازنویسی این ماژول نیز همانند ماژول سینک امکان مقایس‌پذیری و اجرای همزمان روی چندین نود را فراهم آورده است. 
• افزایش کارایی، مدت زمان ارسال ریپورت‌ها را به‌شدت کاهش داده‌است. به صورتی که در شب گذشته اولین ریپورت ساعت ۱۲:۰۵ بامداد و آخرین ریپورت ساعت ۰۱:۵۴ ارسال گردید. نکته قابل توجه این است که فرآیند ریپورت وابسته به سینک بوده و فرآیند سینک راس ساعت ۱۲:۰۱ بامداد آغاز می‌گردد.
• قابلیت تعیین اولویت محاسبه و ارسال ریپورت‌ها توسعه یافت.
• قابلیت دسترسی به ریپورت‌ها و Mid Table ها روی Zeppelin، Metabase و Tableau که چگونگی استفاده از این قابلیت در هر ایمیل ریپورت به‌صورت جداگانه توصیف شده‌است. 

زپلین

• افزایش قابل توجه کارایی کوئری‌ها و کد‌های اجرایی
• کاهش هزینه‌ی IO به دلیل فشرده‌سازی داده‌های ذخیره‌شده
• ساده‌سازی Interface استفاده از سرویس tap30
• امکان ذخیره‌سازی نتایج، دانلود و استفاده از آن‌ها در کوئری‌های بعدی تا سه روز. (اطلاعات ذخیره شده را می‌توان دانلود کرد یا به‌صورت DataFrame برای اجرای کوئری یا کد اسپارک استفاده نمود. به عبارت دیگر هر کاربر می‌تواند به‌راحتی MidTable های Short Term بسازد.)
• 
  
• امکان Visualization نتایج استخراج شده در زپلین
• امکان Commit کردن Noteها در ساختاری Git-Like. (در صورت کامیت کردن Note ها می‌توان از ذخیره آن‌ها روی سرور git شرکت اطمینان حاصل کرد)

یکپارچگی / Data Integration

• یکی از اهداف بازطراحی سیستم، دستیابی به یکپارچگی میان انواع داده‌های ذخیره شده و Interface یکسان برای اجرای کد یا کوئری بود. در طراحی جدید همه اطلاعات در یک قالب واحد ذخیره می‌شوند و می‌توان انواع مختلف داده را JOIN زد. به ‌طور مثال می‌توان میان RidePreview دریافتی از کافکا، User از Postgres و Tickets از ریپورت با Interface یکسان SQL یا نوشتن کد اسپارک، JOIN زد و اطلاعات بیشتری را دریافت نمود. با استفاده از Thrift SQL Interface قابلیت اتصال Tableau و Metabase یا اجرای کوئری از سمت Backend روی این داده‌ها وجود دارد.
• ریپورت‌های ارسال شده نیز به‌صورت Timeseries در ساختار اشاره شده قابل دسترسی هستند و می‌توان اطلاعات استخراج شده برای ریپورت‌ها را نیز در تمامی ابزارهای تحلیلی که از SQL پشتیبانی می‌کنند، استفاده کرد.
• داده‌های دریافتی از دیتابیس‌های Mongo دیتامدل خود را حفظ کرده و به همان شکل ولی با SQL قابل کوئری زدن هستند. (در نسخه قبل داده‌های سلسله‌مراتبی برای خطی شدن به‌صورت String در می‌آمدند)
• 
  

قابلیت تحمل خطا / HA

• در حال حاضر کلاستر جدید DI تحمل از دست دادن یک ماشین بدون از دست‌دادن هر‌گونه داده‌ای را دارد، حتی داده‌هایی که به‌صورت استریم روی کافکا درحال دریافت است. 
• با از دست‌دادن یکی از ماشین‌های Worker همچنان قابلیت اجرای کوئری و پاسخگویی به کوئری‌ها وجود دارد.
• در صورت از دسترس خارج شدن یا خرابی ماشین Master در کلاستر، هیچ داده‌ای از دست نمی‌رود، ولی در بازه‌‌‌ کوتاهی تا راه‌اندازی مجدد نسخه‌ی جدید نمی‌توان از Zeppelin استفاده نمود.
• با افزایش منابع سخت‌افزاری می‌توان افزونگی را به ۳ یا بالاتر رساند و تحمل خطای بالاتری را تضمین کرد.

مانیتورینگ / امنیت

• در نسخه‌ی جدید کلاستر، مانیتورینگ و Alerting اضافه گردیده است.
• کلاستر جدید تنها از طریق VPN قابل دسترس است.

برنامه‌ی زمانی حذف کلاستر قبلی

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

• جدول‌های Postgres حاصل از Mid Table ها از دسترس خارج می‌شوند. راه حل جایگزین استفاده از Thrift/SparkSQL در ابزارهای تحلیلی است. لطفا اگر داشبوردی از Data Source قبلی استفاده می‌نماید به این مورد توجه ویژه داشته باشید.
• با توجه به عدم نیاز ،جدول‌های Metric به‌صورت کامل حذف می‌شوند.
• نوت‌بوک‌های زپلین از ماشین قبلی حذف می‌شوند، بنابرین اگر نیازمند به کوئری یا کدهای قبلی هستید، نسبت به ذخیره یا انتقال آن‌ها به زپلین جدید اقدام نمایید.
• در صورتی که نیازمند داده‌ی خاصی در Zep Serve قبلی هستید، نسبت به دانلود آن‌ها اقدام کنید.

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

برنامه‌ی توسعه‌ی آینده

• استفاده از احراز هویت مرکزی برای تمامی سرویس‌ها (LDAP)
• تعیین سطح دسترسی به داده‌ها بر اساس Role کاربر (Authorization) با استفاده از Knox و Ranger
• ایجاد RPC Authentication برای سرویس‌های مختلف (Kerberos)
• امکان اجرای کد/کوئری از طریق Livy) Rest API)
• اطلاع‌رسانی خودکار در صورت اشکال/دیرکرد در سرویس ریپورت
• امکان ایجاد Data Pipeline برای خودکارسازی و زمان‌بندی اجرای فرآیند‌های داده‌محور

بدون شک بازخورد‌های شما نقش مهمی در رفع ایرادات و اولویت‌بندی توسعه‌های آتی دارد.