‍ نقشه راه Data 3.0 در عصر Lakehouse

خلاصه‌ای از گزارش Bessemer Venture Partners که معماری لیک‌هوس را در دوران مدرن، بسیار آینده‌دار دانسته است. بیایید آنرا با هم مرور کنیم.

📌 https://www.bvp.com/atlas/roadmap-data-3-0-in-the-lakehouse-era

شرکت سرمایه‌گذاری Bessemer Venture Partners (BVP) که سابقه‌ای بیش از یک قرن در حمایت از شرکت‌های نوآور در حوزه‌های ابری، فین‌تک، 🤖 هوش مصنوعی و 🛡 امنیت سایبری دارد، اخیراً گزارشی با عنوان «نقشه راه: Data 3.0 در عصر #Lakehouse» منتشر کرده است. این گزارش با تکیه بر تجربه BVP در سرمایه‌گذاری بر برندهایی مانند Shopify، LinkedIn، Pinterest و Databricks، چشم‌اندازی دقیق از نسل سوم زیرساخت‌های داده ارائه می‌دهد.

🔍 چرا Data 3.0 اهمیت دارد؟

مدیریت داده‌ها طی سه نسل دستخوش تحولات عظیمی شده است:

📦 نسخه اول - Data 1.0 (۱۹۷۰–۲۰۰۰):

✅ تمرکز بر پایگاه‌های داده رابطه‌ای (Oracle، MySQL)

✅ استفاده از انبارهای داده‌ای

❌ محدودیت در مقیاس‌پذیری

❌ ناتوان در پردازش داده‌های غیرساختاریافته

🌊 نسخه دوم - Data 2.0 (از ۲۰۱۰ به بعد):

✅ ظهور Hadoop و Spark برای پردازش داده‌های متنوع و حجیم

✅ انعطاف‌پذیری بیشتر

❌ باتلاق داده‌ای (Data Swamp) به‌دلیل ضعف در کیفیت و حاکمیت

🚀 نسخه سوم - Data 3.0 (از ۲۰۲۰ به بعد):

✅ یکپارچگی

✅ پردازش لحظه‌ای

✅ استفاده از هوش مصنوعی

📌 ابزارهای کلیدی: Lakehouse، Delta Lake، Iceberg، Hudi، خطوط لوله AI-driven


💡 معماری Lakehouse چیست و چرا انقلابی است؟

لیک‌هوس ترکیبی از قدرت Data Warehouse و انعطاف Data Lake است.

ویژگی‌های کلیدی:

📌 پشتیبانی از داده‌های ساختاریافته و غیرساختاریافته

📌 فرمت‌های باز با قابلیت‌های ACID، Time Travel، پردازش لحظه‌ای

📌 کاهش افزونگی داده و وابستگی به Vendorها

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


🔮 چهار روند کلیدی در Data 3.0 به روایت BVP

1️⃣ خطوط لوله هوشمند و لحظه‌ای

🛠 ابزارهای جدید: Prefect، Windmill، dltHub

⚙️ فناوری‌های جریانی: Apache Flink، Kafka

⚡️ پلتفرم‌های بلادرنگ مانند Chalk برای تصمیم‌گیری سریع


2️⃣ متادیتا به‌عنوان منبع حقیقت

🛠 ابزارهایی مانند Datastrato، Acryl Data

💡 بهینه‌سازهایی مثل Flarion.io و Greybeam


3️⃣ تحول در موتورهای محاسباتی:

🛠 موتورهای سبک و سریع: DuckDB، ClickHouse، Daft

🌕 بسترهای Iceberg-native مثل Mooncake و Bauplan و RisingWave


4️⃣ ادغام مهندسی داده و نرم‌افزار:

🧩 ابزارهایی مانند dbt و Gable

🔄 یکپارچه‌سازی با CI/CD، نسخه‌سازی، تست خودکار


💸 فرصت‌های سرمایه‌گذاری و نوآوری

