পাঠ ২৪ · ২৯-এর মধ্যে · মডিউল ৪

Home / AI Courses / Data Engineering / Delta Lake ও Iceberg

Delta Lake ও Iceberg

Open table formats — ACID on the data lake

৭ মিনিট পড়া মাঝারি · Intermediate Lakehouse

এই পাঠে যা শিখবেন

Open table format-এর core abstraction — কেন Parquet একা যথেষ্ট নয়
Delta Lake transaction log ও Iceberg manifest architecture
Schema evolution, time travel, Z-order vs partition spec
BD context — কোন format কখন বাছবেন

১ · Parquet একা কেন যথেষ্ট নয়

একটি data lake-এ ১০ TB Parquet file আছে S3-এ — orders/year=2025/month=05/day=09/। তিনটি সমস্যা।

Atomicity নেই: ১০০ Parquet file লেখার মাঝে job ক্র্যাশ — partial state পড়ে readers। কোনো commit/rollback নেই।
Update/Delete কঠিন: GDPR-এর "right to be forgotten" — একজন customer-এর rows delete করতে — ১০ TB rewrite।
Schema drift: "discount_bdt" নামে নতুন column যোগ করলে — পুরনো file-এ সেই column-এর meaning কী?

এসবের সমাধান open table formatOpen Table FormatParquet/ORC file-এর উপর একটি transaction log/metadata layer — যা ACID, schema evolution, time travel দেয়। Delta Lake, Apache Iceberg, Apache Hudi — তিনটি প্রধান format। — Parquet file রাখার সাথে একটি transaction log/metadata layer যোগ করে।

তিনটি core abstraction

১) Snapshot: table-এর একটি consistent version — কোন file কখন valid।
২) Transaction log: append-only, ordered changes — JSON বা manifest।
৩) Schema evolution: column add/drop/rename — backward + forward compatible।

২ · Delta Lake — Databricks-এর গিফট

Delta LakeDelta LakeDatabricks-এর open-source table format (Linux Foundation, ২০১৯)। Spark-এর সাথে সবচেয়ে শক্তিশালী integration। JSON-based transaction log। ২০১৯-এ Databricks open-source করে। S3-এ একটি Delta টেবিলের layout:

orders/_delta_log/00000000000000000000.json — initial commit।
orders/_delta_log/00000000000000000001.json — পরের commit।
orders/_delta_log/00000000000000000010.checkpoint.parquet — checkpoint (১০টি commit-এ একবার)।
orders/part-00000-...snappy.parquet — actual data files।

প্রতিটি JSON commit log-এ — কী file added, কী file removed, schema কী, statistics। Reader log replay করে current snapshot তৈরি করে।

Python · PySpark + Delta

from pyspark.sql import SparkSession
from delta.tables import DeltaTable

spark = (SparkSession.builder
    .appName("daraz-delta")
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension")
    .config("spark.sql.catalog.spark_catalog",
            "org.apache.spark.sql.delta.catalog.DeltaCatalog")
    .getOrCreate())

# ১. Delta টেবিল তৈরি — partitioned
(spark.read.parquet("s3://daraz-raw/orders/")
   .write.format("delta")
   .partitionBy("order_date")
   .save("s3://daraz-curated/orders_delta/"))

# ২. UPDATE — ACID, partial file rewrite
delta_t = DeltaTable.forPath(spark, "s3://daraz-curated/orders_delta/")
delta_t.update(
    condition = "amount_bdt < 0",
    set = { "amount_bdt": "0", "flag": "'corrected'" }
)

# ৩. MERGE — upsert pattern (CDC থেকে)
updates = spark.read.parquet("s3://daraz-cdc/orders_delta_2025_05_09/")
(delta_t.alias("t")
  .merge(updates.alias("s"), "t.order_id = s.order_id")
  .whenMatchedUpdateAll()
  .whenNotMatchedInsertAll()
  .execute())

