‍ وقتی پای ۵۰۰هزار سیگنال در ثانیه وسط است ⚡️: انتخاب پایگاه داده برای داده‌های سری زمانی

چند روز پیش یکی از دوستان که روی پروژه‌های #SCADA در صنایع زیرساختی کار می‌کند، سوال جالبی مطرح کرد که باعث شد بشینم و یه بررسی دقیق‌تر انجام بدم و نتیجه را با شما هم به اشتراک بذارم 👇

«ما داده‌های سری زمانی داریم و فعلاً در پایگاه‌داده #Oracle ذخیره می‌شن. ولی در پروژه‌های جدید ممکنه نرخ داده به ۵۰۰ هزار سیگنال در ثانیه برسه. دنبال دیتابیسی هستیم که بتونه این حجم رو مدیریت کنه، تحلیل Real-time بده، و قابلیت‌هایی مثل میانگین‌گیری، Sampling، و Backfill رو پشتیبانی کنه.»

سری زمانی یعنی چی؟ 🕒

داده‌های #TimeSeries معمولاً از سنسورها یا لاگ‌ سیستم‌ها میان و بر اساس زمان مرتب می‌شن. ذخیره و تحلیل این داده‌ها با پایگاه‌داده‌های سنتی خیلی وقتا سخت یا ناکارآمده.

چالش مهم: کاردینالیتی بالا 🧠

در دیتابیس‌های سری زمانی، ستون‌هایی مثل Tag یا Label ممکنه میلیون‌ها مقدار یکتا داشته باشن (High Cardinality). مثلاً هر سنسور یا دستگاه یه شناسه خاص داره. دیتابیس‌هایی مثل #InfluxDB یا #Prometheus در این شرایط دچار مشکل می‌شن، چون ایندکس‌گذاری معکوس (Inverted Index) براشون گرونه.

بررسی گزینه‌های جدی برای ذخیره و تحلیل داده‌های سری زمانی 🧪

✅ دیتابیس TimescaleDB

بر پایه‌ی PostgreSQL، آشنا برای خیلی از تیم‌ها، ولی مقیاس‌پذیری افقی محدود داره.

✅ دیتابیس InfluxDB

معروف‌ترین دیتابیس سری زمانی، ولی در حجم و کاردینالیتی بالا ممکنه کم بیاره.

🔹 زبان اختصاصی Flux، نسخه Cloud و OSS


✅ دیتابیس QuestDB

سریع و سبک، با پشتیبانی از SQL و تحلیل‌های ساده Real-time.

🔹 مناسب پروژه‌های سبک تا متوسط


دیتابیس جدید 🚀 Apache HoraeDB

طراحی شده با زبان Rust برای کار با داده‌های سری زمانی با کاردینالیتی بالا.

از تکنیک scan+prune به جای inverted index استفاده می‌کنه.

🔹 سازگار با سیستم های ابری / Cloud-native و مقیاس‌پذیر

🔹 هنوز incubating ولی بسیار جذاب

🔹 معماری Zero-Disk و جداسازی بخش محاسبات و پردازش از بخش ذخیره سازی


گزینه‌های عمومی ولی قدرتمند برای تحلیل داده در مقیاس بالا 🔍

⚡️ دیتابیس ClickHouse

تحلیل سریع و فوق‌العاده روی داده‌های ستونی. اگر تحلیل پیچیده Real-time می‌خواید، عالیه.

🔹 مقیاس‌پذیر افقی

🔹 پشتیبانی از توابع Aggregation


🌀 دیتابیس ScyllaDB / Cassandra

طراحی‌شده برای نوشتن سریع با تأخیر کم.

اگر مدل داده‌ی خوبی طراحی کنید، خیلی خوب جواب می‌ده.

🔹 دیتابیس ScyllaDB سریع‌تر از Cassandra و با مصرف منابع کمتر


✳️ جمع‌بندی برای شرایط صنعتی با داده‌های حجیم:

اگر با سناریوهایی مثل ۵۰۰k در ثانیه، نیاز به واکشی سریع و تحلیل Real-time سروکار دارید، این سه گزینه بیشترین تطابق رو دارن:

🔹 Apache HoraeDB – طراحی‌شده برای مقیاس بالا + کاردینالیتی بالا

🔹 ClickHouse – برای تحلیل بلادرنگ در مقیاس بزرگ

🔹 ScyllaDB – اگر اولویت با نوشتن با نرخ بالا و توزیع‌پذیریه

🤝 دعوت به گفتگو

آیا تجربه‌ای در انتخاب یا مهاجرت از پایگاه‌داده‌های سنتی به TimeSeries DB داشتید؟

کدوم ابزار براتون بهتر جواب داده؟ چه چالش‌هایی داشتید؟👂 شاید این بحث به انتخاب بهتر برای پروژه‌های بعدی همه ما کمک کنه. نظراتتون را در بخش کامنت‌ این پست می توانید با سایر دوستان به اشتراک بگذارید.

#SCADA #TimeSeriesDatabase #HoraeDB #ClickHouse #ScyllaDB #InfluxDB #QuestDB #DataEngineering #IoT #HighCardinality #RustLang

