สถาปัตยกรรม Data Lakehouse (Apache Iceberg & MinIO)

ทฤษฎีและกลไกการทำงาน (How it works): จุดเริ่มต้นของ Lakehouse คือการแยกส่วนประมวลผล (Compute) ออกจากส่วนจัดเก็บข้อมูล (Storage) อย่างเด็ดขาด โดยการใช้ระบบ Metadata Layer (เช่น Apache Iceberg, Delta Lake, Hudi) ครอบทับข้อมูลไฟล์ Parquet ใน Object Storage กลไกนี้ช่วยให้สามารถรันคำสั่ง ACID Transactions ได้เหมือนฐานข้อมูลแบบเดิม โดยใช้ระบบเลขเวอร์ชันกำกับ และนำการเขียนพร้อมกันมาตรวจสอบผ่านกลไก Optimistic Concurrency Control (OCC) โดยไม่มีโหนดศูนย์กลางล็อกไฟล์ประมวลผล

-- Spark SQL demonstrating ACID updates on an Iceberg table
BEGIN TRANSACTION;
UPDATE iceberg_prod.marts.customer_orders
SET order_status = 'COMPLETED'
WHERE order_id = 'ord_90124';
COMMIT;
                    

Use Case ในชีวิตจริง (Real-world Scenario): คลังข้อมูลระดับเทราไบต์ของสายการบิน นำเข้าพฤติกรรมการจองตั๋วแบบสตรีมมิ่งตลอดเวลาในขณะที่ทีมการเงินรันรวบรวมข้อมูลบัญชีสิ้นวันพร้อมกัน ระบบ Lakehouse ช่วยป้องกันไม่ให้การคำนวณสะดุดหรือได้ค่ารายงานการเงินที่คลาดเคลื่อน

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): หากเครื่องวิเคราะห์รันเขียนข้อมูลชนกันถ่วงเวลาพร้อมกันบ่อยครั้ง จะทำให้คำสั่งยกเลิกตัวเองเกิดบ่อยจากข้อผิดพลาด OCC (Concurrent Append Exceptions) แก้ไขโดยตั้งค่าจำกัดขอบเขตการเขียนให้สั้นที่สุด หรือกระจายสเปคพาร์ทิชันย่อยเพื่อหลีกเลี่ยงการเขียนลงตำแหน่งเดียวกัน

ทฤษฎีและกลไกการทำงาน (How it works): Apache Iceberg ทำงานโดยแบ่งสัดส่วนเมทาดาต้าออกเป็น 4 ระดับชั้นแบบต้นไม้กลับหัว: 1. **Iceberg Catalog**: ชี้พิกัดไปยังไฟล์ Metadata JSON ตัวล่าสุดอย่างเป็นทางการ 2. **Metadata File (JSON)**: เก็บลายเซ็นประวัติสกีมาตาราง (Schema Spec) ขอบเขตพาร์ทิชัน และบันทึกประวัติการบันทึกสแนปช็อต (Snapshots) 3. **Manifest List (Avro)**: เก็บไฟล์รายการของสแนปชอตเดี่ยว บันทึกค่าพารามิเตอร์ขอบเขตพาร์ทิชันเพื่อข้ามการเปิดดูโฟลเดอร์ที่ไม่เกี่ยวข้อง 4. **Manifest File (Avro)**: บันทึกรายชื่อไฟล์ข้อมูลดิบจริง (Data Files ในรูปแบบ Parquet/ORC) รวมถึงค่าสถิติ Min/Max ของแต่ละคอลัมน์ในไฟล์นั้น

# Abstract concept of Iceberg metadata tree hierarchy
[Iceberg Catalog Pointer]
       |
       v
[Metadata File JSON (Schema & Snapshots)]
       |
       v
[Manifest List Avro (Snapshot Specific)]
       |
       v
[Manifest File Avro (Data file stats)]
       |
       v
[Data Files (Parquet, Parquet, ...)]
                    

Use Case ในชีวิตจริง (Real-world Scenario): การย้อนเวลาข้อมูลวิเคราะห์ (Time Travel) ไปดูตารางยอดสั่งซื้อ ณ วันที่ 1 มกราคม 2026 เอนจิ้นคิวรี่จะไปไล่อ่านจากไฟล์ Metadata JSON เพื่อดึงลิสต์ของ Snapshot ในวันนั้น ทำให้สามารถสืบค้นรายการประวัติจริงย้อนหลังได้อย่างรวดเร็วและประหยัดงบคิวรี

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ไฟล์สแนปช็อตเก่าและไฟล์ขยะจะสะสมขนาดใหญ่โตขึ้นเรื่อยๆ จนเต็มดิสก์โฮสต์ แก้ไขโดยใช้ระบบตั้งเวลาบดขยะตาราง (Expire Snapshots และ Remove Orphan Files) สม่ำเสมอเพื่อประหยัดค่าใช้จ่ายจัดเก็บ