# ৪. Time travel
old = spark.read.format("delta") \
    .option("versionAsOf", 42) \
    .load("s3://daraz-curated/orders_delta/")

MERGE CDC stream থেকে upsert-এর সবচেয়ে natural pattern। ACID — concurrent reader কখনো partial state দেখবে না। Time travel-এ versionAsOf বা timestampAsOf।

৩ · Apache Iceberg — multi-engine, hidden partitioning

Apache IcebergApache IcebergNetflix-এর তৈরি open table format (Apache, ২০১৮)। Multi-engine support — Spark, Trino, Flink, Snowflake, BigQuery সব pattern-এ। Snapshot-based, hidden partitioning, partition evolution feature-এ unique। ২০১৮-এ Netflix open-source করে। Delta-র চেয়ে কিছু architectural পার্থক্য।

Manifest list + manifest file: hierarchical metadata — ১ লাখ partition-এ scan লাগে না।
Hidden partitioning: User WHERE order_ts >= ... লিখে — Iceberg নিজেই date-derived partition বুঝে নেয়। Delta-র মতো explicit order_date column দরকার নেই।
Partition evolution: partition spec পরিবর্তন করা যায় (daily → hourly) historical rewrite ছাড়াই।
Multi-engine: Snowflake, BigQuery, Trino, Flink — সবাই native Iceberg পড়তে পারে।

ভাবুন Daraz warehouse-এর আলমারি। Delta Lake-এ — "মে মাসের জুতা, রাক ৩-এ" এমন label থাকে; rule fixed। Iceberg-এ — actual stocking যেভাবেই হোক, smart catalog আপনার search request বুঝে directly সঠিক rack pull করে। User-friendlier; query engineer-friendly।

SQL · Iceberg via Spark

-- Iceberg টেবিল তৈরি — hidden partitioning
CREATE TABLE pathao.rides (
    ride_id      BIGINT,
    rider_id     BIGINT,
    driver_id    BIGINT,
    fare_bdt     DECIMAL(10,2),
    pickup_loc   STRING,
    ride_ts      TIMESTAMP
)
USING iceberg
PARTITIONED BY (days(ride_ts), bucket(16, driver_id));

-- User filter — partition column referenced নেই, কিন্তু prune হয়
SELECT driver_id, COUNT(*) AS rides
FROM pathao.rides
WHERE ride_ts >= TIMESTAMP '2025-05-02'
  AND ride_ts <  TIMESTAMP '2025-05-09'
GROUP BY driver_id
ORDER BY rides DESC;

-- Partition evolution — daily থেকে hourly, historical rewrite ছাড়া
ALTER TABLE pathao.rides
  REPLACE PARTITION FIELD days(ride_ts) WITH hours(ride_ts);

-- Snapshot rollback (অন্যায় UPDATE-এর পর)
CALL system.rollback_to_snapshot('pathao.rides', 1234567890);

days(ride_ts) ও bucket(16, driver_id) — Iceberg transform। User SQL-এ partition column লিখতে হয় না। REPLACE PARTITION FIELD historical data rewrite ছাড়াই গ্র্যানুলারিটি পরিবর্তন — Delta-তে এটি native নয়।

৪ · Apache Hudi — upsert-heavy streaming

Apache HudiApache HudiUber-এর তৈরি open table format (Apache, ২০১৭)। CDC ও streaming upsert-এ optimized। Copy-on-write (CoW) ও merge-on-read (MoR) দু'টি storage mode। ২০১৭-এ Uber-এ শুরু — তাদের ride/transaction CDC-এর জন্য। দু'টি storage mode।

Copy-on-Write (CoW): update-এ পুরো parquet file rewrite। Read fast, write slow। OLAP-friendly।
Merge-on-Read (MoR): updates avro log-এ append। Read-time merge। Write fast, read slow। Streaming/CDC-friendly।

Hudi সবচেয়ে strong streaming upsert workload-এ। bKash-এর transaction CDC, Pathao-র live driver location — এই pattern-এ Hudi MoR ভাল ফিট।

