نسل جدید سامانه‌های مدیریت دیتابیس؛ شروع یک مسیر تازه
فرض کنید یک دستیار هوش مصنوعی داشتید که:
👌متریک‌های دیتابیس را دائم بررسی می‌کرد،
👌کوئری‌های غیر‌بهینه را شناسایی و بهبود می‌داد،
👌ایندکس‌های قدیمی را بازسازی می‌کرد،
👌روند مصرف منابع را در بازه‌های زمانی تحلیل می‌کرد،
👌و حتی وقتی نزدیک به کمبود منابع بودید، پیشاپیش هشدار می‌داد.
دقیقاً همین تصویری است که نسل جدید سامانه‌های مدیریت دیتابیس در حال ساخت آن است.
🧩 چالش‌های امروز در مدیریت دیتابیس
ابزارهای مدیریتی سنتی دیتابیس، بیشتر ناظر هستند تا کنش‌گر.
وقتی Query کند میشود یا ترافیک بالا می‌رود، این ابزارها معمولاً پس از وقوع مشکل هشدار می‌دهند، آن هم دیر، دستی و پرهزینه.
در بسیاری از سازمان‌ها، هنوز هم:
⚠️شناسایی کوئری‌های کند به صورت دستی انجام میشود،
⚠️بهینه‌سازی ایندکس‌ها فراموش یا به تعویق می‌افتد،
⚠️تنظیم منابع سخت‌افزاری نیازمند دخالت مستقیم DBA است،
⚠️و تصمیم‌های بهبود عملکرد، بدون تحلیل روند بلندمدت گرفته میشود.
در حالی که نیاز امروز تیم‌های داده، سامانه‌ای است که بتواند:
✨ پیش از بروز خطا، الگوهای خطر را شناسایی کند،
✨خودش پیشنهاد اصلاح یا بهبود بدهد (و حتی اجرا کند)،
✨از رفتار دیتابیس در طول زمان یاد بگیرد و هوشمندتر شود،
✨و در نهایت، مدیریت را از حالت واکنشی به پیش‌فعال و خودکار تبدیل کند.
⚙️ معرفی : Incerto : کوپایلوت واقعی دیتابیس
یکی از نمونه‌های پیشرو این نسل تازه، پلتفرم Incerto است که نسخه دسکتاپ آن برای ویندوز و سایر سیستم‌عامل‌ها در دسترس است و امکانات رایگان آن برای تک‌کاربر، کافی و بسیار کار راه‌انداز است.
https://incerto.in
سامانه‌ای که خود را «Real Co-Pilot for Databases» می‌نامد و عملاً مثل یک همکار هوشمند در کنار DBA یا Data Engineer قرار می‌گیرد.
🧠 ویژگی‌های کلیدی آن شامل:
✅ تشخیص خودکار بیش از ۱۰۰ نوع مشکل در محیط‌های تولیدی
✅ بهینه‌سازی خودکار کوئری‌ها با کمک AI و بازخورد انسانی
✅ پشتیبانی از چندین نوع DBMS در یک محیط
✅ تحلیل بار کاری و پیشنهاد تنظیمات منابع
✅ تبدیل زبان طبیعی به وظیفه دیتابیسی («ایندکس‌های بلااستفاده را حذف کن»، «منابع این سرور را بررسی کن»)
✅ یادگیری مستمر از رفتار دیتابیس‌ها برای بهبود تصمیم‌ها
💡 نتیجه؟ صرفه‌جویی چشمگیر در زمان، کاهش خطای انسانی و تمرکز بیشتر تیم‌ها بر تحلیل و تصمیم‌سازی به جای نگهداری روزمره.
🚀 از پایش تا خودکارسازی
ابزارهایی مثل Incerto تنها یک محصول نیستند؛ بلکه نشانه‌ی تحولی بزرگ‌ترند:
🌟 حرکت از پایش و هشدار به درک، پیش‌بینی و اقدام.
🌟از ابزارهای کمکی به عامل‌های هوشمند وظیفه‌گرا (Agentic Systems).
شاید در آینده‌ای نه‌چندان دور، مدیریت دیتابیس‌ها هم مثل رانندگی، از «کوپایلوت» به «اتوپایلوت» برسد البته با قابلیت Human-in-the-Loop؛ یعنی هر جا نیاز به قضاوت انسانی باشد، سیستم صبر کند تا کارشناس تأیید کند و پس از آن، اکشن به‌صورت خودکار اجرا شود.
✨ به نظر شما آیا زمان آن رسیده که مدیریت دیتابیس‌ها را هم به دست دستیارهای هوش مصنوعی بسپاریم؟
فرض کنید یک دستیار هوش مصنوعی داشتید که:
👌متریک‌های دیتابیس را دائم بررسی می‌کرد،
👌کوئری‌های غیر‌بهینه را شناسایی و بهبود می‌داد،
👌ایندکس‌های قدیمی را بازسازی می‌کرد،
👌روند مصرف منابع را در بازه‌های زمانی تحلیل می‌کرد،
👌و حتی وقتی نزدیک به کمبود منابع بودید، پیشاپیش هشدار می‌داد.
دقیقاً همین تصویری است که نسل جدید سامانه‌های مدیریت دیتابیس در حال ساخت آن است.
🧩 چالش‌های امروز در مدیریت دیتابیس
ابزارهای مدیریتی سنتی دیتابیس، بیشتر ناظر هستند تا کنش‌گر.
وقتی Query کند میشود یا ترافیک بالا می‌رود، این ابزارها معمولاً پس از وقوع مشکل هشدار می‌دهند، آن هم دیر، دستی و پرهزینه.
در بسیاری از سازمان‌ها، هنوز هم:
⚠️شناسایی کوئری‌های کند به صورت دستی انجام میشود،
⚠️بهینه‌سازی ایندکس‌ها فراموش یا به تعویق می‌افتد،
⚠️تنظیم منابع سخت‌افزاری نیازمند دخالت مستقیم DBA است،
⚠️و تصمیم‌های بهبود عملکرد، بدون تحلیل روند بلندمدت گرفته میشود.
در حالی که نیاز امروز تیم‌های داده، سامانه‌ای است که بتواند:
✨ پیش از بروز خطا، الگوهای خطر را شناسایی کند،
✨خودش پیشنهاد اصلاح یا بهبود بدهد (و حتی اجرا کند)،
✨از رفتار دیتابیس در طول زمان یاد بگیرد و هوشمندتر شود،
✨و در نهایت، مدیریت را از حالت واکنشی به پیش‌فعال و خودکار تبدیل کند.
⚙️ معرفی : Incerto : کوپایلوت واقعی دیتابیس
یکی از نمونه‌های پیشرو این نسل تازه، پلتفرم Incerto است که نسخه دسکتاپ آن برای ویندوز و سایر سیستم‌عامل‌ها در دسترس است و امکانات رایگان آن برای تک‌کاربر، کافی و بسیار کار راه‌انداز است.
https://incerto.in
سامانه‌ای که خود را «Real Co-Pilot for Databases» می‌نامد و عملاً مثل یک همکار هوشمند در کنار DBA یا Data Engineer قرار می‌گیرد.
🧠 ویژگی‌های کلیدی آن شامل:
✅ تشخیص خودکار بیش از ۱۰۰ نوع مشکل در محیط‌های تولیدی
✅ بهینه‌سازی خودکار کوئری‌ها با کمک AI و بازخورد انسانی
✅ پشتیبانی از چندین نوع DBMS در یک محیط
✅ تحلیل بار کاری و پیشنهاد تنظیمات منابع
✅ تبدیل زبان طبیعی به وظیفه دیتابیسی («ایندکس‌های بلااستفاده را حذف کن»، «منابع این سرور را بررسی کن»)
✅ یادگیری مستمر از رفتار دیتابیس‌ها برای بهبود تصمیم‌ها
💡 نتیجه؟ صرفه‌جویی چشمگیر در زمان، کاهش خطای انسانی و تمرکز بیشتر تیم‌ها بر تحلیل و تصمیم‌سازی به جای نگهداری روزمره.
🚀 از پایش تا خودکارسازی
ابزارهایی مثل Incerto تنها یک محصول نیستند؛ بلکه نشانه‌ی تحولی بزرگ‌ترند:
🌟 حرکت از پایش و هشدار به درک، پیش‌بینی و اقدام.
🌟از ابزارهای کمکی به عامل‌های هوشمند وظیفه‌گرا (Agentic Systems).
شاید در آینده‌ای نه‌چندان دور، مدیریت دیتابیس‌ها هم مثل رانندگی، از «کوپایلوت» به «اتوپایلوت» برسد البته با قابلیت Human-in-the-Loop؛ یعنی هر جا نیاز به قضاوت انسانی باشد، سیستم صبر کند تا کارشناس تأیید کند و پس از آن، اکشن به‌صورت خودکار اجرا شود.
✨ به نظر شما آیا زمان آن رسیده که مدیریت دیتابیس‌ها را هم به دست دستیارهای هوش مصنوعی بسپاریم؟
incerto.in
Incerto - Agentic AI That Solves All Database Problems
Gain full visibility into your database performance with real-time monitoring and intelligent insights.
❤3👍1
Forwarded from عکس نگار
💫 آنچه خوبان همه دارند، تو تنها داری: معرفی OpenObserve
بیش از یک دهه پیش، مسیر من در دنیای مشاهده‌پذیری زیرساخت‌ها (#Observability) با پشته‌ی کلاسیک ELK (Elasticsearch, Logstash, Kibana) آغاز شد.
در سال‌های بعد، ابزارهایی چون #VictoriaMetrics و #Signoz را نیز تجربه کردم، هر یک با ویژگی‌هایی ارزشمند در حوزه‌ی متریک‌ها، لاگ‌ها و تریس‌ها.
اما در این مسیر، اخیراً با پلتفرمی مواجه شدم که به نظرم می‌رسد حرف تازه‌ای برای گفتن دارد:
🚀 OpenObserve (O2)
openobserve.ai
در بررسی اولیه، با مجموعه‌ای از قابلیت‌ها و معماری چندلایه و آینده‌نگر روبه‌رو شدم که در عین سادگی و کارایی، عمق فنی قابل توجهی دارد.
اینکه پلتفرم کاملاً با زبان Rust نوشته شده است، تنها یکی از دلایل جذابیت آن است؛ چراکه Rust همزمان سرعت، ایمنی حافظه و بهره‌وری بالا را تضمین می‌کند.
🧩 معماری مدرن و الهام‌گرفته از نسل جدید سیستم‌های داده
پروژه #OpenObserve از Apache Parquet به‌عنوان فرمت ذخیره‌سازی ستونی و از DataFusion Query Engine برای اجرای مستقیم کوئری‌ها استفاده می‌کند. (دیتافیوژن مشابه با #duckdb است که با زبان rust توسعه یافته و متعلق به بنیاد آپاچی است)
این طراحی نشان‌دهنده‌ی حرکت آگاهانه به سمت همان معماری‌ای است که در نسل جدید سیستم‌های داده دیده میشود:
> جداسازی کامل لایه‌ی ذخیره‌سازی (Storage Layer) از لایه‌ی محاسبات (Compute Layer)
و تعامل از طریق فرمت‌های باز، ستونی و بهینه مثل #Parquet.
نتیجه‌ی این معماری چندلایه، سیستمی است که هم بسیار سریع و مقیاس‌پذیر است، هم از نظر هزینه و نگهداری به‌صرفه و ساده باقی می‌ماند.
⚙️ آنچه در بررسی اولیه توجه من را جلب کرد
🔰 امکان Full-Stack Observability برای Logs، Metrics و Traces در یک بستر واحد
🔰 پشتیبانی از Session Replay و Real User Monitoring (RUM) برای تحلیل تجربه‌ی واقعی کاربران
🔰 معماری Stateless با مقیاس‌پذیری افقی آسان
🔰 قابلیت High Compression (~40×) و هزینه‌ی ذخیره‌سازی تا ۱۴۰× کمتر از Elasticsearch
🔰 پشتیبانی از ذخیره‌سازی در S3، MinIO، GCS و Azure Blob
🔰 کوئری با SQL، PromQL و VRL
🔰 سیستم Observability Pipelines برای پردازش، پالایش و غنی‌سازی داده‌ها در لحظه
🔰 طراحی High Availability و Clustering برای نیازهای سازمانی بزرگ
⚡ عملکرد و مقیاس
در بنچمارک داخلی، OpenObserve توانسته است ۱ پتابایت داده را در کمتر از ۲ ثانیه کوئری بگیرد، عددی که حتی برای سیستم‌های تحلیلی مدرن نیز قابل توجه است.
معماری Stateless Node آن امکان گسترش افقی بدون پیچیدگی Replication یا وابستگی داده را فراهم می‌کند.
🌍 جامعه و مسیر رشد
این پروژه‌ی متن‌باز اکنون بیش از ۱۶٬۰۰۰ ستاره در GitHub دارد و توسط جامعه‌ای فعال از متخصصان DevOps، SRE و مهندسان داده توسعه می‌یابد.
مستندات رسمی و نمونه‌های کاربردی در openobserve.ai/docs در دسترس است.
🧭 دعوت از تیم‌های DevOps و SRE
اگر در زمینه‌ی DevOps، SRE، Data Platform یا Observability فعالیت می‌کنید، پیشنهاد می‌کنم OpenObserve را از نزدیک بررسی کنید.
ترکیب زبان Rust، طراحی چندلایه‌ی مبتنی بر Parquet و DataFusion، و مجموعه‌ی کامل قابلیت‌ها از Session Replay تا Alerting و Metrics Analysis
آن را به یکی از جامع‌ترین و آینده‌نگرترین پلتفرم‌های مشاهده‌پذیری حال حاضر تبدیل کرده است.
کانال مهندسی داده:
https://t.iss.one/bigdata_ir
بیش از یک دهه پیش، مسیر من در دنیای مشاهده‌پذیری زیرساخت‌ها (#Observability) با پشته‌ی کلاسیک ELK (Elasticsearch, Logstash, Kibana) آغاز شد.
در سال‌های بعد، ابزارهایی چون #VictoriaMetrics و #Signoz را نیز تجربه کردم، هر یک با ویژگی‌هایی ارزشمند در حوزه‌ی متریک‌ها، لاگ‌ها و تریس‌ها.
اما در این مسیر، اخیراً با پلتفرمی مواجه شدم که به نظرم می‌رسد حرف تازه‌ای برای گفتن دارد:
🚀 OpenObserve (O2)
openobserve.ai
در بررسی اولیه، با مجموعه‌ای از قابلیت‌ها و معماری چندلایه و آینده‌نگر روبه‌رو شدم که در عین سادگی و کارایی، عمق فنی قابل توجهی دارد.
اینکه پلتفرم کاملاً با زبان Rust نوشته شده است، تنها یکی از دلایل جذابیت آن است؛ چراکه Rust همزمان سرعت، ایمنی حافظه و بهره‌وری بالا را تضمین می‌کند.
🧩 معماری مدرن و الهام‌گرفته از نسل جدید سیستم‌های داده
پروژه #OpenObserve از Apache Parquet به‌عنوان فرمت ذخیره‌سازی ستونی و از DataFusion Query Engine برای اجرای مستقیم کوئری‌ها استفاده می‌کند. (دیتافیوژن مشابه با #duckdb است که با زبان rust توسعه یافته و متعلق به بنیاد آپاچی است)
این طراحی نشان‌دهنده‌ی حرکت آگاهانه به سمت همان معماری‌ای است که در نسل جدید سیستم‌های داده دیده میشود:
> جداسازی کامل لایه‌ی ذخیره‌سازی (Storage Layer) از لایه‌ی محاسبات (Compute Layer)
و تعامل از طریق فرمت‌های باز، ستونی و بهینه مثل #Parquet.
نتیجه‌ی این معماری چندلایه، سیستمی است که هم بسیار سریع و مقیاس‌پذیر است، هم از نظر هزینه و نگهداری به‌صرفه و ساده باقی می‌ماند.
⚙️ آنچه در بررسی اولیه توجه من را جلب کرد
🔰 امکان Full-Stack Observability برای Logs، Metrics و Traces در یک بستر واحد
🔰 پشتیبانی از Session Replay و Real User Monitoring (RUM) برای تحلیل تجربه‌ی واقعی کاربران
🔰 معماری Stateless با مقیاس‌پذیری افقی آسان
🔰 قابلیت High Compression (~40×) و هزینه‌ی ذخیره‌سازی تا ۱۴۰× کمتر از Elasticsearch
🔰 پشتیبانی از ذخیره‌سازی در S3، MinIO، GCS و Azure Blob
🔰 کوئری با SQL، PromQL و VRL
🔰 سیستم Observability Pipelines برای پردازش، پالایش و غنی‌سازی داده‌ها در لحظه
🔰 طراحی High Availability و Clustering برای نیازهای سازمانی بزرگ
⚡ عملکرد و مقیاس
در بنچمارک داخلی، OpenObserve توانسته است ۱ پتابایت داده را در کمتر از ۲ ثانیه کوئری بگیرد، عددی که حتی برای سیستم‌های تحلیلی مدرن نیز قابل توجه است.
معماری Stateless Node آن امکان گسترش افقی بدون پیچیدگی Replication یا وابستگی داده را فراهم می‌کند.
🌍 جامعه و مسیر رشد
این پروژه‌ی متن‌باز اکنون بیش از ۱۶٬۰۰۰ ستاره در GitHub دارد و توسط جامعه‌ای فعال از متخصصان DevOps، SRE و مهندسان داده توسعه می‌یابد.
مستندات رسمی و نمونه‌های کاربردی در openobserve.ai/docs در دسترس است.
🧭 دعوت از تیم‌های DevOps و SRE
اگر در زمینه‌ی DevOps، SRE، Data Platform یا Observability فعالیت می‌کنید، پیشنهاد می‌کنم OpenObserve را از نزدیک بررسی کنید.
ترکیب زبان Rust، طراحی چندلایه‌ی مبتنی بر Parquet و DataFusion، و مجموعه‌ی کامل قابلیت‌ها از Session Replay تا Alerting و Metrics Analysis
آن را به یکی از جامع‌ترین و آینده‌نگرترین پلتفرم‌های مشاهده‌پذیری حال حاضر تبدیل کرده است.
کانال مهندسی داده:
https://t.iss.one/bigdata_ir
👍2🙏1
Forwarded from مدرسه مهندسی داده سپهرام
وقتی 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 #مدرسه_مهندسی_داده #کافکا #داده_جاری #مهندسی_داده
در بخش تازه‌ای از دوره آموزش تخصصی کافکا در مدرسه مهندسی داده سپهرام، با یکی از جایگزین‌های قدرتمند و مدرن 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 #مدرسه_مهندسی_داده #کافکا #داده_جاری #مهندسی_داده
❤7👍2
Forwarded from مدرسه مهندسی داده سپهرام
وقتی 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
اگر در حوزه نرم‌افزار، تحلیل داده یا دیتابیس کار می‌کنید، احتمالاً با انواع 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
❤8👍2
🔹 نگاهی به معماری چرخش به چپ در طراحی سامانه‌های بلادرنگ مقیاس‌پذیر
پردازش جریانی (Streaming)، چارچوب‌ها و دیتابیس‌های بلادرنگ، بخش جدایی‌ناپذیر از زیرساخت داده مدرن هستند و مرز بین پردازش دسته‌‌ای و پردازش جریانی در حال محو شدن است یعنی حتی پردازش دسته ای را هم میتوانیم نوع خاصی از پردازش جریانی در نظر بگیریم .
از Kafka و Pulsar گرفته تا Flink و اسپارک، همه به ما یاد داده‌اند که داده‌ها را می‌توان همان لحظه‌ای که تولید می‌شوند، تحلیل و استفاده کرد.
اما در عمل، هنوز بسیاری از سازمان‌ها با ذهنیت قدیمی کار می‌کنند:
به زبان ساده، هنوز داده را مثل «کالا» می‌بینیم که باید در انبار (Data Lake / Warehouse) جمع شود و بعداً مصرف گردد.
💡 مفهوم جدید: چرخش به چپ (Shift Left)
مدتی است در ادبیات داده، مفهومی تازه مطرح شده به نام «چرخش به چپ» (Shift Left) - دعوتی برای تغییر همین چارچوب ذهنی.
ایده‌اش ساده ولی کاربردی است:
بیایید داده را مثل جریان آب ببینیم، نه کالا.
آن را همان لحظه ورود، تصفیه، غنی‌سازی و مصرف کنیم.
در این رویکرد، پردازش داده به‌جای انتهای زنجیره (در انبار یا Lakehouse)،
به ابتدای مسیر - یعنی نزدیک به محل تولید داده - منتقل میشود.
برای مثال:
در یک بانک، تراکنش مشکوک به تقلب همان لحظه شناسایی و مسدود میشود.
در یک فروشگاه آنلاین، تغییر رفتار کاربر بلافاصله در موتور پیشنهاددهنده تأثیر می‌گذارد.
⚙️ معماری Shift Left در عمل چگونه کار می‌کند؟
در معماری Shift Left، ما پردازش را به لبه‌ی جریان داده منتقل می‌کنیم -
اما همچنان داده‌ها را در مراحل مختلف در Lakehouse (مثل Iceberg) ذخیره می‌کنیم تا تاریخچه و تداوم داده حفظ شود.
مراحل پیشنهادی برای پیاده‌سازی:
- کافکا یا Pulsar را به‌عنوان لایه‌ی اصلی جریان داده در نظر بگیرید.
همه‌ی رویدادهای اپلیکیشن‌ها از این مسیر عبور می‌کنند.
- فلینک یا Spark Streaming را برای پردازش لحظه‌ای داده به‌کار بگیرید.
این لایه داده‌ها را در حین عبور، پالایش و غنی‌سازی می‌کند.
- خروجی جریان را همزمان به دو مقصد بفرستید:
یک مسیر برای مصرف بلادرنگ (مانند API، موتور تصمیم‌گیری، مانیتورینگ)،
و یک مسیر برای ذخیره‌سازی تحلیلی در Iceberg.
در Iceberg داده‌ها را در سه لایه نگهدارید تا هم داده‌ی خام و هم پردازش‌شده قابل دسترس باشد:
🔸 لایه برنز :
داده‌های خام (Raw) مستقیماً از Kafka یا CDC Stream.
🔸 لایه نقره :
داده‌های پاک‌سازی‌شده و استانداردشده - خروجی Jobهای Flink یا Spark.
🔸 لایه طلا:
داده‌های تجمیع‌شده و تحلیلی، آماده برای BI، ML یا گزارش‌ها.
هر سه لایه در Iceberg ذخیره می‌شوند تا بتوانید با قابلیت‌هایی مانند نسخه‌بندی، Snapshot، و Schema Evolution، داده را از هر مرحله بازیابی کنید.
در Flink می‌توانید Sinkهای همزمان (Dual Sink) تعریف کنید:
یکی برای Iceberg و دیگری برای سامانه‌های بلادرنگ مثل Elastic، Redis یا Kafka Topic دیگر.
🚀 نتیجه
با این الگو، داده از لحظه‌ی تولید،
هم برای تحلیل و تصمیم‌گیری در لحظه در دسترس است،
و هم در لایه‌های ساختارمند Iceberg برای تحلیل تاریخی و یادگیری ماشین ذخیره میشود.
پردازش جریانی (Streaming)، چارچوب‌ها و دیتابیس‌های بلادرنگ، بخش جدایی‌ناپذیر از زیرساخت داده مدرن هستند و مرز بین پردازش دسته‌‌ای و پردازش جریانی در حال محو شدن است یعنی حتی پردازش دسته ای را هم میتوانیم نوع خاصی از پردازش جریانی در نظر بگیریم .
از Kafka و Pulsar گرفته تا Flink و اسپارک، همه به ما یاد داده‌اند که داده‌ها را می‌توان همان لحظه‌ای که تولید می‌شوند، تحلیل و استفاده کرد.
اما در عمل، هنوز بسیاری از سازمان‌ها با ذهنیت قدیمی کار می‌کنند:
عادت کرده‌ایم داده را ابتدا ذخیره کنیم و بعد پردازش کنیم.
فرآیندهای ETL اغلب در انتهای شب یا ابتدای صبح اجرا می‌شوند تا داده‌ها را برای گزارش‌های فردا آماده کنند.
به زبان ساده، هنوز داده را مثل «کالا» می‌بینیم که باید در انبار (Data Lake / Warehouse) جمع شود و بعداً مصرف گردد.
💡 مفهوم جدید: چرخش به چپ (Shift Left)
مدتی است در ادبیات داده، مفهومی تازه مطرح شده به نام «چرخش به چپ» (Shift Left) - دعوتی برای تغییر همین چارچوب ذهنی.
ایده‌اش ساده ولی کاربردی است:
بیایید داده را مثل جریان آب ببینیم، نه کالا.
آن را همان لحظه ورود، تصفیه، غنی‌سازی و مصرف کنیم.
در این رویکرد، پردازش داده به‌جای انتهای زنجیره (در انبار یا Lakehouse)،
به ابتدای مسیر - یعنی نزدیک به محل تولید داده - منتقل میشود.
برای مثال:
در یک بانک، تراکنش مشکوک به تقلب همان لحظه شناسایی و مسدود میشود.
در یک فروشگاه آنلاین، تغییر رفتار کاربر بلافاصله در موتور پیشنهاددهنده تأثیر می‌گذارد.
⚙️ معماری Shift Left در عمل چگونه کار می‌کند؟
در معماری Shift Left، ما پردازش را به لبه‌ی جریان داده منتقل می‌کنیم -
اما همچنان داده‌ها را در مراحل مختلف در Lakehouse (مثل Iceberg) ذخیره می‌کنیم تا تاریخچه و تداوم داده حفظ شود.
مراحل پیشنهادی برای پیاده‌سازی:
- کافکا یا Pulsar را به‌عنوان لایه‌ی اصلی جریان داده در نظر بگیرید.
همه‌ی رویدادهای اپلیکیشن‌ها از این مسیر عبور می‌کنند.
- فلینک یا Spark Streaming را برای پردازش لحظه‌ای داده به‌کار بگیرید.
این لایه داده‌ها را در حین عبور، پالایش و غنی‌سازی می‌کند.
- خروجی جریان را همزمان به دو مقصد بفرستید:
یک مسیر برای مصرف بلادرنگ (مانند API، موتور تصمیم‌گیری، مانیتورینگ)،
و یک مسیر برای ذخیره‌سازی تحلیلی در Iceberg.
در Iceberg داده‌ها را در سه لایه نگهدارید تا هم داده‌ی خام و هم پردازش‌شده قابل دسترس باشد:
🔸 لایه برنز :
داده‌های خام (Raw) مستقیماً از Kafka یا CDC Stream.
🔸 لایه نقره :
داده‌های پاک‌سازی‌شده و استانداردشده - خروجی Jobهای Flink یا Spark.
🔸 لایه طلا:
داده‌های تجمیع‌شده و تحلیلی، آماده برای BI، ML یا گزارش‌ها.
هر سه لایه در Iceberg ذخیره می‌شوند تا بتوانید با قابلیت‌هایی مانند نسخه‌بندی، Snapshot، و Schema Evolution، داده را از هر مرحله بازیابی کنید.
در Flink می‌توانید Sinkهای همزمان (Dual Sink) تعریف کنید:
یکی برای Iceberg و دیگری برای سامانه‌های بلادرنگ مثل Elastic، Redis یا Kafka Topic دیگر.
🚀 نتیجه
با این الگو، داده از لحظه‌ی تولید،
هم برای تحلیل و تصمیم‌گیری در لحظه در دسترس است،
و هم در لایه‌های ساختارمند Iceberg برای تحلیل تاریخی و یادگیری ماشین ذخیره میشود.
👍3
Forwarded from مدرسه مهندسی داده سپهرام
کار با جداول بزرگ در PostgreSQL: همه چیز درباره پارتیشنینگ و کاربردهایش
در ادامه دوره #Postgres in Action و بخش کار با دیتابیس‌های بزرگ، به یکی از مهم‌ترین مباحث PostgreSQL یعنی پارتیشنینگ جداول (Table Partitioning) پرداختیم.
🌟 اما اصلاً پارتیشنینگ چیست و چرا باید از آن استفاده کنیم؟
مزایای اصلی آن شامل:
🚀 افزایش سرعت کوئری‌ها: کوئری‌ها فقط روی پارتیشن‌های مرتبط اجرا می‌شوند و زمان پاسخ کاهش می‌یابد.
🛠 سهولت نگهداری: داده‌های قدیمی یا آرشیو را راحت‌تر مدیریت و حذف می‌کنیم.
📊 بهینه‌سازی ایندکس‌ها و منابع: حجم هر پارتیشن کمتر است و ایندکس‌ها کارایی بهتری دارند.
در این ویدئوی نیم‌ساعته، که بخش مفاهیم پایه پارتیشنینگ را پوشش می‌دهد، مطالب زیر مرور شد:
📌 مباحث مطرح‌شده:
✅مفهوم پارتیشنینگ و نقش آن در مدیریت داده‌های بزرگ
✅انواع پارتیشنینگ در پستگرس: List، Range و Hash
✅پارتیشن‌بندی ترکیبی (Composite Partitioning) برای سناریوهای پیچیده
✅جدول اصلی به عنوان روتر/پروکسی و نحوه تعامل آن با پارتیشن‌ها
✅فرآیند Partition Pruning برای بهینه‌سازی کوئری‌ها
✅استفاده از Partition By Expression برای کنترل کامل روی پارتیشن‌بندی
✅دستورات Attach و Detach و مدیریت پارتیشن‌ها
اگر با دیتابیس‌های بزرگ کار می‌کنید و می‌خواهید عملکرد کوئری‌ها و مدیریت داده‌ها را بهبود ببخشید، این ویدئو برای شما فوق‌العاده کاربردی است.
📺 مشاهده ویدئو: https://youtu.be/gs2Rnp2kAOg
📚 برای مشاهده سایر ویدئوهای مدرسه مهندسی داده سپهرام:
🌐 https://sepahram.ir/courses/
کانال مهندسی داده: https://t.iss.one/bigdata_ir
در ادامه دوره #Postgres in Action و بخش کار با دیتابیس‌های بزرگ، به یکی از مهم‌ترین مباحث PostgreSQL یعنی پارتیشنینگ جداول (Table Partitioning) پرداختیم.
🌟 اما اصلاً پارتیشنینگ چیست و چرا باید از آن استفاده کنیم؟
پارتیشنینگ یعنی تقسیم یک جدول بزرگ به چند زیرجدول کوچکتر و قابل مدیریت بر اساس یک قاعده مشخص (مثل تاریخ، کشور یا شناسه).
مزایای اصلی آن شامل:
🚀 افزایش سرعت کوئری‌ها: کوئری‌ها فقط روی پارتیشن‌های مرتبط اجرا می‌شوند و زمان پاسخ کاهش می‌یابد.
🛠 سهولت نگهداری: داده‌های قدیمی یا آرشیو را راحت‌تر مدیریت و حذف می‌کنیم.
📊 بهینه‌سازی ایندکس‌ها و منابع: حجم هر پارتیشن کمتر است و ایندکس‌ها کارایی بهتری دارند.
در این ویدئوی نیم‌ساعته، که بخش مفاهیم پایه پارتیشنینگ را پوشش می‌دهد، مطالب زیر مرور شد:
📌 مباحث مطرح‌شده:
✅مفهوم پارتیشنینگ و نقش آن در مدیریت داده‌های بزرگ
✅انواع پارتیشنینگ در پستگرس: List، Range و Hash
✅پارتیشن‌بندی ترکیبی (Composite Partitioning) برای سناریوهای پیچیده
✅جدول اصلی به عنوان روتر/پروکسی و نحوه تعامل آن با پارتیشن‌ها
✅فرآیند Partition Pruning برای بهینه‌سازی کوئری‌ها
✅استفاده از Partition By Expression برای کنترل کامل روی پارتیشن‌بندی
✅دستورات Attach و Detach و مدیریت پارتیشن‌ها
اگر با دیتابیس‌های بزرگ کار می‌کنید و می‌خواهید عملکرد کوئری‌ها و مدیریت داده‌ها را بهبود ببخشید، این ویدئو برای شما فوق‌العاده کاربردی است.
📺 مشاهده ویدئو: https://youtu.be/gs2Rnp2kAOg
📚 برای مشاهده سایر ویدئوهای مدرسه مهندسی داده سپهرام:
🌐 https://sepahram.ir/courses/
کانال مهندسی داده: https://t.iss.one/bigdata_ir
👍6
نگاهی به اهمیت پشتیبانی DuckDB از ٰVortex و شروع رواج نسل جدید فرمت‌های ذخیره داده
سال‌ها Apache Parquet استاندارد اصلی برای ذخیره‌سازی داده‌های خام بوده است؛ فرمتی که داده‌ها را به‌صورت فشرده، ستون‌محور و آماده برای تحلیل و پردازش‌های سنگین ذخیره می‌کند و عملاً ستون فقرات بسیاری از پلتفرم‌های تحلیلی بخصوص در حوزه hashtag#Lakehouse به شمار می‌رود.
اما در سال‌های اخیر، نیازهای جدیدی مانند بازیابی سریع ویژگی‌ها در هوش مصنوعی، جستجوی برداری، اسکورینگ کم‌تأخیر و پردازش‌های بلادرنگ باعث شده‌اند نسل تازه‌ای از فرمت‌های ستونی معرفی شوند، فرمت‌هایی که علاوه بر حفظ مزایای پارکت، قابلیت‌های کاملاً جدیدی ارائه می‌کنند:
🔥 سرعت اسکن بسیار بالاتر
🔥 دسترسی تصادفی (Random Access) فوق‌العاده سریع به رکوردها
🔥 ذخیره آمار توکار (Statistics) برای حذف سریع فایل‌های نامرتبط با کوئری
🔥 سازگاری کامل و Zero-Copy با Apache Arrow برای لود بسیار سریع داده
یکی از مهم‌ترین این فرمت‌ها hashtag#Vortex است که بر پایه معماری قابل‌گسترش و با امکان استفاده از encodingها و layoutهای جدید طراحی شده.
طبق گزارش‌ها، Vortex حدود ۱۰۰ برابر دسترسی تصادفی سریع‌تر و ۱۰ تا ۲۰ برابر اسکن سریع‌تر نسبت به hashtag#Parquet ارائه می‌دهد.
خبر خوب این که hashtag#DuckDB در نسخه 4.2 رسماً از Vortex پشتیبانی می‌کند؛ اتفاقی که می‌تواند در کاربردهایی مثل فیلترینگ، جوین‌ها، نرمال‌سازی داده، Feature Engineering و بسیاری از پردازش‌های تحلیلی، تحول جدی ایجاد کند.
همچنین کار روی پشتیبانی Apache hashtag#Iceberg از Vortex نیز آغاز شده و به‌نظر می‌رسد به‌زودی این فرمت به‌صورت کامل وارد اکوسیستم hashtag#Lakehouse شود که این می‌تواند نقطه عطفی در این حوزه باشد.
مرجع اصلی پست : https://www.linkedin.com/feed/update/urn:li:activity:7394922128225144832/
سال‌ها Apache Parquet استاندارد اصلی برای ذخیره‌سازی داده‌های خام بوده است؛ فرمتی که داده‌ها را به‌صورت فشرده، ستون‌محور و آماده برای تحلیل و پردازش‌های سنگین ذخیره می‌کند و عملاً ستون فقرات بسیاری از پلتفرم‌های تحلیلی بخصوص در حوزه hashtag#Lakehouse به شمار می‌رود.
اما در سال‌های اخیر، نیازهای جدیدی مانند بازیابی سریع ویژگی‌ها در هوش مصنوعی، جستجوی برداری، اسکورینگ کم‌تأخیر و پردازش‌های بلادرنگ باعث شده‌اند نسل تازه‌ای از فرمت‌های ستونی معرفی شوند، فرمت‌هایی که علاوه بر حفظ مزایای پارکت، قابلیت‌های کاملاً جدیدی ارائه می‌کنند:
🔥 سرعت اسکن بسیار بالاتر
🔥 دسترسی تصادفی (Random Access) فوق‌العاده سریع به رکوردها
🔥 ذخیره آمار توکار (Statistics) برای حذف سریع فایل‌های نامرتبط با کوئری
🔥 سازگاری کامل و Zero-Copy با Apache Arrow برای لود بسیار سریع داده
یکی از مهم‌ترین این فرمت‌ها hashtag#Vortex است که بر پایه معماری قابل‌گسترش و با امکان استفاده از encodingها و layoutهای جدید طراحی شده.
طبق گزارش‌ها، Vortex حدود ۱۰۰ برابر دسترسی تصادفی سریع‌تر و ۱۰ تا ۲۰ برابر اسکن سریع‌تر نسبت به hashtag#Parquet ارائه می‌دهد.
خبر خوب این که hashtag#DuckDB در نسخه 4.2 رسماً از Vortex پشتیبانی می‌کند؛ اتفاقی که می‌تواند در کاربردهایی مثل فیلترینگ، جوین‌ها، نرمال‌سازی داده، Feature Engineering و بسیاری از پردازش‌های تحلیلی، تحول جدی ایجاد کند.
همچنین کار روی پشتیبانی Apache hashtag#Iceberg از Vortex نیز آغاز شده و به‌نظر می‌رسد به‌زودی این فرمت به‌صورت کامل وارد اکوسیستم hashtag#Lakehouse شود که این می‌تواند نقطه عطفی در این حوزه باشد.
مرجع اصلی پست : https://www.linkedin.com/feed/update/urn:li:activity:7394922128225144832/
Linkedin
#dataengineering #softwareengineering | Dipankar Mazumdar
DuckDB ❤️ Vortex File Format
I wrote about newer file formats such as Vortex before.
Typically, the columnar analytics de facto is Apache Parquet.
And there's a lot to like about Parquet - columnar layout, per-page compression, strong encoding schemes…
I wrote about newer file formats such as Vortex before.
Typically, the columnar analytics de facto is Apache Parquet.
And there's a lot to like about Parquet - columnar layout, per-page compression, strong encoding schemes…
👍4
Forwarded from عکس نگار
وقتی 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، خوشحال می‌شویم از تجربه شما هم بتوانیم استفاده کنیم 🙌
در سال‌های اخیر، با رشد تصاعدی حجم داده در شرکت‌های بزرگ ایرانی، زیرساخت‌های سنتی مانند 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، خوشحال می‌شویم از تجربه شما هم بتوانیم استفاده کنیم 🙌
👍2
چرا Intuit به‌جای ClickHouse، سراغ StarRocks رفت؟
اخیراً تیم 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 همچنان پادشاه است.
امروزه حجم عظیم داده در بسیاری از شرکت‌ها و سازمان‌های ایرانی، ضرورت استفاده از دیتابیس‌های تحلیلی مدرن را بیش از هر زمان دیگری آشکار کرده است. مجموعه‌هایی که می‌خواهند تحلیل‌های 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 همچنان پادشاه است.
❤3
Forwarded from مدرسه مهندسی داده سپهرام
از Kafka تا Iceberg در کمتر از یک دقیقه؛ تجربه عملی AutoMQ
در مدرسه مهندسی داده سپهرام، همیشه تلاش کرده‌ایم جدیدترین فناوری‌های حوزه داده را به‌صورت کاربردی و قابل استفاده در پروژه‌های واقعی ارائه کنیم. در ویدئویی که اخیراً در کانال یوتیوب مدرسه منتشر شده است، به‌صورت کاملاً عملی کار با AutoMQ، جایگزین نوآورانه و cloud-first برای #Kafka و همچنین ذخیره‌سازی مستقیم داده‌های Kafka در Apache Iceberg و کوئری‌گیری آن با #DuckDB را بررسی کرده‌ایم.
این جلسه بخشی از رویکرد ما برای آموزش معماری‌های مدرن داده مانند Lakehouse، Zero-ETL و استریم‌پردازی ابری است.
در این ویدئو، مباحث زیر به‌صورت مرحله‌به‌مرحله و عملی ارائه شده است:
✔️آشنایی با معماری 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
در مدرسه مهندسی داده سپهرام، همیشه تلاش کرده‌ایم جدیدترین فناوری‌های حوزه داده را به‌صورت کاربردی و قابل استفاده در پروژه‌های واقعی ارائه کنیم. در ویدئویی که اخیراً در کانال یوتیوب مدرسه منتشر شده است، به‌صورت کاملاً عملی کار با 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
👍3❤2