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

Home / AI Courses / ডেটা ইঞ্জিনিয়ারিং / Lake / Warehouse / Lakehouse

Data Lake, Warehouse, Lakehouse

Lake / Warehouse / Lakehouse — the storage trinity

৭ মিনিট পড়া শুরু · Beginner Storage architecture

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

Data lake, warehouse, lakehouse-এর সংজ্ঞা ও মূল পার্থক্য
Schema-on-read বনাম schema-on-write — trade-off ও কখন কোনটি
Delta Lake / Apache Iceberg / Hudi কী এবং কেন গুরুত্বপূর্ণ
BD-র startup ও enterprise-এ কোন stack বেছে নেবেন

১ · তিনটি জগৎ — এক নজরে

OLAP storage-এর ৩০ বছরের বিবর্তন তিনটি ধাপে —

১৯৮৬-২০১০: Warehouse যুগ। Teradata, Oracle, Vertica। Structured, expensive, on-prem।
২০১০-২০২০: Lake যুগ। Hadoop/HDFS, পরে cloud object storage (S3, GCS)। Cheap, flexible, কিন্তু ACID/quality দুর্বল।
২০২০-এখন: Lakehouse যুগ। Delta Lake (Databricks ২০১৯), Iceberg (Netflix ২০১৭ open-source ২০২০), Hudi (Uber)। দু'টোর সেরা।

এক বাক্যের তফাৎ

Lake: "সব ফাইল ঢালুন, পরে দেখব।"
Warehouse: "শুধু পরিষ্কার, schema-confirmed ডেটা ঢুকবে।"
Lakehouse: "Lake-এ ফাইল রাখি, কিন্তু একটি smart layer ACID + schema দেয়।"

২ · Data Warehouse — পুরোনো বন্ধু

Data WarehouseData WarehouseAnalytics-এর জন্য optimized একটি database — structured data, schema-on-write, columnar storage, fast SQL, ACID। Snowflake, BigQuery, Redshift, Synapse, Vertica, Teradata উল্লেখযোগ্য। — বহু বছরের পরীক্ষিত pattern। Bill Inmon (১৯৯০) ও Ralph Kimball (১৯৯৬) এর pioneer।

Properties:

Schema-on-write: ডেটা ঢোকার সময় table definition থাকতে হবে।
Structured শুধু: rows + columns।
ACID transaction: নির্ভরযোগ্য update।
Fast SQL: column-store, vectorized engine।
Cost: compute + storage একই system — price বেশি।

উদাহরণ:

Snowflake: ২০১২, separated storage/compute, multi-cloud, popular।
BigQuery: Google, serverless, pay-per-query।
Redshift: AWS, cluster-based।
Azure Synapse: Microsoft enterprise।

Best for: BI dashboard, financial reporting, regulatory query, দৈনিক analyst work।

৩ · Data Lake — সস্তা ও নমনীয়

Data LakeData Lakeসস্তা object storage (S3/GCS/ADLS) যেখানে যেকোনো format-এর ফাইল রাখা যায় — CSV, JSON, Parquet, image, video, log। Schema-on-read; query engine (Athena, Spark) উপরে চালাতে হয়। এসেছিল warehouse-এর তিনটি সীমাবদ্ধতা সমাধানে — cost, structured-only, এবং ML data টানতে কষ্ট।

Properties:

Schema-on-read: ফাইল ঢালার সময় কোনো structure প্রমাণ লাগে না।
সব format: CSV, JSON, Parquet, Avro, image, video, log।
Cheap: S3 স্টোরেজ $0.023/GB/মাস। Warehouse-এর ৫-১০x সস্তা।
Compute আলাদা: Athena, Presto/Trino, Spark — যা চান তা চালান।
দুর্বলতা: ACID নেই। "Same file 2 জন একসাথে update" → corruption। Schema drift। Quality enforce কঠিন।

২০১৪-২০১৮ সময়ে অনেক কোম্পানি pure data lake বানিয়েছিল — পরে এটিকে "data swamp" বলত। কারণ governance ছাড়া lake দ্রুত নোংরা ফাইলের গাদা হয়ে যায়, কেউ আর কী আছে জানে না।

৪ · Lakehouse — দু'টির মেলবন্ধন

