معرفی DuckLake v1.0؛ وقتی Lakehouse سریعتر و چابکتر میشود! 📢
چند سالی است که تب داغ معماری لیکهوس (Lakehouse) همه جا را گرفته است. در این مدت، اکوسیستم بزرگی از پروژهها، فرمتها (مثل Iceberg، Hudi و Delta Lake) و کاتالوگهای مختلف حول آن شکل گرفته است. حتی ابزارهای قدرتمندی مثل ClickHouse، StarRocks و PostgreSQL هم افزونههایی برای کار با این فرمتها ارائه کردهاند تا دادهها به شکل خام، اما قابل جستجو و آپدیت، ذخیره شوند.
وقتی به سراغ معماری لیکهوس میرویم، جداول ما در واقع مجموعهای از فایلها و پوشهها در یک ساختار منظم روی فضای ذخیرهسازی هستند. در این معماری، اطلاعات متادیتا (مانند نام و نوع ستونها، لیست فایلهای مرتبط با هر جدول و همچنین تاریخچه و نسخههای مختلف یک جدول پس از عملیات حذف، اضافه یا آپدیت) بر اساس استانداردهای ذکر شده، به صورت فایل ذخیره میشوند. برای مدیریت و کاوش در میان این فایلهای متادیتا و تسهیل دسترسی موتورهای پردازشی به دادهها، سامانههایی به نام «کاتالوگ» (Catalog) شکل گرفتند.
اما یک چالش بزرگ در این میان وجود دارد: اصرار بر ذخیره همهچیز (از جمله متادیتا) به صورت فایل! وقتی نرخ ورود و تغییر دادهها بالا میرود، ذخیره متادیتا به این شکل باعث تولید انبوهی از فایلهای کوچک (Small Files) میشود. این مسئله در کنار نیاز به استقرار و مدیریت یک لایه سرویس جدید به نام کاتالوگ، به یکی از چالشهای اصلی سامانههای فعلی تبدیل شده و هزینه سربار (overhead) سنگینی از نظر پیچیدگی و افت عملکرد به تیمها تحمیل میکند.
اینجا بود که داکلیک (DuckLake) با یک سوال ساده اما هوشمندانه متولد شد: چرا باید متادیتا را هم به صورت فایل خام ذخیره کنیم و این همه هزینه بپردازیم؟ بیایید این بخش حیاتی را به جایی که به آن تعلق دارد برگردانیم: یک پایگاه داده رابطهای (SQL) سریع و قابل اعتماد! 🤓
داکلیک (DuckLake) دقیقاً چیست و معماری آن چگونه است؟🦆
داکلیک یک فرمت استاندارد Lakehouse است که بر پایه همین ایده ساده و قدرتمند ساخته شده و بخش ذخیره دادههای آن کاملا منطبق بر استاندارد آیسبرگ است. معماری داکلیک از دو لایه مجزا تشکیل شده است:
🔰 لایه داده (Data Layer): ذخیره دادهها در قالب فایلهای تغییرناپذیر (Immutable) Parquet روی Object Storage (مثل S3).
🔰 لایه متادیتا (Metadata Layer): نقطه قوت اصلی داکلیک! تمام متادیتا در یک پایگاه داده رابطهای (SQL) مانند PostgreSQL، SQLite یا خود DuckDB ذخیره میشود.
💡 نتیجه این معماری: داکلیک کاتالوگ را در دل خود دارد و نیازی به مدیریت کاتالوگهای خارجی سنگین (مثل AWS Glue یا Unity Catalog) ندارید.
چرا داکلیک؟ (مقایسه با Apache Iceberg و حل معمای فایلهای کوچک) 🆚
همانطور که پیشتر اشاره کردیم، با وجود ابزارهای قدرتمندی مثل Iceberg، داکلیک دقیقاً روی پاشنه آشیل این معماری دست میگذارد. در سیستمهایی مانند آیسبرگ، زمانی که حجم و سرعت ورود داده بالاست، اصرار بر ذخیره متادیتا به صورت فایل منجر به تولید انبوهی از فایلهای کوچک (Small Files) میشود. اسکن کردن این فایلهای متعدد روی شبکه برای یافتن محل دقیق دادهها، فرآیندی کند و زمانبر است.
برای رفع این چالش در معماریهای رایج، از عملیاتی به نام فشردهسازی (Compaction) استفاده میشود که باید به صورت منظم اجرا شده تا فایلهای کوچک متادیتا را تجمیع، یکپارچه و مرتب کند. اما مسئله اینجاست که خود این عملیات نگهداری، به شدت پرهزینه است، منابع سیستم را درگیر میکند و گاهی اجرای آن ساعتها طول میکشد!
اما در داکلیک، از آنجایی که متادیتا از همان ابتدا درون یک پایگاه داده SQL ذخیره میشود، این صورتمسئله به طور کامل پاک شده است! با حذف مشکل تولید فایلهای کوچک متادیتا و در نتیجه عدم نیاز به عملیات سنگین Compaction برای آنها، داکلیک کوئریهای کاتالوگ را به جای صدها میلیثانیه، تنها در چند میلیثانیه (۱۰ تا ۱۰۰ برابر سریعتر) و با کمترین درگیری منابع انجام میدهد.
کدام را انتخاب کنیم؟
✨ آیسبرگ: برای دادههای مقیاس پتابایت (Petabyte-scale)، سازمانهای بزرگ و استفاده همزمان از چندین موتور پردازشی مختلف.
✨ داکلیک/DuckLake: برای دادههای زیر ۱۰۰ ترابایت، تیمهای کوچکتر که سادگی، سرعت و کاهش هزینهها برایشان اولویت دارد.
🔥 جمع بندی: داکلیک یک تغییر پارادایم نیست، بلکه یک بازگشت به اصول مهندسی داده است. این ابزار با تکیه بر سرعت و قدرت اثباتشدهی پایگاههای داده رابطهای، راه حلی ارائه میدهد که برای اکثر سازمانها مقرونبهصرفهتر، سریعتر و بسیار سادهتر است.
منبع :
https://ducklake.select/2026/04/13/ducklake-10
فایل پی دی اف خصوصیات نسخه ۱ داکلیک را از این آدرس می توانید دانلود کنید :
https://ble.ir/data_engineering/-6112696713536326695/1777121370760