‍ اوج بلوغ تیم‌های مهندسی داده: محیط Staging و چک‌لیست تغییرات دیتابیس 🔴

وقتی یه دستور ساده می‌تونه کل سیستم رو بخوابونه!

چند روز پیش یکی از دوستان تماس گرفت و گفت روی یک جدول بزرگ در ClickHouse دستور OPTIMIZE FINAL زده. جدول مربوط به دیتای اصلی سیستمشون بوده و چند میلیارد رکورد داشته. نتیجه؟ تمام CPUها پر شدن، کوئری‌های عادی از کار افتادن و سیستم عملاً فلج شده. 🧨

اتفاقی که شاید برای خیلی از ما آشنا باشه. ولی پشت این اتفاق، یک نکته خیلی مهم هست:

🧑‍💻 ما باید عادت کنیم مثل مهندسان نرم‌افزار، محیط‌های جدا برای تست و اجرا داشته باشیم.

🚫 داده‌های حساس و عملیاتی هیچ‌وقت نباید محل آزمایش باشن.


اینا چند تا نکته‌ کلیدی هستن که هر مهندس داده باید رعایت کنه:

🔹 محیط staging جداگانه داشته باشیم که شبیه production باشه (نه لزوماً با همون حجم دیتا)

🔹 دیتا رو نمونه‌گیری (sample) کنیم و روی کپی‌ها تست کنیم، نه روی دیتای اصلی

🔹 دستورات سنگین مثل OPTIMIZE, VACUUM, یا REINDEX رو اول روی محیط تست اجرا کنیم

🔹 حتماً از ابزارهای مانیتورینگ، لاگ‌گیری و EXPLAIN استفاده کنیم قبل از اجرای کوئری‌های پرهزینه 📊



✨ جادوی چک‌لیست 📝

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

✅ تست انجام شده؟

✅ دیتای درگیر چقدره؟

✅ منابع مورد نیاز؟

✅ توقف اضطراری یا rollback چطوریه؟

✅ مانیتور فعال هست؟

✅ روی staging امتحان شده؟

چک‌لیست‌ها نه فقط جلوی اشتباهات انسانی رو می‌گیرن، بلکه فرهنگ مسئولیت‌پذیری، نظم و آرامش به تیم می‌دن. 🧠

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

چک‌لیست‌ها تو مهندسی داده جادو می‌کنن.

#مهندسی_داده #DataEngineering #ClickHouse #StagingMatters #ChecklistMagic #DatabaseOps #ProductionReady

چگونه با ClickHouse زیرساخت کمپین بازاریابی شخصی‌سازی‌شده اسنپ! مارکت را طراحی کردیم؟ 🎯

این مقاله ترجمه ای است از :

https://medium.com/@prmbas/clickhouse-in-the-wild-an-odyssey-through-our-data-driven-marketing-campaign-in-q-commerce-93c2a2404a39

در جریان طراحی و اجرای کمپین «سوپرسنج» در اسنپ! مارکت، هدف ما خلق تجربه‌ای متفاوت و هوشمندانه برای میلیون‌ها کاربر بود؛ تجربه‌ای که با تحلیل رفتار خرید واقعی مشتریان و بهره‌گیری از الگوریتم‌های یادگیری ماشین و هوش مصنوعی، به‌شکل شخصی و سرگرم‌کننده ارائه می‌شد.

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

📦 کمپین سوپرسنج: شخصیت خرید شما چیست؟

سوپرسنج یک کمپین خلاقانه و داده‌محور بود که با الهام از تست‌های #MBTI، پرتره‌ای طنز و شخصی‌سازی‌شده از کاربران اسنپ! مارکت ارائه می‌داد. این پرتره با تحلیل واقعی رفتار خرید مشتریان و به‌کمک هوش مصنوعی تولید می‌شد.

اجزای اصلی کمپین:

🧑‍💼 پروفایل شخصی: آمارهایی مثل تاریخ اولین سفارش، مجموع کوپن‌های استفاده‌شده و مسافت طی‌شده توسط پیک‌ها

🧠 تست شخصیت خرید: تخصیص تیپ‌های شخصیتی بر اساس رفتار خرید (مثلاً «تنقلاتی راحت‌طلب» یا «قهوه‌دوست اقتصادی»)

🤖 محتوای طنز با هوش مصنوعی: تولید دیالوگ و داستان کوتاه بر اساس داده‌های مشتری، با استفاده از LLMها


🔧 ساختار فنی: معماری چندلایه پردازش داده

برای پشتیبانی از چنین تجربه‌ای، ما لایه‌های مختلفی از پردازش داده را در نظر گرفتیم:

🟫 لایه برنز : داده‌های خام شامل سفارش‌ها، اطلاعات کاربران، و متادیتاهای مربوط به محصولات در بازه‌ای چهارساله

🟪 لایه نقره: پردازش‌های تحلیلی میانی با استفاده از SQL و Python، ذخیره‌شده به‌شکل فایل‌های Parquet

