دو منبع عالی برای یادگیری سریع و عمیق Airflow 3 📚
چند ماه از انتشار رسمی Airflow 3 می‌گذرد و حالا وقت آن است که ببینیم دقیقاً چه چیزهایی تغییر کرده و چرا این نسخه نقطه عطف مهمی در مسیر این پلتفرم محبوب مدیریت جریان کاری داده (workflow orchestration) محسوب میشود.
در این نوشته می‌خواهیم دو منبع فوق‌العاده را معرفی کنیم که به‌جای خواندن ده‌ها صفحه مستندات یا تماشای ویدیوهای پراکنده، شما را مستقیم و مؤثر به قلب Airflow 3 می‌برند.
گاهی برای درک عمیق‌تر و تجربه‌ی واقعی، باید سراغ منابعی رفت که با نگاه حرفه‌ای نوشته شده‌اند - منابعی که نه‌تنها توضیح می‌دهند چطور کار می‌کند، بلکه کمک می‌کنند در عمل بهتر بسازید.
حالا که چند ماه از انتشار نسخه ۳ می‌گذرد، اگر هنوز با نسخه ۲ کار می‌کنید، باید بدانید از خیلی از قابلیت‌های جدید و بهینه‌سازی‌های Airflow 3 بی‌نصیب مانده‌اید.
دو منبع زیر بهترین نقطه‌ی شروع برای درک تفاوت‌ها و یادگیری عملی نسخه ۳ هستند 👇
1️⃣ جزوه مروری بر امکانات ایرفلو ۳ از Astronomer
یک مرور سریع و فشرده (حدود ۹ صفحه) از همه‌ی قابلیت‌های جدید Airflow 3 - ایده‌آل برای کسانی که می‌خواهند در چند دقیقه بفهمند دقیقاً چه تغییراتی در انتظارشان است. البته با این پیش‌فرض که با ایرفلو قبلا آشنا هستید.
2️⃣ کتاب Practical Guide to Apache Airflow 3 از Manning
از ساخت اولین 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
چند ماه از انتشار رسمی 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
👍3
Forwarded from مدرسه مهندسی داده سپهرام
🎥 ویدئوی جدید منتشر شد: رپلیکیشن در کافکا — درک عمیق از مکانیزم تکثیر داده‌ها
در این جلسه از دوره تخصصی آموزش کافکا، به یکی از بنیادی‌ترین و در عین حال کمتر درک‌شده‌ترین بخش‌های کافکا یعنی رپلیکیشن (Replication) پرداخته‌ایم.
📦 جایی که داده‌های هر پارتیشن در چندین بروکر تکرار می‌شوند تا سیستم در برابر خطا، قطعی و از دست رفتن داده مقاوم بماند.
در این ویدئو موارد زیر بررسی می‌شوند:
🔹 رپلیکیشن در سطح پارتیشن چگونه عمل می‌کند؟
🔹 تفاوت نقش رهبر (Leader) و پیرو (Follower) چیست؟
🔹 مفهوم ISR (In-Sync Replicas) دقیقاً چه نقشی در پایداری داده دارد؟
🔹شاخص High Watermark چگونه تعیین میشود و چرا در مصرف داده حیاتی است؟
🔹 ارتباط بین تنظیمات replication.factor، min.insync.replicas و acks چیست و چطور باید مقدار مناسب را انتخاب کنیم؟
🔹 در صورت خرابی بروکر یا تأخیر در همگام‌سازی، چه اتفاقی می‌افتد و چطور می‌توان از unclean leader election جلوگیری کرد؟
🎯 اگر می‌خواهید بدانید کافکا در پشت‌صحنه چگونه با چند بروکر داده‌ها را همگام نگه می‌دارد و چه مکانیزم‌هایی باعث حفظ پایداری سیستم میشود، این ویدئو را از دست ندهید.
📺 تماشای کامل ویدئو در یوتیوب:
👉 https://youtu.be/l30jp3iXooE
🔗 سایر دوره‌ها و آموزش‌های مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses
در این جلسه از دوره تخصصی آموزش کافکا، به یکی از بنیادی‌ترین و در عین حال کمتر درک‌شده‌ترین بخش‌های کافکا یعنی رپلیکیشن (Replication) پرداخته‌ایم.
📦 جایی که داده‌های هر پارتیشن در چندین بروکر تکرار می‌شوند تا سیستم در برابر خطا، قطعی و از دست رفتن داده مقاوم بماند.
در این ویدئو موارد زیر بررسی می‌شوند:
🔹 رپلیکیشن در سطح پارتیشن چگونه عمل می‌کند؟
🔹 تفاوت نقش رهبر (Leader) و پیرو (Follower) چیست؟
🔹 مفهوم ISR (In-Sync Replicas) دقیقاً چه نقشی در پایداری داده دارد؟
🔹شاخص High Watermark چگونه تعیین میشود و چرا در مصرف داده حیاتی است؟
🔹 ارتباط بین تنظیمات replication.factor، min.insync.replicas و acks چیست و چطور باید مقدار مناسب را انتخاب کنیم؟
🔹 در صورت خرابی بروکر یا تأخیر در همگام‌سازی، چه اتفاقی می‌افتد و چطور می‌توان از unclean leader election جلوگیری کرد؟
🎯 اگر می‌خواهید بدانید کافکا در پشت‌صحنه چگونه با چند بروکر داده‌ها را همگام نگه می‌دارد و چه مکانیزم‌هایی باعث حفظ پایداری سیستم میشود، این ویدئو را از دست ندهید.
📺 تماشای کامل ویدئو در یوتیوب:
👉 https://youtu.be/l30jp3iXooE
🔗 سایر دوره‌ها و آموزش‌های مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses
YouTube
Deep Dive into Kafka Replication & ISR
📝 Description:
In this video, we take a deep and practical look at how replication works in Apache Kafka, one of the most critical mechanisms that guarantees fault tolerance, durability, and data consistency across your Kafka cluster.
This session is presented…
In this video, we take a deep and practical look at how replication works in Apache Kafka, one of the most critical mechanisms that guarantees fault tolerance, durability, and data consistency across your Kafka cluster.
This session is presented…
👍5🙏1
آشنایی با مکانیزم همروندی در پستگرس و ضرورت اجرای منظم Vacuum
یکی از پرسش‌های کلیدی در طراحی پایگاه داده این است که:
🔍 وقتی چندین تراکنش به‌صورت همزمان قصد تغییر رکوردهای مشابه را دارند، سیستم چگونه تصمیم می‌گیرد کدام تغییر اعمال شود؟
پستگرس برای پاسخ به این چالش از مکانیزم MVCC (Multi-Version Concurrency Control) استفاده می‌کند - روشی که اجازه می‌دهد تراکنش‌ها بدون قفل‌های سنگین، همزمان روی داده‌ها کار کنند.
مکانیزم MVCC در پستگرس
در این مدل، هنگام تغییر یک رکورد، نسخه‌ی جدیدی از همان ردیف (tuple) در جدول درج میشود یعنی به ازای تراکنش‌های مختلفی که قصد تغییر یک رکورد را دارند، تعداد نسخه های زیادی از آن رکورد به صورت همزمان ایجاد میشود؛ اگر در همان صفحه (page) فضای کافی وجود داشته باشد، نسخه(ها)ی جدید در همان‌جا ذخیره میشود، وگرنه در صفحه‌ی دیگری قرار می‌گیرد.
برخلاف تصور رایج، کل صفحه کپی نمی‌شود - بلکه فقط ردیف(های) جدید افزوده میشود و نسخه‌ی قبلی به‌عنوان «مرده» (dead tuple) علامت‌گذاری میشود.
اگر تراکنش commit شود، نسخه‌ی جدید قابل مشاهده میشود؛ در غیر این صورت، ردیف‌های جدید هرگز برای سایر تراکنش‌ها دیده نمی‌شوند.
✨ مفهوم Page در پستگرس چیست؟
در PostgreSQL، داده‌ها مستقیماً به‌صورت خطی روی دیسک ذخیره نمی‌شوند، بلکه در قالب واحدهایی به نام Page (صفحه) سازمان‌دهی می‌شوند.
هر Page معمولاً حجمی برابر با ۸ کیلوبایت دارد و شامل چندین tuple (یا همان ردیف داده) است.
وقتی داده‌ای جدید درج میشود، PostgreSQL ابتدا بررسی می‌کند که آیا در یکی از صفحات موجود فضای کافی برای آن وجود دارد یا نه:
✅ اگر فضا کافی باشد، ردیف جدید در همان صفحه قرار می‌گیرد.
📦 اگر صفحه پر باشد، ردیف جدید در صفحه‌ای دیگر ذخیره میشود و ممکن است اندازهٔ فایل جدول افزایش پیدا کند.
در واقع، Page واحد پایهٔ ذخیره‌سازی و بازیابی داده‌ها در پستگرس است؛ همهٔ عملیات خواندن و نوشتن در نهایت در سطح صفحات انجام میشود.
🎯 ضرورت فرآیند VACUUM
با گذر زمان، رکوردهای قدیمی (dead tuples) باید پاک‌سازی شوند تا فضای جدول بی‌دلیل افزایش نیابد. این وظیفه بر عهده‌ی فرآیند #VACUUM است.
در کارگاه عملی این جلسه، با استفاده از PostgreSQL 18 در محیط Docker و ابزار DBeaver، گام‌به‌گام بررسی کردیم که:
🔰مکانیزم MVCC چگونه نسخه‌های مختلف رکوردها را مدیریت می‌کند،
🔰و VACUUM چگونه فضا را بازیابی و از wraparound جلوگیری می‌کند.
🎥 مشاهده ویدئوی کامل در یوتیوب:
👉 https://youtu.be/TtHSDJgFI6g
📌 نکته: در محیط‌های تولیدی، هرگز autovacuum را غیرفعال نکنید - این گزینه فقط برای اهداف آموزشی در این کارگاه موقتاً خاموش شده بود.
Sepahram Data Eng. School
دوره کاربردی پستگرس : https://sepahram.ir/courses/postgresql
یکی از پرسش‌های کلیدی در طراحی پایگاه داده این است که:
🔍 وقتی چندین تراکنش به‌صورت همزمان قصد تغییر رکوردهای مشابه را دارند، سیستم چگونه تصمیم می‌گیرد کدام تغییر اعمال شود؟
پستگرس برای پاسخ به این چالش از مکانیزم MVCC (Multi-Version Concurrency Control) استفاده می‌کند - روشی که اجازه می‌دهد تراکنش‌ها بدون قفل‌های سنگین، همزمان روی داده‌ها کار کنند.
مکانیزم MVCC در پستگرس
در این مدل، هنگام تغییر یک رکورد، نسخه‌ی جدیدی از همان ردیف (tuple) در جدول درج میشود یعنی به ازای تراکنش‌های مختلفی که قصد تغییر یک رکورد را دارند، تعداد نسخه های زیادی از آن رکورد به صورت همزمان ایجاد میشود؛ اگر در همان صفحه (page) فضای کافی وجود داشته باشد، نسخه(ها)ی جدید در همان‌جا ذخیره میشود، وگرنه در صفحه‌ی دیگری قرار می‌گیرد.
برخلاف تصور رایج، کل صفحه کپی نمی‌شود - بلکه فقط ردیف(های) جدید افزوده میشود و نسخه‌ی قبلی به‌عنوان «مرده» (dead tuple) علامت‌گذاری میشود.
اگر تراکنش commit شود، نسخه‌ی جدید قابل مشاهده میشود؛ در غیر این صورت، ردیف‌های جدید هرگز برای سایر تراکنش‌ها دیده نمی‌شوند.
✨ مفهوم Page در پستگرس چیست؟
در PostgreSQL، داده‌ها مستقیماً به‌صورت خطی روی دیسک ذخیره نمی‌شوند، بلکه در قالب واحدهایی به نام Page (صفحه) سازمان‌دهی می‌شوند.
هر Page معمولاً حجمی برابر با ۸ کیلوبایت دارد و شامل چندین tuple (یا همان ردیف داده) است.
وقتی داده‌ای جدید درج میشود، PostgreSQL ابتدا بررسی می‌کند که آیا در یکی از صفحات موجود فضای کافی برای آن وجود دارد یا نه:
✅ اگر فضا کافی باشد، ردیف جدید در همان صفحه قرار می‌گیرد.
📦 اگر صفحه پر باشد، ردیف جدید در صفحه‌ای دیگر ذخیره میشود و ممکن است اندازهٔ فایل جدول افزایش پیدا کند.
در واقع، Page واحد پایهٔ ذخیره‌سازی و بازیابی داده‌ها در پستگرس است؛ همهٔ عملیات خواندن و نوشتن در نهایت در سطح صفحات انجام میشود.
🔹 نکته جالب اینجاست که ساختار داخلی جداول در پستگرس به‌صورت #Heap (پشته‌ای/درهم/بدون هیچ ترتیب خاصی) پیاده‌سازی شده است؛
یعنی برخلاف ساختارهای مرتب‌شده مثل B-Tree، ردیف‌ها به‌ترتیب خاصی ذخیره نمی‌شوند : هر رکورد «هرجا که یک پیج، فضای خالی داشته باشد» درج میشود.
🎯 ضرورت فرآیند VACUUM
با گذر زمان، رکوردهای قدیمی (dead tuples) باید پاک‌سازی شوند تا فضای جدول بی‌دلیل افزایش نیابد. این وظیفه بر عهده‌ی فرآیند #VACUUM است.
فرآیند VACUUM فضای اشغال‌شده توسط تاپل‌های مرده (رکوردهایی که بازنویسی شده‌اند و نسخه قدیمی آنها باید پاک شود) را برای استفاده‌ی مجدد در همان فایل آزاد می‌کند اما اگر بخواهیم این فضای آزاد شده از حذف رکوردهای مرده از سایز فایل کم شوند و به سیستم عامل برگردند، نیاز به VACUUM FULL داریم که می‌تواند آن فضا را واقعاً به سیستم‌عامل بازگرداند.
در کارگاه عملی این جلسه، با استفاده از PostgreSQL 18 در محیط Docker و ابزار DBeaver، گام‌به‌گام بررسی کردیم که:
🔰مکانیزم MVCC چگونه نسخه‌های مختلف رکوردها را مدیریت می‌کند،
🔰و VACUUM چگونه فضا را بازیابی و از wraparound جلوگیری می‌کند.
🎥 مشاهده ویدئوی کامل در یوتیوب:
👉 https://youtu.be/TtHSDJgFI6g
📌 نکته: در محیط‌های تولیدی، هرگز autovacuum را غیرفعال نکنید - این گزینه فقط برای اهداف آموزشی در این کارگاه موقتاً خاموش شده بود.
Sepahram Data Eng. School
دوره کاربردی پستگرس : https://sepahram.ir/courses/postgresql
👍4❤3🙏1
لیک‌هوس در مسیر بلوغ: نگاهی به نسخه جدید #RisingWave و ادغام عمیق آن با #Iceberg
در دنیای امروز که هر سازمان مجموعه‌ای از سرویس‌ها و جریان‌های داده‌ای متنوع دارد، نیاز به بستری متمرکز برای ذخیره و مدیریت «خودِ داده‌ها» بیش از همیشه احساس میشود: بستری مستقل از ابزارها و موتورهای پردازشی، جایی که داده‌ها به‌صورت خام و ساخت‌یافته نگهداری شوند.
این معماری نه‌تنها نظم داده‌ها را تضمین می‌کند، بلکه بستر ایده‌آلی برای توسعه سامانه‌های هوش مصنوعی و مدل‌های یادگیری ماشین فراهم می‌سازد؛ زیرا داده‌های تمیز و استاندارد، پایه‌ی هر سیستم هوشمند هستند.
🚀با این حال، فناوری‌هایی چون Iceberg هنوز در مدیریت متادیتا، snapshotها و عملیات نگهداری، چالش‌هایی دارند. در همین نقطه است که نسخه‌ی جدید #RisingWave v2.6 می‌تواند فرآیند به کارگیری و مدیریت لیک‌هوس را تسهیل کند ✨
⚡️ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper = ترکیب برنده!
✅ در این نسخه، RisingWave، به‌عنوان یک پایگاه داده جریانی سازگار با #PostgreSQL، به‌صورت بومی با Iceberg ادغام شده است. داده‌ها به‌صورت لحظه‌ای از #Kafka دریافت، در RisingWave پردازش، و سپس به شکل استاندارد در Lakehouse ذخیره می‌شوند.
✅این ارتباط از طریق #Lakekeeper برقرار میشود: یک #REST Catalog استاندارد که رابط رسمی میان RisingWave و Iceberg است.
✅ کتابخانه Lakekeeper علاوه بر مدیریت متادیتا و کنترل دسترسی‌ها (با پشتیبانی از #OpenFGA)، امکان راه‌اندازی و تنظیم #Lakehouse را به‌دلخواه شما فراهم می‌کند؛ مثلاً با استفاده از #MinIO یا هر فایل‌سیستم دیگر.
✅ سپس RisingWave با تنظیمات شما و در «لیک‌هوس شما» شروع به درج داده‌ها می‌کند.
✅ داده‌های غیرجریانی سازمان نیز می‌توانند با ابزارهایی مانند #ApacheSpark یا #PyIceberg به این بستر منتقل شوند تا یک Lakehouse کامل شکل گیرد: جایی که RisingWave بخش داده‌های جریانی را مدیریت می‌کند.
این ترکیب، از نظر فنی استاندارد و از نظر معماری، منعطف و آینده‌نگر است.
همچنین، عملیات نگهداشت و بهینه‌سازی داده‌ها مستقیماً در خود RisingWave انجام میشود، و بار سنگین مدیریت #Lakehouse از دوش تیم‌های داده برداشته میشود. 💪
🧠 ویژگی‌های کلیدی نسخه‌ی RisingWave ۲.۶
🔰 پشتیبانی از داده‌های برداری (Vector) برای جست‌وجوی شباهت
🔰حالت جدید Copy-on-Write برای snapshotهای تمیزتر در Iceberg
🔰دستور VACUUM FULL برای پاک‌سازی و فشرده‌سازی داده‌ها
🔰سازگاری کامل با #Lakekeeper REST Catalog
🔰تنوع sinkهای جدید برای #Snowflake، #Redshift، #Elasticsearch
🔰حالت Memory-Only برای پردازش‌های فوق‌سریع
🎥 به‌زودی ویدیویی منتشر می‌کنم که در آن ساخت یک #Lakehouse عملی با
#MinIO + #Lakekeeper + #Spark + #Trino + #StarRocks
را گام‌به‌گام بررسی می‌کنیم. 🚀
به باور من، مسیر آینده‌ی زیرساخت‌های داده به‌سمتی پیش می‌رود که #Lakehouse بستر اصلی ذخیره و تحلیل داده‌ها شود،
و ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper یکی از گزینه‌های خوب سازمانی برای شروع این مسیر است. 🌟
در دنیای امروز که هر سازمان مجموعه‌ای از سرویس‌ها و جریان‌های داده‌ای متنوع دارد، نیاز به بستری متمرکز برای ذخیره و مدیریت «خودِ داده‌ها» بیش از همیشه احساس میشود: بستری مستقل از ابزارها و موتورهای پردازشی، جایی که داده‌ها به‌صورت خام و ساخت‌یافته نگهداری شوند.
این معماری نه‌تنها نظم داده‌ها را تضمین می‌کند، بلکه بستر ایده‌آلی برای توسعه سامانه‌های هوش مصنوعی و مدل‌های یادگیری ماشین فراهم می‌سازد؛ زیرا داده‌های تمیز و استاندارد، پایه‌ی هر سیستم هوشمند هستند.
📌 اینجا همان جایی است که مفهوم #Lakehouse اهمیت خود را نشان می‌دهد: ترکیبی از داده‌های ساخت‌یافته‌ی خام به همراه یک استاندارد سازمان‌دهی مانند #ApacheIceberg که باعث میشود داده‌ها در مقیاس وسیع قابل ذخیره‌سازی، مدیریت و تحلیل باشند.
🚀با این حال، فناوری‌هایی چون Iceberg هنوز در مدیریت متادیتا، snapshotها و عملیات نگهداری، چالش‌هایی دارند. در همین نقطه است که نسخه‌ی جدید #RisingWave v2.6 می‌تواند فرآیند به کارگیری و مدیریت لیک‌هوس را تسهیل کند ✨
⚡️ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper = ترکیب برنده!
✅ در این نسخه، RisingWave، به‌عنوان یک پایگاه داده جریانی سازگار با #PostgreSQL، به‌صورت بومی با Iceberg ادغام شده است. داده‌ها به‌صورت لحظه‌ای از #Kafka دریافت، در RisingWave پردازش، و سپس به شکل استاندارد در Lakehouse ذخیره می‌شوند.
✅این ارتباط از طریق #Lakekeeper برقرار میشود: یک #REST Catalog استاندارد که رابط رسمی میان RisingWave و Iceberg است.
✅ کتابخانه Lakekeeper علاوه بر مدیریت متادیتا و کنترل دسترسی‌ها (با پشتیبانی از #OpenFGA)، امکان راه‌اندازی و تنظیم #Lakehouse را به‌دلخواه شما فراهم می‌کند؛ مثلاً با استفاده از #MinIO یا هر فایل‌سیستم دیگر.
✅ سپس RisingWave با تنظیمات شما و در «لیک‌هوس شما» شروع به درج داده‌ها می‌کند.
✅ داده‌های غیرجریانی سازمان نیز می‌توانند با ابزارهایی مانند #ApacheSpark یا #PyIceberg به این بستر منتقل شوند تا یک Lakehouse کامل شکل گیرد: جایی که RisingWave بخش داده‌های جریانی را مدیریت می‌کند.
این ترکیب، از نظر فنی استاندارد و از نظر معماری، منعطف و آینده‌نگر است.
همچنین، عملیات نگهداشت و بهینه‌سازی داده‌ها مستقیماً در خود RisingWave انجام میشود، و بار سنگین مدیریت #Lakehouse از دوش تیم‌های داده برداشته میشود. 💪
🧠 ویژگی‌های کلیدی نسخه‌ی RisingWave ۲.۶
🔰 پشتیبانی از داده‌های برداری (Vector) برای جست‌وجوی شباهت
🔰حالت جدید Copy-on-Write برای snapshotهای تمیزتر در Iceberg
🔰دستور VACUUM FULL برای پاک‌سازی و فشرده‌سازی داده‌ها
🔰سازگاری کامل با #Lakekeeper REST Catalog
🔰تنوع sinkهای جدید برای #Snowflake، #Redshift، #Elasticsearch
🔰حالت Memory-Only برای پردازش‌های فوق‌سریع
🎥 به‌زودی ویدیویی منتشر می‌کنم که در آن ساخت یک #Lakehouse عملی با
#MinIO + #Lakekeeper + #Spark + #Trino + #StarRocks
را گام‌به‌گام بررسی می‌کنیم. 🚀
به باور من، مسیر آینده‌ی زیرساخت‌های داده به‌سمتی پیش می‌رود که #Lakehouse بستر اصلی ذخیره و تحلیل داده‌ها شود،
و ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper یکی از گزینه‌های خوب سازمانی برای شروع این مسیر است. 🌟
👍3
ما در داتین به‌دنبال همکاری متخصص و پرانگیزه هستیم تا در نقش کارشناس ارشد زیرساخت کلان داده تیم پایگاه داده را همراهی کند. کارشناس ارشد زیرساخت کلان داده در داتین با پذیرفتن مسئولیت‌های زیر به پیش‌برد اهداف تیم کمک می‌کند:
- نصب و راه اندازی دیتابیس های NoSQL ای مثل Cassandra, elastic
- نصب و راه اندازی دیتابیس PostgreSQL
- نصب و راه اندازی Kafka
- راه اندازی کلاسترینگ و HA
- مانیتورینگ دیتابیس ها
دانش و مهارت های مورد نیاز:
- آشنا با مفاهیم NoSQL , SQL
- آشنا با مفاهیم دیتابیس های NoSQL ای نظیر elastic, Arangodb , Cassandra
- آشنا با مفاهیم دیتابیس PostgreSQL
- آشنا با مفاهیم Partitioning و Sharding
- آشنا با مفاهیم HA . کلاسترینگ و Replica Set
- آشنا با سیستم عامل Linux , windows Server
نکات حائز اهمیت:
محیط کاری پویا و یادگیری بالا
کار تیمی
- نصب و راه اندازی دیتابیس های NoSQL ای مثل Cassandra, elastic
- نصب و راه اندازی دیتابیس PostgreSQL
- نصب و راه اندازی Kafka
- راه اندازی کلاسترینگ و HA
- مانیتورینگ دیتابیس ها
دانش و مهارت های مورد نیاز:
- آشنا با مفاهیم NoSQL , SQL
- آشنا با مفاهیم دیتابیس های NoSQL ای نظیر elastic, Arangodb , Cassandra
- آشنا با مفاهیم دیتابیس PostgreSQL
- آشنا با مفاهیم Partitioning و Sharding
- آشنا با مفاهیم HA . کلاسترینگ و Replica Set
- آشنا با سیستم عامل Linux , windows Server
نکات حائز اهمیت:
محیط کاری پویا و یادگیری بالا
کار تیمی
❤1
نسل جدید سامانه‌های مدیریت دیتابیس؛ شروع یک مسیر تازه
فرض کنید یک دستیار هوش مصنوعی داشتید که:
👌متریک‌های دیتابیس را دائم بررسی می‌کرد،
👌کوئری‌های غیر‌بهینه را شناسایی و بهبود می‌داد،
👌ایندکس‌های قدیمی را بازسازی می‌کرد،
👌روند مصرف منابع را در بازه‌های زمانی تحلیل می‌کرد،
👌و حتی وقتی نزدیک به کمبود منابع بودید، پیشاپیش هشدار می‌داد.
دقیقاً همین تصویری است که نسل جدید سامانه‌های مدیریت دیتابیس در حال ساخت آن است.
🧩 چالش‌های امروز در مدیریت دیتابیس
ابزارهای مدیریتی سنتی دیتابیس، بیشتر ناظر هستند تا کنش‌گر.
وقتی 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