৫ · Z-Order ও partition spec — দু'টি ভিন্ন approach

Z-Order (Delta Lake): multi-dimensional clustering। File-এর ভেতরে rows এমনভাবে sort করা হয় যাতে multiple column-এ pruning কাজ করে।

$$\text{Z-curve interleaves bits of multiple columns}$$

উদাহরণ — orders Z-Ordered by (district, customer_segment) → কোনো filter combination-এ pruning ভাল।

Iceberg partition transform: partition spec-এ পরিষ্কার expression — bucket(16, customer_id), truncate(10, name), year(ts)। কোনো column-এর exact value ফাঁস হয় না (privacy bonus)।

SQL · Delta Lake

-- Z-Order optimize — Delta-তে maintenance command
OPTIMIZE daraz.orders_delta
WHERE order_date >= '2025-05-01'
ZORDER BY (district, customer_segment);

-- Statistics ও compaction
VACUUM daraz.orders_delta RETAIN 168 HOURS;  -- 7 day Time Travel

OPTIMIZE — small files compact করে; ZORDER BY — multi-column pruning enable। VACUUM — পুরনো file remove। Production-এ scheduled (Airflow daily)।

তিনটি format একই Parquet ভিত্তির উপর — কিন্তু metadata strategy ভিন্ন। Use case-এ choice নির্ভরশীল।

৬ · Schema evolution — কোনটা সমর্থিত

সব format-এ column add safe। কিন্তু rename, drop, type change — পার্থক্য আছে।

Add column: Delta ✅, Iceberg ✅, Hudi ✅।
Drop column: Delta ✅ (logical), Iceberg ✅ (logical), Hudi ⚠️ (limited)।
Rename column: Iceberg ✅ (id-based), Delta ⚠️ (column mapping mode), Hudi ⚠️।
Promote type (int→bigint): সবাই ✅।
Reorder columns: Iceberg ✅, Delta ✅, Hudi limited।

Iceberg-এর rename support আসে field-id-based schema থেকে — schema-এ প্রতি column-এর integer id, name নয়। তাই rename শুধু metadata পরিবর্তন।

৭ · Bangladesh-এ adoption

Robi/GP analytics: Databricks adoption-এর সাথে Delta Lake। Spark-heavy stack।
Daraz: ETL Spark + Delta; downstream analytics-এ Iceberg export experimentation।
Pathao real-time: Hudi MoR — driver location, ride status streaming।
BD bank lakehouse pilot: Iceberg — multi-engine flexibility ও vendor-neutral।
Brain Station 23 client builds: Iceberg বাড়ছে — Trino + Iceberg lakehouse pattern সস্তা ও open।

খরচ-জ্ঞান: Delta/Iceberg চালাতে শুধু S3 ($২৩/TB/mo) + compute। Snowflake-এর তুলনায় ~৭০% সস্তা যদি engineering capacity থাকে। কিন্তু operational complexity ~৩x বেশি। ছোট BD startup-এ managed warehouse safer; mid-size+-এ lakehouse cost-effective।

Time Travel + storage cost: প্রতি commit-এ পুরনো parquet file retain হয়। VACUUM ছাড়া storage exponentially বাড়ে। Daraz-এর একটি Delta টেবিলে ৬ মাসে storage ১০ TB থেকে ৪০ TB হয়েছিল — VACUUM schedule ভুলে। Production-এ VACUUM RETAIN 168 HOURS daily Airflow job।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ "Lakehouse" বলতে কী বোঝায় এবং কেন BD-র মতো cost-conscious market-এ এটি উপযোগী হতে পারে? Snowflake/BigQuery-র সাথে কোথায় ট্রেড-অফ?

"Lakehouse" — Databricks-এর coined term (২০২০)। মানে data lake-এর সস্তা storage + warehouse-এর ACID/SQL/performance — একসাথে। Open table format এই architecture সম্ভব করেছে।

