Local-first Data Engineering ด้วย DuckDB

ทฤษฎีและกลไกการทำงาน (How it works): ฐานข้อมูลแบบรายแถว (Row-oriented - RDBMS) บันทึกค่าทุกคอลัมน์ในแถวติดกันบนแผ่นดิสก์ เหมาะกับงานเขียนเป็นธุรกรรมรายตัว (OLTP) ในขณะที่ฐานข้อมูลรายคอลัมน์ (Columnar database เช่น DuckDB, ClickHouse) จัดเก็บค่าข้อมูลในแต่ละคอลัมน์แยกกันออกจากกันอย่างสิ้นเชิง เหมาะอย่างยิ่งสำหรับงานวิเคราะห์สรุปผล (OLAP) เนื่องจากคิวรีจะอ่านเฉพาะข้อมูลคอลัมน์ที่ระบุในเงื่อนไขการคำนวณเท่านั้น และข้ามคอลัมน์อื่นได้โดยตรง ส่งผลให้ประหยัดพื้นที่ดิสก์ I/O มหาศาล

# Concept of row storage vs column storage
Row-oriented (PostgreSQL):
[Row 1: ID, Name, Age] -> [Row 2: ID, Name, Age]

Column-oriented (DuckDB):
[Column ID: 1, 2] -> [Column Name: 'A', 'B'] -> [Column Age: 25, 30]
                    

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

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ฐานข้อมูลแบบคอลัมน์ไม่เหมาะกับงานเขียนแทรกทีละแถวถี่ๆ (High-frequency single-row insert) เพราะมีภาระในการจัดเก็บข้อมูลแยกคอลัมน์สูงมาก แก้ไขโดยสะสมข้อมูลเป็นชุด (Micro-batch) แล้วเขียนลงดิสก์พร้อมกันทีเดียว

ทฤษฎีและกลไกการทำงาน (How it works): ระบบประมวลผลทั่วไปจะทำการวนลูปประมวลผลทีละแถวข้อมูลซึ่งเกิดความล่าช้าจาก Instruction loop overhead แต่ DuckDB ใช้เครื่องยนต์รันมติแบบ **Vectorized Execution** โดยจัดเก็บข้อมูลแยกเป็นกลุ่มอาร์เรย์ (Vectors ขนาด 1024 ค่า) และประมวลผลพร้อมกันในหน่วยความจำ L1/L2 Cache ของ CPU ซึ่งประสานร่วมกับคำสั่งระดับฮาร์ดแวร์ **SIMD (Single Instruction Multiple Data)** ทำให้ CPU คำนวณขนานกันในระดับสัญญาณนาฬิกา

# Python demonstration comparing loop vs vectorized calculations
import numpy as np

# Simulate 1 million order amounts
amounts = np.random.rand(1000000)

# 1. Slow loop computation
# total = [x * 1.07 for x in amounts]

# 2. Fast Vectorized SIMD computation (DuckDB model)
total_vectorized = amounts * 1.07
                    

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

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ประสิทธิภาพ Vectorized จะลดลงหากประมวลผลคอลัมน์ประเภท String ขนาดใหญ่ที่มีสถิติผันแปรสูง แก้ไขโดยแปลงประเภทข้อมูลให้เป็นหมวดหมู่ (Enum/Dictionary encoding) เพื่อลดขนาดบิตของอาร์เรย์ในแรม

ทฤษฎีและกลไกการทำงาน (How it works): ส่วนต่อขยาย **httpfs** ของ DuckDB ช่วยให้ผู้พัฒนาสามารถรันคำสั่งคิวรีข้อมูล SQL บนไฟล์ Parquet/CSV ที่เก็บอยู่บนคลาวด์ภายนอกได้โดยตรง ผ่านโปรโตคอล HTTP range requests กลไกนี้จะส่งคำขออ่านพิกัดเฉพาะฟิลด์ Metadata ของไฟล์ Parquet เพื่อหาพิกัดระดับบิตของคอลัมน์ที่ต้องการ จากนั้นยิงขอดึงเฉพาะส่วนต่างข้อมูลระดับบล็อกบิตมาประมวลผลข้ามท่อเครือข่าย โดยข้ามการดาวน์โหลดไฟล์ขนาดใหญ่ทั้งไฟล์มาเก็บไว้ในเครื่อง

-- DuckDB setup script to query remote S3 parquet files directly
INSTALL httpfs;
LOAD httpfs;

-- Configure cloud storage access parameters
SET s3_region = 'ap-southeast-1';
SET s3_access_key_id = 'AWS_ACCESS_KEY';
SET s3_secret_access_key = 'AWS_SECRET_KEY';