BVP باور دارد که Data 3.0 فرصت بی‌سابقه‌ای برای بنیان‌گذاران ایجاد کرده تا:

🔧 ابزارهای منبع‌باز و ابری جدید بسازند

🚀 موتورهای بهینه‌شده برای AI ارائه دهند

📊 راه‌حل‌های هوشمند برای متادیتا خلق کنند


📌 جمع‌بندی : معماری Lakehouse نماد تحول در مدیریت داده‌هاست:

✔️ عملکرد بالا

✔️ تحلیل لحظه‌ای

✔️ پشتیبانی از AI

✔️ مقیاس‌پذیری بالا

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

🏷 #Data3 #Lakehouse #AI #Metadata #StreamingData #DuckDB #Iceberg #DeltaLake #BVP #DataEngineering #ModernDataStack #RealTimeAnalytics #OpenSource #DataInfra #Startup #DataPlatform #VentureCapital #FutureOfData

چطور تسلا با 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

‍ الگوی Outbox و داستان یک راهکار هوشمندانه در پستگرس

اخیراً مقاله‌ای از صادق دوستی در Dev.to خواندم که نشان داد با تجربه و تسلط، می‌توان برای چالش‌های بزرگ، راه‌حل‌هایی هوشمندانه و ساده پیدا کرد. یعنی در دنیای فنی، گاهی غرق پیچیدگی‌ها می‌شویم و راه‌حل‌های ساده اما عمیق را نادیده می‌گیریم. این پست ادای دینی است به صادق عزیز Sadeq Dousti و مقالات ارزشمندش، و مروری بر مشکل پیاده‌سازی الگوی Outbox با PostgreSQL در حجم بالای داده و راه‌حلی خلاقانه برای آن.

https://dev.to/msdousti/postgresql-outbox-pattern-revamped-part-1-3lai/



🎯 الگوی Outbox چیست؟

در یک فروشگاه آنلاین، ثبت سفارش باید چند کار را انجام دهد:

✅ذخیره در پایگاه داده

✅ارسال ایمیل تأیید

✅به‌روزرسانی موجودی

✅اطلاع به واحد ارسال

این اکشن‌ها به بروکرهایی مثل Kafka ارسال می‌شوند تا هر واحد کار خود را انجام دهد.

❓ اگر ارسال پیام به بروکر با خطا مواجه شود؟

Outbox وارد می‌شود! سفارش در پایگاه داده ذخیره شده و یک پیام در جدول Outbox ثبت می‌شود. یک سرویس جداگانه پیام‌ها را خوانده و به بروکر می‌فرستد. در صورت خطا، پیام در جدول باقی می‌ماند تا دوباره برای پردازش ارسال شود اما ...



🔍 چالش: حجم بالای داده‌ها

با افزایش پیام‌ها در Outbox:

⚠️کوئری‌های خواندن پیام‌های منتشرنشده کند می‌شوند.

⚠️ایندکس‌ها به دلیل آپدیت‌های مکرر غیربهینه می‌شوند.

⚠️مصرف منابع سیستم افزایش می‌یابد.



💡 راه‌حل: پارتیشن‌بندی هوشمند

صادق دوستی پیشنهاد می‌کند جدول Outbox را به دو پارتیشن تقسیم کنیم:

outbox_unpublished: پیام‌های منتشرنشده (published_at IS NULL)

outbox_published: پیام‌های منتشرشده (published_at NOT NULL)

با این کار، پیام‌های جدید به outbox_unpublished می‌روند و پس از انتشار، به‌صورت خودکار به outbox_published منتقل می‌شوند. بنابراین کوئری‌ها فقط روی پارتیشن سبک‌تر اجرا می‌شوند.



🎉 مزایا:

✅سرعت بالا: کوئری‌ها روی پارتیشن کوچک‌تر اجرا می‌شوند.