(১) প্রচলিত architecture-এর সমস্যা:

Lake (S3 + Parquet): সস্তা, scalable, কিন্তু ACID নেই, BI tool কঠিন।
Warehouse (Snowflake/Redshift): performant, কিন্তু $২০-৩০/TB/মাস, vendor lock-in।
"Two-tier" — lake-এ raw, warehouse-এ curated। Duplication, latency, double cost।

(২) Lakehouse promise:

একটি copy data — S3-এ Delta/Iceberg।
Spark, Trino, Flink, Athena, Snowflake — সব engine একই ডেটা পড়তে পারে।
ACID, time travel, schema evolution — warehouse-grade।
Compute আলাদা — workload অনুযায়ী choose।

(৩) BD context — খরচ:

৫০ TB curated data + ১০০ analyst।
Snowflake: ~$১২,০০০-১৮,০০০/মাস (compute + storage)।
Lakehouse (S3 + Trino on EMR/EKS): ~$৩,০০০-৫,০০০/মাস। ৬০-৭০% সাশ্রয়।
BDT: ~১২ লাখ vs ৪ লাখ/মাস — মাঝারি BD enterprise-এ significant।

(৪) Trade-off — কোথায় হারে:

Operational complexity: Spark cluster, Trino coordinator, Hive Metastore বা AWS Glue, Airflow — ৩-৪ FTE DE/Platform।
Performance tuning: small file compaction, statistics, Z-order, vacuum — manual। Snowflake auto।
Concurrency: Trino-তে ১০০+ concurrent BI users — coordinator bottleneck। Snowflake elastic scale better।
Talent: Spark + Iceberg + Trino skill BD-তে rare; Snowflake SQL-এর tooling familiar।

(৫) BD-তে কখন lakehouse:

Telco/bank — bulk analytics, large data, predictable workload, খরচ-sensitive। ✅
Mid-size enterprise (১০০+ TB) ভাল engineering team আছে। ✅
Multi-cloud strategy — vendor-neutral ✅।

(৬) BD-তে কখন warehouse:

Startup, ছোট DE team — ops overhead বাঁচাতে। ❌ Lakehouse।
Bursty/unpredictable workload — auto-scale benefit।
Marketing-driven, BI-heavy, low engineering depth।

(৭) Hybrid pattern:

Iceberg lakehouse-এ raw + curated।
Snowflake/BigQuery-তে external table দিয়ে query (read-only)।
BI dashboard-এর hot queries materialized view-এ।
BDT খরচ optimize, vendor lock-in কম।

মূল উপলব্ধি: Lakehouse "সস্তা" নয় — "different cost structure"। Storage saving + ops cost addition। BD-র মাঝারি/বড় enterprise-এ ROI ভালো; ছোট startup-এ premature। Open table format-এর evolution-এ trade-off প্রতি বছর কমছে।

প্র ০২ bKash-এ একটি GDPR-এর মতো request — "এই customer-এর গত ৩ বছরের সব transaction delete করুন।" এটা কীভাবে Delta Lake-এ ACID ভাবে handle করবেন? কী প্রভাব performance-এ?

Banking + privacy regulation-এর pressure-এ "right to be forgotten" বা equivalent request — sensitive ও technically demanding। Delta Lake এই use case-এর key driver ছিল।

(১) প্রচলিত Parquet-এ সমস্যা:

Customer-এর rows ৩৬৫ × ৩ = ১০৯৫ partition-এ ছড়িয়ে।
প্রতিটি partition-এ ১০-১০০ Parquet file।
Single rows delete = ফাইল rewrite।
একই সময়ে concurrent reader থাকলে — partial state risk।

(২) Delta solution:

from delta.tables import DeltaTable

t = DeltaTable.forPath(spark, "s3://bkash-curated/transactions_delta/")

# একটি ACID DELETE — সব partition spans
t.delete("msisdn = '8801712345678'")