ทฤษฎีและกลไกการทำงาน (How it works): ต่างจาก RDBMS แบบดั้งเดิมที่รันล็อกตาราง (Pessimistic Lock) Iceberg ใช้ระบบ **Optimistic Concurrency Control (OCC)** ซึ่งอยู่บนสมมติฐานว่าการชนกันของคำสั่งเขียนมีโอกาสเกิดน้อย ทุกโปรเซสจะเขียนข้อมูลลงดิสก์ส่วนตัวของตัวเองโดยปราศจากการล็อก เมื่อถึงขั้นตอน Commit ระบบจะนำค่าแฮชเวอร์ชันล่าสุดมาเช็คเทียบกับ Catalog หากมีผู้อื่น Commit หน้าไปก่อนแล้ว ทรานแซกชันล่าสุดจะถูกยกเลิก (Abort) เพื่อป้องกันการเขียนทับซ้อนและหลีกเลี่ยงสถานะข้อมูลไม่นิ่ง

# Simulated retry loop script to handle OCC conflicts in Iceberg
import time

def commit_transaction_with_retry(data_payload, max_retries=3):
    retries = 0
    while retries < max_retries:
        try:
            # Attempt atomic catalog update
            # catalog.commit(data_payload)
            print("Commit successful!")
            return True
        except Exception as e: # Catch concurrent commit exceptions
            retries += 1
            print(f"Commit conflict detected. Retrying... {retries}/{max_retries}")
            time.sleep(2 ** retries) # Exponential backoff
    raise Exception("Failed to commit after maximum retries.")
                    

Use Case ในชีวิตจริง (Real-world Scenario): ระบบปรับยอดสมาชิกอัตโนมัติที่รันทำงานพร้อมกันจากสองท่อส่งข้อมูล ข้อมูลยอดใหม่จะถูกคำนวณและเขียนลงไฟล์ Parquet ล่วงหน้าได้ขนานกันโดยไม่ต้องบล็อกเวลารัน จากนั้นจึงมาทำการจัดล็อกต่อคิวสุดท้ายที่ระดับ Catalog เพียงเสี้ยววินาที

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): สภาวะ **Commit Conflict Storm** เกิดเมื่อมีตัวรันระบบประมวลผลขนาดเล็กจำนวนมากพยายามยิงคอมมิตเข้าหาตารางเดียวพร้อมกัน แก้ไขโดยเปลี่ยนมาใช้งานระบบ Catalogs ที่มีความมั่นคงสูงในการล็อกอะตอมิก (เช่น Apache Hive Metastore หรือ AWS Glue Catalog)

ทฤษฎีและกลไกการทำงาน (How it works): ในสถาปัตยกรรมข้อมูลยุคเก่า การจัดหมวดพาร์ทิชันตาราง (เช่น แยกโฟลเดอร์ตามปี `year=2026/`) หากต้องการสลับรูปแบบพาร์ทิชันใหม่ (เช่น เปลี่ยนเป็นแยกตามเดือน) วิศวกรต้องสร้างตารางใหม่และกวาดเขียนข้อมูลย้อนหลังทั้งหมด (Rewrite history) แต่ Apache Iceberg รองรับกลไก **Partition Evolution** ข้อมูลใหม่จะถูกเขียนแยกตามกฎพาร์ทิชันตัวใหม่ ส่วนข้อมูลประวัติเก่าจะคงอยู่ในโฟลเดอร์พาร์ทิชันเดิม โดยมีตัว Metadata คอยจัดการแมปช่วงคำสั่งคิวรี่ประสานงานย้อนหลังให้ผู้ใช้เองโดยอัตโนมัติ

-- Spark SQL demonstrating partition evolution in Iceberg
-- 1. Create table partitioned by month
CREATE TABLE iceberg_prod.db.user_clicks (
    user_id string, click_time timestamp, action string
) USING iceberg PARTITIONED BY (month(click_time));

-- 2. Evolve partitioning scheme to partition by day without rewriting history
ALTER TABLE iceberg_prod.db.user_clicks ADD PARTITION FIELD day(click_time);
                    

Use Case ในชีวิตจริง (Real-world Scenario): ธุรกิจสตาร์ทอัปที่มีข้อมูลผู้ใช้วิ่งเข้ามาต่อวันมีจำนวนเพิ่มขึ้น 100 เท่าตัว จากเดิมที่เคยจัดเก็บพาร์ทิชันตามระดับรายเดือน ปรับเปลี่ยนรูปแบบเป็นพาร์ทิชันรายวันได้อย่างรวดเร็วผ่านคำสั่ง `ALTER TABLE` เพื่อเร่งความเร็วในการคิวรี่ประจำวันโดยไม่ต้องทำลายตารางข้อมูลเดิม

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): แม้จะทำ Partition Evolution ได้ง่าย แต่ต้องระมัดระวังไม่แยกสัดส่วนย่อยเกินไป (Over-partitioning เช่น พาร์ทิชันข้อมูลรายชั่วโมงบนตารางที่มีการอัปเดตหลักสิบแถว) ซึ่งจะส่งผลให้ไฟล์มีขนาดเล็กเกินไปเป็นภาระต่อระบบ Metadata แก้ไขโดยหมั่นตรวจประเมินรูปแบบการฟิลเตอร์เฉลี่ยของทีมวิเคราะห์