✅مدیریت آسان: حذف پیام‌های قدیمی با TRUNCATE سریع است.

✅بهینه‌سازی منابع: ایندکس‌ها کوچک و کارآمد می‌مانند.



🏁 جمع‌بندی

الگوی Outbox برای هماهنگی سیستم‌های توزیع‌شده عالی است، اما پیاده‌سازی نادرست آن مشکل‌ساز می‌شود. پارتیشن‌بندی هوشمند صادق دوستی این الگو را بهینه‌تر و سریع‌تر می‌کند.

🔗 برای جزئیات بیشتر، حتا مقاله صادق در Dev.to را بخوانید!

#outbox #postgres #performance #database #dataengineering

#مهندسی_داده

‍ معرفی رسمی 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

‍ پردازش ۱.۲ میلیون پیام در ثانیه با Kafka و Go — معماری سبک اما حرفه‌ای 🎯
وقتی نرخ ورود داده به میلیون‌ها پیام در ثانیه می‌رسد، عامل تعیین‌کننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینه‌ی سخت‌افزار است و نه تکیه بر زیرساخت‌های سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که می‌تواند تفاوت واقعی را رقم بزند.
📖 اخیراً با مقاله‌ای مواجه شدم که دقیقاً همین رویکرد را نشان می‌داد: تیمی که با استفاده از مفاهیم سبک‌وزن مانند goroutine در Go و چند تصمیم مهندسی‌شده، توانسته بودند تنها با یک سخت‌افزار معمولی، بیش از ۱ میلیون پیام در ثانیه را به‌صورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار می‌پردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستم‌های توزیع‌شده.
📄 مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup 👉 https://freedium.cfd/https://medium.com/@harishsingh8529/kafka-at-1m-messages-second-with-go-our-exact-pipeline-setup-aa2c5473b139

📦 چالش‌ها:
⚠️هجوم سنگین داده‌ها از دستگاه‌های IoT و کاربران
⚠️نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
⚠️تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا

🛠 مکانیزم‌هایی که این معماری را ممکن کردند:
✅ کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام می‌شود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گم‌شدن یا پردازش تکراری داده‌ها.
✅ مکانیزم Worker Pool کنترل‌شده با goroutine:
به‌جای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیام‌ها را موازی اما کنترل‌شده پردازش می‌کنند.
✅ یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون هم‌پوشانی، بدون رقابت اضافه.
✅ الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
✅ دسته بندی پیام ها یا Batching در ارسال خروجی:
پیام‌های پردازش‌شده به‌صورت گروهی ارسال می‌شوند، مثلاً به دیتابیس یا تاپیک‌های دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
✅مکانیزم Backpressure هوشمند:
با محدود کردن ظرفیت صف‌ها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف می‌شود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه می‌دارد.
✅مانیتورینگ دقیق با Prometheus و Grafana:
شاخص‌هایی مثل تأخیر پردازش، consumer lag و مصرف CPU به‌صورت لحظه‌ای مانیتور می‌شوند — برای تنظیم سریع و واکنش فوری.

📊 نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیش‌بینی)

💡 نکات مهم برای مهندسان داده و سیستم‌های توزیع‌شده:
🔹طراحی درست مهم‌تر از افزایش منابع
🔹 طراحی commit دقیق، batching و backpressure = ستون‌های یک سیستم مقاوم
🔹تفکیک دریافت/پردازش + تقسیم کار بین پارتیشن‌ها = مقیاس‌پذیری مؤثر
🔹مانیتورینگ لحظه‌ای = پاسخ سریع به فشارها و خطاها

#Kafka #GoLang #DataEngineering #HighThroughput #Concurrency #RealTime #ScalableArchitecture #مهندسی_داده #سیستم_توزیع_یافته #معماری_مقیاس‌پذیر

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

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

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

‍ معرفی Kedro 1.0 — فریمورکی حرفه‌ای برای ساخت پروژه‌های داده‌ای و هوش مصنوعی 🚀

