← warin.me · Data Science and EngineeringEnglish

ML DATA ENGINEERING · FEATURE PLATFORM

Feature Engineering มีต้นทุนสูง และการสร้างความจริงเดิมซ้ำไปซ้ำมายิ่งแพงกว่า

Feature ที่มีประโยชน์ไม่ใช่เพียงสูตรใน notebook แต่เป็น data product ที่เข้าใจเวลา ผ่านการทดสอบ สร้างซ้ำได้ และต้องให้ความหมายสอดคล้องกันทั้งตอน train และตอนทำนาย Feature Store คือระบบที่ทำให้คำสัญญานั้นดูแลได้

01

ออกแบบ

แปลงเจตนาของโมเดลเป็นนิยาม feature ที่ชัดเจน

02

สร้างซ้ำ

สร้างค่าประวัติศาสตร์ซ้ำโดยไม่รั่วข้อมูลจากอนาคต

03

ให้บริการ

ส่งมอบความหมายเดียวกันให้ batch training และ online inference

04

กำกับดูแล

ติดตาม owner, lineage, freshness, version และคุณภาพ

01 · THE ECONOMICS

สูตรอาจเขียนได้เร็ว แต่วงจรชีวิตของ Feature ไม่ได้ราคาถูก

อัตราส่วนหนึ่งค่าอาจใช้ SQL เพียงบรรทัดเดียว แต่การทำให้ถูกต้องสำหรับข้อมูล train ย้อนหลังห้าปี ตอบได้ในไม่กี่ millisecond ถูก monitor ทุกวัน และมีทีมอื่นเข้าใจตรงกัน คืออีกปัญหาหนึ่งทางวิศวกรรม

DISCOVERY

ค้นหาสัญญาณ

สัมภาษณ์ผู้รู้ วิเคราะห์ข้อมูล ทดลอง และสร้าง feature จำนวนมากที่ไม่เคยไปถึง production

COMPUTE

คำนวณประวัติศาสตร์ใหม่

join ขนาดใหญ่ rolling window, backfill และ training dataset ที่สร้างซ้ำ ใช้ทั้ง compute และเวลาวิศวกร

CORRECTNESS

ความจริงที่สัมพันธ์กับเวลา

Point-in-time join ต้องใช้เฉพาะข้อมูลที่มีอยู่ ณ เวลาที่การทำนายนั้นควรเกิดขึ้น

OPERATIONS

ดูแลให้ยังทำงาน

หลังเปิดใช้ยังมี freshness, pipeline ล้มเหลว schema เปลี่ยน skew, drift, latency, incident และ ownership

DUPLICATION

นิยามซ้ำหลายชุด

หลายทีมสร้าง “customer activity” ใหม่ด้วย window, filter และนโยบาย missing value ที่ต่างกัน

RISK

ความเสียหายที่เงียบ

Leakage หรือ training-serving skew อาจทำให้คะแนน offline ดูดี แต่การทำนายจริงแย่ลง

ต้นทุนรวมของ FEATUREนิยาม + ประวัติศาสตร์ + compute + serving + คุณภาพ + การประสานงาน + การเปลี่ยนแปลง

02 · FROM COLUMN TO DATA PRODUCT

Feature ต้องมี contract ไม่ใช่เพียงชื่อคอลัมน์

“orders_30d” ยังไม่สมบูรณ์ หากไม่รู้ entity, event time, กฎการนับ, นโยบาย null, freshness, owner และ version

ENTITYcustomer_id
FEATUREcompleted_orders_30d
EVENT TIMEas_of_timestamp
WINDOW[t − 30 days, t)
DEFAULT0, not NULL
OWNERCustomer ML Team
สัญลักษณ์เล็กที่มีผลใหญ่

ช่วงเวลาสิ้นสุดที่ t แต่ไม่รวม t เพื่อไม่ให้เหตุการณ์ ณ เวลาทำนายหลุดเข้า training row ก่อนเวลาที่ระบบควรรู้เหตุการณ์นั้น

03 · WHAT A FEATURE STORE DOES

ประสานนิยาม การคำนวณ และการส่งมอบ Feature

