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

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

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

نگاهی به اهمیت پشتیبانی 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/

‍ از Kafka تا Iceberg در کمتر از یک دقیقه؛ تجربه عملی AutoMQ
در مدرسه مهندسی داده سپهرام، همیشه تلاش کرده‌ایم جدیدترین فناوری‌های حوزه داده را به‌صورت کاربردی و قابل استفاده در پروژه‌های واقعی ارائه کنیم. در ویدئویی که اخیراً در کانال یوتیوب مدرسه منتشر شده است، به‌صورت کاملاً عملی کار با 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