# Delta automatically:
# - affected file চিহ্নিত
# - নতুন file সেই rows ছাড়া লেখে
# - tx log-এ remove + add এক commit-এ
# - readers কখনো partial state দেখে না

(৩) Performance প্রভাব:

Customer-এর rows যত partition-এ — তত file rewrite।
৩ বছরে ১০৯৫ partition × ১ affected file = ১০৯৫ rewrite।
প্রতিটি ১০০ MB file ~১০ সেকেন্ডে = ~৩ ঘণ্টা total। Spark cluster size-এ depend।
Storage temporarily ২x — পুরনো file যতক্ষণ Time Travel retain।

(৪) Compliance — সম্পূর্ণ deletion:

Time Travel-এ ৭ দিন পুরনো data retain — privacy regulation-এ অনুমোদিত নয়।
সমাধান:

VACUUM bkash.transactions_delta RETAIN 0 HOURS;
-- ⚠️ default min ১৬৮ hours (safety)। Override:
SET spark.databricks.delta.retentionDurationCheck.enabled = false;

VACUUM-এর পর data অপ্রাপ্য (Time Travel-এও না)।
S3 versioning থাকলে — সেগুলোও delete করতে হবে।
Audit log-এ delete action রেখে compliance prove।

(৫) Iceberg-এ একই কাজ:

DELETE FROM bkash.transactions WHERE msisdn = '8801712345678';
CALL system.expire_snapshots('bkash.transactions',
  TIMESTAMP '2025-05-09 00:00:00', 1);

(৬) Compaction strategy:

Bulk delete-এর পর small files বেড়ে যায়।
OPTIMIZE Z-Order সহ compact — file count কমে, query দ্রুত।
Schedule weekly Airflow।

(৭) bKash-specific consideration:

Bangladesh Bank regulation — transaction record minimum ৭ বছর retain বাধ্যতামূলক।
"Right to be forgotten" ও "regulatory retention" conflict — legal team-এর সাথে clear policy।
Pseudonymization — actual delete-এর আগে hash/encrypt option।

মূল উপলব্ধি: Open table format-এর সবচেয়ে important business value — privacy compliance ও mutability। প্রচলিত Parquet lake-এ এটা প্রায় অসম্ভব। DELETE/MERGE first-class citizen → DE team production-grade lake চালাতে পারে।

প্র ০৩ Pathao Bangladesh ride events — Kafka থেকে real-time S3-এ ingest। 3 sec latency, 1M events/min। Delta, Iceberg, Hudi — কোনটি বাছবেন এবং কেন? ছোট-file সমস্যার সমাধান কী?

Streaming ingestion → table format — তিনটি format-এর pre-eminent comparison ground।

(১) Workload characterize:

1M events/min × 60 = ৬০ M/hour = ১.৪ B events/day।
3 sec latency — query-time freshness requirement।
Upsert pattern — same ride_id-এ status change (started → in-progress → completed)।
Query: dashboard refresh প্রতি ১০s, analyst ad-hoc।

(২) Format ranking:

Hudi MoR: ⭐⭐⭐⭐⭐ — upsert-heavy streaming-এ designed। MoR mode-এ writes দ্রুত (avro log append), read-time merge। Index-based primary key lookup।
Iceberg + Flink streaming: ⭐⭐⭐⭐ — mature streaming write। কিন্তু upsert primarily MERGE, Hudi-র মতো indexed না।
Delta + Spark Structured Streaming: ⭐⭐⭐⭐ — battle-tested। MERGE INTO upsert, কিন্তু latency ১-৫ মিনিট typical।

(৩) সিদ্ধান্ত: Hudi MoR — Pathao-র latency + upsert pattern-এ ভাল ফিট।

(৪) Pipeline design:

-- Flink job: Kafka → Hudi MoR
INSERT INTO pathao.rides_hudi
SELECT * FROM kafka_rides_topic;

-- Hudi properties:
-- hoodie.table.type = MERGE_ON_READ
-- hoodie.datasource.write.recordkey.field = ride_id
-- hoodie.datasource.write.precombine.field = event_ts
-- hoodie.compact.inline = false (async)

