Delta Lake vs Apache Iceberg 2026: สถาปัตยกรรม Lakehouse และคำถามสัมภาษณ์

สถาปัตยกรรม data lakehouse ได้กลายเป็นมาตรฐานอุตสาหกรรมสำหรับแพลตฟอร์มข้อมูลสมัยใหม่ในปี 2026 สองรูปแบบตารางเปิดที่ครองตลาดในพื้นที่นี้คือ Delta Lake และ Apache Iceberg เทคโนโลยีทั้งสองนี้ช่วยให้องค์กรสามารถรวมข้อดีของ data lake (การจัดเก็บราคาถูก รูปแบบเปิด ความสามารถในการขยายตัว) เข้ากับความสามารถของ data warehouse (ธุรกรรม ACID, schema evolution, time travel) บทความนี้วิเคราะห์เชิงลึกเกี่ยวกับความแตกต่างระหว่าง Delta Lake และ Apache Iceberg การนำไปใช้จริง รวมถึงคำถามสัมภาษณ์ที่พบบ่อยในสาขา data engineering

สถาปัตยกรรม Delta Lake: โครงสร้างและส่วนประกอบหลัก

Delta Lake ใช้ transaction log ที่ใช้ JSON ชื่อว่า _delta_log เพื่อติดตามการเปลี่ยนแปลงทั้งหมดบนตาราง ทุกการดำเนินการเขียนจะสร้างไฟล์ JSON ใหม่ที่บันทึกว่าไฟล์ใดถูกเพิ่มหรือลบ วิธีการนี้ช่วยให้ ACID transactions และ concurrent reads/writes ทำงานได้อย่างปลอดภัย

โครงสร้างไดเรกทอรี Delta Lake มีลักษณะดังนี้:

my_delta_table/
├── _delta_log/
│   ├── 00000000000000000000.json
│   ├── 00000000000000000001.json
│   ├── 00000000000000000002.json
│   └── 00000000000000000010.checkpoint.parquet
├── part-00000-xxx.parquet
├── part-00001-xxx.parquet
└── part-00002-xxx.parquet

การสร้างและเขียนไปยัง Delta table โดยใช้ PySpark:

from delta import DeltaTable
from pyspark.sql import SparkSession

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

# Create Delta table with schema
df = spark.createDataFrame([
    (1, "Alice", "2026-01-15", 50000.00),
    (2, "Bob", "2026-01-16", 75000.00),
    (3, "Charlie", "2026-01-17", 60000.00)
], ["customer_id", "name", "signup_date", "revenue"])

df.write.format("delta").mode("overwrite").save("/data/customers_delta")

Delta Lake มีคุณสมบัติ MERGE ที่ทรงพลังสำหรับการดำเนินการ upsert:

from delta.tables import DeltaTable

# Load existing Delta table
delta_table = DeltaTable.forPath(spark, "/data/customers_delta")

# New data to merge
updates_df = spark.createDataFrame([
    (2, "Bob Smith", "2026-01-16", 80000.00),  # Update existing
    (4, "Diana", "2026-01-18", 45000.00)        # Insert new
], ["customer_id", "name", "signup_date", "revenue"])

# Perform MERGE operation
delta_table.alias("target").merge(
    updates_df.alias("source"),
    "target.customer_id = source.customer_id"
).whenMatchedUpdate(set={
    "name": "source.name",
    "revenue": "source.revenue"
}).whenNotMatchedInsert(values={
    "customer_id": "source.customer_id",
    "name": "source.name",
    "signup_date": "source.signup_date",
    "revenue": "source.revenue"
}).execute()

Apache Iceberg: สถาปัตยกรรมและข้อได้เปรียบ

Apache Iceberg ใช้วิธีการที่แตกต่างโดยจัดเก็บ metadata ในโครงสร้างลำดับชั้นสามระดับ: metadata files, manifest lists และ manifest files สถาปัตยกรรมนี้ช่วยให้ snapshot isolation มีประสิทธิภาพมากขึ้นและ partition evolution โดยไม่ต้อง rewrite ข้อมูล

