1. 特征平台概述：它到底是什么？
先说说我自己的理解。特征平台，说白了就是一套专门管理机器学习特征的系统。你想想看，一个模型从开发到上线，最耗时间的往往不是调算法，而是准备特征数据。我见过太多团队，80%的时间都花在写特征脚本、跑数、对口径上——这就是典型的「特征债」。
特征平台要解决的核心问题就三个：特征怎么存、怎么算、怎么用。它把特征从模型代码里抽出来，变成一个可复用、可管理、可监控的资产。嗯，这里要注意，它不是简单的特征存储，而是一整套生命周期管理方案。
1.1 特征平台在MLOps中的定位
MLOps 全流程里，特征平台处在中间层。左边连着数据工程，右边服务模型训练和推理。我个人习惯把它比作「特征的」——数据源进来，经过加工变成特征，再分发给不同的模型消费。
关键定位：特征平台是MLOps中连接数据工程与模型工程的桥梁，负责特征的统一生产、存储、分发和监控。
我在项目中遇到过一种典型场景：推荐团队和搜索团队各自维护一套特征代码，同样的用户点击率特征，两边算出来的值不一样。业务方来质问，两个团队互相甩锅。后来上了特征平台，所有特征统一注册、统一计算、统一输出，这种扯皮的事就再没发生过。
特征平台在MLOps里的具体职责，我列了个表：
| MLOps阶段 | 特征平台职责 | 常见问题（无平台时） |
|---|---|---|
| 数据准备 | 特征定义、特征回溯、数据校验 | 特征口径不统一，回溯数据对不上 |
| 模型训练 | 在线/离线特征获取、特征拼接 | 训练时缺特征，临时补数耽误上线 |
| 模型部署 | 特征服务、特征一致性校验 | 离线特征和在线特征不一致，模型效果崩 |
| 模型监控 | 特征质量监控、特征分布漂移检测 | 特征异常没人知道，模型悄悄退化 |
1.2 核心功能
特征平台的核心功能，我总结为「五件套」：
- 特征注册与管理——每个特征有唯一ID、元数据、Owner。我曾经接手过一个没有特征管理的项目，光梳理特征依赖就花了两周。
- 特征计算与存储——支持离线批处理和实时流计算，存储层要同时服务高吞吐的离线读取和低延迟的在线读取。
- 特征分发与 Serving——通过API或SDK对外提供特征服务，延迟通常要求在10ms以内。
- 特征回溯——能按历史时间点重新计算特征，用于模型回测和离线评估。
- 特征监控与告警——监控特征新鲜度、空值率、分布变化，异常时自动告警。
避坑指南：我曾经在一个项目里只做了前三个功能，忽略了监控。结果上线后某个特征源挂了三天，模型一直在用旧特征做推理，业务指标掉了15%才被发现。从那以后，我把监控放到了和存储同等重要的位置。
1.3 架构组件
一个典型的特征平台架构，从上到下大概分这么几层：
- 接入层：接收特征注册请求、特征查询请求，做鉴权和限流。
- 计算层：包含离线计算引擎（Spark/Flink批处理）和实时计算引擎（Flink流处理）。
- 存储层：离线存储（Hive/Iceberg）、在线存储（Redis/HBase）、混合存储（TiKV）。
- 服务层：提供高可用的特征Serving API，通常用gRPC或HTTP。
- 监控层：采集特征质量指标，对接Prometheus/Grafana。
下面这张图是我自己画的架构示意，你可以对照着看：
各组件之间的交互逻辑，我简单说一下：
- 用户通过接入层注册特征，系统把特征元数据写入存储层，同时触发计算层生成特征数据。
- 模型训练时，通过服务层拉取离线特征；模型推理时，通过服务层拉取在线特征。
- 监控层定时扫描特征存储，检查新鲜度和质量，异常时触发告警。
注意：架构设计时最容易犯的错是把所有功能揉到一个组件里。我见过有人把特征计算和特征服务放在同一个进程里，结果计算任务把CPU打满，线上推理请求全部超时。记住，计算路径和服务路径一定要物理隔离。
1.4 为什么运维同学要懂这些？
你可能会问，我搞运维的，知道特征平台是啥就行了，干嘛要了解架构细节？
原因很简单：特征平台的故障，往往不是单一组件的问题。比如特征延迟变高，可能是计算层资源不足，也可能是存储层热点，还可能是网络带宽打满。不懂架构，你连排查方向都找不到。
我记得有一次线上告警，特征Serving延迟从5ms飙到500ms。我第一反应是查Redis，结果Redis负载正常。后来顺着链路往下查，发现是Flink任务反压，导致特征数据没及时写入在线存储，服务层一直在等数据。如果我不了解整个链路，可能还在Redis上浪费时间。
所以，这门课后面的内容，我会带着你从架构的每个组件入手，把常见的故障场景和排查方法讲透。嗯，准备好了吗？