南大通用的DataAI落地路线图综述我写到了第六篇。熟悉这个系列的朋友应该记得前五篇我分别拆过数据底座选型、湖仓一体规划、主数据治理、机器学习平台对接以及实时特征链路。每次写的时候都有人问我这些架构图看起来都挺顺可到了具体项目里为什么推进得还是磕磕绊绊这个问题其实比任何一张架构图都值得聊所以这一篇我把视角收回来聚焦“最后一公里”——从数据底座稳定运行到AI模型真正产生业务价值的那段路程。本文不会重复前面的架构图而是把南大通用这类数据库产品在DataAI To B落地场景里真正会被用到的工程细节、取舍逻辑和常见失误摊开来给正在规划和实施的朋友一个参考。南大通用这个名字做过国产数据库选型的朋友应该不陌生旗下GBase系列里的分析型、事务型产品都有布局。放在DataAI的场景里数据库不是模型的主场但它是数据的主场。一个模型能不能稳定跑起来、特征算得对不对、上线之后效果能不能保持一致大部分瓶颈都藏在数据这一层。所以本篇延续“路线图综述”的定位不聊某个特定产品的新版本功能点而是讲清楚在使用GBase这类数据库支撑DataAI业务时整体规划上应该怎么走、实操中哪些环节需要较真。1. 落地路线图的岔路口为什么越往后越难讲很多人觉得DataAI路线图就是画几个框数据源—数据平台—算法平台—业务应用连起来就完事。但在To B项目里真正消耗时间的不是总体架构设计而是“每一层如何衔接”。比如数据平台和算法平台之间特征数据怎么约定格式训练用的宽表和线上服务用的特征表是不是同一套口径模型更新后旧版本怎么管理这些细节一旦说不清项目就会卡在联调阶段。南大通用这类数据库厂商近几年的产品迭代和生态方案很多都在解决这类衔接问题。这也是为什么这个系列我一直写下来路线图的框架只是开始越往后越考验工程化能力。1.1 路线图框架的一次回看为了把第六篇放在完整的上下文里简单回看前五篇的路线图分层。第一层是数据底座解决多源异构数据的存储和算力问题分析型数据库在这里扮演核心角色。第二层是数据集成与湖仓一体把离线批量、实时流式、文件湖存储统一纳管让AI团队能在一个地方拿到数据。第三层是数据治理与主数据确保“喂给模型的数据是可信的”包括口径统一、质量校验、血缘追踪。第四层是机器学习平台对接打通训练环境、特征存储和模型仓库。第五层是实时特征链路让在线推理能用上近实时特征。这五层各自都有独立的落地路径但在真实企业里它们是交错推进的用下表可以看成一个整体规划。阶段核心问题系列编号数据底座存储和算力是否够用之一湖仓一体数据和文件能否统一访问之二数据治理喂给模型的数据是否可信之三平台对接训练和特征链路是否打通之四实时特征在线推理能否拿到新鲜数据之五生产化闭环从模型上线到业务反馈是否完整之六本篇前五篇解决的是“从无到有”的建设问题本篇则是在前五层的基础上讨论它们如何被组装成一条可持续迭代的流水线。你可以把前五层理解为修路而第六篇讲的是在这个路上跑车的时候会遇到的堵点、路口和限高杆。没有这些细节路修得再宽车也跑不起来。1.2 本篇的出发点从“能演示”到“能生产”在To B环境里大多数DataAI项目都能做到“能演示”用历史数据训练一个模型做一个展示页面拿一批样本预测出结果。但到了生产环境问题就变样了。数据每天在变业务方隔三差五提出新的特征需求算法团队要调参数运维团队要保证系统稳定数据库偶尔报警。这个时候之前随手写的临时SQL、临时表、一次性训练脚本全变成负债。南大通用在落地路线图里反复强调的一点是数据库层的设计要具备生产属性表要分区、任务要可重跑、数据要可回溯、资源要可隔离。从“能演示”到“能生产”差距往往不在于算法模型有多先进而在于这些不起眼的工程细节有没有提前设计好。本篇后面几章的实操内容都是围绕这个差距展开的。2. 从数据到模型To B场景的DataAI闭环设计先明确一下我们说的闭环长什么样。数据从业务系统进入数据平台经过清洗加工形成特征特征一部分供离线训练一部分供在线推理模型推理结果和最终业务结果再回到数据平台形成新的训练样本。整个链路中数据库层需要提供三类能力支撑批量数据加工的分析计算能力、支撑元数据和结果数据存储的事务能力、以及支撑数据新鲜度的实时处理能力。南大通用现有产品线里GBase 8a偏向第一类GBase 8c、8t偏向第二类实时处理则通过生态组件配合完成。很多人误以为DataAI落地就是上一个大模型平台其实数据库才是那个最容易兜不住底的地方。2.1 数据供给层分析型数据库承担什么分析型数据库在DataAI中的定位是“数据供给层”。AI模型需要训练样本样本来自明细数据和汇总数据分析型数据库接收来自生产库、外部文件的原始数据按业务逻辑加工成一张张宽表和特征表。以GBase 8a为例它采用大规模并行处理架构列式存储配合压缩全表扫描和聚合计算要比普通行存数据库快不少。实际项目中几千万行级的交易表做复杂分组聚合压测到几十并发仍能保持可接受的响应时间这种吞吐能力对特征工程批量计算至关重要。还有一点容易被忽略分析型数据库的数据加载接口往往比通用数据库更擅长大批量导入可以用并行加载工具把T1的数据在很短时间内灌入。在To B项目里这一步直接决定了特征数据的新鲜度。如果加载慢后面的特征计算、模型训练全部都要往后顺延整个数据管道的SLA就会失守。所以规划数据供给层时不能只看查询性能还要看写入和加载能力。2.2 特征计算层让SQL做特征工程许多人认为特征工程必须用Python写Spark任务才算“正规”。但在To B场景我越来越倾向于将大部分结构化特征的计算下沉到分析型数据库用SQL来表达。理由很简单第一团队里懂SQL的人远比懂Spark的人多特征口径可以用一套代码统一管理第二SQL在分析型数据库里是并行执行的写一次就能用在大数据量上不需要额外维护分布式计算集群第三BI报表和AI特征来自同一套计算引擎口径更容易对齐。当然SQL并不是万能的文本嵌入、图特征、交叉特征变换等还是需要模型侧处理但至少80%的统计型特征数据库是更合适的计算场所。这里有一个关键原则特征计算逻辑必须只有一个源头离线训练和在线推理共用同一段定义否则后续的坑会无穷无尽。特征定义一旦分散在多个脚本里哪怕只是一个人改了某个参数线上效果都可能出现断崖式下跌。2.3 模型服务层事务型数据库与推理服务的协同模型训练完成之后需要部署成服务。此时事务型数据库的职责是存储模型元数据、特征版本、推理结果和业务日志。为什么不用分析型数据库来做?因为在线请求要求低延迟、高并发、强一致写入和读取都以单行或少量行为主这正是事务型数据库的强项。GBase 8c这类产品可以承载订单式写入例如实时风控服务每秒写入数万条推理记录同时提供按客户维度的快速查询。协同方式通常是推理服务启动时从数据库加载模型注册表和特征配置运行中将结果写回结果表如果推理失败还要记录错误码和回退策略。这里要提前设计表结构避免把所有结果堆在一张表里导致索引膨胀可以按天分区、定期归档。另外事务型数据库在高并发写入时要注意批量提交的大小太大容易锁竞争太小则吞吐不足这个需要根据实际压测结果找一个折中值。2.4 反馈回路数据回流与模型迭代闭环的最后一环是把业务结果反馈到特征库。一个用户被系统判定为风险用户后后续此人是否真的发生逾期这是模型优化的“金标准”。这种反馈数据往往在业务库里需要定期抽取回分析型数据库和之前的推理样本表做关联生产新的训练样本。实际操作中反馈表的时效性决定了模型迭代周期。有的企业一个月重训一次有的每周重训取决于数据量、业务变化速度和资源成本。南大通用在路线图规划中比较强调把反馈回流的任务纳入统一调度不能依赖人工跑临时脚本。我的建议是建一个反馈流水表每次回灌都追加新分区保留历史版本方便回溯模型效果。这样DataAI才不是一个一次性的项目而是可持续优化的业务能力。3. 实操一个典型风控场景的完整落地路径讲完原理给一个可参考的例子。为了贴近To B场景我选一个金融零售风控的反欺诈应用。这个场景很典型白天有新增申请晚上做批量训练白天同时跑实时推理而且是监管强相关的场景对数据一致性和可解释性要求高。这里只展示关键技术设计不涉及具体公式。注意下面的结构适用于大多数To B预测场景不只是风控。3.1 场景假设和数据流设计假设一家消费金融公司每天新增数万条线上申请每笔申请关联近一年的银行卡交易流水、电商消费行为、外部征信查询记录。目标是实时计算欺诈概率若大于阈值则转入人工审核。基于南大通用产品的数据流可以这样设计业务库的交易流水通过同步工具实时或准实时进入消息队列由消费程序写入GBase 8a的原始流水表每天凌晨定时任务对原始表做清洗、去重、汇总加工成申请客户的特征宽表特征宽表和标注好的历史样本合并生成训练集算法平台在T1的样本上完成模型训练将模型文件注册到模型仓库同时将模型元数据和特征版本写入GBase 8c。白天推理服务启动后从GBase 8c读取模型配置准实时查询GBase 8a特征宽表或特征缓存把特征拼装成模型输入返回概率并写入结果表。整个链路不需要把海量交易数据从分析型数据库搬走所有批量特征都在数据库内完成。这是我一直推荐的方式数据尽量在原地算完把计算结果这一小份东西送出去而不是让数据裸奔到算法集群。3.2 特征加工SQL示例和调优思路拿最常用的“近30天交易流水特征”来说SQL可以先写成这样-- 近30天流水特征交易次数、平均金额、最大金额、大额笔数 SELECT cust_id, COUNT(*) AS tx_cnt_30d, ROUND(AVG(amt), 2) AS avg_amt_30d, MAX(amt) AS max_amt_30d, SUM(CASE WHEN amt 10000 THEN 1 ELSE 0 END) AS high_amt_cnt_30d FROM trade_flow WHERE trans_dt CURRENT_DATE - 30 GROUP BY cust_id;这是一个最简单的例子。在实际项目里特征可能会更多例如统计消费时段分布、商户类别频次、交易间隔均值。为了性能需要注意几点一是流水分表按交易日期分区每天新增切换新分区查询走分区裁剪二是分布键要和最终关联客户一致避免跨节点重分布三是避免在WHERE里对字段做函数计算会限制索引和分区裁剪四是对几十亿行流水做COUNT时列存上的并行扫描优势很大但GROUP BY结果如果超过千万要注意倾斜和中间结果落盘。常见的坏写法是把交易流水表和自己做非等值关联例如统计“前30天内在同一商户的消费次数超过5次”一上来就是大表加非等值JOIN优化器很容易选择全量广播性能直接崩。解决办法是把这类计数先缩聚成“商户—客户—日”的中间表再对中间表做关联能大幅减少数据交换量。3.3 表结构设计与存储划分数据模型设计上我建议在GBase 8a里把“已加工特征”和“原始流水”分开存储。原始流水保留全量用于回溯和问题排查特征表按天分区、按客户号哈希分布列存加高压缩。下面是一个典型的特征长表定义-- 特征长表每个客户每天多行feature_namefeature_value 为一对特征 CREATE TABLE feature_wide ( cust_id VARCHAR(32) NOT NULL, feature_name VARCHAR(128) NOT NULL, feature_value DOUBLE PRECISION, calc_date DATE NOT NULL ) DISTRIBUTE BY HASH(cust_id) PARTITION BY RANGE(calc_date) ( PARTITION p20240101 VALUES LESS THAN (2024-01-02), PARTITION p20240102 VALUES LESS THAN (2024-01-03) );特征表设计为长表还是宽表各有取舍。一般离线训练转换成CSV时宽表方便但特征数量变化频繁时长表更灵活。我建议在数据库内保留长表输出训练集时再PIVOT成宽表。存储分层也要考虑热分区放SSD冷分区放普通盘压缩等级可以调高一些。模型元数据则放在事务型数据库GBase 8c里结构类似这样CREATE TABLE model_registry ( model_id VARCHAR(64) PRIMARY KEY, model_name VARCHAR(128), model_version INT, feature_set VARCHAR(512), status VARCHAR(16), deploy_dt TIMESTAMP, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );为什么要把模型注册表单独做一张因为每次推理请求都要知道当前应该使用哪个版本的模型以及对应哪些特征字段。如果没有这个表算法团队就只能手工修改配置文件改错一个环境变量就可能导致线上全量回退。数据库表刚好能承担这个“单一事实来源”的职责。3.4 模型上线与效果监测模型部署上线不是把模型文件放到服务器就完了。在实际运行中要持续监测数据分布漂移和模型效果衰减。下面这几个指标建议按天汇总并绑定告警指标说明常见告警阈值AUC评估模型排序能力低于0.75或环比下降5%KS区分正负样本能力下降超过10%PSI特征稳定度超过0.25在线调用成功率推理服务可用性低于99.9%特征新鲜度特征落库到可查询的时间超过30分钟另外需要设计模型灰度发布先让5%的流量走新模型观察AUC和线上转化再逐步放开。灰度期间数据库层看到的只是不同模型ID的推理请求需要把模型ID作为维度记录在结果表里。这个思路很多团队都知道但真正落地时经常因为结果表设计没预留字段而没法做。所以在建表时就要把model_id、feature_version、req_id都放进主键或索引里这样每一步都有据可查。4. 避坑指南我在这个路线图上踩过的六个坑这个部分算是整个系列里最“实验性”的内容。以下六个坑都是我在真实To B项目里见过或者踩过的写出来希望你能少走一次弯路。4.1 坑一离线训练特征和在线推理特征不一致这是DataAI项目里最隐蔽、也最致命的问题。团队在离线训练时用了完整的强变量比如“当日前30天交易次数”但在线服务只拿到了缓存下来的前一天特征导致线上效果远不如离线测试。避免措施收敛特征来源离线训练用的特征宽表必须和线上实时拼接的特征逻辑来自同一个SQL模板最好抽象成一个口径文件离线在线统一引用。数据库层可以做的是把特征计算逻辑固化为视图或者SQL模板所有下游消费方只能通过统一接口取数而不是各跑各的临时脚本。4.2 坑二SQL下推的边界没想清楚分析型数据库的优化器并非万能某些函数或表达式可能无法下推到数据节点导致回源到协调节点计算内存和网络瞬间被打爆。常见的是复杂窗口函数、非等值关联、正则表达式。我在项目里遇到过一条特征加工SQL在数据量5000万时跑得很快涨到1亿后突然慢了十倍排查发现优化器选择对某张中间表做全量广播。解决方法是拆分SQL把大表关联拆成小粒度子查询或者改用多次聚合再关联减少数据节点间的数据交换。上线前一定要做数据量递增压测不要只拿一小部分数据验证。4.3 坑三资源隔离缺失引发线上抖动To B生产环境里数据分析任务、批量模型训练、在线推理服务往往会共享同一个数据库集群。如果没有资源隔离下午三点一批重任务开始跑在线查询全部卡住。GBase 8a这类MPP产品一般提供资源队列或动态线程池规划时就要按业务重要性划分队列A队列给在线查询并发高、限额小B队列给批量任务并发低、占用大。同时给批量任务设置执行超时超过阈值自动终止。实际中我还会加一条规则任何临时大查询默认进C队列不占用核心资源。这一点看起来是运维问题实际是架构问题必须在建库时统一规划。4.4 坑四连接池和数据库参数冲突在线推理服务通常通过连接池访问数据库如果连接池最大连接数设置到200而数据库max_connections只有300再加上批量任务和运维后台很容易把连接数打满。更麻烦的是连接池探活和数据库等待超时参数不匹配数据库可能已经拒绝连接服务端还在排队。我的建议是上线前计算每个服务实例需要的最高连接数乘以实例数再乘以1.5的余量得出数据库max_connections配置连接池的初始连接数和最大连接数都要有上限不能随便设一个很大的数字另外开启数据库端的连接数告警。经验法则是让连接池的最大连接数不超过数据库max_connections的40%留下余量给其他工具。4.5 坑五监控看数据不看时效很多项目用监控大盘看CPU、内存、磁盘IO觉得数据库没问题但DataAI业务更关心的是“特征新鲜度”。比如实时风控要求交易发生后5分钟特征生效如果同步任务在凌晨2点停了到了白天才恢复线上推理用的就是旧特征。这类问题不会体现在CPU使用率上必须单独监控链路关键节点的数据水位。我会在每张关键表上记录batch_id和update_time并由调度系统检测数据产出时间超过SLA就触发告警。数据库层还可以配合查询运行时长监控如果一个流式计算任务每天都在变慢大概率是数据量增长或SQL执行计划退化。4.6 坑六项目组缺一个懂数据库和算法交叉的角色最后一个坑来自组织和协作。算法工程师往往不了解分布式数据库的分区、分布键、执行计划DBA又不懂特征工程和模型迭代两边沟通全靠业务翻译。结果就是SQL写得很随意建模晚了才发现数据算不对。我见过比较成功的项目组都会设一个“数据算法工程师”或者“平台工程师”的角色专门负责把算法团队的SQL翻译成可生产的数据库作业也负责把DBA的资源规划建议转成算法团队能理解的约束。如果团队实在没有这个人就把所有SQL规范写进项目文档并让算法工程师在提需求时必须附带数据量和执行频率DBA据此评估分区和资源。这个流程看似增加工作量但能省掉后面大量联调返工。5. 写在系列之六末尾的一点个人体会这个系列写到第六篇我对“落地路线图”这几个字的感受越来越具体。所谓路线图其实不是那张画出来的图而是项目过程中无数个细碎决定的总和特征表是长表还是宽表、模型ID插在哪个字段、凌晨调度选几点、连接池留多少余量。南大通用的产品在DataAI生态里并不算最耀眼的明星但它承担的是最重的数据底座一旦设计不好后面所有AI业务都得在泥地里走路。我再分享一个判断项目能不能落地的简单方法去看特征数据链路是否能用一句SQL解释清楚。如果算法部门说“特征数据在数据仓库里”但具体在哪张表、由谁更新、更新时间多少都没人说得清那这个项目离生产还很远。反之如果连一个小特征都能追踪到原始表和加工代码这个项目哪怕算法不复杂也会走得很稳。这是我在多个To B项目里验证过的经验也是这篇之六最想留在文末的话。