โครงสร้าง metadata ของ Iceberg:

warehouse/
└── my_iceberg_table/
    ├── metadata/
    │   ├── v1.metadata.json
    │   ├── v2.metadata.json
    │   ├── snap-xxx-1.avro (manifest list)
    │   └── xxx-m0.avro (manifest file)
    └── data/
        ├── partition=2026-01/
        │   ├── 00000-0-xxx.parquet
        │   └── 00001-0-xxx.parquet
        └── partition=2026-02/
            └── 00000-0-xxx.parquet

การสร้างและดำเนินการกับ Iceberg table:

from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("IcebergDemo") \
    .config("spark.sql.extensions", "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions") \
    .config("spark.sql.catalog.local", "org.apache.iceberg.spark.SparkCatalog") \
    .config("spark.sql.catalog.local.type", "hadoop") \
    .config("spark.sql.catalog.local.warehouse", "/warehouse") \
    .getOrCreate()

# Create Iceberg table with partitioning
spark.sql("""
    CREATE TABLE local.db.events (
        event_id BIGINT,
        event_type STRING,
        user_id BIGINT,
        event_timestamp TIMESTAMP,
        properties MAP<STRING, STRING>
    )
    USING iceberg
    PARTITIONED BY (days(event_timestamp))
""")

# Insert data
spark.sql("""
    INSERT INTO local.db.events VALUES
    (1, 'page_view', 100, timestamp '2026-01-15 10:30:00', map('page', '/home')),
    (2, 'click', 100, timestamp '2026-01-15 10:31:00', map('button', 'signup')),
    (3, 'purchase', 101, timestamp '2026-01-15 11:00:00', map('amount', '99.99'))
""")

หนึ่งในข้อได้เปรียบหลักของ Iceberg คือ hidden partitioning ที่แยก partition scheme ออกจาก query:

# Partition evolution - change partitioning without rewriting data
spark.sql("""
    ALTER TABLE local.db.events
    ADD PARTITION FIELD hours(event_timestamp)
""")

# Query automatically uses optimal partition pruning
# Users don't need to know the partition structure
result = spark.sql("""
    SELECT event_type, count(*) as event_count
    FROM local.db.events
    WHERE event_timestamp >= '2026-01-15'
      AND event_timestamp < '2026-01-16'
    GROUP BY event_type
""")

การเปรียบเทียบคุณสมบัติ: Delta Lake vs Apache Iceberg

ด้านล่างนี้คือการเปรียบเทียบอย่างครอบคลุมระหว่าง Delta Lake และ Apache Iceberg ตามคุณสมบัติหลัก:

| คุณสมบัติ | Delta Lake | Apache Iceberg | |-----------|------------|----------------| | Transaction Log | JSON files พร้อม checkpoint | Metadata hierarchy หลายระดับ | | Schema Evolution | Add/rename columns | Full evolution รวมถึง reorder | | Partition Evolution | ต้อง rewrite | In-place ไม่ต้อง rewrite | | Time Travel | ตาม version/timestamp | Snapshot-based พร้อม retention | | Compute Engine Support | เหมาะสมกับ Spark/Databricks | Multi-engine (Spark, Flink, Trino, Presto) | | Catalog Integration | Unity Catalog, Hive | REST, Hive, AWS Glue, Nessie | | Delete Operations | Copy-on-write, merge-on-read | Copy-on-write, merge-on-read | | Community | Databricks นำ | Apache Foundation, multi-vendor |

Time travel สำหรับ audit และ debugging:

# Delta Lake time travel
df_v1 = spark.read.format("delta").option("versionAsOf", 1).load("/data/customers_delta")
df_timestamp = spark.read.format("delta").option("timestampAsOf", "2026-01-15 10:00:00").load("/data/customers_delta")

