دِیتاک چطور ۳۰۰ میلیون داده روزانه را پردازش و ذخیره می‌کند؟

سلام

من هامون، مدیر فنی شرکت دیتاک هستم.

در این پست می‌خواهم شما را با معماری بیگ دیتای شرکت دیتاک بیشتر آشنا کنم.

ما در ابتدا چه می‌کردیم!؟

مانند بسیاری از مجموعه‌های دیگر، کار مجموعه‌ی ما نیز با یک دیتابیس رابطه‌ای شروع شد. البته چون از همان ابتدای کار می‌دانستیم یک سیستم write-heavy داریم به سراغ MariaDB Cluster رفتیم.

روال کار  به این صورت بود که هزاران خزنده، جمع‌آوری‌های خودشان را روی MariaDB ذخیره می‌کردند. کدهای پردازشی ما هم به صورت near real time به داده‌هایی که روی MariaDB درج می‌‌شدند گوش می‌دادند، داده‌های جدید را Select، پردازش‌های مورد نظر را انجام داده و در نهایت مجددا روی MariaDB و یا روی Apache Solr ذخیره می‌کردند. شکل زیر روال کار را به صورت ساده نمایش می‌دهد.

مشکل از کجا شروع شد؟

مشکل از آنجا شروع شد که:

1. ما اصلا دغدغه‌ی Transaction نداشتیم.
2. نیاز به CDC داشتیم که کدهای پردازشی ما، تغییرات را از آن طریق متوجه بشوند.
3. ساختار داده‌ها مدام در حال تغییر بود.
4. نیاز به Scale Out داشتیم.
5. Batch Job‌های زیادی داشتیم که نیاز به خواندن حجم زیادی از دیتا را داشتند.

تصمیم ما برای حل مشکلات پیش رو چه بود؟

اینجا بود که تصمیم گرفتیم به طور کامل زیرساخت ذخیره‌سازی را عوض کنیم.

با کمک اعضای تیم، به بررسی معماری Lambda و Kappa که جزء محبوب‌ترین معماری‌های بیگ دیتا هستند، پرداختیم و در نهایت با ترکیب هر دو معماری به یک معماری ۵ لایه رسیدیم.

در لایه‌ی جمع‌آوری، خزنده‌های ما داده‌های روی اینترنت را جمع آوری و روی Kafka درج می‌کنند. در ادامه و در لایه Batch، با استفاده از سرویس PyConsumer که توسط تیم زیرساخت طراحی شده، داده‌های جمع‌آوری‌شده در Kafka، با همان شکل اولیه بر روی HBase که بر روی کلاستر Hadoop قرار دارد، ذخیره می‌شوند. اما در لایه ی Stream، داده های موجود در Kafka خوانده و پردازش‌های مختلف روی این داده‌ها انجام می‌شود. بعضی از این پردازش‌ها عبارتند از: نرمال‌سازی داده‌ها و حذف نویز‌ها، تشخیص زبان متن، تشخیص شباهت، NER و…

این پردازش‌ها با دو زبان JAVA و Python روی داده‌ها انجام می‌شوند.

در نهایت داده‌ها بعد از اتمام پردازش‌ها در لایه‌ی Serving و بسته به نوع تحلیل در دیتابیس‌های OrientDB و MariaDB و موتور جستجو Apache Solr و ElasticSearch ذخیره می‌شوند.

در نهایت در لایه‌ی API و با استفاده از معماری Microservices انواع سرویس‌های مختلف برای دسترسی به این داده‌ها طراحی شده و با استفاده از Kong مدیریت می‌شوند.

همچنین پردازش‌های Batch مانند تشخیص زبان پروفایل‌ها و بروزرسانی مدل‌های ML با استفاده از Apache Airflow مدیریت می‌شوند.

ما در حال حاضر این معماری را روی ۲۵ سرور اختصاصی و بیش از ۸۰ ماشین مجازی مدیریت می‌کنیم.

بیش از ۵۰ ترابایت دیتای متنی فشرده شده روی این سرورها ذخیره شده‌اند و روزانه حداقل ۱۰۰ گیگابایت به داده‌های ما افزوده می‌شود.

نقاط ضعف این معماری چه چیزهایی هستند؟

در یک کلام پیچیدگی.

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

از همراهی شما سپاسگزارم. همکارانم در پست‌های بعدی بیشتر به هر کدام از بخش‌ها خواهند پرداخت.

موفق باشید.