老王经营连锁餐厅“知味轩”十年，最近遇到一个怪事：老客纷纷抱怨“你们家菜口味不稳定”。明明是中央厨房统一送的食材，怎么有的店咸、有的店淡？老王蹲店一周，终于找到根源——中央厨房按“标准菜谱”提前批量备好食材（就像AI训练时离线算好的特征），可是分店厨师接到订单后忙不过来，便凭手感临时换料（线上服务时另算一套特征）。两套做法，菜能一样吗？这个病的学名叫“训练与线上特征不一致”。本文要讲的Tecton，就是给AI特征工程开的“中央厨房标准化管理系统”：统一菜谱（特征定义）、统一加工（特征计算）、统一冷库与保鲜柜（特征存储）、统一出菜口（在线服务）、全程品控巡检（特征监控）。读完你会明白，为什么“特征工程做好容易，上线难”这句话，正在被平台化工具彻底改写。
特征上线是MLOps最贵的隐性成本。理解Tecton这套托管特征平台，你能把训练与服务的特征一致性、实时计算和监控体系一次想透，这是从“会训练模型”走向“能上线模型”的ML工程师必修课。
可视化演示
动态演示Tecton托管特征平台与实的核心机制，通过开始/执行/监控/完成四种模式展示关键概念与交互流程。
本节配有交互动效（进入视口后自动加载，约 3KB）。
Tecton托管特征平台与实：Tect Tecton平台定位：特征即数 实时特征服务架构：在线存储与低 核心机制可视化 Tecton托管特征平台与实整体架构与关键组件
特征上线之痛
老王把中央厨房的标准化食材送往各家分店，头两周口味稳定，客人纷纷点赞。可一个月后，老客开始皱眉：“怎么今天的宫保鸡丁不像上周那味儿？”老王蹲点发现，中央厨房的肉丝是按“标准菜谱批量切配”的，但分店厨师忙不过来时，会随手抓一把冰柜里“早上现买的肉”代替。两批食材规格不同，炒出来的菜自然两个味。
AI线上系统犯着同样的病。训练模型时，算法工程师用“今天凌晨跑批”的特征表训练，拿到满意的AUC；上线部署时，线上服务却要现场实时取用户最新行为拼特征。训练用一套特征，线上用另一套特征，模型一上线效果立刻“拉胯”——不是模型不行，是“食材”变了。
这个病在MLOps圈叫“训练与线上特征不一致”（Training-Serving Skew）。它带来三重痛苦：一是割裂，训练脚本和线上特征服务各自维护一套代码，改一处漏一处；二是偏差，离线特征用历史数据快照，线上特征却总是最新值，两者天然有差距；三是成本，一旦发现不一致，工程师要手动对口径、补数据、重跑训练，每次迭代都提心吊胆。偏差大小可以量化，公式如下。
在老王的厨房里，问题根源就是中央厨房和分店各揣一本菜谱，没人对得上。特征工程同理——不是算特征难，是“两本菜谱”同时维护，迟早翻车。Tecton想解决的，正是这件事。
- 离线特征值$f_{\text{offline}}(t)$ 是训练阶段按历史数据算出的特征值，相当于中央厨房按菜谱批量备好的标准食材。
- 在线特征值$f_{\text{online}}(t)$ 是线上服务时实时算出的特征值，相当于分店接到订单后临时处理的食材。
- 绝对差值$|f_{\text{online}}(t) - f_{\text{offline}}(t)|$ 计算两套做法下同一特征差多远，差得越多，模型“吃”到的料越不一样。
- 归一化百分比$\frac{|f_{\text{online}}(t) - f_{\text{offline}}(t)|}{|f_{\text{offline}}(t)|} \times 100\%$ 把偏差转成相对百分比，便于团队设定统一的容忍阈值（比如超过5%就告警）。
平台核心定位
老王痛定思痛，请来一位餐饮标准化顾问。顾问第一件事：把所有菜谱收上来，统一成电子菜谱，并规定——不管谁做、在哪家店做，配方比例、食材规格、烹饪步骤全按电子菜谱执行。老王的“中央厨房标准系统”上线了。
Tecton就是AI领域的“餐饮标准化顾问加中央厨房系统”。它由前Uber工程师基于Uber内部Michaelangelo平台的经验打造，把特征从“散落在训练脚本里的临时变量”升级为“平台统一管理的资产”。团队通过声明式SDK定义特征，平台自动负责计算、存储、上线和监控，工程师不用再关心底层Spark或Flink集群怎么搭。
Tecton用三类特征视图管理所有特征：BatchFeatureView对应离线跑批，StreamFeatureView对应流式实时，OnDemandFeatureView对应请求时按需计算。工程师只写一份特征定义，平台根据配置自动派发到合适的计算引擎，训练和线上服务共用同一份定义——就像电子菜谱一统天下。一个平台的特征总量可以用下面这个公式表达。
各分店厨师的“手感秘方”被统一电子菜谱取代，口味问题从源头消失。特征平台的价值同理——把“某个工程师脑中的特征逻辑”变成“组织级的工程资产”，新人上手快，团队不再依赖某个“大厨”。
- 离线特征$N_{\text{batch}}$ 是按固定时间窗定时算好的特征，好比提前备好的凉菜，量大、不着急。
- 流式特征$N_{\text{stream}}$ 是事件一到就被窗口算子实时聚合成的新值，好比订单来了才现炒的热菜。
- 按需特征$N_{\text{ondemand}}$ 是只有线上请求触发时才现场计算的特征，好比客人有特殊忌口时厨师单独特制。
- 总量公式$N_{\text{total}} = N_{\text{batch}} + N_{\text{stream}} + N_{\text{ondemand}}$ 说明平台要把三类特征统一纳管，缺一类都不完整。
实时特征计算
老王的标准化系统里有一道招牌菜“火焰虾”，必须客人下单才现炒——提前做好就老了，这对应AI里的“实时特征”。用户的每一次点击、滑动、下单，就像客人不断加菜，特征必须跟着这些事件实时“刷新”。
Tecton的StreamFeatureView基于流式计算引擎，事件一进入Kafka等消息队列，窗口算子立刻聚合出新值并写入在线存储。线上推理服务通过点查API，毫秒级拿到最新特征值，让模型“看到”用户刚刚发生的行为。
最常用的实时计算是滑动窗口聚合——只统计最近W秒内的事件。窗口随当前时刻t不停前移，旧事件滑出，新事件滑进，聚合值连续更新。这里有个关键点：按“事件时间”（事件真实发生时刻）而非“到达时间”归窗，避免网络延迟造成时间错位。滑动窗口均值的公式如下。
火焰虾的“窗口”就是“最近5分钟下的单”，时间一到，旧订单自动滑出窗口。实时特征服务让模型永远吃上“最新鲜的食材”，而不是仓库里放了三天的冻货。
- 窗口条件$i:\ t_i \in [t-W,\ t]$ 表示只挑最近W秒内发生的事件，好比后厨只统计“最近5分钟下的单”。
- 事件值$x_i$ 是第i个事件携带的数值，比如一次点击的计数值或一笔消费的金额。
- 求和$\displaystyle\sum_{i:\ t_i \in [t-W,\ t]} x_i$ 把窗口内所有事件值累加，得到这段窗口的总量。
- 取平均$\frac{1}{n}\displaystyle\sum_{i:\ t_i \in [t-W,\ t]} x_i$ 除以事件个数n，得到“最近W秒平均每个事件的强度”，这就是在线模型拿到的实时特征。
特征存储设计
老王的中央厨房有两套仓储：大冷库储量足、便宜、但取货慢，适合囤“月销千份”的招牌菜用料；出菜口旁的保鲜柜体积小、取货快，只放“当天就要用”的配料。Tecton的特征存储也这样分层。
离线特征存储对应大冷库，用对象存储或数据湖存放全量历史特征快照，容量大、成本低，供训练时全表扫描和历史回放。在线特征存储对应保鲜柜，用高性能键值库（如DynamoDB、Redis），支持按实体ID点查，延迟毫秒级，供线上推理时实时取用。
Tecton在线存储支持多种后端，并区分“数据新鲜度”：有的特征分钟级更新就够，有的需要秒级。平台还提供统一特征仓库，记录每个特征的定义、来源、血缘关系与下游使用方，像菜谱旁的食材档案卡。新鲜度可以量化，衡量特征值多久没被刷新。
冷库不能放在出菜口，保鲜柜也塞不下整头猪。特征存储设计就是让“对的数据在对的位置、以对的速度上桌”——训练要全量历史，服务要单点极速，两者各得其所，谁也别拖累谁。
- 当前时刻$t_{\text{now}}$ 是线上系统当前时间，相当于厨师看表的“现在几点了”。
- 更新时间$t_{\text{last\_update}}$ 是该特征值最后一次被成功刷新的时间，好比食材包装上贴的“入库时间”。
- 差值$\text{staleness}(t) = t_{\text{now}} - t_{\text{last\_update}}$ 算出特征多久没更新了。冷库里的冻货放一个月没问题，保鲜柜里的鲜肉放一天就变质——不同特征能容忍的新鲜度完全不同。
一致性保障
电子菜谱统一后，老王又发现新问题：中央厨房备菜和分店出菜有时差。中午11点备的肉丝，下午3点客人点餐时已不新鲜；分店临时补货的肉丝，规格又和中央厨房不一样。客人尝出来的还是“两个味”。要让训练和线上口味一致，必须“同一时刻、同一规格、同一菜谱”。
Tecton给出的方案是“时间旅行”与“点查快照”。训练时，平台为每个训练样本回放业务发生时刻 t0 的特征快照；线上服务时，模型读到的也是按同一 t0 语义计算出来的值。训练和线上用的是同一把“时间尺子”。
具体实现上，离线训练时对每个（实体ID，时间戳）做点查，查到的就是那一刻该实体的特征状态；线上则把请求时间当作 t0，从在线存储取同一计算逻辑的最新值。因为计算逻辑出自同一份特征定义，两边差异只来自“数据是否已经到达”，系统性偏差被压到最小。点查快照的数学表达如下。
老王要求中央厨房按订单时间“回放”备料——客人3点下单，就按3点的食材标准备，而不是拿11点备好的货凑数。Tecton的时间旅行，就是给特征系统装了一台“时间录像机”，训练时录下、线上重放，两边严丝合缝。
- 点查动作$\text{Lookup}(\text{FeatureView},\ t_0)$ 是按“实体ID + 时间戳”从特征视图中取历史状态，好比到档案室按编号取某一天的采购单。
- 特征视图$\text{FeatureView}$ 是Tecton里定义特征的计算逻辑与数据来源，相当于统一菜谱中的“一道菜的做法”。
- 等号含义$f_{\text{train}}(t_0) = \text{Lookup}(\text{FeatureView},\ t_0)$ 说明训练样本的特征值来自 t0 时刻的快照，线上推理时也按同一 t0 查同一视图，两个值天然对齐。
监控告警体系
系统上线后，老王做了件以前从没做的事：给各分店配了品控巡检员。每天抽查菜品口味，记录咸淡轻重，一旦偏离标准就立刻调整。他明白，不能等客人投诉才救火——那已经晚了。
特征平台同样需要“品控巡检”。Tecton的监控体系覆盖三类指标：数据质量（新鲜度、空值率、异常值占比）、服务健康（在线点查延迟、错误率、缓存命中率）、分布漂移（线上特征分布与训练基线的偏离程度）。
分布漂移常用“群体稳定性指标”（PSI）量化。把特征值分成k个桶，比较线上当前分布 p_i 和训练基线分布 q_i 在每个桶的占比差异，加权求和。PSI小于0.1算健康，0.1到0.25需要关注，大于0.25就要拉响警报。除了告警，Tecton还能自动记录特征血缘，出问题时快速定位是哪个上游数据源变了。PSI的计算公式如下。
品控巡检员不是等客人说咸才动手，而是每天主动测盐度。特征监控同样把“模型悄悄变差”的隐性风险变成“可量化的预警信号”，让ML团队从被动救火变成主动防控。
- 分桶数$k$ 是把特征值取值范围切成的桶个数，桶分得越细，分布刻画越精确。
- 线上占比$p_i$ 是当前线上特征值落入第 i 桶的样本比例，好比今天各分店实际出菜的咸度分布。
- 基线占比$q_i$ 是训练基线特征值落入第 i 桶的样本比例，好比标准菜谱规定的咸度分布。
- 逐桶累加$(p_i - q_i) \times \ln\frac{p_i}{q_i}$ 计算每个桶的分布差异，把所有桶的差异累加起来就是总漂移量。
落地实战指南
老王把标准化系统推向全部7家分店时，没有一步到位。他的做法是：先在1家店试运行两周，旧方法和新系统双轨并行，对比每天的退菜率和客流，确认新系统更好，才逐步切到全家店。
Tecton落地同样讲究“灰度渐进”。第一步离线回放：用平台把过去90天的历史数据重新计算结果，与现有特征表逐一比对，确认偏差在容忍范围；第二步影子验证：线上请求同时走旧管道和新特征服务，对比特征值差异；第三步逐步切流：5%、20%、50%、100%，每步观察模型指标和监控告警。
性能优化上常用三板斧：在线存储加缓存层（热实体命中后省去重复计算）、窗口聚合做预聚合减少计算量、特征按新鲜度需求分优先级缓存。常见踩坑也值得记：事件时间与到达时间混淆导致窗口错位、时区不一致让“7天窗口”变成“6天21小时”、流式任务重启后状态丢失造成特征空洞。整个服务的性能约束可以用延迟预算表达。
老王的经验是——开分店不难，难的是让所有分店保持同一水准。Tecton的落地实践核心就是“先证明、再扩散、全程盯”。对每个要上特征平台的团队，这条路都适用：从回放验证开始，让数据说话，再交给系统托管，最终把特征工程从“玄学”变成“基建”。
- 计算耗时$L_{\text{compute}}$ 是特征计算花的时间，包括窗口聚合和按需计算的算力开销。
- 存储耗时$L_{\text{storage}}$ 是从在线存储取特征的时间，缓存命中时极短，未命中时可能跨网络拉取。
- 网络耗时$L_{\text{network}}$ 是服务间调用与数据传输的传输开销，链路越长延迟越高。
- 预算约束$L_{\text{total}} \le L_{\text{SLA}}$ 把三段延迟相加后必须小于等于SLA约定值，超了就说明特征链路存在瓶颈。
AI 应用场景
实时推荐系统的特征服务
阶段：特征服务（在线推理前的特征准备）
解决的问题：用户兴趣变化极快，刚浏览过商品A，推荐结果必须立刻感知。传统做法要分别维护离线和实时两套特征代码，不仅工作量大，还经常出现“训练用的特征和线上用的特征对不上”的问题。
具体案例：某电商App用Tecton把“用户最近1小时浏览的商品类目分布”“最近3天点击率滑动均值”定义为流式特征。用户点击事件进入Kafka后，Tecton的流式窗口算子在秒级完成聚合，写入在线特征存储。推荐服务在20毫秒内通过点查API拿到最新特征，模型实时感知用户兴趣变化，点击率提升了12%。
金融风控的毫秒级特征计算
阶段：实时特征计算与特征一致性保障
解决的问题：欺诈交易发生在电光石火之间，风控模型需要“请求发生时”的最新特征；同时训练风控模型时，又必须回放历史时刻的精确快照，否则模型学到的规律和线上实际用到的特征不一致。
具体案例：某支付平台把“设备当日交易金额累计”“IP地址历史频次”“用户行为序列熵”做成OnDemand按需特征，交易请求到达时现场计算，50毫秒内返回给风控模型。因为Tecton的训练和线上共用同一份特征定义，离线回放验证时偏差率仅1.2%，模型上线后AUC比旧方案提升了3个百分点，欺诈拦截率明显提高。
Python 演示
# -*- coding: utf-8 -*-"""Tecton特征平台核心操作模拟: 离线训练+在线点查+一致性校验.""" import randomimport time class FeatureStore: """特征存储: 保存离线训练特征和在线实时特征.""" def __init__(self): self.online_table = {} self.offline_table = {} self.update_time = {} def batch_write(self, entity_id, feature_map): """离线批量写入: 模拟训练前的批量特征计算.""" for name, value in feature_map.items(): key = (entity_id, name) self.offline_table[key] = value self.online_table[key] = value self.update_time[key] = time.time() def stream_update(self, entity_id, feature_name, value): """流式更新: 模拟线上实时特征计算.""" key = (entity_id, feature_name) self.online_table[key] = value self.update_time[key] = time.time() def online_lookup(self, entity_id, feature_name): """在线点查: 线上服务实时读取特征.""" key = (entity_id, feature_name) return self.online_table.get(key) def offline_lookup(self, entity_id, feature_name): """离线点查: 训练时读取特征快照.""" key = (entity_id, feature_name) return self.offline_table.get(key) def consistency_check(self, entity_id, feature_name, tolerance=0.05): """一致性校验: 对比线上线下特征值, 相对偏差须小于容忍度.""" online_val = self.online_lookup(entity_id, feature_name) offline_val = self.offline_lookup(entity_id, feature_name) if offline_val is None or abs(offline_val) < 1e-9: return True deviation = abs(online_val - offline_val) / abs(offline_val) return deviation <= tolerance def staleness(self, entity_id, feature_name): """新鲜度检查: 返回特征距上次更新的秒数.""" key = (entity_id, feature_name) return time.time() - self.update_time.get(key, 0) def main(): store = FeatureStore() store.batch_write("user_001", {"total_spend_7d": 1280.5}) for _ in range(5): new_amount = random.uniform(50, 300) store.stream_update("user_001", "total_spend_7d", new_amount) time.sleep(0.01) offline_value = store.offline_lookup("user_001", "total_spend_7d") online_value = store.online_lookup("user_001", "total_spend_7d") print("线下训练时特征值: %.2f" % offline_value) print("线上服务时特征值: %.2f" % online_value) print("一致性校验通过: %s" % store.consistency_check("user_001", "total_spend_7d")) print("特征新鲜度: %.2fs" % store.staleness("user_001", "total_spend_7d")) if __name__ == "__main__": main()
self.offline_table[key] = value离线表保存训练时看到的特征值，像是中央厨房的备菜记录，写好了就不再改动。self.online_table[key] = value同步写入在线表，让训练和服务从同一初始值起步，保证“开局一致”。store.stream_update("user_001", "total_spend_7d", new_amount)模拟新消费事件到达后实时特征被刷新，对应Tecton的流式特征计算。deviation = abs(online_val - offline_val) / abs(offline_val)一致性校验的核心，正是正文中的Deviation偏差公式。print("一致性校验通过: %s" % store.consistency_check(...))线上更新几次后偏差超出5%容忍度，校验就会失败，这就是“训练服务不一致”的直观缩影。return time.time() - self.update_time.get(key, 0)新鲜度计算逻辑，对应Tecton监控中的 staleness 指标。
常见误区
误区我以为特征一致性就是让线上特征值和训练时算好的特征值严格相等，最好把训练时的特征文件复制一份放到线上查询库，一劳永逸。
正解训练和线上永远不可能完全相等，因为时间在前进。训练用的是历史快照，线上请求发生时新数据已经到达，特征值自然会更新——更新本身不是错误。真正的一致性是指“同一业务时刻、同一计算逻辑、同一份特征定义”下取值一致。Tecton用时间旅行点查快照保证两边按同一 t0 取值，剩下的偏差只是“数据是否已到达”的正常差异。
为何常见：大家直觉认为“相同”就是“一致”，忽略了时间维度。科普文章常把一致性画成两条完全重合的线，更强化了这个误解。
误区做实时特征服务，数据刷新频率当然是越快越好，最好每秒都重算，这样模型预测一定最准。
正解实时性是有成本的：流式计算资源、在线存储压力、请求链路延迟都会随刷新频率上升。而且训练用的如果是“过去7天累计消费”这种长窗口特征，线上每秒刷新对预测能力的提升微乎其微。正确做法是按业务语义决定新鲜度：风控需要秒级、推荐偏好分钟级足够、用户画像统计类特征天级也行。
为何常见：人们容易把“实时”当作技术先进性的象征，而不是业务需求驱动的手段。实际上“刚好够用”的新鲜度才是工程上最优的选择。
误区我觉得Tecton就是一个特征数据库嘛，把算好的特征存进去，线上查询快一点而已，和Redis加个封装没区别。
正解存储只是平台的一个环节。Tecton涵盖特征定义（声明式SDK）、计算编排（离线/流式/按需调度）、存储（在线+离线+血缘）、服务（点查API）、治理（监控告警、回放验证）全链路。类比中央厨房：菜谱定标、食材采购、预处理、保鲜、出菜、品控一条龙，而不是只多了一个保鲜柜。
为何常见：很多文章把特征平台简化为“在线特征存储”，让人只见树木不见森林。实际工作中，计算编排和一致性治理才是平台价值的重头戏。
误区特征服务上线后，监控和普通后端服务一样，盯着P99延迟、错误率和CPU使用率就够了。
正解服务健康监控只是“保命”，特征质量监控才是“救命”。特征可能静默地坏掉：上游数据延迟、窗口聚合结果稀疏、特征分布漂移——模型不会报错，AUC却在悄悄下跌。Tecton的监控体系专门盯特征新鲜度、空值率、PSI分布漂移等数据质量指标，这些指标异常往往是模型效果滑坡的早期信号。
为何常见：后端监控的惯性思维。特征数据异常不像接口500那样明显，出错时不报错，只会让模型悄悄变笨，所以特别容易被忽视。
面试题
Q1. Tecton的核心定位是什么？
- A.数据可视化报表工具
- B.全流程托管特征平台← 正确答案
- C.分布式模型训练框架
- D.开源特征数据库系统
答案：B。Tecton是托管特征平台，覆盖特征定义、离线与实时计算、在线存储、服务与监控全链路，不是可视化工具、训练框架或单纯的数据库。它更像中央厨房的整体管理系统，而非其中某一个设备。
Q2. 下列哪项最能体现“特征一致性”？
- A.线上与线下特征名称一致
- B.同一业务时刻取值一致← 正确答案
- C.特征类型统一成浮点数
- D.特征文件存放在同一处
答案：B。特征一致性的核心是“同一业务时刻、同一逻辑、同一份定义”下取值一致。名称、类型、存放位置都是一致性的辅助条件，真正的关键是时间维度上的取值对齐，这正是时间旅行点查快照要解决的问题。
Q3. 在线特征服务通常采用哪种读取方式？
- A.按实体ID进行点查读取← 正确答案
- B.批量扫描全表后过滤
- C.全表JOIN再计算指标
- D.流式读取全部特征值
答案：A。在线推理时，特征服务按请求中的实体ID做点查（lookup），毫秒级返回单个或少量实体的特征值。批量扫描和全表JOIN适合离线训练场景，流式读取全部特征值对单次请求来说既不必要也不现实。
Q4. PSI（群体稳定性指标）主要用于监控什么？
- A.特征整体分布漂移← 正确答案
- B.模型参数量的变化
- C.特征存储的容量大小
- D.网络请求的时延变化
答案：A。PSI把特征当前分布与训练基线分布逐桶对比，量化分布漂移程度。它监控的是“特征分布是否变了”，而不是参数规模、存储容量或网络延迟。PSI超过0.25说明特征漂移严重，模型可靠性大打折扣。
Q5. Tecton上实时特征计算的常用模式有哪些？
- A.固定时间窗口聚合← 正确答案
- B.滑动时间窗口聚合← 正确答案
- C.请求触发式按需计算← 正确答案
- D.全量重算历史特征
答案：ABC。实时特征计算包括固定窗口聚合（每5分钟算一次）、滑动窗口聚合（随当前时刻连续滚动）和OnDemand按需计算（请求到来现场算）。全量重算历史特征是离线批处理的模式，不是实时特征计算的做法。
Q6. 下列哪种情况最容易导致训练与线上特征不一致？
- A.线上请求时用最新数据特征← 正确答案
- B.训练线上共用同一特征函数
- C.特征名在两边完全保持一致
- D.所有特征都来自离线特征表
答案：A。线上请求时用最新数据计算特征，训练时却用历史快照，两边取值天然错位，这是最常见的偏差来源。共用同一特征函数、特征名一致、全部来自离线表都是避免不一致的正确做法。Tecton用时间旅行让两边按同一时刻取值，正是为了治这个病。
Q7. 特征新鲜度衡量的是什么？
- A.特征值的刷新时间间隔← 正确答案
- B.特征值的绝对数值大小
- C.特征名字符串的长短
- D.特征文件数量的多少
答案：A。新鲜度衡量特征值距上次成功更新的时间间隔，间隔越长越“不新鲜”。它和特征值的数值大小、名字长短、文件数量都没有关系。监控新鲜度是为了及时发现“特征停更”这类静默故障。
Q8. 特征平台监控中，属于“数据质量类”指标的有哪些？
- A.特征新鲜度超阈值告警← 正确答案
- B.特征值空值率异常升高← 正确答案
- C.特征分布发生显著漂移← 正确答案
- D.在线存储CPU使用率过高
答案：ABC。数据质量类指标关注特征本身是否健康：新鲜度是否达标、空值率是否异常、分布是否漂移。CPU使用率属于服务基础设施监控，不属于数据质量范畴。数据质量类指标出问题时常不报错，需要主动监控才能发现。
Q9. 时间旅行（Time Travel）主要解决什么问题？
- A.提升在线特征查询速度
- B.训练线上按同时刻取值← 正确答案
- C.压缩特征存储的空间
- D.自动修复特征值缺失
答案：B。时间旅行让训练时能回放任意历史时刻的特征快照，线上服务时按同一业务时刻语义取值，两边共用一把“时间尺子”。它解决的是训练与线上取值时间不一致的问题，与查询速度、存储压缩、缺失修复无关。
Q10. 特征平台上线的良好实践有哪些？
- A.先离线回放验证再上线← 正确答案
- B.上线后持续监控特征质量← 正确答案
- C.跳过测试直接全量切换
- D.灰度对比新旧特征效果← 正确答案
答案：ABD。上线前先离线回放验证新旧特征一致性，上线后持续监控特征质量，切换时用灰度逐步对比新旧特征效果，都是稳妥做法。跳过测试直接全量切换风险极高，一旦特征有问题，线上模型会立刻“翻车”。