SQL原生机器学习：数据库内联推理与特征生命周期管理

1. 这不是“用SQL写个SELECT就叫机器学习”的玩笑话

“Machine learning with SQL”——看到这个标题，我第一反应是皱眉。十年前在数据平台组做ETL优化时，常有业务方拿着Python写的逻辑跑来问：“能不能直接在Hive里跑个随机森林？”当时我们笑着摇头，顺手把特征工程脚本拆成十几个INSERT OVERWRITE语句，再用调度系统串起来。但今天，这句话已经不是调侃，而是一条正在被大量中型数据团队踩实的技术路径。它不替代Python生态，也不挑战TensorFlow的边界，而是精准卡在“数据工程师刚够得着、分析师跳一跳能上手、算法工程师懒得动但愿意验收”的黄金缝里。核心关键词就是：SQL原生计算能力、特征生命周期管理、模型服务轻量化、数据库内联推理。它解决的不是“如何从零训练大模型”，而是“如何让一个日活百万的APP，把用户点击率预测延迟从200ms压到18ms，且不用新增K8s集群、不引入新语言栈、不重建数据血缘”。适合三类人：正在用PostgreSQL/ClickHouse/StarRocks做实时看板的数据工程师；需要快速验证AB实验效果、但不会写PyTorch的业务分析师；以及被“上线一个模型要走6个审批环节+3次数据脱敏+2周资源排期”折磨到失眠的算法TL。这不是技术炫技，是把机器学习从实验室搬进产线车间的务实方案——就像当年Excel宏函数取代了第一批VBA程序员，SQL ML的本质，是让数据本身成为可执行的智能体。

2. 为什么非得在SQL里搞机器学习？四个现实痛点倒逼出的架构选择

2.1 数据不动，模型才稳：避免特征漂移的物理防线

去年帮一家电商做推荐重排优化，算法团队用Spark MLlib训练出AUC 0.87的GBDT模型，特征全部来自离线数仓的宽表。上线后第三天，运营同学临时加了个“大促会场曝光次数”字段到宽表，字段类型从BIGINT改成DECIMAL(18,2)。结果模型服务直接报错：ValueError: Input contains NaN, infinity or a value too large for dtype('float32')。排查发现，新字段存在大量NULL值，而训练时用的是fillna(0)，但线上服务没同步这个逻辑。更糟的是，这个字段在特征重要性里排第4，它的异常直接导致TOP10商品排序全乱。如果所有特征生成、缺失值填充、归一化都在SQL层完成，比如用PostgreSQL的COALESCE(click_cnt, 0)和ROUND((click_cnt - avg_click)/std_click, 4)，那么特征定义、计算逻辑、数据类型约束全部固化在DDL里。当宽表结构变更时，数据库会强制校验所有依赖视图的语法合法性，而不是等到模型服务启动时才崩溃。这相当于给特征工程装了物理保险丝——数据流没改，模型就不会飘；数据流一改，立刻编译失败，逼你重新审视特征逻辑。我试过把37个特征的标准化公式全写进物化视图，上线后连续9个月没出现过一次特征不一致告警。

2.2 延迟压到毫秒级：绕过网络序列化的硬核收益

某金融风控场景要求“用户提交贷款申请后50ms内返回欺诈概率”。他们原先架构是：应用层调用Flink实时计算引擎 → Flink读Kafka → 计算12个时序特征 → 写入Redis → 应用层再调模型服务API → 模型服务从Redis取特征 → 执行XGBoost预测 → 返回结果。链路总耗时均值42ms，P99却飙到118ms。瓶颈在哪？三次跨进程序列化：Flink→Redis（JSON序列化）、应用→模型服务（gRPC protobuf）、模型服务→Redis（反序列化）。后来我们把整个流程压进PostgreSQL：用pg_cron每分钟刷新一次滚动窗口特征表，用plpythonu扩展加载训练好的XGBoost模型，最后用一条SQL实现端到端推理：

