OPERATIONAL DATA → MACHINE LEARNING

OLTP บันทึกสิ่งที่เกิดขึ้น ส่วน Feature Engineering ต้องสร้างซ้ำว่า ณ เวลานั้นเรารู้อะไรได้บ้าง

เส้นทางจาก transaction ตอนชำระเงินไปสู่ Feature ของโมเดล ไม่ใช่เพียงนำ SELECT ไปวางข้าง production แต่เป็นระบบข้อมูลที่เข้าใจเวลา ต้องจับการเปลี่ยนแปลง เก็บประวัติศาสตร์ นิยาม entity และ event คำนวณซ้ำได้ และส่งมอบความหมายเดียวกันให้ทั้ง training และ prediction

อ่านแผนภาพระบบ →เปิด SQL Lab ↓

OLTP

เข้าใจระบบต้นทางและข้อจำกัดของงาน transaction

History

เก็บการเปลี่ยนแปลงแทนการเห็นเพียงสถานะล่าสุด

Time

ไม่ให้ข้อมูลอนาคตหลุดเข้า training row

Feature

เผยแพร่ input ของโมเดลที่ทดสอบและใช้ซ้ำได้

01 · THE COMPLETE PATH

อย่าสับสนระหว่างแหล่งความจริง กับระบบที่ใช้เรียนรู้จากความจริงนั้น

OLTP ปกป้อง transaction ของธุรกิจ ส่วนเส้นทาง Analytics และ ML เก็บประวัติศาสตร์และจัดรูปใหม่เพื่อการสังเกต แต่ละช่วงมีหน้าที่ต่างกัน

ภาพที่ 1 OLTP ยังคงรับผิดชอบ transaction ที่เชื่อถือได้ ส่วนการเก็บประวัติศาสตร์และ Feature Engineering สร้างเส้นทางแยกที่คำนวณซ้ำได้สำหรับ Machine Learning

02 · TWO DIFFERENT WORKLOADS

OLTP กับการคำนวณ Feature ถูกออกแบบให้ตอบคนละคำถาม

ฐานข้อมูลอาจรัน analytical query ได้ในทางเทคนิค แต่ไม่ได้แปลว่า production คือสถานที่เหมาะสำหรับ full-history join และ rolling window ที่ทำซ้ำ

OLTP

Transaction นี้จบอย่างถูกต้องตอนนี้ได้หรือไม่

อ่านและเขียนสั้น ๆ
สถานะปัจจุบันของงาน
Concurrency และ constraints
Latency ต่ำต่อ transaction

≠

FEATURE COMPUTATION

ก่อนแต่ละการตัดสินใจ มองเห็นรูปแบบอะไรได้บ้าง

Scan และ join ขนาดใหญ่
สถานะย้อนหลังและ window
Snapshot ที่สร้างซ้ำได้
Aggregation แบบ batch หรือ stream

ทำไมไม่คำนวณทุกอย่างบน OLTP

Query สำหรับ Feature ที่หนักจะแย่ง CPU, memory, I/O, lock และ connection กับ transaction ของผู้ใช้ อีกทั้งอาจเห็นเพียงสถานะล่าสุด ทำให้สร้าง training data ในอดีตซ้ำไม่ได้ Read replica ช่วยลด contention แต่ไม่ได้แก้เรื่อง history, semantics หรือ point-in-time correctness โดยอัตโนมัติ

03 · STATE IS NOT HISTORY

การ UPDATE อาจลบหลักฐานที่โมเดลต้องใช้

ตารางระบบงานมักเก็บที่อยู่ สถานะ หรือยอดคงเหลือล่าสุด แต่การ train โมเดลอาจต้องรู้ว่าค่าเหล่านั้นเป็นอย่างไร ณ เวลาทำนายในอดีต

09:00order createdstatus = pending

09:07payment acceptedstatus = paid

09:10PREDICTIONwhat was known here?

09:18fraud reviewrisk_flag = high

09:30order cancelledstatus = cancelled

ภาพที่ 2 Training row ณ 09:10 ใช้ข้อมูลการจ่ายเงินเมื่อ 09:07 ได้ แต่ห้ามใช้ fraud flag เมื่อ 09:18 หรือการยกเลิกเมื่อ 09:30 หากมาอ่านแถวปัจจุบันจาก OLTP ภายหลัง จะเห็นข้อเท็จจริงจากอนาคตทั้งสองรายการ

04 · THREE CLOCKS

คำว่า “เมื่อไร” มีมากกว่าหนึ่งความหมายใน Data Pipeline

ข้อมูลที่มาถึงล่าช้าทำให้ event time กับ ingestion timeไม่ตรงกัน ความถูกต้องของ Feature ขึ้นกับว่านาฬิกาใดคือสิ่งที่โมเดลมองเห็นได้จริง

①

Event time

เวลาที่เหตุการณ์ทางธุรกิจเกิดขึ้น เช่น ซื้อเมื่อ 09:07

②

Ingestion time

เวลาที่ Data Platform ได้รับข้อมูล เช่น 09:14 หลัง network delay

③

Prediction time

เวลาที่โมเดลตัดสินใจ เช่น 09:10

กรณีที่ต้องคิดให้ชัด

เหตุการณ์เกิด 09:07 แต่มาถึงระบบ 09:14 โมเดลที่ทำนายเวลา 09:10 ควรเห็นหรือไม่ สำหรับ online system โดยทั่วไปคือไม่ควร เพราะ Platform ยังไม่ได้รับข้อมูล Historical Feature จึงอาจต้องเก็บทั้ง event_time และ available_at/ingestion_time

