⚠️ تله پنهان استریمینگ در ClickHouse

استفاده از ClickHouse با سرعت زیادی در حال گسترش است؛ سرعت بالای کوئری‌ها، معماری ستونی و توان پردازش حجم عظیم داده، آن را به گزینه‌ای محبوب برای داشبوردهای Real-Time و سیستم‌های تحلیلی مدرن تبدیل کرده است 🚀

اما یک واقعیت نگران‌کننده وجود دارد:

❗ اگر معماری پایپ‌لاین استریمینگ شما درست طراحی نشده باشد، ممکن است داده‌هایتان به‌صورت کاملاً بی‌سروصدا خراب شوند و داشبوردها عددهای اشتباه نشان بدهند — بدون هیچ خطا یا هشداری.

من اخیراً یک کارگاه عملی ضبط کرده‌ام که دقیقاً همین مشکل را نشان می‌دهد؛ مشکلی ظریف اما بسیار خطرناک که می‌تواند کل زیرساخت تحلیلی شما را زیر سؤال ببرد.
قبل از دیدن ویدیو، اجازه بدهید اصل ماجرا را ساده و شفاف توضیح بدهم.

🧩 سناریویی که خیلی‌ها از آن استفاده می‌کنند

در بسیاری از تیم‌ها، پایپ‌لاین استریمینگ ClickHouse به شکلی شبیه این ساخته می‌شود:

🔹 دریافت داده از Kafka
🔹 ذخیره داده‌ها در جدول ReplacingMergeTree برای Deduplication
🔹 استفاده از Materialized View برای انتقال داده
🔹 ساخت جداول Aggregation برای آمار و KPIها

روی کاغذ، همه‌چیز منطقی به نظر می‌رسد:
Deduplication داریم، Aggregation داریم، همه‌چیز خودکار است.
اما مشکل دقیقاً همین‌جاست.

🧠 ریشه مشکل کجاست؟

مسئله از درک نادرست رفتار داخلی ClickHouse شروع می‌شود.

۱ – انجین ReplacingMergeTree در لحظه Insert داده‌ها را Deduplicate نمی‌کند
داده‌های تکراری بلافاصله وارد جدول می‌شوند و فقط در آینده، آن هم هنگام Mergeهای پس‌زمینه، نسخه‌های قدیمی حذف می‌شوند.
یعنی برای مدتی (و گاهی طولانی)، داده تکراری واقعاً وجود دارد.

۲ – عملیات Materialized View روی داده خام اجرا می‌شود، نه داده Deduplicated
Materialized View به محض Insert شدن بلاک داده اجرا می‌شود؛
نه بعد از Merge و Deduplication.

نتیجه چه می‌شود؟

🔸 یک رویداد تکراری وارد می‌شود
🔸 View اجرا می‌شود
🔸 جدول Aggregation دوباره آپدیت می‌شود
🔸 بعداً شاید داده اصلی Deduplicate شود
🔸 اما آمار تجمیعی؟ برای همیشه خراب شده

۳ – این خرابی برگشت‌پذیر نیست
وقتی Aggregation اشتباه ثبت شد، ClickHouse به‌صورت خودکار نمی‌تواند آن را اصلاح کند.

🌍 این اتفاق در دنیای واقعی کی می‌افتد؟

برخلاف تصور رایج، داده تکراری خیلی بیشتر از آن‌چیزی که فکر می‌کنیم رخ می‌دهد:

🔹 Fail شدن شبکه
🔹 Rebalance شدن Kafka
🔹 Restart شدن Consumerها
🔹 At-least-once delivery (رفتار پیش‌فرض Kafka)
🔹 Backfill داده‌های قدیمی
🔹 اشتباهات انسانی در تست و دیباگ

و ناگهان:

🔻 درآمد بیشتر از واقعیت نمایش داده می‌شود
🔻 تعداد کاربرها اشتباه است
🔻 Conversion Rate غلط است

بدترین بخش ماجرا؟

🚨 هیچ خطایی در لاگ‌ها نمی‌بینید. فقط عددهای اشتباه.

🛠️ راه‌حل چیست؟

چند اصل مهم برای طراحی پایپ‌لاین قابل اعتماد:

✅ پیشگیری بهتر از درمان است
تا حد ممکن نگذارید داده تکراری وارد سیستم شود.

✅ Deduplication را فقط به ClickHouse نسپارید
مخصوصاً وقتی پای Aggregation بلادرنگ وسط است.

✅ جداول Summary را Idempotent طراحی کنید
طوری که اگر دوباره پردازش شدند، قابل اصلاح باشند.

✅ FINAL راه‌حل دائمی نیست
هزینه پردازشی بالایی دارد و برای production مناسب نیست.

✅ برای سیستم‌های حیاتی، از Streaming Engine واقعی استفاده کنید
ابزارهایی مثل Flink، RisingWave یا Materialize می‌توانند:

• Exactly-once semantics بدهند
• Update و Retract را درست مدیریت کنند
• Deduplication واقعی در سطح Stream انجام دهند

در این حالت، ClickHouse می‌شود لایه Serving نهایی؛ جایی که واقعاً در آن بی‌رقیب است ⚡

🏗️ معماری ترکیبی؛ بهترینِ هر دو دنیا

الگوی رایج در تیم‌های بالغ داده:

Kafka → Streaming Engine → ClickHouse
(پردازش صحیح)      (کوئری سریع)

🎯 نتیجه:

• داده درست
• آمار قابل اعتماد
• داشبوردهایی که می‌شود به آن‌ها اعتماد کرد.

🎥 کارگاه عملی

در کارگاه ویدئویی که به این موضوع به کمک ردپاندا و کلیک هوس، به صورت عملی پرداخته شده است، موارد زیر را مشاهده می‌کنید:

🔹 چگونه یک پایپ‌لاین سالم در ابتدا درست کار می‌کند
🔹 با ورود داده تکراری چطور آمار به‌صورت بی‌صدا خراب می‌شود
🔹 چرا کوئری‌های FINAL عدد متفاوتی نشان می‌دهند
🔹 و چگونه می‌شود معماری را اصلاح کرد

لینک ویدئو در یوتیوب :

https://youtu.be/uzAdYYmDlRU

آدرس کدهای استفاده شده در کارگاه :‌

https://github.com/sepahram-school/workshops

🧾 جمع‌بندی

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

📌 نکات کلیدی:

• ReplacingMergeTree جلوی Insert تکراری را نمی‌گیرد
• Materialized View قبل از Deduplication اجرا می‌شود
• Aggregation اشتباه می‌تواند دائمی شود
• برای Real-Time جدی، به Streaming Engine واقعی فکر کنید

اگر با ClickHouse و استریمینگ کار می‌کنید، حواستان به این موضوع هم باشد. البته بهتر است با دقت توضیحات خود سایت کلیک هوس در این حوزه را هم مرور کنید :

https://clickhouse.com/docs/guides/developer/deduplicating-inserts-on-retries