‍ از استانداردسازی تا ساده‌سازی: آینده‌ی Iceberg در مهندسی داده

🔍تحلیلی بر دو تحول مهم: DuckLake و مقاله جدید MinIO


احتمالاً توی یک سال گذشته، بارها چشم‌تون به مقالات، ابزارها، یا گفتگوهایی افتاده که حول‌وحوش موضوعی به اسم #Iceberg می‌چرخن — یه استاندارد باز و ساخت‌یافته برای ذخیره داده‌ها به‌صورت خام، اما با قابلیت‌هایی شبیه پایگاه داده:

📌امکان اجرای کوئری‌های تحلیلی مستقیم روی فایل‌های Parquet

📌پشتیبانی از schema evolution و تراکنش‌های ACID

📌و جداسازی کامل ذخیره‌سازی از موتور پردازش

🧊 به‌جرات میشه گفت که #Iceberg یکی از ترندهای داغ این روزهای مهندسی داده‌ست — از Google BigQuery گرفته تا AWS S3، از Dremio تا Snowflake و پروژه Polaris، همگی در حال پشتیبانی مستقیم یا بومی از Iceberg هستن.

و البته این موضوع فقط جهانی نیست — همین چند هفته پیش، در یکی از جلسات مشاوره‌ که با یکی از شرکت‌های بزرگ فولادی کشور بود، موضوع جلسه بررسی بهترین راه برای طراحی، راه‌اندازی، و مدیریت یک Lakehouse مبتنی بر Iceberg بود. کاری که تیم فنی این شرکت، نسخه اولیه آنرا راه اندازی کرده بود. 🚀

🔄 اما دو اتفاق باعث شد که احساس کنم : آینده‌ی Iceberg بسیار ساده‌تر و سبک‌تر خواهد بود.

🌟 اولی معرفی DuckLake بود - https://ducklake.select.

در دنیایی که پر بود از سرویس‌های کاتالوگ مختلف (Hive Metastore، Glue، Project Nessie، JDBC Metastore و...)، #DuckLake اومد و گفت:

«همه‌ی اینا رو بذارید کنار! من با یه دیتابیس SQL ساده، همه کارهای مدیریت متادیتا و فایل‌های داده رو انجام می‌دم.»

📦 داده‌ها همون Parquet هستن روی object storage، اما متادیتا داخل یه دیتابیس ساده مثل #DuckDB یا #Postgres ذخیره می‌شن. همه چیز از طریق #SQL مدیریت می‌شه. بدون نیاز به سرویس‌های جانبی، بدون پیچیدگی. دقیقاً شبیه #SQLite برای دیتالیک‌ها.

🔥 و استقبال خوبی هم ازش شده. چون ساده‌تر از Iceberg معمولی راه می‌افته و سربار کمتری داره.

🧠 دومین اتفاق، مقاله‌ای بود که همین چند روز پیش از طرف MinIO منتشر شد.
https://blog.min.io/the-case-for-native-iceberg-catalog-apis-and-unified-governance-in-object-storage

این مقاله به یه نقطه‌ضعف مهم در معماری‌های فعلی دیتالیک اشاره می‌کرد:

«متادیتا و دسترسی به فایل‌های واقعی داده، در دو سیستم جداگانه کنترل می‌شن. همین باعث می‌شه امنیت و حاکمیت داده ناقص باقی بمونه.»

یعنی ممکنه کاربر به جدول Iceberg مجوز نداشته باشه، ولی هنوز بتونه مستقیم فایل‌های #Parquet رو از #S3 یا #MinIO بخونه! 😬

استوریج MinIO پیشنهاد داده که APIهای Iceberg Catalog به‌صورت بومی در خود پلتفرم ذخیره‌سازی تعبیه بشن، طوری که هم متادیتا و هم دسترسی به فایل‌ها، از یک‌جا و با یک مدل امنیتی مدیریت بشن. این یعنی سادگی بیشتر، امنیت بهتر، و مدیریت یکپارچه‌تر.

🔮 پیش‌بینی من؟
ما داریم به سمتی می‌ریم که: Iceberg دیگه یه «ابزار حرفه‌ای مخصوص متخصص‌ها» نیست — بلکه تبدیل می‌شه به یک استاندارد ساده، امن، و در دسترس برای همه تیم‌های داده

🌊 به‌زودی، ساخت یک دریاچه‌داده قدرتمند، به اندازه راه‌اندازی یک دیتابیس ساده خواهد بود. و Iceberg ستون اصلی این تحول باقی می‌مونه.

#ApacheIceberg #DuckLake #MinIO #DataLakehouse #MetadataGovernance #ObjectStorage #OpenTableFormats #SQL #دیتالیک #مهندسی_داده #Parquet #BigData

‍ لیک‌هوس در مسیر بلوغ: نگاهی به نسخه جدید #RisingWave و ادغام عمیق آن با #Iceberg

در دنیای امروز که هر سازمان مجموعه‌ای از سرویس‌ها و جریان‌های داده‌ای متنوع دارد، نیاز به بستری متمرکز برای ذخیره و مدیریت «خودِ داده‌ها» بیش از همیشه احساس می‌شود: بستری مستقل از ابزارها و موتورهای پردازشی، جایی که داده‌ها به‌صورت خام و ساخت‌یافته نگهداری شوند.

این معماری نه‌تنها نظم داده‌ها را تضمین می‌کند، بلکه بستر ایده‌آلی برای توسعه سامانه‌های هوش مصنوعی و مدل‌های یادگیری ماشین فراهم می‌سازد؛ زیرا داده‌های تمیز و استاندارد، پایه‌ی هر سیستم هوشمند هستند.

📌 اینجا همان جایی است که مفهوم #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 یکی از گزینه‌های خوب سازمانی برای شروع این مسیر است. 🌟