در دنیای پیچیده داده و یادگیری ماشین، مدیریت پروژه‌های داده‌ای با کدهای پراکنده و مراحل متعدد چالش بزرگی است. Kedro با ارائه ساختاری منظم، به شما کمک می‌کند تا پروژه‌های خود را قابل توسعه، قابل تکرار و قابل اعتماد بسازید.

🔍 چالش اصلی:

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

Kedro این مشکلات را اینطور حل می‌کند:

📂 تقسیم پروژه به بخش‌های مستقل و قابل مدیریت

🔄 تعریف دقیق و قابل تکرار جریان‌های کاری (Pipeline)

📚 مدیریت داده‌ها در یک سیستم منسجم به نام DataCatalog

🤝 استانداردسازی برای همکاری آسان‌تر تیمی

📊 ابزارهای بصری برای مشاهده و مدیریت اجرای پروژه

⚙️ امکان توسعه و سازگاری با ابزارهای مختلف

💡 ویژگی‌های کلیدی Kedro 1.0:

نسخه ۱.۰ با بهبودهای فراوانی به شما قدرت می‌دهد تا پروژه‌های پیچیده را با اعتماد اجرا کنید و سریع‌تر توسعه دهید:

🔄 DataCatalog بازطراحی شده: مدیریت داده‌ها به شکلی ساده‌تر و قوی‌تر

🧩 بهبود فضای نام (Namespace): گروه‌بندی و استفاده انعطاف‌پذیرتر داده‌ها

🚀 بهبود رانرها: اجرای بهتر و پایدارتر جریان‌های کاری

📚 مستندات نوین: راهنمایی آسان و به‌روز برای شروع سریع

👁‍🗨 نمایش وضعیت خط لوله در Kedro Viz: نظارت بصری بر اجرای پروژه

🤖 آماده برای هوش مصنوعی نسل جدید: پشتیبانی از جریان‌های کاری پیشرفته و AI مولد

👥 چه کسانی باید از Kedro استفاده کنند؟

- دانشمندان داده و مهندسان یادگیری ماشین که دنبال کدی قابل بازتولید و سازمان‌یافته هستند

- مهندسان داده که خطوط لوله داده‌ای پیچیده می‌سازند و مدیریت می‌کنند

- تیم‌ها و سازمان‌هایی که می‌خواهند همکاری و هماهنگی پروژه‌های داده‌ای‌شان را بهبود دهند

- کسانی که وارد حوزه هوش مصنوعی مولد و پروژه‌های نوین داده‌ای می‌شوند


🌟 چرا Kedro 1.0 را انتخاب کنیم؟

با Kedro، پروژه‌های داده‌ای خود را به سطحی کاملاً حرفه‌ای می‌برید:

کدی منظم، قابل تست و مقیاس‌پذیر دارید که به رشد و تغییر پروژه کمک می‌کند و کار تیمی را ساده‌تر می‌کند.

📥 همین امروز شروع کنید!

Kedro ساده نصب می‌شود و جامعه بزرگی پشت آن است.

برای اطلاعات بیشتر و دریافت مستندات به kedro.org مراجعه کنید.

خلاصه در یک نگاه:

📂 ساختاردهی ماژولار پروژه‌ها

🔄 تعریف و مدیریت جریان‌های کاری

📚 DataCatalog پیشرفته

🤝 تسهیل همکاری تیمی

📊 ابزارهای نظارتی و بصری

⚙️ توسعه‌پذیری و سازگاری با ابزارهای نوین

🤖 آماده برای چالش‌های آینده AI

#Kedro #DataScience #MachineLearning #DataEngineering #AI #OpenSource #Python #DataPipeline #MLOps #GenerativeAI

چهارسال پیش هم این پروژه را در سایت مهندسی داده معرفی کردیم :‌

https://lnkd.in/dbn5pBFH

