การแปลงข้อมูลระดับโปรด้วย dbt-core

ทฤษฎีและกลไกการทำงาน (How it works): dbt-core ทำงานในฐานะคลังเก็บโค้ด SQL ที่จัดรูปเป็นแบบระบุปลายทาง (Declarative) โดยใช้คำสั่งระบุความสัมพันธ์เป้าหมายด้วยคำฟังก์ชัน `ref()` และ `source()`. เมื่อสั่งรันคำสั่ง ตัว dbt จะสแกนโฟลเดอร์ไฟล์โมเดลทั้งหมดเพื่อทำการสร้างและคอมไพล์ **Directed Acyclic Graph (DAG)** เพื่อแสดงความสัมพันธ์การไหลของตารางข้อมูล ก่อนจะสร้างคำสั่ง DDL (Data Definition Language) ยิงไปประมวลผลบนคลังข้อมูลปลายทางโดยตรงตามลำดับชั้นความสัมพันธ์ที่ถูกต้อง

-- Defining dependencies inside dbt models using Jinja functions
-- models/marts/fct_weekly_sales.sql
WITH daily_orders AS (
    SELECT * FROM {{ ref('stg_orders') }} -- Tells dbt compiler to compute stg_orders first
),
customer_details AS (
    SELECT * FROM {{ ref('dim_customers') }}
)
SELECT ...
                    

Use Case ในชีวิตจริง (Real-world Scenario): คลังข้อมูลของบริษัทประกันภัยที่มีโมดูล SQL เชื่อมต่อกันกว่า 500 ตาราง การเปลี่ยนโครงสร้างฟิลด์ในตารางฐานล่าง dbt ช่วยระบุความเกี่ยวข้องข้ามสายและไล่แปลงค่าตารางในชั้นถัดไปตามลำดับโดยไม่สร้างความขัดแย้งเชิงโครงสร้าง

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การเกิดโครงสร้างความสัมพันธ์แบบลูปวงกลม (Circular Dependency เช่น ตาราง A เรียก B และ B เรียก A) ซึ่งจะทำให้คอมไพเลอร์ของ dbt รันไม่ผ่าน แก้ไขโดยถอดถอนตรรกะประมวลผลย่อยออกมาสร้างตารางสะพานตัวกลาง (Bridge model) เพื่อตัดการเชื่อมโยงวงกลม

ทฤษฎีและกลไกการทำงาน (How it works): dbt สนับสนุนการทำ Materializations ซึ่งคือการเลือกแปลงรหัส SQL ไปจัดเก็บเป็นสเตทจริงบนฐานข้อมูล 4 รูปแบบ: 1. **View**: สร้างวิวคิวรีจำลองขึ้นมา ไม่เปลืองพื้นที่ดิสก์ แต่จะคำนวณใหม่ทุกครั้งที่มีการเรียกสืบค้นข้อมูล 2. **Table**: บิวด์สร้างตารางดิสก์จริงเต็มรูปแบบ โดยจะรันคำสั่งลบและบิวด์ตารางใหม่ทั้งหมดในทุกครั้งที่รัน (Drop and Recreate) ปลอดภัยต่อข้อมูลนิ่งแต่กินเวลาการประมวลผลสูง 3. **Ephemeral**: แปลงโมเดลเป็นโครงสร้างย่อย (Common Table Expression - CTE) ไปสอดแทรกในโมเดลถัดไปแทนการเขียนลงฐานข้อมูล 4. **Incremental**: ประมวลผลและแทรกเฉพาะข้อมูลพาร์ทิชันแถวใหม่ที่เพิ่มขึ้น ช่วยเซฟเวลาและงบประมาณการดึงข้อมูล OLAP คลาวด์ได้สูงสุด

# Configuration inside dbt model block defining materialization type
# models/staging/stg_orders.sql
{{ config(
    materialized='table',
    indexes=[{'columns': ['order_id'], 'type': 'btree'}]
) }}
                    

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

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การรันโมเดลแบบ Table บนฐานข้อมูลขนาดใหญ่เป็นร้อยล้านแถวทำให้เกิดความล่าช้าและเปลืองค่าคอมพิวต์คลาวด์ แก้ไขโดยปรับเปลี่ยนสเปคโมเดลเหล่านั้นให้มาใช้กลไก `incremental` โดยกรองดักเฉพาะฟิลด์แก้ไขล่าสุด

