Dataform คืออะไร ? — Tool ที่อยากแนะนำ Data Team ที่ใช้ BigQuery ให้รู้จัก

เคยเจอแบบนี้กันมั้ย ? — SQL Code อยู่กันแบบกระจัดกระจาย , ลำดับการ RUN ก็พัง และก็ยังไม่รู้ว่าใครแก้อะไรอีก

ถ้าคำตอบในใจ คือ ใช่ ดังนั้นบทความนี้เขียนมาเพื่อเพื่อนๆ โดยเฉพาะ Data Team ของเรานั้น อาจจะต้องการ Dataform อยู่แล้วโดยไม่รู้ตัว !

เคยเจอแบบนี้กันไหม 👀

SQL ของเราอยู่แบบกระจัดกระจาย บางทีอยู่ใน Notebook หรือในDrive บ้าง บางทีอยู่ก็ใน BigQuery ที่ใครบางคน Save ไว้แบบไม่มีชื่อ 😅 แล้วก็ไม่มีใครกล้าลบเพราะไม่รู้ว่ามันสำคัญไหม

พอทีมเริ่มใหญ่ขึ้น คนในทีมมากขึ้น หรือ Pipeline เริ่มซับซ้อน คำถามเหล่านี้ก็จะตามมาเรื่อย ๆ

• ไฟล์นี้ต้องรันก่อนหรือหลังอันไหนนะ ?
• ถ้าแก้ Table นี้แล้วจะกระทบอะไรบ้าง ?
• ใครแก้อะไรไปเมื่อกี้ แล้วทำไมข้อมูลมันเพี้ยน ??

ถ้าเคยเจออย่างน้อยหนึ่งข้อ — มาทำความรู้จัก Dataform กันเลยดีกว่า เพราะมันถูกสร้างมาเพื่อแก้ปัญหาพวกนี้โดยเฉพาะเลย

Dataform คือ อะไรกันแน่ ?

พูดแบบตรง ๆ — Dataform คือ

“เครื่องมือจัดการ Source Code ของ SQL Transformation บน BigQuery”

พูดให้เห็นภาพขึ้น — แทนที่จะเขียน SQL แล้วรันตรง ๆ บน BigQuery เราจะเขียน SQL ไว้ใน SQLX File ที่อยู่ใน Dataform แทน แล้วให้ Dataform เป็นคนจัดการสร้าง Table หรือ View บน BigQuery ให้เรา

ตัว Dataform นั้นจะอยู่ในขั้นตอน Transform ของ ELT — ซึ่งต่างจาก ETL ตรงที่ข้อมูลจะถูก Load เข้า BigQuery ก่อนเลย แล้ว Dataform ค่อยเข้ามารัน SQL ที่เราเขียนไว้เพื่อสร้างและ Transform ข้อมูลใน BigQuery ทีหลัง ทุกอย่างเกิดขึ้น ภายใน BigQuery ทั้งหมด ไม่ต้องไปประมวลผลที่อื่นเลย(สะดวกมากๆ)

ทำไมต้องใช้กันนะ ? RUNใน BigQuery ตรง ๆ ไม่ได้หรอ ?

จริงๆทำได้ ค่ะ— แต่* เมื่อ PROJECT ใหญ่ขึ้น ปัญหาเหล่านี้มักจะตามมาเสมอ :

• SQL กระจัดกระจาย — ไม่มีที่เก็บกลาง ไม่รู้ว่า version ล่าสุดอยู่ที่ไหน
• ลำดับการ RUN ไม่ชัดเจน — Table A ต้องสร้างก่อน Table B ถ้าลืมหรือสลับกัน ลำดับจะพัง
• ไม่มี Version Control — ไม่รู้ว่าใครแก้อะไรไปเมื่อไหร่ ย้อนกลับไม่ได้
• Collaborate ยาก — หลายคนแก้ไฟล์เดียวกัน ไม่รู้จะ Merge ยังไง

Dataform สามารถที่จะแก้ทุกปัญหาข้างต้น เพราะเค้าถูกออกแบบมาให้ ทีม Data ทำงานกับ SQL เหมือนที่ทีม Dev ทำงานกับ Code นั่นเอง— มี Git, มี Branch, มี Review ก่อน Deploy

แล้ว Dataform เนี่ยทำงานยังไงกันนะ ?

1. เก็บ SQL เป็น Source Code (SQLX File) 📁

แทนที่จะเขียน SQL แล้ว run ทิ้ง เราจะเขียนไว้ใน SQLX File ซึ่งแต่ละไฟล์มี องค์ ประกอบ 2 ส่วน ได้แก่

[1] Config Block — บอก Dataform ว่าจะสร้างอะไร ที่ไหน และรอใครก่อน

config {
    type: "operations",
    name: "staging_employee",
    schema: "staging_data",
    dependencies: ["raw_employee"],
    hasOutput: true
}

CODE นี้บอกว่า : “ฉันชื่อ staging_employee จะไปสร้าง Table ที่ Dataset staging_data และขอรอให้ raw_employee รันเสร็จก่อนนะ”

