تجربه استفاده از 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-
پست رضا دهقانی در لینکدین
تجربه کار با 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-
Linkedin
#dataengineering #starrocks #lakehouse #warehouse #استارراکس | Reza Dehghani
تو جریان پروژه های کاری دنبال راه‌حلی بودیم که بتونیم داده‌هامون رو همزمان سریع و از منابع مختلف تحلیل کنیم. بعد از مقایسه ابزارهای مختلف، در نهایت StarRocks رو انتخاب کردم و تجربه متفاوت و جالبی بود.
استارراکس خودش رو یه دیتاورهوس نسل جدید معرفی میکنه…
استارراکس خودش رو یه دیتاورهوس نسل جدید معرفی میکنه…
❤1👍1🙏1
مهندسی داده
Apache Doris vs ClickHouse.pdf
آپاچی دوریس و سرعت بالا در سناریوهای مبتنی بر JOIN
- توضیحی راجع به pdf بالا ـ
اخیراً گزارشی از سمت VeloDB (Powered by Apache Doris) منتشر شد که در آن، عملکرد Apache Doris و ClickHouse در سناریوهای سنگین مبتنی بر JOIN و کوئری‌های تحلیلی پیچیده با هم مقایسه شده‌اند.
در همین زمینه، تجربه اخیر اسنپ‌فود با 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
- توضیحی راجع به 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
Linkedin
#dataengineering #starrocks #lakehouse #warehouse #استارراکس | Reza Dehghani
تو جریان پروژه های کاری دنبال راه‌حلی بودیم که بتونیم داده‌هامون رو همزمان سریع و از منابع مختلف تحلیل کنیم. بعد از مقایسه ابزارهای مختلف، در نهایت StarRocks رو انتخاب کردم و تجربه متفاوت و جالبی بود.
استارراکس خودش رو یه دیتاورهوس نسل جدید معرفی میکنه…
استارراکس خودش رو یه دیتاورهوس نسل جدید معرفی میکنه…
👍2🙏1
از 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
💡 اما 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
مدت‌ها بود که پروژه 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
Linkedin
Databricks Acquires Mooncake Labs to Boost Lakebase | Databricks posted on the topic | LinkedIn
We’re excited to announce that Databricks has acquired Mooncake Labs to accelerate the vision of Lakebase, a new category of OLTP database built on Postgres and optimized for AI agents!
AI agents are transforming application development, and traditional…
AI agents are transforming application development, and traditional…
👍3😱1
دو منبع عالی برای یادگیری سریع و عمیق 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 مدرسه مهندسی داده سپهرام
وقتی 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
نگاهی به اهمیت پشتیبانی 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 مدرسه مهندسی داده سپهرام
از 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
👍6❤2