(৫) Small file problem:

Streaming writes প্রতি micro-batch-এ small parquet/log file।
10s × 6/min × 60 × 24 = 8640 file/day per partition। S3 cost + query slow।
সমাধান ১: Hudi inline/async compaction।
সমাধান ২: ছোট buffer (60s window) দিয়ে batch larger।
সমাধান ৩: Daily compaction job — Hudi-র run_compaction বা Iceberg-এর rewrite_data_files।

(৬) Hudi compaction tuning:

-- Async compaction প্রতি ৪ commit-এ
hoodie.compact.inline.max.delta.commits = 4
hoodie.cleaner.commits.retained = 24
hoodie.parquet.small.file.limit = 104857600  # 100 MB target

(৭) Read pattern:

Hudi MoR-এ read query — base parquet + delta avro logs merge।
Real-time view = freshest, slower।
Read-optimized view = compacted only, faster, slightly stale।
Pathao dashboard real-time view-এ; analyst report read-optimized-এ।

(৮) Iceberg consideration:

২০২৪+ Iceberg streaming features দ্রুত matured (positional + equality deletes)।
Apple Music, LinkedIn, Netflix — Iceberg streaming-এ massive scale।
Multi-engine flexibility lock-in কমায়।
Pathao-এর choice ৩-৫ বছর pertinent — Iceberg ভবিষ্যত-proof।

(৯) BD operational reality:

Hudi documentation Iceberg-এর তুলনায় কম mature; debugging কঠিন।
BD-তে Hudi expert সংখ্যায় ছোট।
Pragmatic: Iceberg + Flink-এ shift, latency ৩-৫s acceptable হলে।

মূল উপলব্ধি: Streaming + upsert + low-latency = Hudi-র সবচেয়ে strong domain। কিন্তু Iceberg দ্রুত catch up করছে; multi-engine flexibility long-term winner। Small file problem — সব format-এ compaction strategy ছাড়া survive না।

প্র ০৪ Eastern Bank lakehouse design করছে। তারা চায় BI tool (Tableau), AI/ML team (Python), এবং Snowflake — তিনটিই একই table পড়তে পারে। কোন format ও কী architectural choice?

Multi-engine + Snowflake interop — modern BD enterprise lakehouse-এর key requirement। ২০২৪-এ Snowflake-এর Iceberg native support এই scenario unlock করেছে।

(১) Format choice: Apache Iceberg

Snowflake-এ native external table support (২০২৩-২৪ থেকে)।
Trino, Spark, Flink, Dremio, BigQuery — সব read native।
Field-id-based schema → schema evolution safe across engines।
Hidden partitioning → engine-agnostic query।
Vendor-neutral (Apache governance, Tabular acquisition by Databricks-এর পরও open)।

(২) Architectural blueprint:

S3 / Azure Blob (single source of truth)
       │
   ┌───┼─────────────────────┬──────────────┐
   │   Iceberg tables        │              │
   │   + AWS Glue catalog    │              │
   ▼                         ▼              ▼
Spark/EMR              Trino cluster      Snowflake
(ETL, ML)              (BI, ad-hoc)       (governance,
                                            BI premium)

(৩) Catalog choice:

AWS Glue Data Catalog: AWS-native, low-cost, S3-backed।
Apache Polaris (Snowflake) / Unity Catalog (Databricks): rich governance, costly।
Project Nessie: git-style branching catalog। Banking-এ "audit branch" pattern পাওয়া যায়।
Eastern Bank-এর জন্য — Glue + future Polaris migration option।

(৪) Data layout:

s3://eastern-lakehouse/
  ├── raw/         (landing — Avro, JSON)
  ├── bronze/      (Iceberg — cleaned, raw schema)
  ├── silver/      (Iceberg — conformed, joined)
  └── gold/        (Iceberg — business-ready aggregates)