# Iceberg time travel
spark.sql("SELECT * FROM local.db.events VERSION AS OF 1")
spark.sql("SELECT * FROM local.db.events TIMESTAMP AS OF '2026-01-15 10:00:00'")

# Iceberg snapshot history
spark.sql("SELECT * FROM local.db.events.history").show()

การเพิ่มประสิทธิภาพและการบำรุงรักษา

ทั้งสองรูปแบบต้องการการบำรุงรักษาเป็นประจำเพื่อประสิทธิภาพที่ดีที่สุด Delta Lake ใช้ OPTIMIZE และ VACUUM ในขณะที่ Iceberg ใช้ compaction และ expire snapshots

การเพิ่มประสิทธิภาพ Delta Lake:

from delta.tables import DeltaTable

delta_table = DeltaTable.forPath(spark, "/data/customers_delta")

# Compact small files into larger ones
delta_table.optimize().executeCompaction()

# Z-order for query optimization on specific columns
delta_table.optimize().executeZOrderBy("signup_date", "customer_id")

# Remove old versions (retain 7 days)
spark.sql("VACUUM '/data/customers_delta' RETAIN 168 HOURS")

# View table history
delta_table.history().show()

การเพิ่มประสิทธิภาพ Apache Iceberg:

# Compact data files
spark.sql("""
    CALL local.system.rewrite_data_files(
        table => 'db.events',
        strategy => 'binpack',
        options => map('target-file-size-bytes', '134217728')
    )
""")

# Sort data for better query performance
spark.sql("""
    CALL local.system.rewrite_data_files(
        table => 'db.events',
        strategy => 'sort',
        sort_order => 'event_timestamp ASC, event_type ASC'
    )
""")

# Expire old snapshots
spark.sql("""
    CALL local.system.expire_snapshots(
        table => 'db.events',
        older_than => TIMESTAMP '2026-01-08 00:00:00',
        retain_last => 5
    )
""")

# Remove orphan files
spark.sql("""
    CALL local.system.remove_orphan_files(
        table => 'db.events',
        older_than => TIMESTAMP '2026-01-01 00:00:00'
    )
""")

การบูรณาการกับ Data Pipeline สมัยใหม่

ทั้งสองรูปแบบบูรณาการได้ดีในระบบนิเวศข้อมูลสมัยใหม่ ด้านล่างนี้คือตัวอย่าง pipeline กับ Apache Airflow:

from airflow import DAG
from airflow.providers.apache.spark.operators.spark_submit import SparkSubmitOperator
from datetime import datetime, timedelta

default_args = {
    'owner': 'data-engineering',
    'depends_on_past': False,
    'email_on_failure': True,
    'retries': 2,
    'retry_delay': timedelta(minutes=5)
}

with DAG(
    'lakehouse_etl_pipeline',
    default_args=default_args,
    schedule_interval='@hourly',
    start_date=datetime(2026, 1, 1),
    catchup=False
) as dag:

    ingest_to_bronze = SparkSubmitOperator(
        task_id='ingest_raw_events',
        application='/jobs/ingest_events.py',
        conf={
            'spark.sql.extensions': 'io.delta.sql.DeltaSparkSessionExtension',
            'spark.jars.packages': 'io.delta:delta-spark_2.12:3.1.0'
        }
    )

    transform_to_silver = SparkSubmitOperator(
        task_id='transform_events',
        application='/jobs/transform_silver.py'
    )

    aggregate_to_gold = SparkSubmitOperator(
        task_id='aggregate_metrics',
        application='/jobs/aggregate_gold.py'
    )

    optimize_tables = SparkSubmitOperator(
        task_id='optimize_delta_tables',
        application='/jobs/optimize_maintenance.py'
    )

    ingest_to_bronze >> transform_to_silver >> aggregate_to_gold >> optimize_tables

คำถามสัมภาษณ์ Data Engineering: สถาปัตยกรรม Lakehouse

ด้านล่างนี้คือคำถามสัมภาษณ์ที่พบบ่อยเกี่ยวกับ Delta Lake และ Apache Iceberg ในปี 2026:

คำถามที่ 1: อธิบายความแตกต่างหลักระหว่าง transaction log ของ Delta Lake และ metadata architecture ของ Apache Iceberg อันไหนเหมาะสมกว่าสำหรับกรณีการใช้งานเฉพาะ?

Delta Lake ใช้ transaction log ที่ใช้ JSON แบบ sequential ซึ่งทุกการดำเนินการจะสร้างไฟล์ JSON ใหม่ Checkpoint files ในรูปแบบ Parquet ถูกสร้างขึ้นเป็นระยะเพื่อเร่งการอ่าน state ล่าสุด วิธีการนี้เรียบง่ายและมีประสิทธิภาพ แต่ต้องอ่านไฟล์ JSON หลายไฟล์เพื่อสร้าง state ใหม่บน cluster ขนาดใหญ่

Apache Iceberg ใช้ metadata hierarchy สามระดับ: metadata files (JSON) ที่ชี้ไปยัง manifest lists (Avro) ซึ่งจากนั้นชี้ไปยัง manifest files (Avro) ที่มีข้อมูลไฟล์ข้อมูล สถาปัตยกรรมนี้ช่วยให้ pruning มีประสิทธิภาพมากขึ้นเพราะ statistics ถูกเก็บไว้ที่ระดับ manifest และ snapshot isolation ที่ดีกว่าสำหรับ concurrent queries

Delta Lake เหมาะสมกว่าสำหรับทีมที่ใช้ Databricks ecosystem อยู่แล้ว ต้องการการบูรณาการอย่างแน่นแฟ้นกับ Spark และต้องการ setup ที่ง่ายกว่า Iceberg เหนือกว่าในสภาพแวดล้อม multi-engine (Spark, Flink, Trino) ต้องการ partition evolution โดยไม่ต้อง data rewrite หรือทำงานกับ catalogs เช่น AWS Glue หรือ Apache Nessie

คำถามที่ 2: Partition evolution ทำงานอย่างไรใน Apache Iceberg? ทำไมนี่จึงเป็นข้อได้เปรียบที่สำคัญเมื่อเทียบกับวิธีการแบบดั้งเดิม?

Partition evolution ใน Iceberg ช่วยให้เปลี่ยน partition scheme โดยไม่ต้องเขียนข้อมูลที่มีอยู่ใหม่ เมื่อ partition scheme เปลี่ยน Iceberg จะเก็บข้อมูลนี้ใน metadata และจัดการ query ที่รวมข้อมูลทั้ง partition เก่าและใหม่โดยอัตโนมัติ

ตัวอย่างเช่น หากตารางถูก partition ตามเดือน (month(event_date)) ในตอนแรกและหลังจากนั้นเปลี่ยนเป็นวัน (day(event_date)) ข้อมูลเก่ายังคงอยู่ใน partition รายเดือนในขณะที่ข้อมูลใหม่ถูกเขียนไปยัง partition รายวัน Query planner ของ Iceberg จะใช้ partition pruning ที่เหมาะสมสำหรับ partition ทั้งสองประเภทโดยอัตโนมัติ

นี่แตกต่างอย่างมากจากวิธีการ Hive แบบดั้งเดิมหรือแม้แต่ Delta Lake ที่การเปลี่ยน partition ต้อง rewrite ตารางทั้งหมด สำหรับตารางขนาด petabyte นี่ช่วยประหยัดเวลาและค่าใช้จ่าย compute อย่างมาก

คำถามที่ 3: Copy-on-write vs merge-on-read คืออะไร? ควรใช้แต่ละกลยุทธ์เมื่อใด?

Copy-on-write (COW) เขียนไฟล์ข้อมูลทั้งหมดใหม่เมื่อมีการ update หรือ delete วิธีการนี้ให้ read performance ที่ดีที่สุดเพราะไม่มี overhead เมื่อ query แต่ write performance อาจช้าสำหรับการ updates บ่อยครั้ง