🟨 لایه طلا : خروجی نهایی شامل برچسب‌های شخصیتی، آمار اختصاصی، و JSONهایی که به مدل‌های زبانی برای تولید متن تزریق می‌شد

⚠️ چالش فنی: جوین‌های سنگین و مصرف بالای حافظه

در مراحل اولیه، از الگوریتم پیش‌فرض Join در ClickHouse استفاده کردیم. اما با رشد داده‌ها و افزایش پیچیدگی کوئری‌ها، مصرف حافظه سر به فلک کشید و در مواردی منجر به کرش شد.

برای حل این مشکل، با بررسی دقیق مستندات ClickHouse و رفتارهای کوئری، به الگوریتم partial_merge مهاجرت کردیم.

‍‍‍-- changing join algorithm in the current CLI session
SET join_algortim = 'partial_merge';

-- data easlity stored in a parquet file
-- default path: /var/lib/clickhouse/user_files
INSERT INTO FUNCTION file('temp_data.parquet', Parquet)
SELECT *
FROM [db1].[table1] AS t1
LEFT JOIN [db2].[table2] AS t2 ON t1.[column1] = t2.[column2];

✅ نتیجه:

💥پایداری بیشتر در کوئری‌های سنگین

💥کاهش چشمگیر استفاده از RAM

💥حذف نیاز به ایجاد جداول staging برای ترکیب داده‌ها


🚀 قابلیت‌های ویژه ClickHouse که بهره‌برداری کردیم:

🌱 خواندن مستقیم فایل‌های Parquet از مسیرهای محلی و شبکه‌ای

🌱 توابع تحلیلی سطح بالا مانند argMax, groupArray, corr, toStartOfInterval

🌱 پشتیبانی بومی از JSON و آرایه‌ها برای ذخیره داده‌های ساخت‌یافته در فرمت نیمه‌ساخت‌یافته

🌱 اتصال Real-time به داشبورد Grafana برای مشاهده نتایج و رفتار کمپین در زمان اجرا

📈 نتیجه نهایی

کمپین سوپرسنج با مشارکت بیش از ۱۰۰ هزار کاربر در مدتی کوتاه، به‌عنوان یکی از موفق‌ترین کمپین‌های داده‌محور در صنعت تجارت الکترونیک ایران شناخته شد. این موفقیت تنها به دلیل طراحی خلاقانه و محتوای طنز نبود؛ بلکه به لطف یک زیرساخت داده‌ای دقیق، سریع، و بومی‌سازی‌شده به دست آمد — زیرساختی که علی‌رغم نبود زیرساخت‌های ابری بین‌المللی، بر پایه ابزارهای متن‌باز مانند ClickHouse توسعه یافت و در مقیاس وسیع به‌کار گرفته شد.

چطور تسلا با ClickHouse یک پلتفرم مشاهده‌پذیری در مقیاس نجومی ساخت؟

مشاهده‌پذیری در مقیاس کوادریلیون (هزار بیلیارد) با ClickHouse و پروژه‌ای به نام Comet

داستان تغییر زیرساخت observability تسلا از کجا شروع شد ؟

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

👨‍💻 مهندس ارشد تسلا Alon Tal، می‌گوید:

«ما به سیستمی نیاز داشتیم که بتونه ده‌ها میلیون ردیف در ثانیه را ingest کنه، سال‌ها داده رو نگه داره، و همچنان real-time پاسخ بده.»

چرا Prometheus کافی نبود؟

🔸 مقیاس‌پذیری افقی محدود

🔸 وابستگی به یک سرور واحد (ریسک از دست دادن کل متریک‌ها)

🔸 مشکلات نگهداری بلندمدت و زبان کوئری محدود

✅ راه‌حل: ساخت یک سیستم جدید به نام Comet

💡 با استفاده از ClickHouse به عنوان هسته‌ی اصلی، تسلا یک پلتفرم metrics محور ساخت که:

📥 داده‌ها را از طریق OTLP و Kafka ingest می‌کند

⚙️ با ETLهای سفارشی داده‌ها را به شکل ساخت‌یافته وارد ClickHouse می‌کند

🔄 و مهم‌تر از همه:

کوئری‌های PromQL را به SQL معادل در ClickHouse ترجمه می‌کند بدون اینکه مهندسان متوجه تفاوت شوند!

🧠 یعنی داشبوردهای موجود (Grafana، Alertmanager، و...) بدون تغییر کار می‌کنند!

💥 مقیاس واقعی؟

یک میلیارد ردیف در ثانیه! به مدت ۱۱ روز پیاپی!

نتیجه؟

🔹 بدون یک خطا

🔹 مصرف ثابت RAM و CPU

🔹 بیش از ۱ کوادریلیون رکورد با موفقیت ingest شده!

📊 سیستم هنوز هم در حال scale شدن برای تیم‌های داخلی تسلاست!

✨ چرا ClickHouse؟

🔹 سرعت بی‌رقیب در پاسخ به کوئری‌های پیچیده

🔹 UDFهای اجرایی برای کوئری‌های غیر trivial

🔹 پشتیبانی از PromQL و TraceQL