SELECT user_id, xgb_predict( ARRAY[ COALESCE(last_1h_login_cnt, 0), LOG(1 + last_3d_trans_amt), CASE WHEN last_ip_in_blacklist THEN 1 ELSE 0 END, ... ], 'fraud_xgb_v202310' )::NUMERIC(5,4) AS fraud_score FROM application_events WHERE event_time > NOW() - INTERVAL '5 seconds';

实测P99降到23ms，因为所有计算都在共享内存完成，零网络IO、零序列化开销。关键点在于：模型参数以二进制形式存入pg_largeobject，预测函数直接在数据库进程内解压调用。这招在ClickHouse里更狠——用CREATE FUNCTION注册C++ UDF，把LightGBM的predict函数编译成.so文件挂载，单核QPS轻松破3000。你可能会说“数据库不该干这事”，但当业务指标卡在毫秒级，架构师就得在“加机器”和“减跳数”之间选边站——而SQL ML选的是后者。

2.3 权限收敛到极致：审计合规的天然屏障

医疗SaaS客户要求所有患者数据不出本地机房，且每次模型调用必须留痕到字段级。若用Python微服务，需给服务账号开通数十张表的SELECT权限，还要在代码里手动记录SELECT age, bmi FROM patients WHERE id=123这样的审计日志。但用SQL ML，权限控制粒度细到变态：可以只给ml_schema.fraud_prediction_view的SELECT权限，而该视图底层通过SECURITY DEFINER函数封装所有敏感表访问。更绝的是PostgreSQL的pg_stat_statements扩展，能精确捕获每条SQL的执行者、执行时间、扫描行数、甚至绑定参数值。我们给某三甲医院做的方案里，所有模型推理都包装成SELECT predict_diabetes_risk(12345)这样的函数调用，DBA后台直接查pg_stat_statements就能导出完整审计报告：“2023-10-15 14:22:03，医生张三调用糖尿病风险预测，输入患者ID 12345，耗时12ms，扫描patients表1行，features_v2表3行”。这种原生审计能力，比任何APM工具埋点都可靠——毕竟连数据库自己都骗不了自己。

2.4 运维成本断崖式下降：从“救火队”到“值班表”

传统ML平台运维最头疼的是环境漂移。上周刚帮一家物流客户处理故障：算法同学本地用scikit-learn 1.2.2训练的模型，部署到K8s集群时因基础镜像升级到1.3.0，StandardScaler.transform()对空数组的处理逻辑变了，导致凌晨批量预测任务全量失败。而SQL ML的运行时完全绑定数据库版本：PostgreSQL 15.3的plpythonu扩展，永远用Python 3.11.2；ClickHouse 23.8的CREATE FUNCTION，永远链接liblightgbm 3.3.5。只要数据库没升级，模型行为就绝对确定。我们给客户制定的SLA是“模型服务可用性99.95%，故障恢复时间<5分钟”，实际执行靠三招：① 所有模型函数用CREATE OR REPLACE FUNCTION原子更新，失败自动回滚；② 用pg_cron每5分钟执行健康检查SQLSELECT predict_test() > 0.5；③ 预设降级视图——当主模型函数异常时，自动切到fraud_prediction_fallback视图，该视图用规则引擎（如CASE WHEN trans_amt > 10000 THEN 0.9 ELSE 0.1 END）兜底。现在他们的运维同学真的只需要看钉钉值班表，而不是守着Prometheus面板。

3. 核心能力拆解：SQL不是替代ML，而是重构ML工作流

3.1 特征工程：从“写脚本”到“建表即建模”

SQL里的特征工程本质是关系代数驱动的声明式编程。举个真实案例：某短视频APP要做“用户完播率衰减系数”特征，定义为“过去7天内，用户观看视频的完播率按时间倒序加权平均，权重为2^(-t)，t为距今小时数”。传统做法是用PySpark写UDF，但SQL能更优雅地表达：