Merge-on-read (MOR) เก็บ deletes และ updates ในไฟล์แยกต่างหาก (delete files) และ merge เมื่ออ่าน Write performance เร็วกว่า แต่ reads ต้องการ overhead สำหรับการ merging

ใช้ copy-on-write สำหรับ: workloads ที่มี reads มากกว่า writes, batch processing ที่มี update window ชัดเจน และกรณีที่ read latency สำคัญ

ใช้ merge-on-read สำหรับ: streaming ingestion ที่มี frequent updates, workloads ที่มี high write throughput และกรณีที่ write latency สำคัญกว่า read latency ในทางปฏิบัติ หลายทีมใช้ทั้งสองร่วมกับ compaction job ที่แปลง MOR files เป็น COW เป็นระยะ

คำถามที่ 4: จะนำ data quality checks มาใช้ในสถาปัตยกรรม lakehouse ได้อย่างไร?

Data quality ในสถาปัตยกรรม lakehouse ถูกนำมาใช้ในหลาย layer:

ที่ ingestion layer ใช้ schema enforcement ที่ Delta Lake หรือ Iceberg ให้มาเพื่อปฏิเสธข้อมูลที่ไม่ตรงกับ schema Delta Lake มี constraint เช่น CHECK constraints และ NOT NULL

ที่ transformation layer เครื่องมือเช่น Great Expectations หรือ dbt tests สามารถบูรณาการเพื่อ validate ข้อมูล ตัวอย่างเช่น validate ว่าไม่มีค่า null ในคอลัมน์สำคัญ ค่าอยู่ใน range ที่คาดหวัง หรือ referential integrity ถูกรักษาไว้

ที่ serving layer ใช้ monitoring สำหรับ data freshness และ completeness แจ้งเตือนเมื่อตารางไม่ได้รับการอัปเดตใน window ที่คาดหวังหรือเมื่อ row counts เปลี่ยนแปลงอย่างผิดปกติ

คำถามที่ 5: อธิบายกลยุทธ์สำหรับการ migration จาก Hive tables ไปยังรูปแบบ lakehouse (Delta/Iceberg)

การ migration จาก Hive ไปยังรูปแบบ lakehouse สามารถทำได้หลายวิธี:

In-place conversion สำหรับ Iceberg: ใช้ procedure migrate ที่เพิ่ม metadata Iceberg ไปยัง Parquet files ที่มีอยู่โดยไม่ต้องย้ายข้อมูล นี่ช่วยให้ migration เร็วแต่ไม่ได้รับประโยชน์จาก file optimization

CTAS (Create Table As Select) migration: สร้างตารางใหม่ในรูปแบบเป้าหมายและ copy ข้อมูล วิธีการนี้ช่วยให้ optimization เช่น re-partitioning และ file sizing แต่ต้องการ storage เพิ่มเติมและ downtime

Dual-write migration: เขียนไปยังทั้งสองรูปแบบในช่วงเปลี่ยนผ่าน validate consistency จากนั้น cutover ไปยังรูปแบบใหม่ นี่ลดความเสี่ยงแต่ต้องการความพยายาม engineering มากขึ้น

Delta Lake ยังมี CONVERT TO DELTA สำหรับการแปลง Parquet tables ที่มีอยู่ Best practice คือเริ่มต้นด้วยตารางที่ไม่สำคัญ validate อย่างละเอียด จากนั้น migrate ตารางสำคัญทีละขั้นตอน

Best Practices สำหรับ Production Lakehouse

การจัดการ lakehouse ใน production ต้องการความสนใจในหลายแง่มุม:

# Example: Production-ready table configuration for Delta Lake
spark.sql("""
    CREATE TABLE IF NOT EXISTS prod.analytics.user_events (
        event_id STRING NOT NULL,
        user_id BIGINT NOT NULL,
        event_type STRING NOT NULL,
        event_properties MAP<STRING, STRING>,
        event_timestamp TIMESTAMP NOT NULL,
        processing_timestamp TIMESTAMP NOT NULL,
        _partition_date DATE GENERATED ALWAYS AS (CAST(event_timestamp AS DATE))
    )
    USING DELTA
    PARTITIONED BY (_partition_date)
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.logRetentionDuration' = 'interval 30 days',
        'delta.deletedFileRetentionDuration' = 'interval 7 days',
        'delta.columnMapping.mode' = 'name'
    )
""")

# Example: Production-ready table configuration for Iceberg
spark.sql("""
    CREATE TABLE IF NOT EXISTS local.analytics.user_events (
        event_id STRING NOT NULL,
        user_id BIGINT NOT NULL,
        event_type STRING NOT NULL,
        event_properties MAP<STRING, STRING>,
        event_timestamp TIMESTAMP NOT NULL,
        processing_timestamp TIMESTAMP NOT NULL
    )
    USING ICEBERG
    PARTITIONED BY (days(event_timestamp))
    TBLPROPERTIES (
        'write.format.default' = 'parquet',
        'write.parquet.compression-codec' = 'zstd',
        'write.target-file-size-bytes' = '134217728',
        'history.expire.max-snapshot-age-ms' = '604800000',
        'write.metadata.delete-after-commit.enabled' = 'true'
    )
""")

Monitoring และ observability สำคัญมากสำหรับ lakehouse production ใช้ metrics สำหรับ: จำนวนไฟล์ต่อ partition (เพื่อตรวจจับปัญหา small files), latency ของการดำเนินการ write และ read, storage utilization และอัตราการเติบโต รวมถึง query performance patterns

สรุป: การเลือกรูปแบบที่เหมาะสม

Delta Lake และ Apache Iceberg ทั้งคู่เป็นโซลูชันที่ mature สำหรับสถาปัตยกรรม lakehouse ในปี 2026 การเลือกระหว่างสองเทคโนโลยีนี้ขึ้นอยู่กับหลายปัจจัย:

เลือก Delta Lake ถ้า: องค์กรใช้ Databricks เป็นแพลตฟอร์มหลักอยู่แล้ว ทีมต้องการการบูรณาการอย่างแน่นแฟ้นกับ Spark ecosystem หรือต้องการคุณสมบัติเช่น Change Data Feed สำหรับ streaming CDC

เลือก Apache Iceberg ถ้า: ต้องการความสามารถในการทำงานร่วมกัน multi-engine (Spark, Flink, Trino, Presto), partition evolution โดยไม่ต้อง data rewrite เป็นข้อกำหนดสำคัญ หรือชอบมาตรฐานเปิดกับ governance ของ Apache Foundation

ในทางปฏิบัติ หลายองค์กรใช้ทั้งสองรูปแบบสำหรับ use cases ที่แตกต่างกัน สิ่งที่สำคัญที่สุดคือการเข้าใจ trade-offs ของแต่ละเทคโนโลยีและเลือกตามความต้องการเฉพาะของ workload

ประเด็นสำคัญที่ต้องจำ:

• Transaction log vs metadata hierarchy: Delta Lake ใช้ JSON logs, Iceberg ใช้ multi-level metadata
• Partition evolution: Iceberg เหนือกว่าด้วย in-place evolution โดยไม่ต้อง data rewrite
• Engine support: Delta Lake เหมาะสมที่สุดกับ Spark, Iceberg รองรับ multi-engine
• Maintenance: ทั้งสองรูปแบบต้องการ compaction และ cleanup เป็นประจำ
• Interview preparation: เข้าใจสถาปัตยกรรมภายใน ไม่ใช่แค่ syntax API

การเชี่ยวชาญทั้งสองเทคโนโลยีนี้ให้ความยืดหยุ่นในการเผชิญกับความท้าทาย data engineering ที่หลากหลายและเตรียมผู้สมัครสำหรับคำถามสัมภาษณ์ที่ลึกซึ้งมากขึ้นเกี่ยวกับสถาปัตยกรรม lakehouse สมัยใหม่