🔹 نگهداری بلندمدت داده‌ها با حجم بالا

🔹 و مهم‌تر از همه: قابلیت اطمینان بالا در مقیاس تسلا!

🔭 آینده‌ی Comet؟

🔧 پشتیبانی از distributed tracing

🌍 احتمال open-source شدن

🎯 گسترش به دیگر واحدهای عملیاتی در تسلا

📎 جمع‌بندی

تسلا با پروژه‌ی Comet ثابت کرد که observability در مقیاس سیاره‌ای ممکن است—اگر ابزار مناسب انتخاب شود!


✅ حالا واقعا پرومتئوس حذف شد؟

تسلا Prometheus رو به‌طور مستقیم حذف نکرد، ولی:

🌟دیگه از خود Prometheus برای ذخیره‌سازی و کوئری استفاده نمی‌کنه.

🌟 به‌جاش، پلتفرمی به نام Comet ساخت که خودش می‌تونه PromQL (زبان کوئری Prometheus) رو اجرا کنه و پشت صحنه با کلیک‌هوس ارتباط بگیره و خروجی بده بدون اینکه واقعاً Prometheus وجود داشته باشه!


🔗 منبع اصلی:

https://clickhouse.com/blog/how-tesla-built-quadrillion-scale-observability-platform-on-clickhouse

#ClickHouse #Observability #Tesla #PromQL #DataEngineering #Scalability #TimeSeries #Kafka #DevOps #OpenTelemetry #Infrastructure

‍ معرفی رسمی ClickStack – استک Observability اپن‌سورس بر پایه ClickHouse

سال‌ها بود که با وجود قدرت بالای ClickHouse در ذخیره و کوئری‌گیری سریع داده‌ها، جای یک راه‌حل Observability واقعی در این اکوسیستم حس می‌شد.

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

اما حالا اوضاع فرق کرده.

با خرید HyperDX در ابتدای سال 2025، کلیک‌هوس قدم بزرگی در این حوزه برداشت و اخیرا از ClickStack رونمایی کرد:

یک استک کامل، اپن‌سورس و بسیار سریع برای Observability – ساخته‌شده بر قلب تپنده‌ی ClickHouse. ❤️‍🔥

آدرس : https://clickhouse.com/use-cases/observability

📦 مجموعه ابزار ClickStack چیست؟

🔹 یک پلتفرم سبک و قدرتمند برای مانیتورینگ و دیباگ

🔹 سازگار با OpenTelemetry

🔹 شامل رابط کاربری HyperDX، کلکتور سفارشی، و ClickHouse

🔹 آماده برای محیط‌های تولیدی، با نصب آسان و تجربه‌ای روان برای تیم‌ها


💡 چرا این اتفاق مهمه؟

تا پیش از این، حتی تیم‌هایی مثل نتفلیکس که سال‌ها از کلیک‌هوس برای تحلیل داده‌های Observability استفاده می‌کردند، مجبور بودند ابزارهای اختصاصی خودشون رو بسازند. حالا با ClickStack، همون قدرت و کارایی در اختیار همه هست آن‌ هم به سادگی و سهولت .


✨ ویژگی‌های جذاب ClickStack:
✅ جستجوی بسیار سریع در لاگ‌ها و تریس‌ها

✅ تجزیه‌وتحلیل داده‌های عظیم بدون نیاز به SQL

✅ مشاهده زنده‌ی لاگ‌ها و بازپخش جلسات

✅ پشتیبانی کامل از JSON و schemaهای پویا

✅ همبستگی خودکار بین لاگ، متریک، تریس و سشن

✅ طراحی‌شده برای کار با داده‌های با کاردینالیتی بالا

✅ هشداردهی، تحلیل روند و شناسایی ناهنجاری


🧱 معماری ClickStack

🎯 ClickHouse: قلب پردازش تحلیلی

🎯 OpenTelemetry Collector: جمع‌آورنده‌ی داده‌ها با ساختار بهینه

🎯HyperDX UI: رابط کاربری مدرن برای مشاهده و کاوش داده‌ها

می‌تونید این اجزا رو مستقل یا به‌صورت یکپارچه استفاده کنید. نسخه مبتنی بر مرورگر HyperDX UI هم در دسترسه که می‌تونه به استقرارهای موجود کلیک‌هوس متصل بشه – بدون نیاز به زیرساخت اضافه.


📚 طراحی ClickStack بر اساس چند اصل ساده شکل گرفته:

📌نصب سریع و بدون پیچیدگی

📌پشتیبانی از SQL و Lucene-style search برای راحتی توسعه‌دهنده‌ها

📌دید کامل از سیستم از سشن کاربر تا کوئری دیتابیس

📌سازگاری کامل با اکوسیستم OpenTelemetry

📌و مهم‌تر از همه: اپن‌سورس، قابل‌توسعه و شفاف

🎯 برای همه‌ی تیم‌هایی که دنبال یک راه‌حل سریع، منعطف و قابل‌اتکا برای Observability هستند، حالا یک گزینه جامع و بسیار سریع و در عین حال سبک و مقیاس پذیر داریم.