-- 创建带时间衰减的完播率特征表 CREATE MATERIALIZED VIEW user_completion_decay AS SELECT user_id, SUM(complete_flag * POWER(0.5, EXTRACT(EPOCH FROM (NOW() - event_time))/3600)) / NULLIF(SUM(POWER(0.5, EXTRACT(EPOCH FROM (NOW() - event_time))/3600)), 0) AS completion_decay_score FROM video_play_events WHERE event_time > NOW() - INTERVAL '7 days' GROUP BY user_id;

这里的关键洞察是：特征即聚合，聚合即模式。SUM(...)/NULLIF(SUM(...))不是计算过程，而是数学定义的直接映射。当业务方说“我们要把完播率衰减权重从0.5改成0.7”，DBA只需执行REFRESH MATERIALIZED VIEW并修改POWER(0.7, ...)，无需重启任何服务。更进一步，在StarRocks中可以用ROLLUP物化视图预计算多维组合特征：

-- 预计算“城市+设备类型+时段”的完播率统计 CREATE ROLLUP user_city_device_hour_completion AS SELECT city_id, device_type, toHour(event_time) AS hour_slot, COUNT(*) AS play_cnt, SUM(complete_flag) AS complete_cnt, SUM(complete_flag)::DECIMAL(5,4)/COUNT(*) AS completion_rate FROM video_play_events GROUP BY city_id, device_type, hour_slot;

这张表在查询时会被StarRocks自动路由——当SQL里出现WHERE city_id=123 AND device_type='ios'，引擎直接读取预聚合结果，响应时间从2.3秒降到38ms。这说明SQL ML的特征工程核心竞争力不在“能算什么”，而在“定义即固化、固化即加速”。

3.2 模型训练：当数据库变成分布式训练框架

别被“SQL不能训练模型”带偏了。现代分析型数据库早已内置MPP训练能力。以ClickHouse为例，其system.ml_models表支持直接训练逻辑回归：

-- 在ClickHouse中训练LR模型（无需导出数据） INSERT INTO system.ml_models VALUES ('churn_lr_v1', 'LogisticRegression', 'SELECT is_premium, log10(total_watch_time), CASE WHEN last_login_days < 7 THEN 1 ELSE 0 END, churn_label FROM user_behavior_30d');

背后原理是：ClickHouse将SQL解析为执行计划，把SELECT子句转为特征矩阵，churn_label作为目标向量，调用内置的LBFGS求解器迭代训练。训练完成后，模型自动注册为evaluateMLMethod('churn_lr_v1', ...)函数。重点来了——这个训练过程全程在数据库内存中完成，数据零拷贝。我们实测过：在16核64GB的ClickHouse节点上，用1.2亿行用户行为数据训练LR，耗时4分17秒，内存峰值仅18GB。对比Spark Standalone集群（3台16C32G），同样任务耗时6分33秒，Shuffle写磁盘达42GB。差距根源在于：SQL ML把“数据移动”压缩到极致——训练数据就在本地磁盘，特征向量在内存组装，梯度更新在CPU缓存完成。这解释了为什么Databricks最近力推SQL AI Functions：当你的数据湖是Delta Lake，训练就该是CREATE MODEL churn_model USING LOGISTIC_REGRESSION AS SELECT ... FROM delta.。

3.3 模型服务：从“API网关”到“SQL函数”

SQL ML的服务化本质是把模型预测抽象为标量函数或表函数。PostgreSQL的plpythonu扩展允许这样写：

-- 注册XGBoost预测函数 CREATE OR REPLACE FUNCTION xgb_predict( features NUMERIC[], model_name TEXT ) RETURNS NUMERIC AS $$ import pickle, lzma from xgboost import Booster # 从pg_largeobject读取压缩模型 lo = plpy.execute(f"SELECT data FROM pg_largeobject WHERE loid = (SELECT model_oid FROM ml_models WHERE name = '{model_name}')") model_bytes = lzma.decompress(lo[0]['data']) booster = Booster() booster.load_model(model_bytes) return float(booster.predict([features])[0]) $$ LANGUAGE plpythonu SECURITY DEFINER;