LakehouseLakehouseObject storage-এর উপর একটি smart metadata layer যা ACID, schema enforcement, time-travel, ও SQL দেয়। Delta Lake, Apache Iceberg, Apache Hudi — এই pattern-এর তিন প্রধান implementation। ধারণা: lake-এর সস্তা storage রাখো, কিন্তু একটি "table format" layer যোগ করো যা warehouse-সদৃশ guarantee দেয়।

Mechanism:

Underlying file = Apache Parquet (columnar, compressed)।
উপরে metadata log (JSON/Avro) — কোন ফাইল কোন version-এ valid।
Transaction log — ACID-এর ভিত্তি।
Schema evolution — column যোগ/বাদ, type বদল।
Time travel — "৩ দিন আগের state দেখাও"।

তিনটি প্রধান open-source format:

Delta Lake: Databricks, ২০১৯। Spark-এর সাথে best integration।
Apache Iceberg: Netflix-এ origin (২০১৭), open-source ২০২০। Engine-agnostic, AWS, Snowflake, BigQuery সবার সাথে কাজ করে।
Apache Hudi: Uber-এ origin। Streaming + upsert focused।

২০২৪-২০২৫-এ industry-র tide Iceberg-এর দিকে। Snowflake-ও Iceberg native support দিয়েছে — এক table যেকোনো engine থেকে। এটি data engineering-এর নতুন standard হচ্ছে।

তিনটি storage architecture। Lake ডান দিকে evolve করেছে warehouse-এর trust pick up করতে; warehouse বাঁ দিকে evolve করেছে lake-এর flexibility পেতে — দু'টিই lakehouse-এ মিলেছে।

৫ · Schema-on-read বনাম Schema-on-write

এই দু'টি ধারণা lake/warehouse-এর ভিত্তি।

Schema-on-write (warehouse):

ডেটা ঢোকার আগে — columns, types, constraints define।
Validation upfront — "amount must be int, not null"।
সুবিধা: query সবসময় predictable; data quality high।
অসুবিধা: schema change costly; new source slow onboard।

Schema-on-read (lake):

ডেটা যেমন আছে তেমনই ফাইলে — CSV, JSON।
Read-time query engine (Spark, Athena) schema infer বা manually declare।
সুবিধা: যেকোনো source দ্রুত ingest; iteration fast।
অসুবিধা: Type mismatch run-time-এ ফাটে; multiple consumer-এর interpretation আলাদা।

Schema-on-write = ভর্তি পরীক্ষা। ঢোকার আগেই যাচাই করে নেয়। ঢুকলে — everyone fits the rule। Schema-on-read = ফ্রি লাইব্রেরি। যা চান ঢালুন; পড়তে গিয়ে কেউ বুঝে নেয় কী আছে। বাংলা বই, English book, সব এক shelf-এ।

৬ · বাস্তব Lakehouse code — PySpark + Delta

Python · PySpark + Delta

from pyspark.sql import SparkSession

spark = (SparkSession.builder
    .appName("daraz_orders")
    .config("spark.jars.packages", "io.delta:delta-core_2.12:2.4.0")
    .getOrCreate())

# একটি Delta table তৈরি (S3-এ)
(spark.read.csv("s3://daraz/raw/orders/")
    .write
    .format("delta")
    .mode("overwrite")
    .save("s3://daraz/curated/orders_delta/"))

# Time travel — ৭ দিন আগের state পড়া
yesterday = (spark.read
    .format("delta")
    .option("timestampAsOf", "2025-05-02 00:00:00")
    .load("s3://daraz/curated/orders_delta/"))

print(f"Today rows:    {spark.read.format('delta').load('s3://daraz/curated/orders_delta/').count()}")
print(f"7 days ago:    {yesterday.count()}")

Delta-এর সবচেয়ে শক্তিশালী feature — time travel। যেকোনো historical version পুনঃ-পড়া যায়। এই কারণেই audit, debugging, ও ML reproducibility-তে lakehouse warehouse-এর চেয়ে এগিয়ে।

৭ · কোথায় কোনটি — সিদ্ধান্ত matrix

Warehouse বাছুন যদি:

প্রধান use case BI dashboard ও analyst SQL।
Team SQL-এ comfortable, Spark/Python কম।
Data বেশিরভাগ structured (relational source)।
Volume মাঝারি (< ১০-৫০ TB)।
সরল setup চান।

Lakehouse বাছুন যদি:

ML/AI workload আছে — image, log, sensor, embedding।
Volume বড় (> ১০০ TB)।
Streaming + batch একসাথে।
Multi-engine চান (Spark, Trino, Snowflake একই table-এ)।
Cost-conscious enterprise।

Lake (pure) বাছুন যদি:

Raw archive — "যা আসছে রাখুন, ভবিষ্যতে দেখা যাবে।"
One-time analysis।
Compliance — original raw রাখা required।

বাস্তবে — বেশিরভাগ মাঝারি BD কোম্পানি Hybrid stack চালায়: S3 lake (raw) → Snowflake warehouse (curated)। Bigger তে — S3 + Iceberg + Trino + Snowflake। ছোটে — শুধু Snowflake/BigQuery।

৮ · একটি SQL উদাহরণ — Iceberg-এ time travel

SQL · Iceberg via Trino

-- বর্তমান state
SELECT COUNT(*) FROM iceberg.daraz.orders;

-- ৩ দিন আগের snapshot
SELECT COUNT(*)
FROM iceberg.daraz.orders FOR TIMESTAMP AS OF
    TIMESTAMP '2025-05-06 00:00:00 +06:00';

-- নির্দিষ্ট snapshot id
SELECT *
FROM iceberg.daraz.orders FOR VERSION AS OF 8472193847;

-- Schema evolution — নতুন column যোগ
ALTER TABLE iceberg.daraz.orders
    ADD COLUMN delivery_partner VARCHAR;

-- পুরোনো row-এ নতুন column null হবে — কোনো full rewrite না

Iceberg-এর schema evolution Parquet-এর underlying file rewrite ছাড়াই হয় — metadata-এ পরিবর্তন। এটি বিশাল সুবিধা: ১০০ TB lake-এ একটি column যোগ instant, traditional warehouse-এ ঘণ্টার পর ঘণ্টা।

Apache Iceberg ২০২৫-এ industry standard হয়ে উঠেছে — AWS Glue, Snowflake, BigQuery, Databricks, Trino, Spark, Flink সবাই native support দেয়। যিনি Iceberg শিখবেন — তিনি multi-cloud, multi-engine ready।

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

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

প্র ০১ Daraz ২০১৫-তে শুধু MySQL-এ ছিল। ২০১৮-এ Hadoop lake বানিয়েছিল — "data swamp" হয়ে গেল। ২০২২-এ Snowflake। এখন ২০২৫-এ Iceberg consider করছে। প্রতিটি migration-এর কারণ ও pain point কী?

এই pattern অনেক BD/global কোম্পানি hit করেছে — এটিই warehouse-lake-lakehouse evolution-এর বাস্তব গল্প।

Phase 1 — MySQL only (২০১৫):

Single OLTP database, BI sub-set query সরাসরি।
Pain: ব্যবসা বাড়ার সাথে query slow, production load। আগের পাঠের problem।

Phase 2 — Hadoop/HDFS lake (২০১৮):

Cheap storage, "save everything" mantra।
Pain accumulated:
- Schema chaos: ১০০+ folder, কেউ জানে না কোনটায় কী।
- No ACID: দু'টি Spark job same partition লিখলে — race condition।
- Quality issue: কেউ একটি CSV upload করল wrong column order — সব downstream broken।
- Operational cost: Hadoop cluster maintain করতে full team।
- Slow query: Hive query 30+ মিনিট, dashboard unusable।
"Data swamp" — Forrester analyst-এর টার্ম। ২০১৯-এ ৬০% Hadoop project failed-categorized।

Phase 3 — Snowflake warehouse (২০২২):

Cloud-native, no infra maintenance।
SQL-first, analyst happy।
Pain returns:
- Cost spike: Snowflake credit বিল ১০-৫০ লাখ টাকা/মাস।
- ML data পেইন: image, large parquet warehouse-এ inefficient।
- Lock-in: Snowflake-এর native format SCALAR closed।
- Streaming weak: Snowpipe latency-prone।