(৫) Engine assignment:

Spark on EMR: bronze → silver transformation, ML feature engineering।
Trino: analyst ad-hoc, BI dashboard back-end (Tableau)।
Snowflake: external table → gold layer; executive dashboard, regulator report (premium polish)।
Python ML: PyIceberg লাইব্রেরি — directly read Iceberg-এ Pandas/DuckDB।

(৬) Governance:

Lake Formation row/column-level security S3 + Glue।
Iceberg snapshot expiration policy — banking ৭ বছর retention।
Tag-based classification (PII, internal, public)।
Audit log — Iceberg snapshot history + S3 access log।

(৭) খরচ comparison (৫০ TB):

Pure Snowflake: $১৮,০০০/মাস।
Iceberg lakehouse + ছোট Snowflake (gold only): $৭,০০০/মাস।
~৬০% সাশ্রয়; Snowflake polish যেখানে দরকার সেখানেই।

(৮) BD bank-specific concerns:

Bangladesh Bank IT Security Guidelines — data residency।
S3 region: ap-south-1 (Mumbai) vs ap-southeast-1 (Singapore) — regulatory clarity।
BB Cyber Incident Response — encryption at rest (KMS) + in transit (TLS) mandatory।
Auditor friendly: Iceberg snapshot-এ point-in-time queryable।

(৯) Migration roadmap:

Q1: Glue catalog + bronze Iceberg setup, ১-২ source migrate।
Q2: silver layer, Trino BI।
Q3: gold + Snowflake external table।
Q4: ML feature store on Iceberg, governance hardening।

মূল উপলব্ধি: Modern BD enterprise lakehouse — Iceberg-এর "single source, many engines" promise-এর strongest fit। Snowflake পুরোপুরি ছাড়তে হয় না; partial use (premium tier) সবচেয়ে effective। Open format = vendor lock-in escape; এটা banking-এর মতো decade-long architectural commitment-এ অমূল্য।

অনুশীলন

Format match: তিনটি use case — কোন format বাছবেন? (ক) Daraz product catalog (slow-moving, BI-heavy), (খ) bKash transaction CDC (high-throughput upsert), (গ) Multi-cloud governance project।
- (ক) Delta Lake — Spark-heavy, mature MERGE, BI tool integration।
- (খ) Hudi MoR — streaming upsert-এ designed, low-latency।
- (গ) Iceberg — multi-engine, vendor-neutral, partition evolution।
সাধারণ rule: workload characterize → format এর strength match।

Time Travel query লিখুন: Iceberg টেবিলে গতকালের snapshot দেখান, যখন day = '2025-05-08'।

-- Iceberg time travel
SELECT * FROM pathao.rides
FOR TIMESTAMP AS OF TIMESTAMP '2025-05-08 23:59:59';

-- বা specific snapshot
SELECT * FROM pathao.rides
FOR VERSION AS OF 1234567890123;

-- snapshot history দেখা
SELECT * FROM pathao.rides.snapshots
ORDER BY committed_at DESC;

VACUUM strategy: Daraz-এর Delta টেবিল ১০ TB live data, কিন্তু storage bill দেখায় ৪০ TB। কী diagnose ও fix করবেন?
Diagnose:
```
-- পুরনো version size
DESCRIBE HISTORY daraz.orders_delta;
DESCRIBE DETAIL daraz.orders_delta;
```
সম্ভাব্য কারণ: ৬ মাসে UPDATE/DELETE বহুবার, পুরনো parquet retain, VACUUM চলেনি।

Fix:
```
-- 7 দিন time travel রেখে rest delete
VACUUM daraz.orders_delta RETAIN 168 HOURS;

-- Daily Airflow job:
-- 1. OPTIMIZE table ZORDER BY (...)
-- 2. VACUUM RETAIN 168 HOURS
-- 3. Storage trend monitor
```
প্রতিরোধ: Time Travel retention requirement document; VACUUM scheduled production day-1 থেকেই।