‍ چرا Intuit به‌جای ClickHouse، سراغ StarRocks رفت؟

امروزه حجم عظیم داده در بسیاری از شرکت‌ها و سازمان‌های ایرانی، ضرورت استفاده از دیتابیس‌های تحلیلی مدرن را بیش از هر زمان دیگری آشکار کرده است. مجموعه‌هایی که می‌خواهند تحلیل‌های Real-Time، گزارش‌های سریع، داشبوردهای منعطف و زیرساخت داده قابل‌اتکا داشته باشند، ناچارند بین نسل جدید OLAPها، مثل #ClickHouse، #StarRocks یا Apache #Doris انتخاب کنند.

اخیراً تیم IPS در شرکت Intuit (سازنده QuickBooks، TurboTax، CreditKarma و ده‌ها سرویس مالی دیگر) تجربه بسیار جالبی منتشر کرده‌اند.

https://celerdata-com.cdn.ampproject.org/c/s/celerdata.com/blog/how-intuit-achieved-sub-4-second-real-time-analytics-at-100k-events-per-second?hs_amp=true

آن‌ها سالانه ۱۴۰ میلیارد تراکنش پردازش می‌کنند و در پیک کاری به ۱۰۰,۰۰۰ رویداد در ثانیه می‌رسند.

💡 نیاز اصلی‌شان: تاخیر سرتاسری کمتر از ۴ ثانیه برای تغذیه مدل‌های ML و تحلیل رفتار لحظه‌ای کاربران.

در این سطح از Scale و Real-Time، معماری قبلی آن‌ها (Apache Druid) دیگر جوابگو نبود. Intuit چند گزینه را بررسی کرد: ClickHouse، Pinot، DuckDB … اما در نهایت StarRocks را انتخاب کرد.

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

🔥 چرا #StarRocks انتخاب شد؟

1) پشتیبانی Native از Upsert و جداول منطبق بر منطق Primary Key

در معماری‌های Real-Time، داشتن State برای هر کاربر، تراکنش یا session ضروری است.

در کلیک‌هوس، upsert واقعی وجود ندارد و نیاز به workaround‌هایی مثل ReplacingMergeTree یا CollapsingMergeTree است. StarRocks این مشکل را به‌صورت بومی حل کرده.

2) پرفورمنس بسیار قوی روی Multi-Table Join

در سناریوهایی مثل:

✔️ترکیب داده‌های کلیک‌استریم با پروفایل کاربر

✔️عملیات Join بین چند دامنه مختلف (مثلاً محصولات مالی Intuit)

✔️ساخت Featureهای پیچیده ML

کلیک‌هوس به دلیل طراحی column-oriented pure و join planner محدود، در joins سنگین، عقب می‌ماند.

✅ در همین بخش، #StarRocks مزیت قطعی دارد.

3) تاخیر بسیار کم در Query (زیر ۵۰۰ms در TP99)

برای مدل‌های ML که روی آخرین ۳۰ کلیک کاربر تصمیم‌گیری می‌کنند، هر میلی‌ثانیه اهمیت دارد.

دستاورد StarRocks در تست Intuit:

✔️درج صدهزار رکورد در ثانیه

✔️ ۰.۵ ثانیه latency در ۹۹٪ کوئری‌ها

✔️ تازگی داده‌ها : زیر ۱ ثانیه

این سطح از پرفورمنس با ClickHouse سخت‌تر و پرهزینه‌تر است.

4) معماری Shared-Data مشابه Lakehouse با تکیه بر S3

استارراکز می‌تواند:

✔️ جدا کردن Compute از Storage

✔️داشتن چند warehouse مجزا

✔️ قابلیت resource group برای multi-tenancy واقعی

کلیک هوس در نسخه Cloud این مسیر را آغاز کرده، اما اکوسیستم cloud-native StarRocks پخته‌تر است.

5) سادگی عملیاتی (Operational Simplicity)

کلیک‌هوس ابزارهای عملیاتی خوب دارد، اما scale-out پیشرفته نیازمند:

✔️ عملیات sharding دستی

