یک منبع حقیقت واحد برای تمام داده‌های سازمان — از CDC بانکی تا CDR مخابراتی، با ACID روی Object Storage

GITA Lakehouse هر سه را پشتیبانی می‌کند، اما پیشنهاد پیش‌فرض ما Iceberg است. دلیل: استاندارد باز با حاکمیت Apache، REST Catalog مستقل از vendor، Hidden Partitioning، Partition Evolution و Branching/Tagging از همه قوی‌تر است. Delta برای تیم‌هایی که در اکوسیستم Databricks سرمایه‌گذاری کرده‌اند مناسب است و Hudi برای workloadهای upsert سنگین streaming. در فاز Discovery، با workload واقعی شما تصمیم می‌گیریم.

ما یک ابزار migration اختصاصی داریم که جدول‌های Hive را به Iceberg به‌صورت in-place تبدیل می‌کند — فایل‌های Parquet موجود را بدون rewrite استفاده می‌کند و فقط متادیتای Iceberg را می‌سازد. برای یک DWH با ۵۰۰ جدول و ۸۰ ترابایت داده، معمولاً ۸ تا ۱۲ هفته مهاجرت تدریجی با dual-write انجام می‌شود — بدون downtime برای گزارش‌های production.

Trino برای کوئری‌های BI تعاملی (sub-second تا چند ثانیه) و ad-hoc analysis بهینه است — MPP engine بدون JVM overhead per-query. Spark برای ETL سنگین، transformation پیچیده و ML بهتر است. در GITA Lakehouse هر دو روی همان جدول Iceberg کار می‌کنند و شما می‌توانید برای هر workload بهترین موتور را انتخاب کنید. DuckDB برای تحلیل embedded و ClickHouse برای دشبورد real-time هم در دسترس‌اند.

Iceberg از in-place schema evolution پشتیبانی می‌کند: add column، drop column، rename، reorder و حتی تغییر type (با قواعد سازگاری) بدون نیاز به rewrite داده. هر ستون با ID داخلی track می‌شود نه نام، پس rename هزینه ندارد. Partition Evolution هم پشتیبانی می‌شود — می‌توانید partition strategy را تغییر دهید و داده قدیمی با strategy قدیمی و داده جدید با strategy جدید کنار هم زندگی کنند.

سه سناریوی اصلی: (۱) Audit و Reproducibility — بازتولید گزارش‌های قدیمی با Snapshot ID؛ (۲) Rollback — برگرداندن فوری جدول به snapshot قبلی بعد از یک bad write؛ (۳) WAP (Write-Audit-Publish) — نوشتن داده در یک branch، اجرای quality checkها، و publish به main فقط بعد از تأیید. Branchها فضای فیزیکی اضافی مصرف نمی‌کنند تا زمانی که تغییر داده شوند.

موتور policy ما با Trino و Spark integration دارد. policyها در یک repository مرکزی نوشته می‌شوند (DSL یا UI) و در زمان query parsing اعمال می‌شوند — یعنی Trino خودش query را rewrite می‌کند تا فقط ردیف‌ها و ستون‌های مجاز خوانده شوند. masking پویا (مثل تبدیل شماره کارت به ۴ رقم آخر) برای کاربران غیرمجاز اعمال می‌شود. attributeهای کاربر از GITA Identity (SCIM) خوانده می‌شوند.

از سه لایه isolation استفاده می‌کنیم: (۱) Namespace در REST Catalog با policyهای جداگانه؛ (۲) bucket یا prefix جداگانه در Object Storage با IAM مستقل؛ (۳) Trino resource groups برای محدودیت CPU/Memory per-tenant. هر tenant کاتالوگ خودش را می‌بیند، نمی‌تواند به متادیتای tenant دیگر دسترسی داشته باشد و quota محاسباتی و ذخیره‌سازی مستقل دارد.

بله. scheduler maintenance ما به‌صورت دوره‌ای: (۱) فایل‌های کوچک را compact می‌کند (هدف ۵۱۲MB-۱GB)؛ (۲) Z-Order rewrite بر اساس کوئری‌های پرکاربرد انجام می‌دهد؛ (۳) Snapshotهای قدیمی‌تر از retention policy را expire می‌کند؛ (۴) orphan filesها را پاک می‌کند. در Object Storage هم erasure coding (مثل ۱۰+۴) به‌جای replication ۳x استفاده می‌کنیم — کاهش ۵۰٪+ هزینه نسبت به HDFS سنتی.

Iceberg از همان جدول هم برای streaming write (با Flink یا Spark Structured Streaming یا Kafka Connect) و هم batch write پشتیبانی می‌کند. ما الگوی Medallion (Bronze/Silver/Gold) را پیاده می‌کنیم: Bronze با CDC از Debezium به‌صورت append-only، Silver با merge-on-read برای upsert، Gold با aggregate batch روزانه. خوانندگان همیشه snapshot consistent می‌بینند و isolation بین streaming و batch به‌صورت خودکار مدیریت می‌شود.

از طریق Trino JDBC/ODBC که با تمام ابزارهای BI استاندارد سازگار است. برای Power BI کانکتور اختصاصی Trino و برای Tableau هم driver رسمی وجود دارد. Superset و Metabase به‌صورت native پشتیبانی می‌شوند. برای کارایی بالاتر، می‌توانید Materialized Views در Trino بسازید یا از کش result استفاده کنید — کوئری‌های داشبورد روی petabyte در sub-second پاسخ می‌دهند.