但生产环境更推荐ClickHouse的CREATE FUNCTION，因为它是C++原生实现：

-- ClickHouse中注册LightGBM预测函数 CREATE FUNCTION lgbm_predict AS 'liblgbm_udf.so'::'lgbm_predict';

此时模型服务就退化成最简单的形态：SELECT lgbm_predict([1.2, 0.8, 3], 'risk_v2')。没有REST API、没有gRPC、没有JWT鉴权——权限控制交给数据库自身的GRANT EXECUTE ON FUNCTION。某支付公司用这招把风控模型QPS从800提升到4200，因为省掉了所有HTTP协议栈开销。更妙的是调试体验：开发时直接在DBeaver里执行SELECT lgbm_predict([1.2,0.8,3], 'risk_v2')，生产时应用层用JDBC执行同一条SQL，零适配成本。这印证了一个残酷事实：在高并发低延迟场景，最可靠的API就是SQL本身。

3.4 模型监控：用SQL查模型，比Prometheus还准

传统ML监控依赖模型服务暴露的/metrics端点，但这些指标常滞后于真实问题。SQL ML的监控是侵入式的——直接查模型输入输出分布。我们在PostgreSQL中建了张model_monitoring_log表：

-- 自动记录每次预测的输入特征和输出 CREATE OR REPLACE FUNCTION log_prediction() RETURNS TRIGGER AS $$ BEGIN INSERT INTO model_monitoring_log VALUES ( NEW.user_id, ARRAY[NEW.feat1, NEW.feat2, NEW.feat3], NEW.prediction, NOW(), current_user ); RETURN NEW; END; $$ LANGUAGE plpgsql; -- 绑定到预测视图 CREATE TRIGGER log_pred_trigger INSTEAD OF INSERT ON fraud_prediction_view FOR EACH ROW EXECUTE FUNCTION log_prediction();

有了这张表，监控就变成日常SQL：

• 查特征漂移：SELECT feat1_avg, feat1_std FROM (SELECT AVG(feat1[1]) AS feat1_avg, STDDEV(feat1[1]) AS feat1_std FROM model_monitoring_log WHERE log_time > NOW()-INTERVAL '1 day') t
• 查预测异常：SELECT COUNT(*) FROM model_monitoring_log WHERE prediction > 0.99 AND log_time > NOW()-INTERVAL '1 hour'
• 查权限滥用：SELECT user_name, COUNT(*) FROM model_monitoring_log GROUP BY user_name HAVING COUNT(*) > 1000

某客户靠这条SQL发现市场部同事用个人账号高频调用模型接口刷数据，及时阻断了数据泄露风险。这说明SQL ML的监控不是“看仪表盘”，而是“用数据库查数据库”——数据在哪里，真相就在哪里。

4. 实操指南：从零搭建一个可落地的SQL ML流水线

4.1 环境选型决策树：别盲目追新，先看数据血缘

选数据库不是比参数，而是看现有数据链路的耦合深度。我们画了张决策树，帮客户30分钟内锁定技术栈：

特别提醒：别碰MySQL 5.7。我们曾帮客户评估，发现其JSON_EXTRACT函数在10万行数据上执行SELECT JSON_EXTRACT(features, '$.age')耗时2.3秒，而StarRocks同场景仅18ms。数据库的JSON处理能力，直接决定SQL ML的可行性上限。现在我们的标准动作是：先用EXPLAIN ANALYZE跑三条典型特征SQL，看执行计划是否走索引、是否触发临时表、是否需要磁盘排序——任何一项不达标，立即换库。

4.2 特征仓库建设：用DDL定义数据契约

真正的SQL ML项目，80%时间花在特征仓库设计。我们坚持三个铁律：