✔️معماری پیچیده ReplicatedMergeTree

✔️ابزارهای جانبی custom

استارراکز این‌ها را تقریباً به‌صورت plug-and-play ارائه می‌کند.

⭐️ جمع‌بندی

تجربه Intuit نشان می‌دهد:

اگر real-time واقعی، joins سنگین، upsert و latency زیر ۲–۳ ثانیه نیاز دارید، StarRocks انتخاب بسیار مناسب‌تری خواهد بود.

اگر batch analytics با مقیاس بسیار بزرگ دارید، ClickHouse همچنان پادشاه است.

‍ از Kafka تا Iceberg در کمتر از یک دقیقه؛ تجربه عملی AutoMQ
در مدرسه مهندسی داده سپهرام، همیشه تلاش کرده‌ایم جدیدترین فناوری‌های حوزه داده را به‌صورت کاربردی و قابل استفاده در پروژه‌های واقعی ارائه کنیم. در ویدئویی که اخیراً در کانال یوتیوب مدرسه منتشر شده است، به‌صورت کاملاً عملی کار با AutoMQ، جایگزین نوآورانه و cloud-first برای #Kafka و همچنین ذخیره‌سازی مستقیم داده‌های Kafka در Apache Iceberg و کوئری‌گیری آن با #DuckDB را بررسی کرده‌ایم.
این جلسه بخشی از رویکرد ما برای آموزش معماری‌های مدرن داده مانند Lakehouse، Zero-ETL و استریم‌پردازی ابری است.

🔰 اما AutoMQ‌ دقیقا چیست ؟
کتابخانه AutoMQ یک کافکای بازنویسی شده است که مستقیماً بر پایه کدهای Kafka توسعه یافته و تنها لایه ذخیره‌سازی آن بازطراحی شده است. در این معماری، پیام‌ها به جای ذخیره روی دیسک هر بروکر، در یک فضای ذخیره‌سازی خارجی مانند S3 یا MinIO قرار می‌گیرند. این تغییر مهم باعث می‌شود بتوان بروکرهای بدون دیسک داشت، مقیاس‌پذیری را بسیار ساده‌تر کرد و عملیات نگه‌داری را کاهش داد. علاوه بر این، AutoMQ در مدیریت خودکار مقیاس‌پذیری هنگام افزایش حجم داده، عملکردی به‌مراتب بهتر از Kafka سنتی ارائه می‌دهد و همین موضوع آن را به یک گزینه مناسب برای تیم‌های دواپس و محیط‌های با بار سنگین داده تبدیل کرده است

در این ویدئو، مباحث زیر به‌صورت مرحله‌به‌مرحله و عملی ارائه شده است:
✔️آشنایی با معماری AutoMQ و تفاوت آن با Kafka سنتی
✔️راه‌اندازی کامل AutoMQ، MinIO، Iceberg، Schema Registry و DuckDB با Docker Compose
✔️معرفی و تشریح قابلیت AutoMQ Table Topic
✔️ارسال داده Avro از طریق یک Producer پایتونی
✔️ذخیره‌سازی خودکار داده‌ها از Kafka در جداول Iceberg بدون Kafka Connect و بدون Flink/Spark
✔️بررسی قابلیت Zero-ETL در سناریوی واقعی
✔️یکپارچگی Schema Registry و انتقال خودکار اسکیمـا به Iceberg
✔️مشاهده داده‌های ذخیره‌شده در Iceberg و اجرای کوئری‌های تحلیلی با DuckDB
✔️بررسی قابلیت Time Travel، تکامل اسکیمـا (Schema Evolution) و Partitioning
✔️نکات مهم برای استقرار AutoMQ در محیط Production و تنظیمات پیشنهادی

برای مشاهده این آموزش کاربردی می‌توانید ویدئو را در کانال یوتیوب مدرسه مشاهده کنید:
🎥 پیوند ویدئو:
https://lnkd.in/d4ZHK4n8
#Kafka #ApacheIceberg #AutoMQ #DataEngineering #DataPipeline #ZeroETL #DuckDB #Lakehouse