[2] Statement Block — SQL ธรรมดาที่เราเขียนกันทุกวันเลย

CREATE TABLE IF NOT EXISTS `staging_data.employee`
(
    employee_id   STRING,
    full_name     STRING,
    department    STRING,
    hire_date     STRING,
    salary        FLOAT64,
    status        STRING
);

CODE นี้บอกว่า : สร้างตาราง employee ใน staging_data ถ้ายังไม่มี — โดยมี 6 columns คือ employee_id, full_name, department, hire_date, salary และ status แต่ยังไม่มีข้อมูลอยู่ในตารางเลย แค่เตรียมโครงสร้างรอไว้ก่อน

แค่นี้ Dataform ก็รู้แล้วว่าต้องสร้าง Table employee ใน Dataset staging_data และต้องรอให้ raw_employee รันเสร็จก่อน

แล้วข้อมูลเข้ามายังไง 📥? — CREATE TABLE IF NOT EXISTS สร้างแค่ โครงสร้างตารางเปล่า ๆ คือบอกเราว่ามี Column อะไร Data Type คืออะไร แต่ยังไม่มีข้อมูลอยู่ในตารางเลย ข้อมูลจะเข้ามาจาก 2 ทางนี้

[1] Raw Zone — ข้อมูลถูก Load เข้ามาจาก Pipeline ภายนอก (เช่น Fivetran, Airbyte หรือ Azure Data Factory ที่ดึงข้อมูลจาก Source แล้ว Load เข้า BigQuery) Dataform ทำหน้าที่แค่เตรียมโครงสร้าง schema/table รอไว้ก่อน — “ยังไม่มีการ transform อะไรทั้งนั้น ”

[2] Staging / Warehouse — เราเขียน INSERT INTO ... SELECT ใน Statement Block เพื่อดึงข้อมูลจาก Table ชั้นก่อนหน้ามาใส่ได้เลย ดังตัวอย่างด้านล่าง

ตัวอย่าง SQLX File สำหรับ Staging — สร้างโครงสร้างแล้ว INSERT ข้อมูลจาก Raw มาต่อในไฟล์เดียวกันเลย

config {
    type: "operations",
    name: "staging_employee",
    schema: "staging_data",
    dependencies: ["raw_employee"],
    hasOutput: true
}

-- ขั้นที่ 1: สร้างโครงสร้างตาราง (ถ้ายังไม่มี)
CREATE TABLE IF NOT EXISTS `staging_data.employee`
(
    employee_id   STRING,
    full_name     STRING,
    department    STRING,
    hire_date     STRING,
    salary        FLOAT64,
    status        STRING
);

-- ขั้นที่ 2: ดึงข้อมูลจาก raw_data มาใส่
INSERT INTO `staging_data.employee`
SELECT
    employee_id,
    full_name,
    department,
    hire_date,
    salary,
    status
FROM `raw_data.employee`
WHERE status IS NOT NULL;

💡 SQLX file เดียวกันเขียน CREATE TABLE แล้วตามด้วย INSERT INTO ได้เลย — Dataform จะรันตามลำดับจากบนลงล่างให้อัตโนมัติเอง

ข้อควรระวัง : ห้ามใช้ *CREATE TABLE แบบไม่มี `IF NOT EXISTS`* เด็ดขาด !! — เพราะมันจะลบข้อมูลใน Table ทิ้งแล้วสร้างใหม่เลย ข้อมูลหายหมด (อันตรายมากฮะ😱)

2. Dependencies — ตรงนี้แหละที่ทำให้ชีวิตดีขึ้นเยอะมาก 🎉

เวลามี Table หลายตัวที่ต้องรันเป็นลำดับ เช่น ต้องสร้าง raw_employee ก่อน แล้ว staging_employee ถึงจะรันได้ — แทนที่จะต้องนั่งจำหรือเขียน script จัดลำดับเอง แค่บอกใน Config Block ว่า

dependencies: ["raw_employee"]

💡 dependencies ใส่อะไร?

ใส่ค่า name ที่เราตั้งไว้ใน Config Block ของ SQLX File ที่ต้องรันก่อน — ไม่ใช่ชื่อไฟล์นะคะ

ตัวอย่างเช่น raw_employee ในที่นี้ก็คือ SQLX File ที่มี name: "raw_employee" อยู่ใน Config Block ซึ่งทำหน้าที่สร้างตาราง employee ใน Raw Zone

Dataform จะรันไฟล์นั้นให้เสร็จก่อน แล้วถึงจะมาทำ staging_employee ต่อได้ — ไม่ต้องมานั่งจำลำดับเองเลย 🎉

🔖 Tips: แนะนำให้ตั้งชื่อไฟล์ *.sqlx กับค่า `name* ให้เหมือนกันไว้เลยนะ จะได้ไม่งง และไม่ต้องมานั่งไล่หาว่าdependencies` ชี้ไปที่ไฟล์ไหน — เชื่อเถอะ อนาคตจะขอบคุณตัวเองมาก 😄

Dataform จะรู้เองเลยว่าต้องรัน raw_employee ก่อน ถึงจะมาทำ staging_employee ได้ — ไม่ต้องจำ ไม่ต้องกลัวรันผิดลำดับอีกต่อไป