Phase 4 — Iceberg lakehouse (২০২৫ planning):

Storage S3-এ (cheap)।
Iceberg metadata দিয়ে ACID + schema।
Query engine choice: Snowflake অথবা Trino অথবা Spark।
ML team Spark, BI team Snowflake — same table।
সম্ভাব্য pain:
- Setup complex — Glue catalog, IAM, partition strategy।
- Optimization (compaction, snapshot expiry) ongoing কাজ।
- Multi-engine debugging কঠিন।

প্রতিটি migration শিখিয়েছে:

"Cheap storage" alone enough না — governance চাই।
"Premium warehouse" alone enough না — ML/streaming weak।
Hybrid lakehouse — দু'টোর সেরা কিন্তু complexity তে দাম।

মূল উপলব্ধি: Architecture decision business stage-এর সাথে evolve। যিনি প্রতিটি stage-এ trade-off বোঝেন এবং migration plan করেন — তিনি senior data engineer।

প্র ০২ একটি BD bank GDPR-সদৃশ Data Protection Act মেনে চলতে চায় — "right to be forgotten" (একটি customer চাইলে তাঁর সব data মুছে যাবে)। Data lake-এ এটি কেন কঠিন এবং lakehouse এই সমস্যা কীভাবে সহজ করে?

GDPR Article 17 ("right to erasure") ২০১৮ থেকে EU-তে। BD-র Data Protection Act ২০২৩-এ পাশ — অনুরূপ provision। এটি data engineering-এর architectural challenge।

সমস্যা গভীরে:

Customer X চাইলেন — "আমার সব data মুছে দিন।"
X-এর data ২০০টি Parquet ফাইলে scattered — ৩ বছরের history।
একটি OLTP DB হলে — DELETE WHERE user_id = X এক query।

Pure lake-এ challenge:

Immutable Parquet: Parquet ফাইল delete-friendly না। X-এর row বাদ দিতে হলে — ফাইল পড়, X বাদ, নতুন ফাইল লেখ, পুরোনো ডিলিট।
২০০ ফাইল × ৩ বছর × ৪ partition strategy: মেগা cost।
No ACID: মাঝে কোনো reader থাকলে inconsistent state দেখবে।
Audit trail: "X-এর data deleted" প্রমাণ কীভাবে?
Backup: আগের backup-এ X এখনো আছে — সেগুলো কী করব?
Derived data: X-এর data থেকে aggregate (যেমন district-wise revenue)। Aggregate-এ X-এর contribution কি delete করতে হবে?

Lakehouse (Delta/Iceberg) যা সহজ করে:

Native DELETE: DELETE FROM iceberg.bank.customers WHERE customer_id = 'X' — SQL working।
Copy-on-write: Iceberg engine background-এ affected ফাইল rewrite। User-এর কাছে atomic।
Snapshot + retention: Old snapshot expire করে — X এর data older snapshot-এও থাকে না (after expiry)।
Audit log: Iceberg metadata-এ delete operation logged — "এই snapshot-এ X deleted" প্রমাণ।
Time-travel control: Compliance retention period (e.g., ৩০ দিন) এর পর old snapshot সব clear।

BD bank-এর সম্পূর্ণ approach:

PII separation: NID, ফোন, ঠিকানা একটি pseudonymization vault-এ; warehouse-এ token।
Right-to-be-forgotten request: token vault থেকে customer's PII delete। Warehouse-এ token left, কিন্তু token meaningless (no link to person)।
Aggregate retain: "Sylhet district 2023 revenue" remain — X-এর contribution irreversible mixed (allowed under GDPR)।
Backup retention policy: ৩০ দিন rolling, তারপর old backup auto-purge।
Audit dashboard: "এই বছর কতটি deletion request, কতটি SLA-এ complete"।

BB compliance:

BD-র ব্যাংকিং নিয়ম ৭ বছর transaction record রাখা required।
Personal info তাও pseudonymize-able।
Lakehouse-এর partial-delete + audit এই দু'টি conflicting demand handle করে।

মূল উপলব্ধি: Compliance শুধু legal team-এর কাজ না — data architecture থেকে শুরু। যিনি pillar-level (PII vault, lakehouse, audit) ভাবেন — তিনি future-proof system বানান।

