‍ وقتی 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

‍ 🔹 نگاهی به معماری چرخش به چپ در طراحی سامانه‌های بلادرنگ مقیاس‌پذیر
  پردازش جریانی (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 برای تحلیل تاریخی و یادگیری ماشین ذخیره می‌شود.