اگر از ClickHouse استفاده می‌کنید، می‌توانید به راحتی به ClickStack مهاجرت کنید و یا حداقل آنرا امتحان کنید.

#ClickStack #ClickHouse #Observability #OpenTelemetry #DevOps #SRE #OpenSource #HyperDX #MonitoringTools #DataEngineering

‍ شمارش بازدیدها و اکشن‌های کاربر با فناوری‌های مدرن داده

در پست قبلی درباره روش‌های کلاسیک شمارش بازدید محصولات یا تماشای ویدئو صحبت کردم.

https://t.iss.one/bigdata_ir/445

به‌طور خلاصه گفتیم که در بار ترافیکی بالا، بهتر است بازدیدها را در حافظه نگهداری و جمع‌بندی کرده، سپس در بازه‌های زمانی مشخص وارد دیتابیس کنیم. همچنین به رویکرد پیشرفته‌تری با Kafka + Flink برای ایجاد بافر و بروزرسانی دوره‌ای دیتابیس اشاره شد.

اما امروز می‌خواهیم به سراغ راهکارهای مدرن‌تر برویم. پیشرفت‌های اخیر در استک‌های داده، امکانات جدیدی برای ما فراهم کرده که فقط محدود به شمارش ساده نیستند.

🎯 هدف ما فقط شمارش نیست!

آنچه امروز اهمیت دارد، ذخیره‌سازی دقیق تمام اکشن‌های کاربر است.

چرا؟

✅برای شخصی‌سازی تجربه کاربری بر اساس رفتار هر فرد

✅برای تحلیل عمیق روی محصولات یا ویدئوها و بهبود تجربه کاربران

پس راهکار ایده‌آل باید هم شمارش و هم ذخیره‌سازی کامل داده‌ها را پوشش دهد.


🛠 سه راهکار مدرن برای شمارش و ذخیره اکشن‌ها

1️⃣ استفاده از Cassandra / ScyllaDB و قابلیت Distributed Counter

🎯برای هر کاربر و هر محصول، یک جدول بازدید ایجاد می‌کنیم

🎯هر اکشن را در هر دو جدول ذخیره می‌کنیم (مدل داده این دیتابیس‌ها بر اساس Query طراحی می‌شود)

🎯شمارش اکشن‌ها با Distributed Counter انجام می‌شود

🎯امکان تعریف شمارنده برای بازه‌های زمانی مختلف (ساعتی، روزانه و...) وجود دارد

✅مزیت اصلی: مقیاس‌پذیری بالا و سرعت فوق‌العاده


2️⃣ ذخیره خام داده‌ها در قالب Apache Iceberg با AutoMQ

🎯جایگزین Kafka سنتی با AutoMQ

🎯 پیام رسان AutoMQ که دقیقا منطبق بر استاندارد کافکا است، پیام‌ها را مستقیماً در Iceberg ذخیره می‌کند

🎯شمارش با Flink + Redis انجام می‌شود

🎯امکان تحلیل بعدی رفتار کاربران با ابزارهایی مثل ClickHouse یا Spark

✅مزیت اصلی: فشار کمتر روی دیتابیس اصلی و نگهداری داده‌های خام برای تحلیل‌های آینده

3️⃣ استفاده از دیتابیس جریانی RisingWave – سریع، مدرن و چندکاره 🚀

دیتابیس RisingWave یک دیتابیس جریانی (Streaming Database) است که با استاندارد PostgreSQL توسعه یافته و از SQL به‌عنوان زبان اصلی پردازش داده‌های جریانی استفاده می‌کند.

📌 ویژگی‌ها و مزایا:

🎯شمارش و پردازش جریانی با SQL ساده → ایجاد Materialized Viewها برای شمارش بازدیدها و اکشن‌ها در لحظه

🎯ذخیره اکشن‌ها در S3 و Iceberg → امکان نگهداری داده‌های خام برای تحلیل‌های آینده

🎯سرعت بالا به لطف Rust → هسته سیستم با زبان Rust نوشته شده و از مزایای کارایی و مصرف کم منابع بهره می‌برد

🎯پشتیبانی از Sinkهای متنوع → خروجی مستقیم به دیتابیس‌ها، سیستم‌های پیام‌رسان، S3، Kafka و...

🎯پردازش رویدادهای پیچیده → اجرای Queryهای تحلیلی پیشرفته بر روی جریان داده بدون نیاز به ابزار جداگانه

✅ نتیجه؟

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

📌 جمع‌بندی

این سه راهکار نسبت به روش‌های سنتی و حتی رویکرد Kafka + Flink، مدرن‌تر هستند و از فناوری‌های جدید حوزه داده بهره می‌برند.

اگر در حال طراحی یا ارتقای بخش شمارش بازدید و اکشن‌ها هستید، پیشنهاد می‌کنم این گزینه‌ها را نیز بررسی کنید.

#DataEngineering #StreamingData #RealTimeAnalytics #Kafka #Flink #Iceberg #ClickHouse #RisingWave #ScyllaDB #BigData #UserAnalytics #TechInnovation #RustLang #SQL