ทฤษฎีและกลไกการทำงาน (How it works): ในโหมดการรันแบบส่วนต่าง dbt จะประยุกต์ใช้งาน 2 รูปแบบย่อยเพื่อซิงก์ข้อมูลเข้าตารางเป้าหมาย: - **Append-only**: นำระเบียนข้อมูลใหม่ไปเขียนต่อท้ายตารางโดยตรงอย่างรวดเร็ว เหมาะสำหรับตารางล็อกเหตุการณ์ที่ไม่เคยมีการแก้ไขย้อนหลัง - **Merge**: นำคีย์หลัก (Unique Key) ของข้อมูลชุดใหม่มาเทียบชนกับตารางหลัก หากคีย์ตรงกันจะสั่งอัปเดตฟิลด์ (Update) หากไม่เจอจะสั่งแทรกแถวใหม่ (Insert) ช่วยรักษาความสะอาดไม่ให้เกิดรายการแถวซ้ำซ้อน - **Insert-Overwrite**: เขียนทับข้อมูลทั้งพาร์ทิชัน (เช่น รายวัน) ด้วยข้อมูลใหม่ทั้งหมด เหมาะกับข้อมูลที่มีการเปลี่ยนแปลงบ่อยในระดับพาร์ทิชัน - **Microbatching**: ทยอยรันข้อมูลทีละชุดเล็กๆ ตามช่วงเวลา (เช่น ทุก 1 ชั่วโมง) เพื่อลดภาระหน่วยความจำและทำให้ข้อมูลใกล้เคียงเรียลไทม์มากขึ้น

-- Incremental configuration using merge strategy
-- models/marts/fct_orders.sql
{{ config(
    materialized='incremental',
    unique_key='order_id',
    incremental_strategy='merge'
) }}

SELECT * FROM {{ ref('stg_orders') }}
{% if is_incremental() %}
  -- Filter records updated within the last lookback window
  WHERE order_updated_at >= (SELECT MAX(order_updated_at) FROM {{ this }})
{% endif %}
                    

Use Case ในชีวิตจริง (Real-world Scenario): ตารางประวัติยอดขายสินค้าของระบบอีคอมเมิร์ซที่สถานะคำสั่งซื้อสามารถเปลี่ยนจาก "กำลังจัดส่ง" ไปเป็น "จัดส่งสำเร็จ" การใช้ Merge Strategy ในโหมด Incremental ช่วยอัปเดตสถานะของออร์เดอร์เดิมได้อย่างถูกต้องครบถ้วน

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

ทฤษฎีและกลไกการทำงาน (How it works): ปัญหาคลาสสิกของท่อส่งแบบส่วนต่างคือ **Late-arriving Data** ข้อมูลเกิดเมื่อวานแต่เพิ่งส่งมาถึงคลังวันนี้เนื่องจากระบบเน็ตเวิร์กของแอปพลิเคชันสะดุด หากเรากรองดึงเฉพาะข้อมูลที่เกิดขึ้นหลังเวลาสูงสุดปัจจุบันของตาราง ข้อมูลที่มาสายกลุ่มนี้จะหลุดรอดการประมวลผลถาวร วิธีแก้ไขคือการเขียนตรรกะเผื่อเวลาคิวรี่ย้อนหลังเรียกว่า **Lookback Window** โดยขยับเวลาเริ่มต้นการดึงข้อมูลย้อนหลังไปเผื่อ เช่น 3 วันล่าสุดเสมอ และพึ่งพา Merge strategy เพื่อลบอัปเดตแถวเก่าซ้ำซ้อน