‍ جلسه اول دوره 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

‍ تجربه استفاده از StarRocks در تیم دیتای اسنپ
پست رضا دهقانی در لینکدین

تجربه کار با StarRocks

تو پروژه‌های کاری دنبال یه راه‌حل بودیم که بتونیم داده‌هامون رو همزمان سریع و از منابع مختلف تحلیل کنیم. بعد از بررسی ابزارهای مختلف، StarRocks رو انتخاب کردم و تجربه واقعاً متفاوت و جالبی بود

.

💡 چرا StarRocks؟
استارراکس خودش رو یه دیتاوروس نسل جدید معرفی میکنه که میتونه داده‌ها رو هم بلادرنگ (Real-time) و هم Batch پردازش کنه. بدون نیاز به انتقال داده، میشه مستقیم روی Data Lake کوئری زد و با ابزارهای معمول مثل MySQL Client یا BI Tools وصل شد.

✨ تجربه شخصی من:

✅ اتصال به Iceberg خیلی خوب پشتیبانی میشه و کوئری‌ها روان اجرا میشن. کش دیتای قوی باعث میشه سرعت برخی کوئری‌ها حتی روی دیتالیک بالا باشه. این بخش تو هر نسخه جدید بهبود پیدا میکنه.

✅ جوین‌های پیچیده رو در زمان معقول اجرا میکنه بدون نیاز به تغییر ساختار داده‌ها. این قابلیت تو مدل‌سازی داده خیلی کمک کننده بود.

✅ قابلیت  Materialized View به صورت Async: میشه روی دیتالیک یا هر منبع داده دیگه زمان‌بندی مشخص داد. پشتیبانی از Incremental Refresh هم داره، یعنی لازم نیست کل ویو دوباره پردازش بشه.

✅ سازگاری با Kafka و Spark: امکان خوندن و نوشتن دیتا به صورت Batch، که تو پردازش‌های ما خیلی کمک کرد.


⚠️ چالش‌ها و نکات منفی:

«بهش میگم ابزار زیبا با طراحی زشت 😅»

❌ دیپلوی کلاستر خوب مستند نشده و بعضی مواقع نیاز به تغییرات دستی داره.

❌ کانفیگ‌های زیاد: از یه زاویه خوبه ولی میتونه گیج‌کننده باشه. مقادیر پیشفرض بعضاً بهینه نیستن.

❌ امنیت هنوز جای کار داره. بعضی تنظیمات پیشفرض باز هستن، ولی سازگاری با LDAP و متدهای احراز هویت خوبه و با کمی تنظیمات قابل اصلاحه.

منبع :
https://www.linkedin.com/posts/reza-dehghani-572b3b154_dataengineering-starrocks-lakehouse-activity-7375817395812257793-B-J-

آپاچی دوریس و سرعت بالا در سناریوهای مبتنی بر 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

‍ از Postgres تا Lakehouse زنده در کمتر از یک ثانیه -  نگاهی به Mooncake و استراتژی جسورانه Databricks

مدت‌ها بود که پروژه Pg_mooncake رو زیر نظر داشتم تا ببینم کی به مرحله نهایی می‌رسه ،  پروژه‌ای نوآور که می‌خواست Postgres رو با Iceberg ترکیب کنه و داده‌های تحلیلی و عملیاتی رو روی یک پایه مشترک بیاره.

و حالا… دیدم که Databricks این تیم خلاق رو هم خریداری کرده! درست مثل خرید قبلی‌شون یعنی Neon (نسخه‌ی cloud-native از Postgres).

لینک خبر :
https://www.linkedin.com/posts/databricks_were-excited-to-announce-that-databricks-activity-7379138538652696576-2pbr