‍ آغاز به کار رسمی مدرسه مهندسی داده سپهرام

با افتخار اعلام می‌کنم که وب‌سایت https://sepahram.ir به عنوان اولین مدرسه کاربردی مهندسی داده در ایران راه‌اندازی شد. هدف ما ارائه آموزش‌های عملی و پروژه‌محور در حوزه #مهندسی_داده برای جامعه فارسی‌زبان است.

🔰 شروع فعالیت مدرسه با برگزاری دوره نوین:
✨ مبانی مهندسی داده ✨


در این دوره، مفاهیم پایه و ابزارهای اصلی مهندسی داده به شکلی کاملاً عملی آموزش داده می‌شود، شامل:

🗄 پایگاه داده‌ها و طراحی اولیه با #PostgreSQL

🛠 آشنایی با #Airflow برای مدیریت و زمان‌بندی جریان‌های داده

⚡️ پردازش داده‌های عظیم با #ApacheSpark

🔄 پردازش جریان‌های داده در #Kafka

📊 آشنایی عملیاتی با #ClickHouse برای تحلیل سریع و بلادرنگ داده‌ها

🧊 کار با #ApacheIceberg به عنوان نسل جدید فرمت‌های جدولی و مدیریت داده در مقیاس بزرگ


🎯 برای تضمین یادگیری گام‌به‌گام و مؤثر:

- هر درس شامل چند آزمون کوتاه و مفهومی است.

- برای دریافت گواهینامه پایان دوره، انجام و تحویل یک پروژه عملی و کاربردی الزامی است. جزئیات این پروژه در صفحه دوره ذکر شده است.


💬 در صورت بروز مشکل در مسیر آموزشی یا هنگام انجام آزمون‌ها، می‌توانید از طریق پیام‌رسان‌های تلگرام، واتساپ یا بله با حساب پشتیبانی مدرسه مهندسی داده سپهرام در ارتباط باشید:

📌 شناسه پشتیبانی: @sepahram_ir

🙌 به عنوان موسس و مدرس اصلی این مدرسه، امیدوارم سپهرام گامی مؤثر در جهت توانمندسازی جامعه فارسی‌زبان در مسیر حرفه‌ای مهندسی داده باشد.

🔗 جزئیات بیشتر و ثبت‌نام:

https://sepahram.ir/courses/intro-to-data-engineering

کانال رسمی سپهرام :

https://t.iss.one/sepahram_school

‍ وقتی شمارش دقیق خیلی گرون میشه: HyperLogLog 🔢

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

✅چند کاربر یکتا در سایت بوده‌اند؟

✅چند IP مختلف به API ما وصل شده‌اند؟

✅چند محصول متفاوت در یک بازه دیده شده؟

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

اما در دیتابیس‌های توزیع‌شده، این یعنی انفجار حافظه و فشار شدید روی شبکه.

برای همین سراغ ساختارهای داده‌ی «تقریبی» می‌رویم که با مصرف کم حافظه، جواب نزدیک به درست بدهند. یکی از معروف‌ترین‌ها: #HyperLogLog.


🎲 مثال با تاس: رخدادهای نادر

فرض کن کسی مدام تاس می‌ریزد. تو نمی‌دانی چند بار تاس انداخته، فقط نتایج را می‌بینی.

🔹 اگه فقط یک بار ۶ آمد → عادی است.

🔹 اگه دو بار پشت سر هم ۶ آمد → کمی نادرتر.

🔹 اگه چهار بار پشت سر هم ۶ آمد → خیلی خیلی نادر.

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


🔑 ارتباط با #HyperLogLog

حالا این ایده را می‌بریم به دنیای هش:

📌هر آیتم (مثل IP یا UserID) را هش می‌کنیم → یک رشته‌ی طولانی صفر و یک.

📌به ابتدای این رشته نگاه می‌کنیم: چند صفر پشت سر هم آمده؟

📌هرچه صفرهای بیشتری پشت سر هم باشد، اتفاق نادرتر است → پس احتمالاً داده‌های یکتای زیادی وارد شده‌اند.

📌در نسخه‌ی ساده‌ی الگوریتم، همیشه بیشترین تعداد صفر دیده‌شده را نگه می‌داریم.

مثلاً اگر حداکثر ۶ صفر دیده‌ایم، می‌گوییم:

تقریباً 6^2 = 64 آیتم یکتا داشته‌ایم. (بر اساس فرمول‌های آماری)


🚨 ایراد نسخه‌ی ساده

این روش یک اشکال بزرگ دارد:

اگر همان اوّل کار شانسی هشی بیاید با ۲۰ صفر پشت سر هم، الگوریتم می‌گوید: «اینجا باید حدود یک میلیون آیتم یکتا دیده شده باشد!»

در حالی که شاید فقط ۱۰ آیتم وارد شده‌اند.

مثل این است که دفعه‌ی اوّل ۴ تا شش پشت سر هم بیاید و ما فکر کنیم هزار بار تاس ریخته‌ایم!



🪣 راه‌حل: باکتینگ

برای حل این مشکل، #HyperLogLog واقعی از باکت‌ها استفاده می‌کند:

🎯چند بیت اول هش → تعیین می‌کند آیتم در کدام باکت قرار بگیرد.

🎯بقیه بیت‌ها → برای شمردن تعداد صفرهای ابتدای رشته استفاده می‌شود.

🎯در هر باکت، فقط «بیشترین تعداد صفر» ذخیره می‌شود.

🎯در پایان، الگوریتم همه باکت‌ها را با هم ترکیب می‌کند (با میانگین هارمونیک + اصلاح خطا).

به این ترتیب، یک رخداد نادر شانسی نمی‌تواند کل تخمین را خراب کند.


🏗 کجاها استفاده می‌شود؟

الگوریتم شمارش #HyperLogLog امروز در خیلی از دیتابیس‌ها و ابزارهای بزرگ به‌کار می‌رود:

🧩ردیس → دستورات PFADD و PFCOUNT برای شمارش یکتاها

🧩بیگ‌کوئری→ پشت APPROX_COUNT_DISTINCT

🧩ترینو/Presto و #ClickHouse → توابع شمارش تقریبی

🧩اسپارک و #Snowflake → در approx_count_distinct

🧩و حتی سیستم‌هایی مثل Cassandra / ScyllaDB که برای کم کردن بار IO از ساختارهای مشابه استفاده می‌کنند

✨ خلاصه اینکه:

الگوریتم HyperLogLog به‌جای شمردن دقیق، «حدس تقریبی اما پایدار» می‌زند؛ و همین باعث شده در مقیاس وب و دیتای عظیم، تبدیل به یک ابزار استاندارد شود.


کانال مدرسه مهندسی داده سپهرام: @sepahram_school

‍ جلسه اول دوره ClickHouse در مدرسه مهندسی داده سپهرام برگزار شد و فیلم بخش نصب و راه‌اندازی و شروع به کار با ClickHouse اکنون در یوتیوب و صفحه درس دوره منتشر شده است.

دوستانی که تاکنون فرصت نصب و کار کردن با ClickHouse را نداشته‌اند اما علاقه دارند با این دیتابیس پرقدرت و سریع تحلیلی آشنا شوند، می‌توانند در یک جلسه کوتاه نیم‌ساعته به صورت عملی کار با آن را تجربه کنند.

در این ویدئو خواهید دید:

ـ نصب ClickHouse روی ویندوز با استفاده از WSL

ـ راه‌اندازی سرور و اتصال اولیه

ـ کار با محیط clickhouse-client

ـ ایجاد دیتابیس و جداول اولیه برای شروع کار



📺 مشاهده ویدئوی جلسه اول:

👉 https://www.youtube.com/watch?v=gGpSbMpfAiM

برای دیدن بخش دوم و ادامه ویدئوهای آموزشی به آدرس زیر مراجعه کنید:

👉 https://sepahram.ir/courses/clickhouse-201/

#ClickHouse #DataEngineering #BigData #Analytics #OLAP #HandsOn


کانال تلگرام سپهرام : @sepahram_school

آپاچی دوریس و سرعت بالا در سناریوهای مبتنی بر JOIN
- توضیحی راجع به pdf بالا ـ
اخیراً گزارشی از سمت VeloDB (Powered by Apache Doris) منتشر شد که در آن، عملکرد Apache Doris و ClickHouse در سناریوهای سنگین مبتنی بر JOIN و کوئری‌های تحلیلی پیچیده با هم مقایسه شده‌اند.

من این گزارش را اینجا بازنشر می‌کنم تا برای دوستانی که به دنبال یک راهکار تحلیلی سریع و مشابه دنیای دیتابیس‌های رابطه‌ای هستند، مفید باشد. به‌ویژه برای کسانی که نیاز به تضمین یکتایی کلید اصلی و اجرای JOINهای متعدد دارند، اما امکان ایجاد جداول denormalized در ClickHouse برایشان مقدور نیست.


در همین زمینه، تجربه اخیر اسنپ‌فود با StarRocks (که رضا دهقانی در پست زیر به آن اشاره کرده بود) هم نشان می‌دهد که انتخاب دیتابیس تحلیلی تصمیمی وابسته به نیازها و شرایط سازمان است و یک پاسخ واحد برای همه سناریوها وجود ندارد.
https://lnkd.in/dvc76Dxa

خلاصه عملکرد (Benchmark Results)

در تست‌ها مشخص شد که در سناریوی CoffeeBench (که به شدت بر JOIN متکی است)، Doris حدود ۴ برابر سریع‌تر از ClickHouse عمل کرده است. در مجموعه تست‌های TPC-H که بار تحلیلی پیچیده‌تری دارند، سرعت Doris تا ۳۰ برابر بیشتر گزارش شد. و در نهایت در سناریوهای سنگین‌تر TPC-DS، Doris تا ۴۰ برابر سریع‌تر از ClickHouse نتیجه گرفت.

⚙️ مشخصات تست (Test Config):

- 2 × AWS m6i.8xlarge (هرکدام 32 vCPU و 128GiB RAM)

- Apache Doris v3.0.7 در برابر ClickHouse v25.8