-- Implementing a 3-day lookback window inside dbt incremental logic
SELECT * FROM {{ ref('stg_events') }}
{% if is_incremental() %}
  -- Scan last 3 days to capture delayed telemetry events
  WHERE event_timestamp >= (SELECT DATEADD(day, -3, MAX(event_timestamp)) FROM {{ this }})
{% endif %}
                    

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

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การกำหนด Lookback Window กว้างเกินไป (เช่น สแกนย้อนหลัง 30 วันในทุกๆ ชั่วโมง) จะทำให้ท่อประมวลผลใช้เวลานานขึ้นและเสียค่าคอมพิวต์สูงเกินความจำเป็น แก้ไขโดยการประเมินสถิติเวลาล่าช้าเฉลี่ย (SLA tracking) เพื่อกำหนดระยะ Lookback ให้เหมาะสมที่สุด

ทฤษฎีและกลไกการทำงาน (How it works): dbt Semantic Layer (ขับเคลื่อนโดย Metricflow) ช่วยให้องค์กรสามารถนิยามตัวชี้วัด (Metrics) เช่น รายได้ (Revenue) หรือ จำนวนลูกค้า (Active Users) ไว้ที่ส่วนกลางแทนที่จะเขียน SQL ซ้ำๆ ในหลาย Dashboard

# models/metrics/revenue.yml
metrics:
  - name: revenue
    description: "Total revenue from completed orders"
    type: simple
    type_params:
      measure: total_amount
    meta:
      has_pii: false
                    

Use Case ในชีวิตจริง (Real-world Scenario): ทีมการตลาดและทีมการเงินดึงตัวเลข "ยอดขายประจำเดือน" ไปใช้ใน Tableau และ PowerBI โดยได้ตัวเลขตรงกันเสมอเพราะดึงจาก Semantic Layer เดียวกัน

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การออกแบบ Dimension และ Measure ที่ซับซ้อนเกินไปอาจทำให้คิวรี่ช้า แก้ไขโดยการทำ Pre-aggregation หรือการทำ Caching

ทฤษฎีและกลไกการทำงาน (How it works): เมื่อองค์กรขยายใหญ่ขึ้น การมี dbt project เดียว (Monolith) จะทำให้รันช้าและจัดการยาก dbt Mesh อนุญาตให้แบ่งโปรเจกต์ย่อยและอ้างอิงโมเดลข้ามโปรเจกต์ได้ผ่าน `{{ ref('project_name', 'model_name') }}`

-- models/marts/marketing_roi.sql
SELECT * FROM {{ ref('finance_project', 'fct_revenue') }} -- Cross-project reference
                    

Use Case ในชีวิตจริง (Real-world Scenario): ทีมการตลาดสามารถอ้างอิงตารางรายได้ (Revenue) ที่ทีมการเงินดูแลอยู่ได้โดยตรง โดยไม่ต้องก็อปปี้โค้ดหรือรอให้ทีมการเงินสร้างวิวให้

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การผูกมัด (Coupling) ระหว่างโปรเจกต์อาจทำให้เกิดปัญหาเมื่อโปรเจกต์ต้นทางเปลี่ยนสกีมา แก้ไขโดยใช้ Data Contracts ระหว่างโปรเจกต์ (Model Contracts)

ทฤษฎีและกลไกการทำงาน (How it works): หาก Materialization มาตรฐาน (Table, View, Incremental) ไม่ตอบโจทย์ dbt เปิดให้เขียน Jinja macro เพื่อกำหนดวิธีการสร้างตารางด้วยตัวเอง (Custom Materialization)

{% materialization custom_insert_only, default %}
  {%- set target_relation = api.Relation.create(identifier=model['alias'], schema=schema, database=database) -%}
  {% call statement('main') -%}
    INSERT INTO {{ target_relation }} ( {{ sql }} );
  {%- endcall %}
  {{ return({'relations': [target_relation]}) }}
{% endmaterialization %}
                    

Use Case ในชีวิตจริง (Real-world Scenario): ต้องการยิงข้อมูลเข้าสู่ระบบปลายทางที่เป็นฐานข้อมูลแบบพิเศษที่ต้องการคำสั่ง SQL เฉพาะเจาะจง (เช่น ClickHouse หรือระบบ Real-time เฉพาะ)

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การเขียน Custom Materialization เองอาจเกิดข้อผิดพลาดในการจัดการ State ของข้อมูล (เช่น ข้อมูลซ้ำ) จึงต้องเขียนโค้ดรองรับกรณีล้มเหลว (Idempotency) ให้ดี