প্র ০৩ Snowflake বনাম BigQuery বনাম Databricks (Delta)। তিনটি leading choice। একটি BD enterprise-এর জন্য কোন criteria দিয়ে বাছবেন?

এই তিনটি বাজারের ৭০% দখল করে রেখেছে। সিদ্ধান্ত পাঁচটি dimension-এ।

(১) Cloud preference / lock-in tolerance:

BigQuery: GCP only। Google ecosystem (Analytics, Ads) থাকলে obvious।
Snowflake: AWS, Azure, GCP — multi-cloud। কিন্তু Snowflake itself একটি vendor।
Databricks: Multi-cloud, এবং open Delta/Iceberg format — lock-in কম।
BD-র অনেক ব্যাংক/insurance Azure-এ রেগুলেটরি কারণে — Synapse অথবা Snowflake on Azure।

(২) Workload type:

Pure SQL/BI: Snowflake king — analyst experience সবচেয়ে polished।
Big data + ML + streaming: Databricks — Spark native।
Serverless analytics + Google ML: BigQuery + Vertex AI।

(৩) Cost model:

BigQuery: Pay per byte scanned ($5/TB)। Predictable cost; runaway query risky।
Snowflake: Pay per warehouse-hour। Auto-suspend; predictable usage।
Databricks: DBU + cloud compute + storage। Most flexible, most complex।
Small workload (১ TB/মাস)-এ BigQuery cheap। Heavy ETL workload-এ Snowflake/Databricks।

(৪) Team skill:

SQL শুধু: Snowflake easiest।
SQL + Python: BigQuery + Vertex বা Snowpark।
Python/Spark advanced: Databricks।
BD-তে Snowflake skill সহজে hire; Databricks specialist costly।

(৫) Open vs proprietary:

Snowflake: Native format proprietary; recently Iceberg support।
BigQuery: Native proprietary; Iceberg/Hudi external table support।
Databricks: Delta open-source; lock-in lowest।
Long-term flexibility চাইলে Iceberg/Delta on object storage।

BD-specific consideration:

Bangladesh Bank reporting: compliance-grade audit log। তিনটিই দেয়।
Data residency: BD-তে datacenter কারো নেই — নিকটতম Singapore (AWS/GCP) বা Mumbai (Azure)। Latency 50-80ms acceptable analytics-এ।
Skilled hire: Dhaka-তে Snowflake & BigQuery skill দু'টোই available; Databricks rare।
Hardware budget: Free tier — Snowflake $400 credit, BigQuery 1 TB/মাস ফ্রি।

সিদ্ধান্ত হিউরিস্টিক:

BI-heavy SaaS startup → Snowflake।
Google-ecosystem ad/marketing → BigQuery।
ML-heavy fintech / streaming → Databricks।
Heavy regulatory bank → Snowflake on Azure।
Open-future, multi-engine → Iceberg + Trino + Spark on S3।

মূল উপলব্ধি: "Best tool" বলে কিছু নেই — "context-এ best" আছে। এই context analysis-ই senior architect-এর core skill।

প্র ০৪ Iceberg-এর "snapshot expiry" feature কী এবং কেন এটি দীর্ঘমেয়াদে operational cost ও compliance-এ critical?

Iceberg metadata layer-এর সবচেয়ে কম-আলোচিত কিন্তু production-critical feature। Time travel free না — এর cost আছে।

Snapshot mechanism:

প্রতি INSERT/UPDATE/DELETE-এ Iceberg নতুন snapshot তৈরি করে।
Snapshot = একটি pointer set যা বলে "এই version-এ এই Parquet ফাইল valid"।
পুরোনো snapshot-এর Parquet ফাইল delete হয় না — তাই time travel কাজ করে।

সমস্যা:

প্রতি ঘণ্টায় ১০ snapshot — ১ মাসে ৭,২০০ snapshot।
প্রতিটি snapshot নতুন Parquet ফাইল রাখে (full বা partial)।
S3 cost linearly বাড়ছে। ৬ মাসে ১০x storage।
Metadata file (manifest list) অনেক বড় — query planning slow।

Snapshot expiry:

Policy — "৭ দিনের চেয়ে পুরোনো snapshot expire"।
Expired snapshot-এর দ্বারা reference না-হওয়া file delete।
Storage reclaim।

CALL system.expire_snapshots(
    table       => 'daraz.orders',
    older_than  => TIMESTAMP '2025-05-02 00:00:00'
);

Cost implication (BD context):

১০ TB warehouse + ৬ মাস retention without expiry → ১০০+ TB।
S3 cost: ১০ TB × $0.023/GB/মাস × ১২ মাস = ~$2,800। অথবা bloated 100 TB → $28,000।
BD ব্যাংক/fintech-এ এই difference yearly কোটি টাকা scale-এ।

Compliance angle:

GDPR/Data Protection Act — right to erasure:
- Customer X-এর data delete করলেও — পুরোনো snapshot-এ X এখনো reachable।
- Snapshot expiry না করলে — legally non-compliant।
- Retention policy: "DELETE-এর পর ৩০ দিন expire" required।
BB regulation:
- ৭ বছর transaction history retain করতে হবে।
- কিন্তু intermediate snapshot না।
- Production policy: "আজকের state ৭ বছর; intermediate snapshot ৩০ দিন"।
Audit:
- "কখন কোন data deleted হলো" — metadata log immutable।
- Compliance officer-কে snapshot history demonstrate করা যায়।

Operational best practices:

Tiered retention: production critical table 30 দিন; staging 7 দিন; dev 1 দিন।
Compaction job: ছোট ফাইল মার্জ — query performance ভাল।
Orphan file cleanup: reference-হীন file periodically delete।
Monitoring: snapshot count, total storage, query latency dashboard।

Pitfall:

Aggressive expiry — "৩ দিন" — কোনো ML reproducibility টিম "৭ দিন আগের training data" পাবে না।
Stakeholder সাথে retention policy align করা data engineer-এর কাজ।

মূল উপলব্ধি: Lakehouse "click-and-run" না। Day-2 operations — expiry, compaction, monitoring — warehouse-এর than চেয়ে বেশি কাজ। যিনি এই lifecycle thinking করেন — তিনি production-grade system বানান।

অনুশীলন

চিনুন: নিচের প্রতিটি use case-এর জন্য lake / warehouse / lakehouse — কোনটি best fit?
- (ক) BTRC monthly subscriber count report
- (খ) Pathao rider GPS log archive (৩ বছরের)
- (গ) Daraz user-product image embedding for ML model
- (ঘ) bKash daily fraud detection feature pipeline
- (ক) Warehouse: structured, regulatory, dashboard-friendly। Snowflake বা BigQuery।
- (খ) Lake: বিশাল, semi-structured, archive। S3 + Parquet।
- (গ) Lakehouse: mixed image + tabular, ML team Spark চালায়। Delta বা Iceberg।
- (ঘ) Lakehouse: streaming + batch, ACID দরকার, ML model serve। Delta/Iceberg + Spark Streaming।
হিসাব করুন: ১০ TB warehouse-এ Snowflake Storage cost $40/TB/মাস। S3 cost $23/TB/মাস। Lakehouse-এ ৭০% data S3-এ archive (cold), ৩০% warehouse-এ active। Pure warehouse vs lakehouse-এর মাসিক cost কত?
- Pure warehouse: $40 × ১০ = $400/মাস।
- Lakehouse: S3 cold ৭ TB × $23 = $161; warehouse hot ৩ TB × $40 = $120। Total $281।
- সাশ্রয়: $119/মাস (~৩০%)। বছরে $1,428।
১০০ TB scale-এ এই savings কোটি টাকা/বছর।
ভাবুন: আপনি একটি BD insurance company-র data architect। Customer claim history + medical document (PDF) + dashcam video (motor claim) সব রাখতে হবে। Storage architecture কী হবে?
প্রস্তাবিত:
- Object lake (S3): medical PDF, dashcam video raw। Compliance-grade encryption।
- Lakehouse (Iceberg on S3): claims tabular — structured + ACID + history।
- Warehouse (Snowflake): regulatory report, BI dashboard।
- Vector DB: medical document embedding RAG-এর জন্য।
প্রতিটি layer-এর cost-fit-purpose।