- On-premises


📌 لازم به ذکر است که CoffeeBench در ابتدا توسط Josue “Josh” Bogran برای مقایسه Databricks و Snowflake طراحی شده بود، اما به دلیل ماهیت JOIN-heavy خود، اکنون به یکی از معیارهای پرکاربرد برای سنجش دیتابیس‌های تحلیلی تبدیل شده است.

#doris #starrocks #clickhouse

‍ وقتی Excel به ClickHouse متصل می‌شود
در سال‌های اخیر، با رشد تصاعدی حجم داده در شرکت‌های بزرگ ایرانی، زیرساخت‌های سنتی مانند Oracle و SQL Server که سال‌ها نقش ستون فقرات ذخیره‌سازی داده‌ها را داشتند، دیگر پاسخ‌گوی نیازهای تحلیلی جدید نیستند. بسیاری از این سازمان‌ها در گزارش‌گیری و تحلیل داده‌های حجیم دچار کندی محسوس شده‌اند.
در نتیجه، تمایل به سمت استفاده از دیتابیس‌های تحلیلی نوین مانند hashtag#ClickHouse و hashtag#StarRocks افزایش یافته است، فناوری‌هایی که با معماری columnar و توان پردازشی بالا، به‌خوبی برای تحلیل‌های سنگین و بلادرنگ طراحی شده‌اند.
در یکی از مشاوره‌های اخیرم با یکی از فروشگاه‌های زنجیره‌ای بزرگ کشور، در حال بررسی #ClickHouse برای ذخیره و سرویس‌دهی تراکنش‌های روزانه هستیم.

🔥اما چالش اصلی این بود که تیم فنی و کاربران نهایی سال‌ها با استک مایکروسافت کار کرده بودند؛ بیشتر گزارش‌ها از طریق Excel و با استفاده از SSAS و Power Pivot تولید می‌شد. بنابراین به دنبال راهکاری بودیم که بدون تغییر اساسی در محیط گزارش‌گیری کاربران، بتوان از ClickHouse نیز بهره برد.
در این مسیر، به دنبال یک ROLAP Engine بودیم که از MDX پشتیبانی کند و به پروژه‌ای جالب به نام eMondrian رسیدیم.

🔰 پروژه eMondrian در واقع نسخه‌ای توسعه‌یافته از Mondrian OLAP Engine است که امکان اتصال به دیتابیس‌های مدرن از جمله ClickHouse را فراهم می‌کند. با این ابزار می‌توان:
✔️همان مدل چند‌بعدی (Cube) را روی داده‌های ClickHouse تعریف کرد،
✔️همچنان از MDX Query‌ها استفاده نمود،
✔️و حتی گزارش‌ها را مستقیماً از طریق Excel یا Power BI به‌صورت Live Connection مشاهده کرد.
در تست‌های اولیه، سرعت اجرای کوئری‌ها روی داده‌های چندصدمیلیونی بسیار قابل‌قبول بود و ساختار XML‌-محور schema نیز اجازه تعریف دقیق ابعاد و اندازه‌ها را می‌دهد. تنها نکته مهم، نیاز به دقت در طراحی schema است، چرا که برخلاف SSAS در اینجا خبری از Wizard نیست.

✅ مزیت اصلی eMondrian
راه‌حل کم‌هزینه و سریع برای «نگه داشتن لایهٔ گزارش‌گیری فعلی (Excel/MDX)» و در عین حال انتقال داده‌ها به ClickHouse؛ مخصوصاً مناسب برای مهاجرت تدریجی و جلوگیری از بازنویسی کامل داشبوردها.

ریسک‌ها / محدودیت‌ها:
🔴قابلیت‌های کامل SSAS را ندارد، برخی امکانات پیشرفته ممکن است موجود نباشند یا متفاوت اجرا شوند.

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

🔴پروژه هنوز وابسته به به‌روزرسانی‌ها و رفع باگ‌هاست؛ ممکن است نیاز به توسعه یا patch محلی باشد.

🔴طراحی schema و tune کردن ClickHouse برای عملکرد مطلوب حیاتی است، بدون این، ممکن است سرعت یا مصرف منابع مشکل‌ساز شود.

🔴سازگاری کامل با همه نسخه‌های Excel/Power BI سرویس ممکن نیست، بعضی ابزارها رفتار متفاوتی دارند.

در حال حاضر دو نسخه از این موتور موجود است:
🔹 نسخه اصلی Pentaho Mondrian که سال‌هاست در پروژه‌های BI استفاده می‌شود،
🔹 و نسخه توسعه‌یافته eMondrian که برای اتصال به دیتابیس‌های مدرن مانند ClickHouse بهینه‌سازی شده است.
ما در حال تست نسخه دوم هستیم که برای ClickHouse مناسب‌تر است.
اگر تجربه‌ای در استفاده از Mondrian یا eMondrian دارید، به‌ویژه در ترکیب با ClickHouse، خوشحال می‌شویم از تجربه شما هم بتوانیم استفاده کنیم 🙌

‍ چرا 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 همچنان پادشاه است.