شاید بد نباشه تجربیاتمون رو در مورد پلت فرمهای بیگ دیتا ای که تا حالا استفاده یا امتحان کردیم به اشتراک بزاریم. چه خوبی هایی داشتن چه بدی هایی داشتن و در کل نظرتون در مورد هر کدوم چی هست. مخصوصا در مورد پلت فرم های stream processing.
خودم. Spark , Samza, Storm, Onyx و Kafka streams رو برای stream processing و hadoop رو برای batch processing استفاده کردم.
توی اینها هر کدوم نکات جالبی داشتند. برای مثال Samza خیلی انعطاف پذیر بود و از لحاظ دولپمند خیلی scalable اما به این قیمت که نحوه ارتباط برقرار کردن اجزاء نرم افزار از طریق kafka بود که باعث می شد تو ترافیک بالا یه مقدار latency داشته باشیم ولی در عوض انعطاف پذیری خیلی خوبی داره. Kafka streams خیلی ساده هستش و در عین حال قدرتمند اما از لحاظ توسعه مخصوصا تو نرم افزار های بزرگ راحت می تونه دردسر ساز شه و همه چی رو پیچیده کنه.
بکی از فیچر هایی که تو onyx دیدم و خیلی خوب بود این هست که در زمان اجرا می تونین workflow دیتا رو عوض کنین و این خیلی حداقل برای ما کاربردی بود مخصوصا وقتی که نیاز بود state رو مدیریت کنیم برای stream های جدا گانه.
حالا اگه در این زمینه تجربه دارین شیر کنین که بحث کنیم و از تجربیاتتون بهره ببریم.
من با چندهمکار درساخت lambda architecture برای شرکت قبلی نقش داشتیم
ETL اولیه هرشب اجرا می‌شد و کلی مشکل داشت
سیستم جدید توسط کافکا spark و چند data store مختلف کار میکنه cassandra impala elasticsearch
نیاز ما به دو قسمت تقسیم کردیم OLTP که زمان درخواست داده باید کوتاه باشه و یا OLAP برای query روی کلی داده برای report …
Microservice ها تمامه داده که ذخیره می‌کردند و یا اتفاقات مهم و به کافکا میفرستند سپارک با spark streaming می‌خواد
ETL تقریبا realtime شد با این کار و داده ای از سیستم پاک نمیشد
تیم analytics کلی report و dashboard میخواستن بعضی report ها دو روز طول میکشید برای همه ی کاربر ها اجرا بشه و با سپارک شد نیم ساعت
تیم data science میخواستن مدل هارو سریع تر تست کنن
تیم های مهندسی میخواستن به عنوان telemetry و metric از این سیستم استفاده کنن مثلا وقتی deploy میکردیم تعداد خرید موفق این نسخه رو با نسخه قبل مقایسه میکردیم و پاک نکردن داده منجر شد کلی از باگ ها ی کد پیدا کنیم کلاستر کافکا زیاد بزرگ نبود سه تا نود 8GB و به صورت نرمال ۲۰۰۰ پیام در ثانیه میگرفت
برای کاربرد ما سپارک بسیار خوب عمل کرد
دلیل انتخاب سپارک این بود که یک فریورک همه نیازهامون برای اجرای sql و streaming و ذخیره کردن داده در data store یک جا انجام میداد latency تا دو دقیقه برای رسیدن داده به Data store برای ما قابل قبول بود
سپارک کاملا بی دردسر نبود ولی بیشترش برمیگشت به کمبود RAM کلاستر
با کافکا هم partition key اوایل خوب نبود و به اندازه کافی random نبود که باعث شد به مشکل hot partition دست وپنجه نرم کنیم وقتی partition key به اندازه کافی random نباشه یک partition اکثر ترافیک و میگیره و داغون میشه
تو اکثر دیتابیس ها nosql هم همین طوره خلاصه من یک شب ساعت 2 بیدارشدم با alarm دیدم کل کافکاکلاستر رو آتیشه
اگر درست یادم بیاد بین 150-200 پارتیشن داشتیم event ها حدود ۱۰۰ kB بودند به طور متوسط و نوع داده یک json بود که نوع پیام ، سازنده ، نسخه ،state قبل و بعد داشت
فکر میکنم در هر پارتیشن تا 10 GB داشتیم یا 7 روز داده بعد 7 روز پاک می‌شد از پارتیشن