Feature Store ไม่ใช่เพียงฐานข้อมูลที่ตั้งชื่อใหม่ให้ทันสมัย แต่เป็นระบบข้อมูลสำหรับ ML ที่เชื่อม registry, historical retrieval และในกรณี latency ต่ำ ก็รวม online serving

SOURCESorders · events · profiles
TRANSFORMbatch / stream pipelines
OFFLINE STOREhistorical training features
ONLINE STORElatest low-latency values
CONSUMERStraining · batch scoring · API
REGISTRY / CONTROL PLANEdefinition · schema · owner · lineage · version

04 · OFFLINE AND ONLINE ARE DIFFERENT JOBS

นิยามเดียวกันอาจต้องมีเส้นทางกายภาพสองแบบ

Training ต้องการ dataset ประวัติศาสตร์ขนาดใหญ่ที่ถูกต้อง ส่วน real-time inference อาจต้องการค่าล่าสุดในระดับ millisecond Store ประสานความหมาย แต่ไม่ได้ลบ trade-off ทางกายภาพ

Offline Store

เหมาะกับ scan, history, point-in-time retrieval, backfill และการสร้าง training set มักอยู่บน warehouse หรือ lakehouse

Online Store

เหมาะกับ keyed lookup และ latency ต่ำที่คาดการณ์ได้ โดยทั่วไปเก็บค่าล่าสุด ไม่ได้เก็บประวัติศาสตร์ทั้งหมด

Feature Registry

อธิบายตัวตนและเจ้าของ Feature ช่วยให้ค้นพบและใช้ซ้ำ แต่ไม่สามารถทำให้นิยามที่ไม่ดีมีความหมายขึ้นมาเอง

05 · LAB: DEFINE HISTORICAL FEATURES

สร้าง Feature ณ เวลาของแต่ละการทำนาย

ตัวอย่างแบบ PostgreSQL-compatible นี้ใช้สอนหลักการ ระบบ production ยังต้องออกแบบ storage, incremental computation และ orchestration ที่ผ่านการทดสอบ

CREATE TABLE ml.training_events (
  customer_id INTEGER NOT NULL,
  prediction_time TIMESTAMP NOT NULL,
  label INTEGER
);

-- One row represents one customer at one prediction time.
CREATE VIEW ml.v_customer_features_training AS
SELECT
  t.customer_id,
  t.prediction_time,
  t.label,
  COUNT(o.order_id) FILTER (
    WHERE o.status = 'completed'
  ) AS completed_orders_30d,
  COALESCE(SUM(o.amount) FILTER (
    WHERE o.status = 'completed'
  ), 0) AS completed_value_30d,
  MAX(o.ordered_at) AS latest_known_order_time
FROM ml.training_events AS t
LEFT JOIN raw.orders AS o
  ON o.customer_id = t.customer_id
 AND o.ordered_at >= t.prediction_time - INTERVAL '30 days'
 AND o.ordered_at <  t.prediction_time
GROUP BY t.customer_id, t.prediction_time, t.label;
กฎ Point-in-timeทุก record ที่ join ต้องมี event time ก่อน prediction_time และอาจต้องพิจารณา ingestion time ด้วยเมื่อข้อมูลมาถึงล่าช้า

06 · LAB: MATERIALIZE THE LATEST VALUES

เตรียมตารางรูปแบบ online โดยไม่สรุปเกินจริงว่าเป็น online platform

Primary key แทน feature vector ล่าสุดหนึ่งชุดต่อ entity ส่วน online store จริงยังต้องมี atomic write, freshness guarantee, availability, latency SLO และ recovery

CREATE TABLE ml.customer_features_online (
  customer_id INTEGER PRIMARY KEY,
  completed_orders_30d INTEGER NOT NULL,
  completed_value_30d DECIMAL(14,2) NOT NULL,
  feature_timestamp TIMESTAMP NOT NULL,
  feature_version VARCHAR(20) NOT NULL
);

INSERT INTO ml.customer_features_online
SELECT
  c.customer_id,
  COUNT(o.order_id) FILTER (WHERE o.status='completed'),
  COALESCE(SUM(o.amount) FILTER (WHERE o.status='completed'), 0),
  CURRENT_TIMESTAMP,
  'customer_activity_v1'
