‍ معرفی DuckLake: ساده‌سازی Lakehouse با قدرت SQL

🔍 فرض کنید می‌خواهیم رفتار کاربران روی یک فروشگاه آنلاین را تحلیل کنیم. آمار کلی مثل نرخ کلیک، نرخ تبدیل و زمان حضور را در پایگاه‌داده ذخیره می‌کنیم — اما داده‌های ریز و حجیم مثل تک‌تک کلیک‌های کاربران روی محصولات را به صورت خام ذخیره می‌کنیم، بدون اینکه دیتابیس‌های عملیاتی را سنگین کنیم. این داده‌های خام به شکلی بهینه ذخیره می‌شوند که هر زمان نیاز داشتیم بتوانیم روی آن‌ها کوئری اجرا کنیم و تحلیل عمیق‌تری داشته باشیم.

🧠 این همان فلسفه‌ی #Lakehouse است:

ترکیب بهترین ویژگی‌های Data Lake (انعطاف و مقیاس‌پذیری) و Data #Warehouse (ساختارمندی و قابلیت تحلیل)

اما واقعیت این است که #Lakehouse ها در عمل با پیچیدگی‌هایی همراه هستند:
برای هر جدول، باید اطلاعاتی مانند schema، نسخه‌ها، تغییرات، پارتیشن‌بندی و ... در فراداده‌ها نگه داشته شود. این یعنی نیاز به سیستم‌های اضافی کاتالوگ‌ها، متادیتا‌ها و گاهی سرویس‌‌های اضافی برای مدیریت نسخه‌ها

اما : چرا وقتی به هر حال به یک دیتابیس نیاز داریم (برای کاتالوگ)، از ابتدا همه چیز را در SQL مدیریت نکنیم؟

📢 امروز #DuckDB با معرفی #DuckLake، پاسخی جسورانه و منطقی به این سوال داده است.

✅ اما سوال اصلی : DuckLake چیست؟

استاندارد DuckLake یک فرمت Open Table جدید برای معماری Lakehouse است که:

داده‌ها را در قالب‌های باز مانند Parquet در Blob Storage ذخیره می‌کند؛

اما تمام فراداده‌ها (metadata)، snapshotها، schemaها و آمار را در یک پایگاه داده SQL ساده (مثل PostgreSQL یا خود DuckDB) مدیریت می‌کند.

🔍 چرا DuckLake یک تغییر بنیادین است؟

1. سادگی واقعی

برخلاف Iceberg و Delta که برای یک append ساده، باید چندین فایل JSON و Avro ایجاد یا به‌روز کرد، در DuckLake همه چیز فقط چند query ساده SQL است.
نیازی به لایه‌ی اضافه‌ی catalog server یا فایل‌های اضافی نیست. فقط یک دیتابیس و فایل‌های Parquet.

2. مدیریت تراکنش‌پذیر (ACID) واقعی

تغییرات در جدول‌ها، snapshotها و آمار ستون‌ها در یک تراکنش واحد SQL انجام می‌شود. این یعنی:
📌atomic commitها؛
📌پشتیبانی از تغییرات پیچیده و multi-table؛
📌 بدون ترس از ناسازگاری فایل‌ها در blob storage.

3. سازگاری، مقیاس‌پذیری و سرعت
می‌توانید DuckLake را با DuckDB روی لپ‌تاپ اجرا کنید یا با PostgreSQL روی کلاود.
برخلاف ساختارهای فایل‌محور، پردازش‌ها سریع‌تر، قابل کش‌شدن و قابل مشاهده‌اند.
محدود به هیچ vendor خاصی نیستید؛ جابه‌جایی آسان است.

🏗 یک نگاه به معماری DuckLake:

📁 داده‌ها → Parquet روی S3 یا هر blob store

📚 فراداده → SQL Tables روی DuckDB/PostgreSQL/...

🔁 عملیات → فقط SQL transactions ساده با DuckDB

🧠 چرا مهم است؟

در حالی که بسیاری از معماری‌های داده در مسیر «Lakehouse» پیچیدگی‌های جدیدی اضافه می‌کنند، DuckLake مسیر را به عقب برمی‌گرداند و از یک حقیقت ساده دفاع می‌کند:

وقتی که به هر حال از یک دیتابیس استفاده می‌کنیم، چرا بقیه‌ی بخش‌ها را هم در همان قالب SQL مدیریت نکنیم؟

📌 نتیجه‌گیری

استاندارد DuckLake نه فقط یک فرمت جدید، بلکه بازاندیشی دوباره‌ای است در طراحی Lakehouse — مبتنی بر اصل «سادگی، مقیاس‌پذیری، سرعت». اگر به دنبال آینده‌ای پایدارتر، قابل نگهداری‌تر و بدون vendor lock-in برای lakehouse هستید، DuckLake را جدی بگیرید.

📎 مطالعه‌ی کامل مقاله: https://duckdb.org/2025/05/27/ducklake.html

#DuckDB #DuckLake #DataEngineering #Lakehouse #OpenFormats #SQL #Parquet #PostgreSQL

‍ تجربه استفاده از StarRocks در تیم دیتای اسنپ
پست رضا دهقانی در لینکدین

تجربه کار با 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-

آپاچی دوریس و سرعت بالا در سناریوهای مبتنی بر JOIN
- توضیحی راجع به 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