به‌نظر می‌رسه دیتابریکز داره با قدرت وارد فضای Lakehouse + OLTP + AI می‌شه.  چیزی که خودشون اسمش رو گذاشتن Lakebase؛ پایگاه‌داده‌ای مبتنی بر Postgres که برای Agentهای هوش مصنوعی بهینه‌سازی شده و عملاً نیاز به ETL رو از بین می‌بره.

💡 اما Mooncake دقیقاً چی بود و چرا مهمه؟

به زبان ساده، Mooncake کمک می‌کنه داده‌هایی که در Postgres ذخیره می‌شن به کمک یک افزونه پستگرس که با rust نوشته شده، تقریباً بلافاصله و بدون نیاز به ابزارهای پیچیده، داخل یک لیک‌هوس با فرمت آیس‌برگ یا دلتا ذخیره شده و برای تحلیل و گزارش های سنگین با انواع کوئری انجین ها مثل ترینو، استارراکز، اسپارک و حتی کلیک‌هوس آماده بشن.
با ترکیب Postgres و Iceberg و با استفاده از امکانات خود mooncake:

🔰 داده‌ها به‌صورت زنده (real-time) همگام می‌شن حتی با آپدیت و حذف
🔰 تحلیل‌ها با کمک DuckDB سریع انجام می‌شن،
🔰 و همه‌چی بدون پیچیدگی ETL یا کپی‌کاری، در همون لحظه قابل استفاده‌ست.

یه جور پل بین ذخیره‌سازی عملیاتی و تحلیل زنده‌ست - دقیقاً همون چیزی که خیلی از شرکت‌ها مدت‌هاست دنبالش بودن.


🎯 واقعاً مشخص نیست دقیقاً چه استراتژی‌ بزرگی پشت این خریدهاست، اما چیزی که واضحه اینه که Databricks داره آینده پایگاه‌های داده Postgres-محور رو با هوش مصنوعی و تحلیل real-time بازتعریف می‌کنه.

👋 به تیم Mooncake تبریک می‌گم، و مشتاقم ببینم در ادامه چه اتفاقات بزرگی رقم می‌زنن!

شروع رسمی دوره پستگرس کاربردی در مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses/

#Databricks #Mooncake #Postgres #Iceberg #Lakehouse #OLTP #AI #Lakebase #DataEngineering #OpenSourc

‍ دو منبع عالی برای یادگیری سریع و عمیق Airflow 3 📚

چند ماه از انتشار رسمی Airflow 3 می‌گذرد و حالا وقت آن است که ببینیم دقیقاً چه چیزهایی تغییر کرده و چرا این نسخه نقطه عطف مهمی در مسیر این پلتفرم محبوب مدیریت جریان کاری داده (workflow orchestration) محسوب می‌شود.

در این نوشته می‌خواهیم دو منبع فوق‌العاده را معرفی کنیم که به‌جای خواندن ده‌ها صفحه مستندات یا تماشای ویدیوهای پراکنده، شما را مستقیم و مؤثر به قلب Airflow 3 می‌برند.
گاهی برای درک عمیق‌تر و تجربه‌ی واقعی، باید سراغ منابعی رفت که با نگاه حرفه‌ای نوشته شده‌اند - منابعی که نه‌تنها توضیح می‌دهند چطور کار می‌کند، بلکه کمک می‌کنند در عمل بهتر بسازید.

حالا که چند ماه از انتشار نسخه ۳ می‌گذرد، اگر هنوز با نسخه ۲ کار می‌کنید، باید بدانید از خیلی از قابلیت‌های جدید و بهینه‌سازی‌های Airflow 3 بی‌نصیب مانده‌اید.

دو منبع زیر بهترین نقطه‌ی شروع برای درک تفاوت‌ها و یادگیری عملی نسخه ۳ هستند 👇

1️⃣ جزوه مروری بر امکانات ایرفلو ۳ از Astronomer

یک مرور سریع و فشرده (حدود ۹ صفحه) از همه‌ی قابلیت‌های جدید Airflow 3 - ایده‌آل برای کسانی که می‌خواهند در چند دقیقه بفهمند دقیقاً چه تغییراتی در انتظارشان است. البته با این پیش‌فرض که با ایرفلو قبلا آشنا هستید.

