1. 项目背景为什么一个初版平台敢走轻量路线1.1 业务场景与真实规模先说清楚这个平台解决的是什么问题。我们团队负责公司内部的AI应用落地具体场景包括智能客服的知识库检索、运营侧的自动化报表解读、以及一个正在摸索中的个性化推荐模块。早期这些东西全是“点状项目”——算法工程师自己拉数据、自己写脚本、自己起服务每个人手里都有一堆互不相同的处理逻辑数据口径对不上模型版本也管理得乱七八糟。所以问题不是“要不要搭平台”而是“怎么用最小的成本先把流程跑通”。当时团队只有4个人两个算法、一个后端、一个我负责整体架构和工程落地。公司层面没有专职的运维和DBA大数据基础设施是有的但审批流程很长动不动要等一周。这种情况下上K8s、上Flink、上完整的DataOps全家桶等于给项目提前判死刑——光是折腾环境就够喝一壶。我当时的判断是这个阶段的核心矛盾不是“规模”而是“协作和数据一致性”。数据量大概在千万级到亿级之间日增几百万条特征维度几十个单机内存能放下。这个规模老老实实说根本不需要分布式。目标很明确用两周搭一个初版把数据接入、特征处理、向量检索、模型服务这几条主链路串起来让算法能自助用数据让后端能稳定调用模型接口。1.2 轻量不是将就而是刻意设计很多人一听“轻量”就觉得是简化版、玩具版其实不是。轻量在我的定义里是控制每一层的复杂度和运维成本用最少的组件覆盖主流程且每个组件都留了未来替换的接口。为什么这么设计核心逻辑是初版平台的唯一目标是验证业务流程而不是展示架构能力。每一层多引入一个组件就意味着多一个需要维护的系统、多一种故障的可能性、多一份知识传递的成本。对于一个4人小团队来说这些“多”都是实打实的时间消耗。所以我定了一条铁律能用数据库解决的不单独上中间件能在单机跑完的不上分布式能用一个框架搞定的不引入全家桶。这条铁律在后面几次选型中帮了大忙——比如调度器我们一开始差点上了Airflow后来发现团队没人熟悉DAG编程模式最后直接用Python的APScheduler加数据库状态表做了一个几十行的调度器反而更贴合当时的协作方式。后面我会详细拆解这些决策。2. 架构分层与关键技术选型2.1 五层架构的划分逻辑整个平台我划分成五层接入层、存储层、处理层、服务层、观测层。这个划分不是学术意义上的严格分层而是从“数据流向”和“故障边界”两个维度切出来的。接入层负责数据的进入包括业务库的增量同步、日志文件的定时导入、第三方API的拉取。存储层提供两类能力结构化数据的OLTP存储以及向量数据的检索能力。处理层做特征工程、数据清洗、向量化等离线计算。服务层面向上层应用提供统一API包括模型推理、相似检索、特征查询。观测层包含日志、监控、指标统计这个层看起来不起眼但初版阶段恰恰最不能省——没有它后面所有故障排查都会变成瞎猜。各层之间的通信协议我统一用了HTTP JSON没上消息队列。原因很简单初版流量不大同步调用足够MQ只会增加架构复杂度。等某个链路的吞吐量真正成为瓶颈时再在那个点上引入异步机制这是演进式架构的基本思路。实际跑下来日均百万级的数据流转同步调用完全没压力。2.2 存储选型PostgreSQL pgvector 的组合这是整个架构里最关键的决策之一。结构化数据我们选了PostgreSQL 15理由除了大家熟知的可靠性外还有个私心它可以无缝承载向量检索扩展。单独上一套向量数据库比如Milvus、Qdrant意味着要额外维护一套分布式系统而且向量数据与结构化数据之间经常需要关联查询——比如“找出某个用户最近一周浏览过的商品里和当前查询最相似的前10个”。如果向量和业务数据分库应用代码里就要做多次查询再内存关联逻辑复杂且容易出错。用PostgreSQL pgvector一个库搞定结构化数据和向量数据的统一查询还能直接用SQL做过滤条件开发效率高一个量级。有人会质疑pgvector的性能这个我实测过在1000万级别的向量规模下使用HNSW索引单机QPS能做到几百到上千召回率在0.95以上取决于ef_search参数。对初版平台来说完全够用。后续如果向量规模真的涨到需要分布式pgvector还提供了到独立向量库的迁移路径——索引类型和API风格相似迁移成本可控。当然这只是我在实际场景下的经验之谈。如果你的项目一开始就是上亿级向量且对延迟要求是毫秒级那直接上分布式向量库更对口。选型这事儿没有绝对的优劣只有匹配不匹配。2.3 计算与调度DuckDB 自研调度器离线计算这块我放弃Spark和Pandas是有原因的。Spark太重做小规模处理还得去YARN集群提交任务开发调试链路很长。Pandas的问题在于内存管理——处理千万级数据时一个groupby操作就能把内存干到十几个GB而且代码一长中间变量管理起来很痛苦。DuckDB解决了这两个问题它是个进程内的列式OLAP数据库能在单机上高效跑SQL支持直接用SQL查询Parquet文件处理亿级以下数据的速度比Pandas快好几倍。我们团队人人会SQL这样一来特征工程的开发门槛大幅降低很多原本要写几十行Pandas的操作一条SQL就搞定了。特征处理的代码量至少减少了一半。调度器一开始真的纠结过。Airflow功能全但DAG代码的调试和维护对团队来说有点重。后来我们做了个最简单的方案一张task_run表记录任务状态APScheduler的cron表达式触发定时检查满⓫足条件的任务就提交到线程池执行。总共不到200行代码加上失败重试和超时熔断的逻辑。这个简陋的调度器撑过了整个初版阶段直到后续任务数量超过50个才考虑换Prefect。2.4 模型服务与特征对齐模型服务我们基于FastAPI自研了一个轻量推理网关。为什么不用现成的模型服务平台因为初版阶段模型类型还比较单一——一个文本Embedding模型、两个分类模型、一个排序模型——用一个统一的FastAPI服务包起来就够了。但这里有个隐藏的复杂点特征对齐。训练时的特征和线上推理时的特征必须完全一致否则模型效果会大打折扣。比如我们有个点击率预估模型训练时用的特征是“用户过去7天曝光次数”但如果线上服务从Redis里查到的是“截止当前时刻的曝光次数”口径就漂了。这个问题我后面专门列了踩坑项这里先提个醒特征对齐不是靠工程师自觉而是要靠平台机制保证。3. 核心模块的落地实现3.1 数据接入的三种通道接入层我设计了三条通道分别对应三种数据来源第一种是业务库同步。我们用PostgreSQL的逻辑复制Logical Replication把业务系统的订单、用户行为数据实时同步到平台的独立Schema里。逻辑复制比基于时间戳的增量查询可靠得多不会漏数据也不需要在业务库加字段。配置一次发布订阅关系平台侧建一张订阅表数据自动流转。第二种是日志文件导入。运营那边会定期导出Excel或CSV文件我把这些文件统一放到一个HDFS兼容的对象存储目录——我们用的是MinIO——然后定时任务扫描新文件用DuckDB的read_csv函数直接查询写到结构化表里。整个过程SQL就搞定不需要写复杂的解析代码。第三种是第三方API拉取。比如我们用的一个外部数据服务每天凌晨会生成前一天的统计结果。用APScheduler每天触发一次拉取任务把数据拉下来做增量合并。这里有个注意点API拉取经常会有延迟或失败所以任务状态表里必须记录“数据日期”而不是“任务执行时间”否则补数据的时候会乱。3.2 特征与离线批处理的实现细节特征处理层是平台的核心它负责把原始数据转换成模型可用的特征。我们沿用了一套经典的“数据日期”体系每个特征表都有一个ds字段数据日期所有离线计算都以ds为分区维度。具体流程是这样的每天凌晨2点调度器触发批量特征任务从ODS层原始数据层读取前一天的增量数据通过DuckDB计算各类特征写入DWS层特征宽表层。比如用户特征宽表就是一行一个用户列是各种维度聚合后的值——7日消费金额、30日活跃天数、偏好类目分布等。这里的一个关键细节是数据日期边界的处理。比如计算“过去7天”这个窗口必须明确是“自然日的过去7天”还是“滚动7天”。我们统一采用自然日聚合每个特征都严格对应某个ds这样训练和推理时按同一个ds取特征就不会出现口径漂移。代码里我会把特征公式写在配置表里每个人都能看到特征是怎么算的而不是埋在某个py文件深处。3.3 向量检索服务的实现和参数调试向量这块是平台最有辨识度的功能。我们的知识库数据要先经过Embedding模型转成768维的向量然后存入pgvector表。整体流程是文档清洗 - 分段 - 向量化 - 入库。分段大小我们调试了很久最终定在256个字符左右重叠32个字符。为什么这么定因为分段太大会丢失局部语义太小则每个片段上下文不足。256字符对我们这个领域的文档类型来说是精确率和召回率都比较均衡的窗口。检索服务的核心是一个ANTI递归SQL查询用算符做向量距离计算配合HNSW索引加速。调参上最重要的是ef_search和nprobe——它们控制检索的广度和精度。参数作用我们的取值调参心得ef_searchHNSW搜索时的候选集大小40越大召回越准确但延迟线性上升超过100收益递减明显距离函数向量相似度计算方式余弦距离文本Embedding场景优先用余弦欧氏距离受向量模长影响大min_similarity过滤阈值0.72低于此阈值的检索结果直接丢弃避免垃圾结果混入调参时我们先用一个固定的评测集跑批量测试扫描不同参数组合下的召回率和延迟做成一张曲线图再决定生产取值。这个方法比较笨但有效与其猜测参数不如用评测数据说话。4. 踩坑实录初版平台最容易翻车的5个地方4.1 幂等性设计任务重跑导致数据翻倍这是第一个让我长教训的坑。某个特征任务第一次跑失败了我直接在数据库里改了源数据然后手动重跑结果发现特征值翻了一倍——因为任务不是“重算”而是“再追加一遍”。罪魁祸首是写入逻辑用了INSERT而不是UPSERT即按主键冲突时执行更新。这个教训后来变成了一条硬性规范所有离线计算任务必须支持安全重跑写入前必须保证幂等。最稳妥的方案是每个任务先按ds分区删除目标数据再执行写入计算。写完以后把任务结果和任务参数包括数据日期、代码版本、输入数据快照一起记录到task_run表。这样重跑、排查、回溯都有据可查。4.2 特征穿越模型上线后发现训练和推理口径不一致这是我们踩过的最严重的坑。有个推荐模型的离线指标AUC高达0.85但一上线线上指标惨不忍睹排名反而下降了。排查了三天最后定位到是特征穿越。具体是这样的离线训练时特征宽表使用的是“T日之前的数据计算T日的特征”逻辑上是正确的。但我们的T日特征任务是在T1日凌晨跑的所以特征宽表的dsT实际上用的数据是T日全天的——而线上推理时T时刻能拿到的只有T-1日之前的数据。一来一回特征里包含了一部分“未来信息”训练指标自然虚高。这也是经典的时间穿越问题在数据平台里的具体表现。解决方案很简单但需要严格执行特征任务必须声明“统计截止时间”比如ds2024-05-20的特征只能用event_time 2024-05-20 00:00:00的数据计算而不是用整天2024-05-20的数据。我把这个校验逻辑直接写进了调度器每个任务提交前检查输入数据的最大时间戳是否小于等于数据日期减一天否则直接拒绝执行。从此再没出现过类似问题。4.3 向量数据与结构化数据的同步问题pgvector虽然能统一存储但同步更新的问题还是存在的。我们最初的设计是业务库主表更新数据时通过逻辑复制同步到平台侧然后平台侧解析变更事件触发对应的Embedding重新计算再更新向量表。听起来合理但实际执行时发现大量向量数据处于“失效未更新”状态。原因是逻辑复制的事件是异步的当主表数据频繁更新时向量化任务队列积压严重什么时候处理到哪个事件完全不可控。一个文档改了标题你以为向量已经更新了实际检索出来的还是旧内容。后来我调整了策略不追求流式同步而是每15分钟做一次增量轮询通过对比主表和向量表的更新时间戳找出“脏数据”批量重算向量。虽然延迟从秒级变成了分钟级但对于知识库检索场景完全可接受而且数据一致性得到了保障。这也再次印证了那句话初版平台可预测的一致性比极致的低延迟更重要。4.4 连接池与并发线程的资源配置FastAPI服务上线后出现过一个诡异的问题服务看起来没挂但有些请求会卡死几十秒才返回。后来才发现是连接池和线程池的配置不当导致的连环死锁。我们的服务同时操作PostgreSQL和调用外部Embedding API。PostgreSQL连接池默认大小是10而我们的FastAPI进程用了Uvicorn的默认配置工作进程的线程数远大于连接池容量。当并发请求超过10个时大部分线程在等待连接池释放连接而连接池里的连接又被阻塞在等待外部API返回的时间上形成了“线程饿死”的局面。简单说就是外部API响应越慢PostgreSQL连接被持有的时间越长系统的吞吐量就越差。修复方案分两步一是调整连接池大小到30并设置max_overflow20二是把外部API调用改为并发限制器保护的异步任务避免一个慢API拖垮整个服务。事后复盘这类问题在初版阶段非常典型——不是性能不够而是资源池的并发模型没对齐。4.5 内存与处理性能瓶颈DuckDB虽然解决了Pandas的内存问题但也不是没有坑。我们有个处理流程需要加载一个200GB的Embedding模型其实模型文件没这么大是说处理语料的时候跑批量向量化时内存占用飙升到70GB直接把单机搞OOM了。排查后定位到问题代码里用了map函数把整个DataFrame一次性传入Embedding模型模型内部会先把所有输入都加载到显存或内存中一次性处理。后来改成“分批传入每批处理完释放”每批512条内存占用稳定在8GB以内。另外DuckDB查询结果默认是惰性加载的但如果调用了.fetchall()或者.df()会把整个结果集拉到内存里大数据量场景同样会炸。能流式处理的场景就不要一次性加载全量数据这个原则什么时候都不过时。5. 与生产环境的真实差距5.1 高可用与故障恢复的差距这是我们初版平台最明显的短板。所有服务都跑在一台机器上数据库、DuckDB任务、FastAPI服务、MinIO存储全在一起。好处是架构极简坏处是单点故障风险非常高。机器一宕整条链路全断恢复时间是“重启机器 手动检查任务”的量级可能需要几个小时。生产环境的AI数据平台即使规模不大通常也会做基础的高可用设计数据库主备切换、服务多副本部署、负载均衡。这些能力在初版阶段我们没有做不是不想是确实没时间和运维资源。所以我给自己留了退路所有关键数据都做了自动化备份到对象存储至少保证“数据不丢”这个底线。服务挂了可以快速重搭数据丢了就真的没法补救了。5.2 数据质量与可观测性的差距初版平台的数据质量保障基本靠“人肉巡检”——每天看任务状态表有没有失败的记录偶尔抽查几个指标值是否合理。这离生产环境的要求差得很远。生产级的平台应该有自动的数据质量规则比如字段非空率、枚举值分布偏移检测、主键唯一性校验一旦指标超过阈值就自动告警并阻止下游任务消费。可观测性方面我们只有一套简单的日志方案和几个基础指标任务耗时、API延迟、错误率。生产环境的服务通常还会做链路追踪Trace和指标大盘Dashboard。这个差距直接体现在了“故障定位速度”上——有一次线上检索变慢我们只能靠猜和反复看日志排查花了两个小时才定位到是pgvector索引失效了。如果当时有执行计划监控这个问题的定位时间是秒级的。5.3 多租户、权限与合规的差距我们平台目前只有内部一个小团队在使用权限控制就是账号密码加角色表。真到了生产环境这会成为硬伤数据访问要按部门、按项目隔离特征和模型有版本权限控制操作要留审计日志。尤其涉及到用户行为数据这类敏感信息合规要求会非常严格。我一直认为权限体系应该是从第一天就埋下设计伏笔的东西哪怕初版不做全量控制也要在数据表设计时预留owner、team这两个字段。否则等到用户规模上来再重构权限付出的代价是巨大的——所有表结构、所有查询接口都有可能要改。5.4 成本与性能的真实账单初版阶段我们投入了大约两周的研发时间硬件成本是一台高配服务器32核CPU、128GB内存、一块不错的GPU卡做向量化推理月租成本大概在几千元。这个投入换来了完整的数据接入链路、50特征任务自动化、百万级向量的检索服务、以及3个模型的统一推理接口。如果换成生产级的K8s集群加全套组件硬件成本至少翻3倍还需要一个专职运维负责日常维护。对当前业务体量来说这种投入是不划算的。所谓“生产差距”有时候不是技术上的差距而是投入产出比的抉择——你要想清楚你的业务阶段需要多少成本和复杂度的支撑。6. 后续演进路线与个人体会6.1 从初版到生产版的增量路径如果这个平台要往生产级演进我会按以下顺序推进而不是一步到位第一步是补高可用。数据库做流式复制加自动故障切换应用服务容器化部署到两台机器上用负载均衡分担流量。这一步解决“挂了就全挂”的问题。第二步是上数据质量监控。引入校验任务每天自动检查核心特征表的关键指标异常就告警。这一步解决“数据错了没人知道”的问题。第三步是完善多租户和权限。把数据访问按团队隔离操作审计日志接入统一日志平台。这一步解决“合规和协作安全”的问题。每一步都可以独立交付且立即可用不需要一次性翻新。这种渐进式路线是我个人比较推崇的演进方式——每一次改动都能快速验证风险可控也容易得到团队和业务方的支持。6.2 一些经验与取舍原则回头看这个初版平台的搭建过程我最有感触的几条经验分享给大家第一架构决策要敢于做减法。很多团队一上来就追新潮技术K8s、Spark、消息队列全堆上去结果是每天在维护基础设施而不是做业务。我的判断标准是这个组件能不能解决当前的实际问题不能解决就不上。后续真需要时在现有架构上做增量演进完全不迟。第二数据的口径一致性比功能的丰富度优先级高。一个计算错的指标比没有这个指标危害大得多。所以数据日期的设计、幂等性的保障、特征对齐的校验这些“不那么酷”的基建反而构成了平台真正的价值。第三给未来的迁移留接口。轻量绝对不是锁死技术栈而是在选型时留意替换成本。比如我们选pgvector时看中的就是它未来可以平滑迁移到独立向量库调度器虽然简陋但接口设计成了标准任务模型换Prefect时只需要改驱动层。这个初版平台到现在已经稳定运行了几个月支撑了两个AI应用的上线。它不完美但它是团队自己一步步趟出来的真实作品每一个决策背后都有明确的理由和踩过的坑。如果你也在规划自己的轻量AI数据平台希望这篇记录能帮你少走一些弯路——架构上的取舍、幂等性的设计、特征对齐的铁律、以及那些别人不会写进文档里的教训都在里面了。