نگاهی به اهمیت پشتیبانی DuckDB از ٰVortex و شروع رواج نسل جدید فرمت‌های ذخیره داده
سال‌ها Apache Parquet استاندارد اصلی برای ذخیره‌سازی داده‌های خام بوده است؛ فرمتی که داده‌ها را به‌صورت فشرده، ستون‌محور و آماده برای تحلیل و پردازش‌های سنگین ذخیره می‌کند و عملاً ستون فقرات بسیاری از پلتفرم‌های تحلیلی بخصوص در حوزه hashtag#Lakehouse به شمار می‌رود.
اما در سال‌های اخیر، نیازهای جدیدی مانند بازیابی سریع ویژگی‌ها در هوش مصنوعی، جستجوی برداری، اسکورینگ کم‌تأخیر و پردازش‌های بلادرنگ باعث شده‌اند نسل تازه‌ای از فرمت‌های ستونی معرفی شوند، فرمت‌هایی که علاوه بر حفظ مزایای پارکت، قابلیت‌های کاملاً جدیدی ارائه می‌کنند:
🔥 سرعت اسکن بسیار بالاتر
🔥 دسترسی تصادفی (Random Access) فوق‌العاده سریع به رکوردها
🔥 ذخیره آمار توکار (Statistics) برای حذف سریع فایل‌های نامرتبط با کوئری
🔥 سازگاری کامل و Zero-Copy با Apache Arrow برای لود بسیار سریع داده
یکی از مهم‌ترین این فرمت‌ها hashtag#Vortex است که بر پایه معماری قابل‌گسترش و با امکان استفاده از encodingها و layoutهای جدید طراحی شده.
طبق گزارش‌ها، Vortex حدود ۱۰۰ برابر دسترسی تصادفی سریع‌تر و ۱۰ تا ۲۰ برابر اسکن سریع‌تر نسبت به hashtag#Parquet ارائه می‌دهد.
خبر خوب این که hashtag#DuckDB در نسخه 4.2 رسماً از Vortex پشتیبانی می‌کند؛ اتفاقی که می‌تواند در کاربردهایی مثل فیلترینگ، جوین‌ها، نرمال‌سازی داده، Feature Engineering و بسیاری از پردازش‌های تحلیلی، تحول جدی ایجاد کند.
همچنین کار روی پشتیبانی Apache hashtag#Iceberg از Vortex نیز آغاز شده و به‌نظر می‌رسد به‌زودی این فرمت به‌صورت کامل وارد اکوسیستم hashtag#Lakehouse شود که این می‌تواند نقطه عطفی در این حوزه باشد.
مرجع اصلی پست : https://www.linkedin.com/feed/update/urn:li:activity:7394922128225144832/
سال‌ها Apache Parquet استاندارد اصلی برای ذخیره‌سازی داده‌های خام بوده است؛ فرمتی که داده‌ها را به‌صورت فشرده، ستون‌محور و آماده برای تحلیل و پردازش‌های سنگین ذخیره می‌کند و عملاً ستون فقرات بسیاری از پلتفرم‌های تحلیلی بخصوص در حوزه hashtag#Lakehouse به شمار می‌رود.
اما در سال‌های اخیر، نیازهای جدیدی مانند بازیابی سریع ویژگی‌ها در هوش مصنوعی، جستجوی برداری، اسکورینگ کم‌تأخیر و پردازش‌های بلادرنگ باعث شده‌اند نسل تازه‌ای از فرمت‌های ستونی معرفی شوند، فرمت‌هایی که علاوه بر حفظ مزایای پارکت، قابلیت‌های کاملاً جدیدی ارائه می‌کنند:
🔥 سرعت اسکن بسیار بالاتر
🔥 دسترسی تصادفی (Random Access) فوق‌العاده سریع به رکوردها
🔥 ذخیره آمار توکار (Statistics) برای حذف سریع فایل‌های نامرتبط با کوئری
🔥 سازگاری کامل و Zero-Copy با Apache Arrow برای لود بسیار سریع داده
یکی از مهم‌ترین این فرمت‌ها hashtag#Vortex است که بر پایه معماری قابل‌گسترش و با امکان استفاده از encodingها و layoutهای جدید طراحی شده.
طبق گزارش‌ها، Vortex حدود ۱۰۰ برابر دسترسی تصادفی سریع‌تر و ۱۰ تا ۲۰ برابر اسکن سریع‌تر نسبت به hashtag#Parquet ارائه می‌دهد.
خبر خوب این که hashtag#DuckDB در نسخه 4.2 رسماً از Vortex پشتیبانی می‌کند؛ اتفاقی که می‌تواند در کاربردهایی مثل فیلترینگ، جوین‌ها، نرمال‌سازی داده، Feature Engineering و بسیاری از پردازش‌های تحلیلی، تحول جدی ایجاد کند.
همچنین کار روی پشتیبانی Apache hashtag#Iceberg از Vortex نیز آغاز شده و به‌نظر می‌رسد به‌زودی این فرمت به‌صورت کامل وارد اکوسیستم hashtag#Lakehouse شود که این می‌تواند نقطه عطفی در این حوزه باشد.
مرجع اصلی پست : https://www.linkedin.com/feed/update/urn:li:activity:7394922128225144832/
Linkedin
#dataengineering #softwareengineering | Dipankar Mazumdar
DuckDB ❤️ Vortex File Format
I wrote about newer file formats such as Vortex before.
Typically, the columnar analytics de facto is Apache Parquet.
And there's a lot to like about Parquet - columnar layout, per-page compression, strong encoding schemes…
I wrote about newer file formats such as Vortex before.
Typically, the columnar analytics de facto is Apache Parquet.
And there's a lot to like about Parquet - columnar layout, per-page compression, strong encoding schemes…
👍4
Forwarded from عکس نگار
وقتی Excel به ClickHouse متصل می‌شود
در سال‌های اخیر، با رشد تصاعدی حجم داده در شرکت‌های بزرگ ایرانی، زیرساخت‌های سنتی مانند Oracle و SQL Server که سال‌ها نقش ستون فقرات ذخیره‌سازی داده‌ها را داشتند، دیگر پاسخ‌گوی نیازهای تحلیلی جدید نیستند. بسیاری از این سازمان‌ها در گزارش‌گیری و تحلیل داده‌های حجیم دچار کندی محسوس شده‌اند.
در نتیجه، تمایل به سمت استفاده از دیتابیس‌های تحلیلی نوین مانند hashtag#ClickHouse و hashtag#StarRocks افزایش یافته است، فناوری‌هایی که با معماری columnar و توان پردازشی بالا، به‌خوبی برای تحلیل‌های سنگین و بلادرنگ طراحی شده‌اند.
در یکی از مشاوره‌های اخیرم با یکی از فروشگاه‌های زنجیره‌ای بزرگ کشور، در حال بررسی #ClickHouse برای ذخیره و سرویس‌دهی تراکنش‌های روزانه هستیم.
🔥اما چالش اصلی این بود که تیم فنی و کاربران نهایی سال‌ها با استک مایکروسافت کار کرده بودند؛ بیشتر گزارش‌ها از طریق Excel و با استفاده از SSAS و Power Pivot تولید می‌شد. بنابراین به دنبال راهکاری بودیم که بدون تغییر اساسی در محیط گزارش‌گیری کاربران، بتوان از ClickHouse نیز بهره برد.
در این مسیر، به دنبال یک ROLAP Engine بودیم که از MDX پشتیبانی کند و به پروژه‌ای جالب به نام eMondrian رسیدیم.
🔰 پروژه eMondrian در واقع نسخه‌ای توسعه‌یافته از Mondrian OLAP Engine است که امکان اتصال به دیتابیس‌های مدرن از جمله ClickHouse را فراهم می‌کند. با این ابزار می‌توان:
✔️همان مدل چند‌بعدی (Cube) را روی داده‌های ClickHouse تعریف کرد،
✔️همچنان از MDX Queryها استفاده نمود،
✔️و حتی گزارش‌ها را مستقیماً از طریق Excel یا Power BI به‌صورت Live Connection مشاهده کرد.
در تست‌های اولیه، سرعت اجرای کوئری‌ها روی داده‌های چندصدمیلیونی بسیار قابل‌قبول بود و ساختار XML-محور schema نیز اجازه تعریف دقیق ابعاد و اندازه‌ها را می‌دهد. تنها نکته مهم، نیاز به دقت در طراحی schema است، چرا که برخلاف SSAS در اینجا خبری از Wizard نیست.
✅ مزیت اصلی eMondrian
راه‌حل کم‌هزینه و سریع برای «نگه داشتن لایهٔ گزارش‌گیری فعلی (Excel/MDX)» و در عین حال انتقال داده‌ها به ClickHouse؛ مخصوصاً مناسب برای مهاجرت تدریجی و جلوگیری از بازنویسی کامل داشبوردها.
ریسک‌ها / محدودیت‌ها:
🔴قابلیت‌های کامل SSAS را ندارد، برخی امکانات پیشرفته ممکن است موجود نباشند یا متفاوت اجرا شوند.
🔴ممکن است در گزارشات چند سطحی، مجموع‌ها یا گزارش‌های زمانی، اختلاف در نتایج دیده شود، باید با دقت تست شوند.
🔴پروژه هنوز وابسته به به‌روزرسانی‌ها و رفع باگ‌هاست؛ ممکن است نیاز به توسعه یا patch محلی باشد.
🔴طراحی schema و tune کردن ClickHouse برای عملکرد مطلوب حیاتی است، بدون این، ممکن است سرعت یا مصرف منابع مشکل‌ساز شود.
🔴سازگاری کامل با همه نسخه‌های Excel/Power BI سرویس ممکن نیست، بعضی ابزارها رفتار متفاوتی دارند.
در حال حاضر دو نسخه از این موتور موجود است:
🔹 نسخه اصلی Pentaho Mondrian که سال‌هاست در پروژه‌های BI استفاده می‌شود،
🔹 و نسخه توسعه‌یافته eMondrian که برای اتصال به دیتابیس‌های مدرن مانند ClickHouse بهینه‌سازی شده است.
ما در حال تست نسخه دوم هستیم که برای ClickHouse مناسب‌تر است.
اگر تجربه‌ای در استفاده از Mondrian یا eMondrian دارید، به‌ویژه در ترکیب با ClickHouse، خوشحال می‌شویم از تجربه شما هم بتوانیم استفاده کنیم 🙌
در سال‌های اخیر، با رشد تصاعدی حجم داده در شرکت‌های بزرگ ایرانی، زیرساخت‌های سنتی مانند Oracle و SQL Server که سال‌ها نقش ستون فقرات ذخیره‌سازی داده‌ها را داشتند، دیگر پاسخ‌گوی نیازهای تحلیلی جدید نیستند. بسیاری از این سازمان‌ها در گزارش‌گیری و تحلیل داده‌های حجیم دچار کندی محسوس شده‌اند.
در نتیجه، تمایل به سمت استفاده از دیتابیس‌های تحلیلی نوین مانند hashtag#ClickHouse و hashtag#StarRocks افزایش یافته است، فناوری‌هایی که با معماری columnar و توان پردازشی بالا، به‌خوبی برای تحلیل‌های سنگین و بلادرنگ طراحی شده‌اند.
در یکی از مشاوره‌های اخیرم با یکی از فروشگاه‌های زنجیره‌ای بزرگ کشور، در حال بررسی #ClickHouse برای ذخیره و سرویس‌دهی تراکنش‌های روزانه هستیم.
🔥اما چالش اصلی این بود که تیم فنی و کاربران نهایی سال‌ها با استک مایکروسافت کار کرده بودند؛ بیشتر گزارش‌ها از طریق Excel و با استفاده از SSAS و Power Pivot تولید می‌شد. بنابراین به دنبال راهکاری بودیم که بدون تغییر اساسی در محیط گزارش‌گیری کاربران، بتوان از ClickHouse نیز بهره برد.
در این مسیر، به دنبال یک ROLAP Engine بودیم که از MDX پشتیبانی کند و به پروژه‌ای جالب به نام eMondrian رسیدیم.
🔰 پروژه eMondrian در واقع نسخه‌ای توسعه‌یافته از Mondrian OLAP Engine است که امکان اتصال به دیتابیس‌های مدرن از جمله ClickHouse را فراهم می‌کند. با این ابزار می‌توان:
✔️همان مدل چند‌بعدی (Cube) را روی داده‌های ClickHouse تعریف کرد،
✔️همچنان از MDX Queryها استفاده نمود،
✔️و حتی گزارش‌ها را مستقیماً از طریق Excel یا Power BI به‌صورت Live Connection مشاهده کرد.
در تست‌های اولیه، سرعت اجرای کوئری‌ها روی داده‌های چندصدمیلیونی بسیار قابل‌قبول بود و ساختار XML-محور schema نیز اجازه تعریف دقیق ابعاد و اندازه‌ها را می‌دهد. تنها نکته مهم، نیاز به دقت در طراحی schema است، چرا که برخلاف SSAS در اینجا خبری از Wizard نیست.
✅ مزیت اصلی eMondrian
راه‌حل کم‌هزینه و سریع برای «نگه داشتن لایهٔ گزارش‌گیری فعلی (Excel/MDX)» و در عین حال انتقال داده‌ها به ClickHouse؛ مخصوصاً مناسب برای مهاجرت تدریجی و جلوگیری از بازنویسی کامل داشبوردها.
ریسک‌ها / محدودیت‌ها:
🔴قابلیت‌های کامل SSAS را ندارد، برخی امکانات پیشرفته ممکن است موجود نباشند یا متفاوت اجرا شوند.
🔴ممکن است در گزارشات چند سطحی، مجموع‌ها یا گزارش‌های زمانی، اختلاف در نتایج دیده شود، باید با دقت تست شوند.
🔴پروژه هنوز وابسته به به‌روزرسانی‌ها و رفع باگ‌هاست؛ ممکن است نیاز به توسعه یا patch محلی باشد.
🔴طراحی schema و tune کردن ClickHouse برای عملکرد مطلوب حیاتی است، بدون این، ممکن است سرعت یا مصرف منابع مشکل‌ساز شود.
🔴سازگاری کامل با همه نسخه‌های Excel/Power BI سرویس ممکن نیست، بعضی ابزارها رفتار متفاوتی دارند.
در حال حاضر دو نسخه از این موتور موجود است:
🔹 نسخه اصلی Pentaho Mondrian که سال‌هاست در پروژه‌های BI استفاده می‌شود،
🔹 و نسخه توسعه‌یافته eMondrian که برای اتصال به دیتابیس‌های مدرن مانند ClickHouse بهینه‌سازی شده است.
ما در حال تست نسخه دوم هستیم که برای ClickHouse مناسب‌تر است.
اگر تجربه‌ای در استفاده از Mondrian یا eMondrian دارید، به‌ویژه در ترکیب با ClickHouse، خوشحال می‌شویم از تجربه شما هم بتوانیم استفاده کنیم 🙌
👍2
چرا Intuit به‌جای ClickHouse، سراغ StarRocks رفت؟
اخیراً تیم IPS در شرکت Intuit (سازنده QuickBooks، TurboTax، CreditKarma و ده‌ها سرویس مالی دیگر) تجربه بسیار جالبی منتشر کرده‌اند.
https://celerdata-com.cdn.ampproject.org/c/s/celerdata.com/blog/how-intuit-achieved-sub-4-second-real-time-analytics-at-100k-events-per-second?hs_amp=true
آنها سالانه ۱۴۰ میلیارد تراکنش پردازش می‌کنند و در پیک کاری به ۱۰۰,۰۰۰ رویداد در ثانیه می‌رسند.
💡 نیاز اصلی‌شان: تاخیر سرتاسری کمتر از ۴ ثانیه برای تغذیه مدل‌های ML و تحلیل رفتار لحظه‌ای کاربران.
در این سطح از Scale و Real-Time، معماری قبلی آنها (Apache Druid) دیگر جوابگو نبود. Intuit چند گزینه را بررسی کرد: ClickHouse، Pinot، DuckDB … اما در نهایت StarRocks را انتخاب کرد.
دلایل انتخاب آنها برای ما - به‌خصوص شرکت‌های ایرانی - کاملاً کاربردی و قابل تعمیم است.
🔥 چرا #StarRocks انتخاب شد؟
1) پشتیبانی Native از Upsert و جداول منطبق بر منطق Primary Key
در معماری‌های Real-Time، داشتن State برای هر کاربر، تراکنش یا session ضروری است.
در کلیک‌هوس، upsert واقعی وجود ندارد و نیاز به workaroundهایی مثل ReplacingMergeTree یا CollapsingMergeTree است. StarRocks این مشکل را به‌صورت بومی حل کرده.
2) پرفورمنس بسیار قوی روی Multi-Table Join
در سناریوهایی مثل:
✔️ترکیب داده‌های کلیک‌استریم با پروفایل کاربر
✔️عملیات Join بین چند دامنه مختلف (مثلاً محصولات مالی Intuit)
✔️ساخت Featureهای پیچیده ML
کلیک‌هوس به دلیل طراحی column-oriented pure و join planner محدود، در joins سنگین، عقب می‌ماند.
✅ در همین بخش، #StarRocks مزیت قطعی دارد.
3) تاخیر بسیار کم در Query (زیر ۵۰۰ms در TP99)
برای مدل‌های ML که روی آخرین ۳۰ کلیک کاربر تصمیم‌گیری می‌کنند، هر میلی‌ثانیه اهمیت دارد.
دستاورد StarRocks در تست Intuit:
✔️درج صدهزار رکورد در ثانیه
✔️ ۰.۵ ثانیه latency در ۹۹٪ کوئری‌ها
✔️ تازگی داده‌ها : زیر ۱ ثانیه
این سطح از پرفورمنس با ClickHouse سخت‌تر و پرهزینه‌تر است.
4) معماری Shared-Data مشابه Lakehouse با تکیه بر S3
استارراکز می‌تواند:
✔️ جدا کردن Compute از Storage
✔️داشتن چند warehouse مجزا
✔️ قابلیت resource group برای multi-tenancy واقعی
کلیک هوس در نسخه Cloud این مسیر را آغاز کرده، اما اکوسیستم cloud-native StarRocks پخته‌تر است.
5) سادگی عملیاتی (Operational Simplicity)
کلیک‌هوس ابزارهای عملیاتی خوب دارد، اما scale-out پیشرفته نیازمند:
✔️ عملیات sharding دستی
✔️معماری پیچیده ReplicatedMergeTree
✔️ابزارهای جانبی custom
استارراکز این‌ها را تقریباً به‌صورت plug-and-play ارائه می‌کند.
⭐️ جمع‌بندی
تجربه Intuit نشان می‌دهد:
اگر real-time واقعی، joins سنگین، upsert و latency زیر ۲–۳ ثانیه نیاز دارید، StarRocks انتخاب بسیار مناسب‌تری خواهد بود.
اگر batch analytics با مقیاس بسیار بزرگ دارید، ClickHouse همچنان پادشاه است.
امروزه حجم عظیم داده در بسیاری از شرکت‌ها و سازمان‌های ایرانی، ضرورت استفاده از دیتابیس‌های تحلیلی مدرن را بیش از هر زمان دیگری آشکار کرده است. مجموعه‌هایی که می‌خواهند تحلیل‌های Real-Time، گزارش‌های سریع، داشبوردهای منعطف و زیرساخت داده قابل‌اتکا داشته باشند، ناچارند بین نسل جدید OLAPها، مثل #ClickHouse، #StarRocks یا Apache #Doris انتخاب کنند.
اخیراً تیم IPS در شرکت Intuit (سازنده QuickBooks، TurboTax، CreditKarma و ده‌ها سرویس مالی دیگر) تجربه بسیار جالبی منتشر کرده‌اند.
https://celerdata-com.cdn.ampproject.org/c/s/celerdata.com/blog/how-intuit-achieved-sub-4-second-real-time-analytics-at-100k-events-per-second?hs_amp=true
آنها سالانه ۱۴۰ میلیارد تراکنش پردازش می‌کنند و در پیک کاری به ۱۰۰,۰۰۰ رویداد در ثانیه می‌رسند.
💡 نیاز اصلی‌شان: تاخیر سرتاسری کمتر از ۴ ثانیه برای تغذیه مدل‌های ML و تحلیل رفتار لحظه‌ای کاربران.
در این سطح از Scale و Real-Time، معماری قبلی آنها (Apache Druid) دیگر جوابگو نبود. Intuit چند گزینه را بررسی کرد: ClickHouse، Pinot، DuckDB … اما در نهایت StarRocks را انتخاب کرد.
دلایل انتخاب آنها برای ما - به‌خصوص شرکت‌های ایرانی - کاملاً کاربردی و قابل تعمیم است.
🔥 چرا #StarRocks انتخاب شد؟
1) پشتیبانی Native از Upsert و جداول منطبق بر منطق Primary Key
در معماری‌های Real-Time، داشتن State برای هر کاربر، تراکنش یا session ضروری است.
در کلیک‌هوس، upsert واقعی وجود ندارد و نیاز به workaroundهایی مثل ReplacingMergeTree یا CollapsingMergeTree است. StarRocks این مشکل را به‌صورت بومی حل کرده.
2) پرفورمنس بسیار قوی روی Multi-Table Join
در سناریوهایی مثل:
✔️ترکیب داده‌های کلیک‌استریم با پروفایل کاربر
✔️عملیات Join بین چند دامنه مختلف (مثلاً محصولات مالی Intuit)
✔️ساخت Featureهای پیچیده ML
کلیک‌هوس به دلیل طراحی column-oriented pure و join planner محدود، در joins سنگین، عقب می‌ماند.
✅ در همین بخش، #StarRocks مزیت قطعی دارد.
3) تاخیر بسیار کم در Query (زیر ۵۰۰ms در TP99)
برای مدل‌های ML که روی آخرین ۳۰ کلیک کاربر تصمیم‌گیری می‌کنند، هر میلی‌ثانیه اهمیت دارد.
دستاورد StarRocks در تست Intuit:
✔️درج صدهزار رکورد در ثانیه
✔️ ۰.۵ ثانیه latency در ۹۹٪ کوئری‌ها
✔️ تازگی داده‌ها : زیر ۱ ثانیه
این سطح از پرفورمنس با ClickHouse سخت‌تر و پرهزینه‌تر است.
4) معماری Shared-Data مشابه Lakehouse با تکیه بر S3
استارراکز می‌تواند:
✔️ جدا کردن Compute از Storage
✔️داشتن چند warehouse مجزا
✔️ قابلیت resource group برای multi-tenancy واقعی
کلیک هوس در نسخه Cloud این مسیر را آغاز کرده، اما اکوسیستم cloud-native StarRocks پخته‌تر است.
5) سادگی عملیاتی (Operational Simplicity)
کلیک‌هوس ابزارهای عملیاتی خوب دارد، اما scale-out پیشرفته نیازمند:
✔️ عملیات sharding دستی
✔️معماری پیچیده ReplicatedMergeTree
✔️ابزارهای جانبی custom
استارراکز این‌ها را تقریباً به‌صورت plug-and-play ارائه می‌کند.
⭐️ جمع‌بندی
تجربه Intuit نشان می‌دهد:
اگر real-time واقعی، joins سنگین، upsert و latency زیر ۲–۳ ثانیه نیاز دارید، StarRocks انتخاب بسیار مناسب‌تری خواهد بود.
اگر batch analytics با مقیاس بسیار بزرگ دارید، ClickHouse همچنان پادشاه است.
❤3👍1
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