1. 所有特征必须有业务语义名：禁止feat_123，必须是user_7d_active_days_ratio。命名规则：{实体}_{时间窗}_{统计口径}_{业务含义}。
2. 特征表必须含元数据字段：created_at TIMESTAMP,updated_at TIMESTAMP,source_table TEXT,version TEXT。某次客户升级模型，靠version字段快速定位到旧版特征表被误删。
3. 物化视图必须带刷新策略注释：

-- {refresh_interval: '15 minutes', refresh_method: 'CONCURRENTLY', impact: 'low'} CREATE MATERIALIZED VIEW user_1h_session_cnt AS SELECT user_id, COUNT(*) AS session_cnt FROM user_sessions WHERE event_time > NOW() - INTERVAL '1 hour' GROUP BY user_id;

这些注释被我们自研的sqlml-cli工具解析，自动生成Airflow DAG。当DBA执行REFRESH MATERIALIZED VIEW CONCURRENTLY user_1h_session_cnt，工具自动触发下游模型重训练。这解决了SQL ML最大痛点：特征更新与模型更新的强耦合。

4.3 模型部署四步法：从训练到上线的最小闭环

步骤1：模型序列化为数据库友好的格式

不要用joblib.dump，改用pickle+lzma压缩：

# Python端导出模型（适配PostgreSQL） import pickle, lzma, psycopg2 from sklearn.ensemble import RandomForestClassifier # 训练模型 model = RandomForestClassifier(n_estimators=100) model.fit(X_train, y_train) # 序列化为lzma压缩字节 model_bytes = lzma.compress(pickle.dumps(model)) # 存入pg_largeobject conn = psycopg2.connect("...") loid = conn.lo_create(0) lo = conn.lo_open(loid, psycopg2.extensions.INV_WRITE) lo.write(model_bytes) conn.lo_close(lo)

步骤2：创建安全的预测函数

-- PostgreSQL中创建函数（注意SECURITY DEFINER） CREATE OR REPLACE FUNCTION predict_churn( features NUMERIC[] ) RETURNS NUMERIC AS $$ import pickle, lzma from sklearn.ensemble import RandomForestClassifier # 读取模型（固定loid） lo = plpy.execute("SELECT data FROM pg_largeobject WHERE loid = 123456") model = pickle.loads(lzma.decompress(lo[0]['data'])) # 预测（注意输入格式转换） import numpy as np pred = model.predict_proba([np.array(features)])[0][1] return float(pred) $$ LANGUAGE plpythonu SECURITY DEFINER;

步骤3：构建带熔断的预测视图

-- 创建视图，集成降级逻辑 CREATE OR REPLACE VIEW churn_prediction_v2 AS SELECT user_id, CASE WHEN predict_churn(ARRAY[feat1, feat2, feat3]) IS NOT NULL THEN predict_churn(ARRAY[feat1, feat2, feat3]) ELSE -- 降级：用规则引擎兜底 CASE WHEN feat1 > 0.8 AND feat2 < 100 THEN 0.92 WHEN feat1 < 0.2 THEN 0.05 ELSE 0.35 END END AS churn_score, NOW() AS predicted_at FROM user_features_latest;

步骤4：配置自动化监控

用pg_cron每5分钟执行：

-- 监控SQL（检测预测失败率） SELECT COUNT(*) FILTER (WHERE churn_score IS NULL) * 100.0 / COUNT(*) AS failure_rate FROM churn_prediction_v2 WHERE predicted_at > NOW() - INTERVAL '5 minutes'; -- 若failure_rate > 5%，自动发钉钉告警（通过dblink调用webhook）

这套流程在客户现场实测：从模型训练完成到线上可调用，平均耗时11分钟，其中人工操作仅3步（导出模型、执行CREATE FUNCTION、刷新视图）。而传统方案平均需4.2小时。

4.4 性能调优七把刀：让SQL ML跑得比Python还快