ถ้า SQLX File ไหนต้องรอหลายไฟล์ก่อน ก็ใส่ทั้งหมดใน list ได้เลย:

// warehouse_employee ต้องรอให้ทั้ง 2 ไฟล์นี้รันเสร็จก่อน
dependencies: ["staging_employee", "staging_department"]

3. Compiled Graph — เห็นทุกอย่างในภาพเดียว 🗺️

ก่อนที่ SQL จะถูกส่งไปรันบน BigQuery จริง Dataform จะผ่านขั้นตอน Compilation ก่อน โดยจะ:

• ตรวจสอบว่า Dependencies ครบถ้วน ไม่มีการวน loop
• สร้าง Execution Order ที่ถูกต้อง
• แสดง Compiled Graph ให้เห็นภาพรวมของ Data Pipeline ทั้งหมด

ภาพด้านล่างคือ Compiled Graph จริง ๆ จาก Dataform — จะเห็นว่า Node แต่ละตัวแทน 1 SQLX File และเส้นลูกศรแสดงถึง Dependencies ระหว่างกัน

แค่มองกราฟก็รู้ทันทีว่า Data ไหลยังไง และถ้าจะแก้ raw_employee ก็เห็นเลยว่าจะกระทบ staging_employee และ warehouse_employee ตามลำดับ — ทำให้ debug หรือวางแผนแก้ไขง่ายขึ้นเยอะมาก

4. Git Integration — ทีมทำงานร่วมกันได้ไม่พัง 🤝

Dataform เชื่อมกับ Git ได้โดยตรง (GitHub, GitLab, Azure DevOps, Bitbucket) ทำให้ทีมทำงานกับ SQL ได้เหมือนทีม Dev ทำงานกับ Code เลย:

• แต่ละคนมี Workspace ของตัวเอง — พัฒนาแยกกันโดยไม่กระทบกัน
• เมื่อพร้อม Commit & Push ขึ้น Branch ตัวเอง
• Team Lead Review ผ่าน Pull Request แล้ว Merge เข้า Main Branch
• Code จาก Main Branch Deploy ขึ้น Production

ทุก commit มี history ย้อนกลับได้ รู้หมดว่าใครแก้อะไร เมื่อไหร่ — ปัญหา “ใครไปแก้อะไรมา” จะหายไปเลย

โครงสร้างข้อมูล 3 ชั้นที่ใช้จริง

ใน Dataform เราแบ่งข้อมูลออกเป็น 3 ชั้นตามระดับความพร้อม ซึ่งเป็น pattern ที่นิยมใช้กันทั่วไปในวงการ Data Engineering

หรือที่รู้จักกันในชื่อ Medallion Architecture — แต่ละชั้นสอดคล้องกับ BigQuery Dataset และ Subfolder ใน Workspace โดยตรง ไม่ต้อง config เพิ่ม

raw_data

เก็บข้อมูลดิบตรง ๆ จาก Source — Schema เป๊ะตาม Source เลย ไม่แตะอะไรทั้งนั้น

staging_data

นำข้อมูลจาก Raw มา clean, standardize, deduplicate ก่อนส่งต่อให้ Warehouse

warehouse_data

ข้อมูลที่ join, aggregate และ transform เสร็จแล้ว พร้อมเอาไปทำ Dashboard หรือ Report ได้เลย

รูปด้านล่างคือผลจริงบน BigQuery หลัง Dataform รันเสร็จ — เห็น Dataset ทั้ง 3 ตัว (raw_data, staging_data, warehouse_data) ขึ้นมาพร้อมกัน มี Table employee อยู่ในแต่ละตัว และฝั่งขวาแสดง Schema ที่ตรงกับที่เราเขียนไว้ใน SQLX File เป๊ะ ๆ

โครงสร้างนี้สะท้อนให้เห็นว่า Dataform ไม่ได้แค่เก็บ SQL — สามารถช่วยให้ทีมเห็นภาพรวมว่าข้อมูลเดินทางจาก Source ไปสู่ผู้ใช้งานอย่างไร

📊 มาทวนกันอีกรอบฮะ ว่าข้อมูลเข้ามาในแต่ละ Zone ยังไง

• raw_data — Pipeline ภายนอก (ADF ฯลฯ) Load เข้ามา Dataform แค่เตรียมโครงสร้าง TABLE เปล่า ๆ รอ
• staging_data — Dataform รัน INSERT INTO ... SELECT FROM raw_data
• warehouse_data — Dataform รัน INSERT INTO ... SELECT FROM staging_data

สรุปความแตกต่างของการ ใช้ / ไม่ใช้ Dataform

Dataform เปลี่ยน SQL ที่เคยอยู่แบบกระจัดกระจายอยู่ทั่วไป ให้กลายเป็น Source Code ที่จัดการได้ ตรวจสอบได้ และ Deploy ได้อย่างมีระบบ

REFERENCE :

Google Cloud, “Dataform overview,” Google Cloud Documentation. https://cloud.google.com/dataform/docs/overview