2️⃣ کتاب Practical Guide to Apache Airflow 3 از Manning

اگر می‌خواهید با Airflow 3 به‌صورت واقعی و پروژه‌محور کار کنید، این کتاب انتخاب فوق‌العاده‌ای است.

از ساخت اولین pipeline تا معماری جدید، UI به‌روز، نسخه‌بندی DAGها و حتی اجرای inference با OpenAI - همه‌چیز در قالب مثال‌های عملی و توضیحات تصویری ارائه شده است آنهم در ۱۴۰ صفحه، مفید و مختصر

📘 فهرست فصل‌ها در یک نگاه:

✅آشنایی با Airflow 3

✅ساخت اولین pipeline

✅قابلیت اطمینان و زمان‌بندی

✅ واسط کاربری جدید و DAG Versioning

✅معماری داخلی نسخه ۳

✅حرکت به محیط Production

✅اجرای inference

✅مهاجرت از نسخه ۲

✅آینده Airflow


💡 اگر به دنبال یادگیری جدی نسخه ۳ و امکانات جذاب و کاربردی آن هستید:

✨ با جزوه Astronomer شروع کنید تا دید کلی بگیرید،

✨ و سپس با کتاب Manning جلو بروید تا Airflow 3 را به‌صورت عملی و حرفه‌ای تجربه کنید.

برای دانلود این دو pdf به دو پست قبلی، مراجعه کنید. 👆👆👆

کانال مدرسه مهندسی داده سپَهرام : آموزش‌های تخصصی مهندسی داده : @sepahram_school

#ApacheAirflow #DataEngineering #ETL #WorkflowAutomation #ManningBooks #Astronomer #OpenAI #Airflow3 #DataOps

‍ وقتی Kafka ساده‌تر، سریع‌تر و سبک‌تر می‌شود: آشنایی با Redpanda در دوره تخصصی کافکا 🎥

در بخش تازه‌ای از دوره آموزش تخصصی کافکا در مدرسه مهندسی داده سپهرام، با یکی از جایگزین‌های قدرتمند و مدرن Kafka یعنی Redpanda آشنا می‌شویم.

در این ویدیو که به‌صورت کارگاهی و کاملاً عملی برگزار شده است، مراحل زیر را گام‌به‌گام انجام می‌دهیم 👇

🔹 راه‌اندازی یک کلاستر تک‌نودی از Redpanda به همراه Redpanda Console

🔹 اجرای دو رابط کاربری معروف دنیای Kafka یعنی AKHQ و Kafka-UI (Kafbat) و بررسی سازگاری کامل آن‌ها با Redpanda

🔹 کار با ابزار خط فرمان rpk برای مدیریت کلاستر و پیکربندی‌ها

🔹 ساخت یک پایپ‌لاین واقعی با Redpanda Connect و زبان Bloblang برای پردازش فایل‌های CSV

🔹 و در نهایت، اجرای PostgreSQL CDC با استفاده از Kafka Connect + Debezium برای همگام‌سازی بلادرنگ داده‌ها

این بخش از دوره، دیدی جامع از توانایی‌های Redpanda در دنیای استریم دیتا و جایگاه آن در اکوسیستم Kafka ارائه می‌دهد.

📺 ویدیو کامل این کارگاه را می‌توانید از طریق لینک زیر در یوتیوب مشاهده کنید:

👉 🔗 https://youtu.be/nu_L4OSRUZc

🎓 این ویدیو بخشی از دوره آموزش تخصصی Kafka از مدرسه مهندسی داده سپهرام (Sepahram) است.

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

🌐 https://sepahram.ir/courses/

📢 کانال رسمی سپهرام در تلگرام:

📬 https://t.iss.one/sepahram_school