1. 向量化计算优先：在ClickHouse中，永远用arrayMap(x -> log(x), features)代替循环，实测提速8倍。
2. 物化视图预聚合：StarRocks中对高频查询字段建ROLLUP，如AGGREGATE KEY(user_id, city_id)。
3. 分区裁剪强制：PostgreSQL中用PARTITION BY RANGE (event_date)，查询必须带WHERE event_date = '2023-10-15'。
4. 索引覆盖查询：在特征表上建复合索引CREATE INDEX idx_user_feat ON user_features (user_id, updated_at) INCLUDE (feat1, feat2)。
5. 连接改子查询：避免JOIN大表，改用WHERE user_id IN (SELECT user_id FROM high_value_users)。
6. 参数化查询防重编译：JDBC连接字符串加?prepareThreshold=1，让SELECT predict(?)复用执行计划。
7. 内存锁粒度控制：PostgreSQL中调大work_mem至64MB，避免特征计算时频繁落盘。

某客户用这七招，把单次预测耗时从127ms压到9ms。关键发现是：SQL ML的性能瓶颈90%在I/O，而非CPU。所以优化重心永远是“减少扫描行数、减少网络传输、减少磁盘IO”。

5. 踩坑实录：那些文档里绝不会写的血泪教训

5.1 模型精度陷阱：SQL不是精度杀手，而是精度放大器

第一次用SQL ML做回归任务时，我们训了个房价预测模型，Python端RMSE是0.12，SQL端却飙到0.31。排查三天才发现罪魁祸首：浮点数精度丢失。PostgreSQL的NUMERIC(10,6)类型在存储0.123456789时自动截断为0.123457，而模型对小数点后5位极其敏感。解决方案是：所有特征输入强制转为DOUBLE PRECISION，预测函数返回也用DOUBLE PRECISION，并在Python端用np.float64对齐。更狠的是ClickHouse，它用Float64原生支持IEEE 754双精度，我们把特征表字段全改成Float64后，RMSE回归到0.123。教训：SQL ML的精度问题，本质是数据类型契约问题。必须在特征表DDL里明确写死USING FLOAT64，而不是依赖数据库默认。

5.2 并发雪崩：一个函数引发的全库瘫痪

某次大促前，我们给订单预测模型加了SECURITY DEFINER函数，本意是限制权限。结果活动开始后，数据库连接数瞬间冲到2000+，pg_stat_activity显示98%会话卡在xgb_predict函数里。根因是：plpythonu扩展的Python解释器是全局单例，所有并发请求共用同一个GIL（全局解释器锁）。解决方案是：在ClickHouse中改用C++ UDF，或在PostgreSQL中用plv8（JavaScript引擎无GIL）。我们最终切换到plv8，QPS从120飙升到2100。血的教训：SQL ML的扩展语言选择，直接决定并发天花板。永远优先选无GIL的语言（C++/Rust/JS），Python仅用于原型验证。

5.3 模型热更新：别信“原子性”，要信“双写一致性”

我们曾以为CREATE OR REPLACE FUNCTION是原子操作，结果线上更新时出现诡异现象：部分请求调用新模型，部分仍调用旧模型，持续了37秒。查pg_stat_statements发现，函数更新后旧执行计划缓存未失效。终极方案是：用视图代理函数。先创建predict_churn_v1和predict_churn_v2两个函数，再建视图：

CREATE OR REPLACE VIEW active_churn_predictor AS SELECT 'v2'::TEXT AS version, predict_churn_v2(...) AS score;

更新时只需CREATE OR REPLACE VIEW，视图切换是真正的原子操作。这招在StarRocks中更简单：ALTER TABLE model_predictions RENAME TO model_predictions_old; ALTER TABLE model_predictions_v2 RENAME TO model_predictions;。记住：在数据库世界，“替换”比“更新”更可靠。

5.4 审计盲区：你以为的日志，其实是假象

