آیا همیشه برای دریافت داده‌های ورودی به یک سرویس اختصاصی نیاز داریم ؟ معرفی RudderStack
به‌عنوان مهندس داده، یکی از اولین قدم‌ها در ساخت یک خط پردازش داده، دریافت رویدادها از کلاینت‌های مختلف و انتقال سریع و قابل‌اعتماد آن‌ها به زیرساختی مثل Kafka است.

بسیاری از تیم‌ها برای این کار سراغ توسعهٔ یک سرویس اختصاصی با زبان‌هایی مثل Go می‌روند؛ اما پیاده‌سازی و نگهداری SDKها، بافرگذاری، ارسال گروهی، تلاش مجدد و مقیاس‌پذیری، خودش به پروژه‌ای جداگانه تبدیل می‌شود.

آیا واقعاً لازم است این بخش را از صفر بسازیم؟

معرفی RudderStack؛ درگاه ورود رویدادها به خطوط پردازش داده
رادراستک (RudderStack) در اصل یک پلتفرم مدیریت داده‌های مشتریان (CDP) است که برای جمع‌آوری، پردازش و انتقال داده‌های رفتاری از وب‌سایت‌ها، اپلیکیشن‌ها و سرویس‌های مختلف به کار می‌رود. بخشی از این پلتفرم به‌صورت متن‌باز ارائه شده است. در این پست، مشخصاً Rudder Server را معرفی می‌کنیم؛ موتور سمت سرور این پلتفرم که وظیفهٔ پردازش و مسیریابی رویدادها را بر عهده دارد و می‌توان از آن به‌عنوان لایهٔ ورود رویدادها به خط پردازش داده، برای مثال پیش از Kafka، استفاده کرد.
معماری پیشنهادی به کمک این ابزار، به شکل زیر خواهد بود :

Client SDK → RudderStack → Kafka → Consumers → ClickHouse

در این معماری، RudderStack رویدادها را از کلاینت‌های مختلف دریافت می‌کند و به Kafka تحویل می‌دهد. سپس مصرف‌کنندگان Kafka مسئول پردازش و تبدیل داده‌ها هستند و در نهایت، داده‌ها می‌توانند در ClickHouse ذخیره شوند.

چه قابلیت‌هایی دارد؟

پشتیبانی از SDKهای متنوع: پشتیبانی از پلتفرم‌هایی مانند JavaScript، iOS، Android، React Native و Flutter و زبان‌هایی مثل Python، Go، Java، .NET و Rust.

ارسال کارآمد: بافرگذاری و ارسال گروهی رویدادها برای کاهش سربار ارتباطات شبکه.

اتصال به Kafka: پشتیبانی از ارسال گروهی پیام‌ها، فشرده‌سازی و قابلیت‌های مرتبط با قالب و اعتبارسنجی داده‌ها.

مقیاس‌پذیری افقی: امکان اجرای چند نمونه پشت Load Balancer برای افزایش ظرفیت دریافت رویدادها.
(هر چند نسخه رایگان آن تک نود هست اما می‌توان با اتخاذ راهکارهایی ، از چند نسخه آن پشت یک Load Balancer استفاده کرد)
میزبانی مستقل: امکان استقرار نسخهٔ متن‌باز در زیرساخت خودمان.

️ چند نکتهٔ عملیاتی

توان عملیاتی واقعی به سخت‌افزار، اندازهٔ رویدادها و تنظیمات وابسته است؛ بنابراین اعداد بنچمارک را باید در محیط خودمان آزمایش کنیم.

همچنین اگر ترتیب رویدادهای هر کاربر اهمیت دارد، باید مسیریابی، رفتار مصرف‌کنندگان و کلید پارتیشن‌بندی Kafka را با دقت طراحی کنیم. اجرای چند نمونه به‌تنهایی تضمین‌کنندهٔ ترتیب رویدادها نیست.

یک نکتهٔ تکمیلی

اگر مسئلهٔ ما دریافت داده‌های تله‌متری، مانند لاگ، متریک و تریس است، OpenTelemetryCollector هم راهکار مهمی برای دریافت و انتقال این نوع داده‌هاست. اما برای رخدادهای محصول و کسب‌وکار، مانند کلیک کاربران، ثبت سفارش و فعالیت اپلیکیشن‌ها، RudderStack می‌تواند گزینه‌ای برای لایهٔ ورود رویدادها باشد.

کد منبع: https://github.com/rudderlabs/rudder-server
وب‌سایت: https://www.rudderstack.com/

@DevTwitter | <Mojtaba Banaie/>