🔖 #Kafka #Redpanda #StreamingData #DataEngineering #Debezium #PostgreSQL #KafkaConnect #RealTimeData #Sepahram #مدرسه_مهندسی_داده #کافکا #داده_جاری #مهندسی_داده

‍ وقتی SQL هم حلقه For دارد! نگاهی به Lateral Join در PostgreSQL

اگر در حوزه نرم‌افزار، تحلیل داده یا دیتابیس کار می‌کنید، احتمالاً با انواع JOIN‌های معمول در SQL مثل INNER JOIN و LEFT JOIN آشنا هستید.

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

بیایید با یک مثال شروع کنیم 👇

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

🔰 مجموع کل فروش،

🔰حجم فروش،

🔰تعداد مشتریان منحصربه‌فرد،

🔰و میانگین فروش

در سه ماه گذشته را به‌دست آورید (به تفکیک ماه).

اگر بخواهید این کار را با زبان‌هایی مثل Python یا JavaScript انجام دهید، معمولاً یک حلقه (for) روی تمام محصولات اجرا می‌کنید و درون آن، برای هر محصول، محاسبات آماری مربوط به فروش را انجام می‌دهید.

در واقع، یک حلقه بیرونی برای محصولات و یک حلقه داخلی برای فروش‌های هر محصول دارید. در SQL هم می‌توان دقیقاً همین رفتار را شبیه‌سازی کرد: با استفاده از LATERAL JOIN.

اینجاست که Lateral مثل یک پل ارتباطی عمل می‌کند:

⚡️ به زیرکوئری اجازه می‌دهد به داده‌های هر ردیف از جدول اصلی دسترسی داشته باشد. یعنی در زیرکوئری، رکوردها ابتدا بر اساس رابطه آنها با جدول اصلی فیلتر می‌شوند و سپس محاسبات آماری روی آنها انجام میشود و نهایتا هم در کنار رکوردهای جدول اصلی قرار می‌گیرند.

به همین دلیل معمولاً از CROSS JOIN LATERAL استفاده می‌کنیم، چون شرط اتصال درون زیرکوئری و با WHERE تعریف می‌شود و در اینجا Inner Join معنا نخواهد داشت.

💫 نتیجه این رهیافت

می‌توانید به‌سادگی کوئری‌هایی بنویسید که مثلاً:

🌟 «ده محصول پرفروش هر کتگوری» را پیدا کند،

🌟یا برای هر مشتری، آخرین تراکنش ثبت‌شده‌اش را نمایش دهد،

🌟یا حتی تحلیل‌های زمانی و Top-N را مستقیماً داخل SQL انجام دهد: بدون نیاز به کدهای پیچیده و توابع پنجره‌ای


🎥 برای آشنایی دقیق‌تر با این مفهوم، یک ویدئوی آموزشی حدود ۴۰ دقیقه‌ای آماده کرده‌ام که در آن، با مثال‌های واقعی و کاربردی نحوه‌ی استفاده از LATERAL JOIN را گام‌به‌گام توضیح داده‌ام.

🔗 لینک مشاهده ویدئو در یوتیوب:

👉 https://youtu.be/vVc2EewTSQU


💡 در این ویدئو یاد موارد زیر را به صورت عملی مرور می‌کنیم:

✅ایده‌ی اصلی و کاربرد LATERAL JOIN

✅تفاوت آن با جوین‌های معمول

✅نوشتن کوئری‌های Top-N per Group

✅تحلیل داده‌های واقعی (مشتریان، فروش، زمان)

✅و نکات مهم برای بهینه‌سازی عملکرد کوئری


📚 این ویدئو بخشی از دوره‌ی PostgreSQL Practical Course در مدرسه مهندسی داده سپهرام است.

👉 https://sepahram.ir/courses


#PostgreSQL #SQL #DataEngineering #Database #LateralJoin #Sepahram #BigData #PostgresTutorial #Analytics