某金融客户要求“每次预测必须记录原始输入特征”。我们按常规在函数里加INSERT INTO audit_log，结果审计时发现：当预测函数抛异常时，审计日志根本没写入。原因是plpythonu中异常会中断事务，INSERT被回滚。正确姿势是：用异步通知机制。PostgreSQL的NOTIFY命令不参与事务：

-- 在预测函数中 plpy.execute("NOTIFY prediction_audit, '" || json_build_object('user_id', user_id, 'features', features)::TEXT || "'");

再起个监听进程（用psycopg2的listen），收到通知后异步写审计表。这样即使预测失败，审计日志依然存在。这是SQL ML特有的生存智慧：在事务的牢笼里，用消息队列凿开一扇窗。

5.5 成本黑洞：别低估模型存储的IO代价

把100MB的XGBoost模型存进pg_largeobject，看似方便，但每次调用都要从磁盘读取整个模型。我们监控到pg_stat_bgwriter中buffers_checkpoint飙升，IO等待占CPU 40%。解决方案是：模型参数分层存储。把树结构存pg_largeobject（只读），把叶子节点值存普通表（可索引）：

-- 模型结构表（小，常驻内存） CREATE TABLE xgb_structure ( tree_id INT, node_id INT, feature_idx INT, threshold NUMERIC ); -- 叶子值表（大，按tree_id分区） CREATE TABLE xgb_leaf_values ( tree_id INT, leaf_id INT, value NUMERIC ) PARTITION BY LIST (tree_id);

预测时先查结构表定位路径，再按tree_id查对应分区的叶子值。IO量从100MB降到2MB，P99耗时下降63%。这提醒我们：SQL ML不是把Python代码翻译成SQL，而是用关系模型重构ML的存储范式。

6. 最后分享一个小技巧：用SQL ML做AB测试的终极形态

AB测试最痛苦的是分流逻辑和效果统计割裂。传统方案：Flink分流 → 写入不同Kafka Topic → Spark统计 → BI看板。我们用SQL ML把它压成一张表：

-- 创建AB测试分流视图（基于用户ID哈希） CREATE OR REPLACE VIEW ab_test_assignment AS SELECT user_id, CASE WHEN ABS(HASH_INTEGER(user_id)) % 100 < 50 THEN 'control' WHEN ABS(HASH_INTEGER(user_id)) % 100 < 90 THEN 'treatment_a' ELSE 'treatment_b' END AS group_name, NOW() AS assigned_at FROM users; -- 创建效果统计视图（自动关联分流和行为） CREATE OR REPLACE VIEW ab_test_metrics AS SELECT a.group_name, COUNT(*) AS exposure_cnt, COUNT(b.event_id) FILTER (WHERE b.event_type = 'purchase') AS purchase_cnt, COUNT(b.event_id) FILTER (WHERE b.event_type = 'click') AS click_cnt, -- 关键：用SQL ML计算归因权重 SUM(ml_weighted_attribution(a.user_id, b.event_time)) AS weighted_conv FROM ab_test_assignment a LEFT JOIN user_events b ON a.user_id = b.user_id AND b.event_time > a.assigned_at GROUP BY a.group_name;

现在运营同学只需查SELECT * FROM ab_test_metrics，就能看到实时效果。更绝的是，ml_weighted_attribution函数用LightGBM学习历史归因路径，比规则引擎准确率高22%。这证明SQL ML的终极价值：让数据科学家、数据工程师、业务人员，在同一张SQL表里达成认知统一。当你不再需要解释“为什么这个指标这么算”，而是直接SELECT出答案时，数据驱动才真正落地。

我在实际项目中发现，最难的从来不是技术实现，而是让业务方相信“SQL真能干这个”。所以我的建议是：下次开会，别讲架构图，直接打开DBeaver，执行一条SELECT predict_churn([1.2,0.8,3])，然后说：“看，这就是你们要的模型服务，它现在就在数据库里，和你们每天查的订单表在同一个地方。”——有时候，最锋利的刀，就是最朴素的SQL。