SQL ระบุ Training และ Prediction โดย Engine ดูแล Model State และ Execution
THE IMPORTANT DISTINCTION
มี SQL อยู่รอบ Model ไม่ได้แปลว่าเป็น SQL-native ML เสมอไป
ต้องถามว่า Training รันที่ไหน Model Artifact เก็บที่ใด และ Prediction เป็นส่วนหนึ่งของ Query Plan จริงหรือเรียกบริการภายนอก ขอบเขตทางสถาปัตยกรรมสำคัญกว่าหน้าตา Syntax
SQL เรียก Extension หรือ Function แต่การคำนวณอาจรันใน Runtime อื่น
SQL ดูแล Feature และ Snapshot ขณะที่ Python, Spark หรือ Framework อื่น Train
REFERENCE ARCHITECTURE
SQL หนึ่งคำสั่งอาจซ่อนความรับผิดชอบห้าส่วน
ต้องตามรอยได้ครบทั้ง Snapshot Time, Feature Contract, Training Configuration, Model Version และ Scoring Output
OPEN-SOURCE DEEP DIVES
เรียนผ่านระบบที่เปิดดูและทดลองรันเองได้
ทุกตัวอย่างใช้ customer_features ชุดเดียวกันเพื่อเปรียบเทียบ Syntax และ Execution Boundary งานจริงยังต้องมี Temporal Split, Access Control, Monitoring และ Rollback
ไลบรารี In-database Analytics ที่มีวุฒิภาวะ Training เขียนผลเป็น Model Table และ Prediction ใช้ค่าสัมประสิทธิ์ผ่าน SQL Function จึงเห็นชัดว่า Model สามารถเป็น Relational State ได้
SELECT madlib.logregr_train(
'customer_features', 'churn_model_madlib',
'churned',
'ARRAY[1, recency_days, orders_90d, spend_90d]'
);
SELECT f.customer_id,
madlib.logregr_predict_prob(
m.coef,
ARRAY[1, f.recency_days, f.orders_90d, f.spend_90d]
) AS churn_probability
FROM customer_features f, churn_model_madlib m;ลำดับของ Feature Array ต้องตรงกันระหว่าง Train และ Score นี่คือ Data Contract ที่มองข้ามไม่ได้
แถวข้อมูลเคลื่อนที่ไปไหน Process ใดคำนวณ และ Object ใดเป็นตัวแทน Model
PostgreSQL Extension แบบ End-to-end ที่เปิด Training, Deployment และ Prediction เป็น pgml functions พร้อม Project และ Snapshot สำหรับจัดระเบียบ Model Iteration
SELECT * FROM pgml.train(
project_name => 'customer_churn',
task => 'classification',
relation_name => 'customer_features',
y_column_name => 'churned',
algorithm => 'xgboost',
test_size => 0.20
);
SELECT customer_id,
pgml.predict(
'customer_churn',
ARRAY[recency_days, orders_90d, spend_90d]
) AS prediction
FROM customer_features;Project ทำให้เปรียบเทียบหลาย Algorithm บน Snapshot เดียวกันและติดตาม Deployment ได้ แต่ยังต้องออกแบบ Temporal Split เองให้ถูกโจทย์
แถวข้อมูลเคลื่อนที่ไปไหน Process ใดคำนวณ และ Object ใดเป็นตัวแทน Model
ชั้น SQL ที่เชื่อม Data Source กับ AI/ML Engine ทำให้ Model เป็น Object ที่ Query ได้ เหมาะกับการสาธิต Federated Prediction และการตาม Execution Boundary
CREATE MODEL churn_model
FROM analytics_db
(SELECT recency_days, orders_90d,
spend_90d, churned
FROM customer_features)
PREDICT churned;
SELECT d.customer_id,
m.churned AS predicted_churn,
m.churned_confidence
FROM analytics_db.customer_features AS d
JOIN churn_model AS m;ผิวภายนอกเป็น SQL เดียวกัน แต่การคำนวณอาจเกิดใน Handler หรือ Service อื่น ต้องตรวจว่า Data เคลื่อนที่ไปไหน
แถวข้อมูลเคลื่อนที่ไปไหน Process ใดคำนวณ และ Object ใดเป็นตัวแทน Model
ฝึก Linear/Logistic Model แบบ Aggregate-function State จัดเก็บ State และใช้ใน Analytical Query ได้ ทำให้ Training กลายเป็น Aggregation และ Model กลายเป็น Typed State
CREATE TABLE churn_models
(
name String,
model AggregateFunction(
stochasticLogisticRegression(0.01,0.0,10,'Adam'),
UInt8, Float64, Float64, Float64)
) ENGINE=AggregatingMergeTree ORDER BY name;
INSERT INTO churn_models
SELECT 'churn_v1',
stochasticLogisticRegressionState(0.01,0.0,10,'Adam')(
churned, recency_days, orders_90d, spend_90d)
FROM customer_features;
WITH (SELECT model FROM churn_models WHERE name='churn_v1') AS m
SELECT customer_id,
evalMLMethod(m, recency_days, orders_90d, spend_90d) AS score
FROM customer_features;เหมาะกับข้อมูลวิเคราะห์ขนาดใหญ่ แต่ Built-in Training มีขอบเขตแคบ งานซับซ้อนยังใช้ Framework ภายนอก
แถวข้อมูลเคลื่อนที่ไปไหน Process ใดคำนวณ และ Object ใดเป็นตัวแทน Model
ไม่ใช่ SQL-native Trainer เต็มรูปแบบ DuckDB เหมาะกับ Local Feature Computation และ Reproducible Dataset ส่วน dbt เพิ่ม Test, Documentation และ Lineage
CREATE OR REPLACE TABLE train_snapshot AS
SELECT customer_id,
date_diff('day',max(order_at),DATE '2026-08-31') AS recency_days,
count(*) FILTER(WHERE order_at>=DATE '2026-06-01') AS orders_90d,
sum(amount) FILTER(WHERE order_at>=DATE '2026-06-01') AS spend_90d,
max(churned)::INTEGER AS churned
FROM read_parquet('orders/*.parquet')
GROUP BY customer_id;
COPY train_snapshot TO 'train_snapshot.parquet'
(FORMAT PARQUET, COMPRESSION ZSTD);เรียกให้ถูกว่า SQL-first Feature Pipeline ไม่ใช่ In-database ML เพราะ Python หรือ Framework ภายนอกยังเป็นผู้ Train
แถวข้อมูลเคลื่อนที่ไปไหน Process ใดคำนวณ และ Object ใดเป็นตัวแทน Model
SIDE-BY-SIDE
เลือกจากขอบเขตการคำนวณ ไม่ใช่ Syntax ที่ดูทันสมัย
ฟรีอาจหมายถึง Open-source Code, Local Runtime, Cloud Free Tier แบบจำกัด หรือ Proprietary Software ที่ Bundle มากับ Database หน้านี้แยกความหมายเหล่านั้น
| System | ประเภท | Train SQL | Predict SQL | สิ่งที่ควรเรียนรู้ |
|---|---|---|---|---|
| Apache MADlib | In-database library | Yes | Yes | Model table · feature array |
| PostgresML | Postgres extension | Yes | Yes | Project · snapshot · deployment |
| MindsDB | SQL AI layer | Yes | Yes | Queryable model · federation |
| ClickHouse | Columnar database | เฉพาะบาง Model | Yes | Aggregate state as model |
| DuckDB + dbt | SQL-first pipeline | No | UDF / integration | Snapshot · test · lineage |
COMMERCIAL AWARENESS
รู้จักคำศัพท์ แต่เรียนแก่นที่ย้ายข้ามระบบได้
ระบบ Proprietary หรือ Paid Cloud เหล่านี้มีไว้เป็นแผนที่สำหรับอ่าน Job Description และ Architecture Document ไม่ใช่แกน Hands-on Lab
BigQuery ML
CREATE MODEL, ML.EVALUATE และ ML.PREDICT ใน Google BigQuery
Official overview ↗Snowflake ML
ML functions และ Model workflow ใกล้ข้อมูลใน Warehouse
Official overview ↗Amazon Redshift ML
CREATE MODEL เชื่อมข้อมูล Redshift กับ Managed Training
Official overview ↗Oracle ML for SQL
In-database algorithms, model objects และ SQL prediction functions
Official overview ↗SQL Server ML Services
T-SQL เรียก Python/R runtime จึงต่างจาก Pure SQL-native Training
Official overview ↗Databricks SQL AI
SQL AI functions บน Lakehouse; Platform เป็นบริการเชิงพาณิชย์
Official overview ↗TEACHING LAB SEQUENCE
ทำโจทย์เดียวกันสี่แบบ แล้วอธิบาย Boundary ให้ได้
เป้าหมายไม่ใช่จำ Syntax แต่ต้องอธิบายได้ว่าข้อมูลเคลื่อนที่ตรงไหน Version ถูกควบคุมอย่างไร และอะไรทำให้ Evaluation ใช้ไม่ได้
กำหนดเวลาที่ทำนาย
ระบุ Observation Cutoff, Horizon, Entity Key และเวลาที่ Label ปรากฏ ก่อนสร้าง Feature
สร้าง Feature Contract กลาง
กำหนดชื่อ Type หน่วย Null Policy ลำดับ Feature และ Versioned Snapshot
Train ใน MADlib
ตรวจ Model Table, Coefficient, Convergence Diagnostic และ Scoring Function
เปรียบเทียบ Project Lifecycle
ใช้ PostgresML เปรียบเทียบ Algorithm บน Snapshot เดิมและดู Deployment State
มอง Model เป็น Relation และ State
เปรียบเทียบ MindsDB Join กับ ClickHouse Aggregate State และตาม Physical Execution
สร้าง SQL-first Boundary
สร้าง DuckDB/dbt Snapshot ให้ Python แล้วระบุว่า Declarative Control สิ้นสุดตรงไหน
Audit การประเมิน
ตรวจ Leakage, Class Imbalance, Calibration, Subgroup Error และ Reproducibility
วางแผน Rollback และ Retraining
เก็บ Query Hash, Data Snapshot, Parameter, Metric, Owner และ Deployment Decision
SQL สั้นไม่ได้แปลว่าหนี้ทางเทคนิคจะสั้นตาม
- อย่าใช้ Random Split กับผลลัพธ์ที่ขึ้นกับเวลาโดยไม่มีเหตุผล
- เก็บ Feature Schema, Cutoff, Query Hash, Parameter และ Model Version
- วัด Data Movement เพราะ SQL อาจยังเรียก Runtime ภายนอก
- ประเมิน Business Cost เพราะ False Positive และ False Negative มักมีต้นทุนไม่เท่ากัน
CONTINUE LEARNING
จากเครื่องมือหนึ่งตัว สู่มุมมองระบบที่ย้ายข้ามค่ายได้
ลงมือรัน MADlib Lab แล้วกลับมาเปรียบเทียบ Model State, Execution Placement และ Governance ข้ามระบบ