05 · CAPTURE CHANGE DELIBERATELY

CDC เคลื่อนย้ายการเปลี่ยนแปลง ส่วน Data Model ทำให้การเปลี่ยนแปลงนั้นมีความหมาย

Change Data Capture อ่าน database log แล้วส่ง insert, update และ delete โดยกระทบ source ต่ำ แต่ CDC ไม่ได้นิยาม entity, deduplicate business event หรือเลือก Feature Window ให้เอง

OLTP LOGUPDATE orders SET status='paid'

→

CHANGE EVENT

before: pending
after: paid
source_ts: 09:07

→

HISTORICAL MODEL

valid_from · valid_to
event_time · loaded_at

Log-based CDC

จับการเปลี่ยนแปลงจาก transaction log โดยเพิ่ม query load ต่ำ แต่ต้องออกแบบ connector, ordering และ recovery

Incremental extract

Query แถวใหม่กว่าค่า watermark ทำง่ายกว่า แต่ต้องระวังคุณภาพ timestamp, update, delete และขอบเขตเวลา

Snapshot

คัดลอกสถานะเป็นช่วง เหมาะกับ reconciliation แต่มีต้นทุนสูงและไม่เห็นทุก transition ระหว่าง snapshot

06 · SQL LAB: POINT-IN-TIME FEATURES

Join แต่ละการทำนายกับข้อเท็จจริงที่มีอยู่ก่อนเวลานั้นเท่านั้น

SQL แบบย่อนี้คำนวณกิจกรรมลูกค้า 30 วันก่อนแต่ละการทำนาย ระบบจริงต้องจัดการข้อมูลมาช้า time zone, event ซ้ำ และขนาดของ query

-- Grain: one row per customer per prediction_time
SELECT
  p.customer_id,
  p.prediction_time,
  COUNT(o.order_id) AS orders_30d,
  COALESCE(SUM(o.amount), 0) AS spend_30d,
  MAX(o.ordered_at) AS last_order_time
FROM ml.prediction_events AS p
LEFT JOIN history.orders AS o
  ON o.customer_id = p.customer_id
 AND o.ordered_at >= p.prediction_time - INTERVAL '30 days'
 AND o.ordered_at <  p.prediction_time
 AND o.available_at <= p.prediction_time
 AND o.status = 'completed'
GROUP BY p.customer_id, p.prediction_time;

t − 30 daysประวัติศาสตร์ที่ใช้ได้prediction time (t)

อนาคต: ห้ามใช้

เงื่อนไขป้องกันสองชั้นordered_at < prediction_time กันเหตุการณ์ธุรกิจในอนาคต available_at <= prediction_time กันข้อมูลที่มาช้าไม่ให้ถูกมองว่าระบบรู้มาก่อนแล้ว

07 · FAILURE MODES

Pipeline อาจรันสำเร็จ แต่สร้าง Feature ที่ไม่ซื่อตรงต่อเวลาได้

ความสำเร็จทางเทคนิคคือ query ทำงานจบ ส่วนความถูกต้องของข้อมูลคือผลลัพธ์แทนสิ่งที่โมเดลควรรู้ได้จริง

Production contention

Feature scan ทำให้ transaction ของลูกค้าช้า หรือใช้ replica และ connection จนเต็ม

Current-state bias

นำ segment ล่าสุดของลูกค้าไปใส่ training row ในอดีต

Target leakage

การยกเลิกหรือ fraud review ที่เกิดหลังทำนายหลุดเข้า Feature

Duplicate change events

Retry หรือ replay ทำให้นับ business event เดียวหลายครั้ง

Entity mismatch

Join customer, account และ household ID ราวกับเป็น entity เดียวกัน

Training-serving skew

Logic ใน notebook ต่างจาก implementation ของ online service

08 · ENGINEERING DECISIONS

แยก workload รักษาเวลา และทำให้รอยต่อทดสอบได้

ไม่มีสถาปัตยกรรมบังคับเพียงแบบเดียว แต่หลักการยังคงเดิม คือปกป้องระบบงาน เก็บประวัติศาสตร์เพียงพอ ระบุความหมาย Feature และสร้างค่าซ้ำได้ ณ เวลาที่ต้องการ

คำถามหลักฐานในการออกแบบ

อ่าน OLTP โดยตรงได้หรือไม่เฉพาะกรณีควบคุมได้ ผลกระทบต่ำ วัด load แล้ว และสร้างซ้ำได้ งานคำนวณซ้ำควรใช้ replica หรือ analytical copy

CDC, extract หรือ snapshotเลือกจาก latency, การจับ delete/update, ความสามารถ source, recovery, volume และทักษะทีม ไม่ใช่ตามกระแส

Warehouse model หรือ Feature StoreWarehouse model ที่ทดสอบแล้วอาจเพียงพอสำหรับ batch ML เพิ่ม Feature Store เมื่อ reuse, historical retrieval, online parity และ governance คุ้มกับต้นทุน platform

เรียนต่อจากหน้านี้

จาก Feature Engineering สู่ Feature Store ที่กำกับดูแลได้

เปิดบทเรียน Feature Store →

THE CENTRAL IDEA

ฐานข้อมูลระบบงานบอกว่าอะไรจริงในตอนนี้ ส่วน Feature Engineering ที่ดีต้องรักษาว่าในตอนนั้นเรารู้อะไรได้บ้าง

ปกป้อง workload ของ OLTP
เก็บการเปลี่ยนแปลง
รักษา event time
นิยาม entity ให้ชัด
ทดสอบ point-in-time join
กระทบยอด source กับ Feature