-- Query only 2 target columns from a 5GB remote parquet file
SELECT customer_id, SUM(purchase_amount)
FROM read_parquet('s3://my-prod-datalake/gold/sales/**/*.parquet')
GROUP BY customer_id;
                    

Use Case ในชีวิตจริง (Real-world Scenario): วิศวกรข้อมูลวิเคราะห์แนวโน้มยอดขายสินค้าผ่านไฟล์บันทึกประวัติขนาด 50GB บน Amazon S3 โดยรันสคริปต์ DuckDB คอนฟิก HTTPFS บนแล็ปท็อป ดึงข้อมูลผ่านเน็ตเวิร์กเพียง 2MB ประมวลผลและตอบคำถามคิวรีได้ทันควันในเวลาครึ่งวินาที

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การรันคิวรีลักษณะนี้บ่อยครั้งอาจมีค่าใช้จ่ายแฝงจากการส่งคำขอเรียกเก็บไฟล์จาก Object Store (API Get/List request charges) แก้ไขโดยดาวน์โหลดส่วนต่างที่กรองพาร์ทิชันแล้วลงฮาร์ดดิสก์เพื่อรันวิเคราะห์แบบ Offline

ทฤษฎีและกลไกการทำงาน (How it works): อุปสรรคหนึ่งของการแลกเปลี่ยนข้อมูลระหว่างฐานข้อมูลและหน่วยความจำของโค้ดโปรแกรมคือขั้นตอนการแปลงรูปแบบตัวแปล (Serialization/Deserialization) DuckDB แก้ปัญหานี้โดยสนับสนุนการทำงานบนมาตรฐานความปลอดภัยหน่วยความจำ **Apache Arrow** ทำให้เราสามารถแลกเปลี่ยนตารางข้อมูลขนาดใหญ่ระหว่าง DuckDB, Pandas, Polars และ PyArrow ใน RAM วงเดียวกันได้ทันทีแบบ **Zero-Copy** โดยไม่มีการก๊อปปี้บล็อกข้อมูลหรือเขียนทับในหน่วยความจำ

# Zero-Copy integration demo using DuckDB and Polars
import polars as pl
import duckdb

# 1. Create Polars DataFrame in RAM
df_polars = pl.DataFrame({"id": [1, 2, 3], "score": [95.5, 88.0, 92.4]})

# 2. DuckDB queries Polars DataFrame directly in memory without copy
result_df = duckdb.query("SELECT id, score * 1.1 AS new_score FROM df_polars").pl()
print(result_df)
                    

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

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ความเข้ากันไม่ได้ของบางสเปคฟิลด์วันเวลา (Timestamp timezone offset) ระหว่าง Pandas และ DuckDB อาจทำให้ประเภทข้อมูลเคลื่อนแก้ไขดักจับยาก แก้ไขโดยการระบุการจัดรูปแบบประเภทให้อยู่ในมาตรฐานกลาง UTC (Timezone-naive) ก่อนประมวลผล

ทฤษฎีและกลไกการทำงาน (How it works): DuckDB เป็นฐานข้อมูลแบบ **Embedded** ซึ่งรันอยู่ในโปรเซสหน่วยความจำเดียวกันกับแอปพลิเคชันหลัก เมื่อต้องประมวลผลข้อมูลที่มีขนาดใหญ่กว่า RAM (Larger-than-RAM) DuckDB จะใช้กลไก **Out-of-Core Processing** โดยโหลดข้อมูลเข้ามาทำใน RAM ทีละบล็อก (Chunking) และหาก RAM ใกล้เต็ม จะทำการพักข้อมูล (Spill) ลงบนฮาร์ดดิสก์อัตโนมัติ ทำให้รันคำนวณผ่านไฟล์ใหญ่ได้โดยไม่เกิด Out-of-Memory (OOM)

-- Configuration variables to cap resource footprint and enable out-of-core spilling
SET memory_limit = '4GB';   -- Cap RAM usage to 4 gigabytes
SET threads = 4;            -- Limit execution threads to 4 cores
SET temp_directory = '/tmp/duckdb_temp/'; -- Spill excess data to specific disk directory
                    

Use Case ในชีวิตจริง (Real-world Scenario): การรันสคริปต์ทำ JOIN ตารางข้อมูลขนาด 50GB บนแล็ปท็อปที่มีแรมเพียง 16GB กลไก Out-of-Core จะสลับการอ่านเขียนลงดิสก์ NVMe ทำให้งานคำนวณเสร็จสิ้นได้โดยเครื่องไม่แฮงก์

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การพักข้อมูล (Spill to disk) บนฮาร์ดดิสก์แบบเก่า (HDD) จะทำให้ระบบทำงานช้าลงมหาศาล แก้ไขโดยรันงานบนดิสก์ SSD/NVMe และขยาย memory_limit ให้มากที่สุดเท่าที่จะเป็นไปได้