‏StarRocks روی EKS: مقیاس‌پذیری OLAP با KEDA و Karpenter

این پست از وبلاگ AWS رو تیم WW Stores FinTech آمازون نوشته و تجربهٔ ساختن یک پلتفرم تحلیل مالی رو روی Kubernetes تعریف می‌کنه. به گفتهٔ نویسنده‌ها، نیازشون سه‌تا بود که با هم جور درنمیومد: پاسخ زیر چند ثانیه روی ترابایت‌ها داده، صدها کاربر همزمان توی پیک، و مقیاس‌پذیری افقی بدون جابه‌جایی پردردسر داده. سیستم‌های قبلی‌شون فقط یکی دوتای این‌ها رو می‌تونستن همزمان بدن.

برای ارزیابی، به‌جای بنچمارک‌های عمومی یک Query Complexity Framework تعریف کردن که الگوهای واقعی کوئری مالی رو پوشش می‌ده: فیلتر روی ستون‌های high-cardinality، تجمیع (GROUP BY) سنگین، جوین روی بیش از سه جدول، عملیات pivot و پیمایش سلسله‌مراتبی. دو کاندیدای OLAP یعنی StarRocks و ClickHouse رو روی زیرساخت یکسان تست کردن.

نتیجه به گفتهٔ نویسنده‌ها روشن بود: روی کوئری‌های ساده و تک‌جدولی ClickHouse کمی جلوتره و دادهٔ حجیم رو سریع‌تر ingest می‌کنه، ولی به محض اینکه کوئری‌ها به سمت چندجوینی و pivot سلسله‌مراتبی و فیلتر high-cardinality می‌رن، StarRocks جلو می‌افته؛ مثلاً روی multi-JOIN حدود ۳ تا ۵ برابر throughput بیشتر. دلیلش هم Cost-Based Optimizer هست که پلن کوئری رو خودش با تغییر توزیع داده تنظیم می‌کنه.

نکتهٔ معماری مهم اینه که StarRocks دو نوع نود داره: نودهای CN که stateless هستن و داده رو مستقیم از S3 می‌خونن، و نودهای BE که جدول‌های dimension ایندکس‌شده رو روی EBS نگه می‌دارن تا جوین‌ها سریع‌تر بشن. چون CN‌ها هیچ دادهٔ ماندگاری ندارن، لحظه‌ای بالا و پایین می‌شن بدون اینکه داده‌ای جابه‌جا بشه — و همین چیزیه که autoscaling رو روی یک بار OLAP عملی می‌کنه.

برای مقیاس‌پذیری، KEDA متریک‌های خود StarRocks مثل عمق صف کوئری و مصرف CPU/Memory رو از Prometheus می‌خونه و تعداد podها رو تنظیم می‌کنه. بعدش Karpenter پایین‌تر، نودهای EC2 با سایز مناسب رو on-demand می‌سازه؛ نودهای FE و BE روی On-Demand و CN‌ها روی Spot اجرا می‌شن. وقتی بار می‌خوابه، Karpenter نودهای کم‌استفاده رو خودش جمع می‌کنه.

نویسنده‌ها چند درس عملیاتی هم می‌گن: تو تست ۱۰۰۰ کاربری اولش حدود ۴۰٪ کوئری‌ها با خطای memory limit شکست می‌خورد که با مهاجرت به اینستنس‌های memory-optimized و تنظیم Resource Groups به زیر ۵٪ رسید. یک یافتهٔ جالب دیگه دربارهٔ EBS بود: با throughput پیش‌فرض gp3 لود یک دیتاست ۴.۷ ترابایتی ۱۳ ساعت طول می‌کشید، ولی بعد از تنظیم throughput روی ۱۰۰۰ مگابایت بر ثانیه، همون لود ۲۵ دقیقه‌ای شد — حدود ۳۱ برابر بهتر.

نکات کلیدی:

• StarRocks روی کوئری‌های پیچیدهٔ چندجوینی و high-cardinality از ClickHouse جلو زد، هرچند ClickHouse روی کوئری ساده و ingest سریع‌تره
• جدا بودن استوریج از کامپیوت (نودهای stateless CN) همون چیزیه که autoscaling با KEDA و Karpenter رو ممکن می‌کنه
• معماری ترکیبی: fact tableها روی S3 از طریق CN، و dimensionهای ایندکس‌شده روی EBS با نودهای BE
• نتیجه: پاسخ زیر ۵ ثانیه برای کوئری استاندارد و زیر ۲۰ ثانیه برای پیچیده، با ۱۰۰۰ کاربر همزمان
• تنظیم throughput روی EBS قبل از هر بنچمارک حیاتیه؛ تفاوت ۳۱ برابری ساخت