FROM raw.customers c
LEFT JOIN raw.orders o
  ON o.customer_id=c.customer_id
 AND o.ordered_at >= CURRENT_TIMESTAMP - INTERVAL '30 days'
GROUP BY c.customer_id
ON CONFLICT (customer_id) DO UPDATE SET
  completed_orders_30d=EXCLUDED.completed_orders_30d,
  completed_value_30d=EXCLUDED.completed_value_30d,
  feature_timestamp=EXCLUDED.feature_timestamp,
  feature_version=EXCLUDED.feature_version;

07 · WHEN A FEATURE STORE EARNS ITS COST

อย่าสร้าง platform ก่อนมีปัญหาการประสานงานที่มากพอ

Feature Store มีต้นทุนของ platform เอง จึงคุ้มเมื่อ reuse, time correctness, serving consistency และ governance ช่วยประหยัดมากกว่าค่าใช้จ่ายในการดูแลระบบ

สัญญาณว่าควรพิจารณา
  • หลายโมเดลใช้ entity และ feature ร่วมกัน
  • มีปัญหา historical reconstruction และ leakage ซ้ำ ๆ
  • Online prediction ต้องการ feature สดและ latency ต่ำ
  • หลายทีมนิยามไม่ตรงกันหรือสร้าง pipeline ซ้ำ
  • ต้องการ ownership, lineage และ compliance ใน control plane ร่วม
อาจยังไม่จำเป็น
  • มีโมเดลเดียว ทีมเดียว และ batch dataset ขนาดเล็ก
  • Feature ใช้ครั้งเดียวและเปลี่ยนเร็วในช่วงสำรวจ
  • ตาราง warehouse หรือ dbt model ที่ทดสอบแล้วตอบโจทย์อยู่
  • ยังไม่มีเจ้าของที่จะดูแล platform เพิ่ม
  • คอขวดจริงคือคุณภาพ label ไม่ใช่การส่งมอบ feature

08 · OPERATING CHECKLIST

การใช้ซ้ำปลอดภัยเมื่อความหมายยังมองเห็นได้

Feature platform ควรลดงานที่ซ่อนอยู่ ไม่ใช่ซ่อนกระบวนการจนไม่มีใครตรวจสอบสมมติฐานได้

01

Point-in-time correctness

ทดสอบว่า historical row ไม่อ่านเหตุการณ์ในอนาคต

02

Training-serving parity

เปรียบเทียบค่า offline และ online ของ entity ตัวอย่าง

03

Freshness & latency

วัดอายุ feature และ retrieval latency เทียบ SLO ที่ระบุชัด

04

Quality & drift

ติดตาม null rate, range, distribution shift และ entity coverage

05

Version & lineage

สืบย้อน code, source, window, owner และโมเดลที่ใช้แต่ละ version

06

Cost & retirement

วัด compute และ storage แล้วเลิกใช้ feature ที่ไม่มีผู้ใช้อย่างปลอดภัย

CHALLENGES

ออกแบบระบบ แล้วอธิบาย trade-off ให้ได้

01

หาจุดที่เกิด leakage ใน historical join ซึ่งใช้ CURRENT_TIMESTAMP แทน prediction_time

02

นิยาม “customer spend in 7 days” ให้ครบ entity, ขอบเขต window, event time, default และ owner

03

ออกแบบ query ตรวจ offline-to-online parity และกำหนด mismatch threshold ที่ยอมรับได้

04

ออกแบบ backfill เมื่อกฎ cancelled order เปลี่ยน พร้อมระบุโมเดลและ dataset ที่ได้รับผล

05

ประมาณต้นทุนรายเดือนของ 200 features สำหรับ 20 ล้าน entities โดยเขียนสมมติฐานทุกข้อ

06

โต้แย้งการใช้ Feature Store ในโครงการ batch ขนาดเล็ก แล้วระบุเงื่อนไขที่จะทำให้เปลี่ยนการตัดสินใจ

THE CENTRAL IDEA

Feature Store ไม่ได้ทำให้ Feature Engineering ราคาถูก แต่ทำให้ต้นทุนมองเห็น ใช้ซ้ำ และกำกับดูแลได้