FDE-Wiki

主题

#数据工程#MLOps#RAG#项目交付

专题定位:行业里有句话——"企业 AI 项目 70% 的工作量在数据工程"。这不是夸张。本专题讲 FDE 在客户现场面对的真实数据工程挑战,以及如何用工程化方法搞定它们。

一、为什么数据工程占 70% ​

模型是现成的(开源/国产),prompt 可以调,但客户的真实数据,是 FDE 必须亲手处理的"烂泥潭":

  • 散:数据散落在几十个系统(ERP/CRM/HIS/MES/Excel/纸质);
  • 脏:缺失、错误、重复、不一致、格式混乱;
  • 乱:同一概念多个口径,主数据不统一;
  • 封:老系统没 API,只有数据库直连或导出文件;
  • 险:敏感数据要脱敏,权限要管控;
  • 变:业务变化,数据口径随之变化。

FDE 的现实判断:一个客户项目,把数据理顺、接通、质量达标,往往就耗掉大半工期。模型反而是最后几步。忽视数据工程的 FDE,必然在现场翻车。

二、数据接入:批、流、多源 ​

批处理(Batch)

  • 定时从源系统抽数(每日/每小时);
  • 工具:Spark、Pandas(小数据)、DataX、Sqoop;
  • 适合:不需要实时的场景。

流处理(Streaming)

  • 实时捕获数据变更(CDC);
  • 工具:Flink、Kafka Streams、Debezium(CDC);
  • 适合:实时风控、实时监控、实时推荐。

多源接入的挑战

  • 不同系统协议各异(JDBC/REST/文件/MQ);
  • 增量识别(怎么知道哪些变了);
  • schema 演进(源系统加字段);
  • 抽取压力(不能把源系统拖垮)。

可照抄(CDC 增量同步,企业常用):

源数据库 → Debezium(捕获 binlog 变更)→ Kafka → Flink(清洗转换)→ 目标库/特征平台

三、数据清洗:脏数据处理实战 ​

常见脏数据与处理

  • 缺失值:删除/填充/标记;
  • 重复:去重(基于主键/模糊匹配);
  • 格式不一致:统一(日期、电话、地址);
  • 错误值:规则/统计识别并修正;
  • 异常值:箱线图/孤立森林识别;
  • 编码问题:GBK/UTF-8 转换。

清洗的工程化

  • 规则可配置(而非硬编码);
  • 清洗日志(改了什么,可追溯);
  • 可重跑(幂等);
  • 质量度量(清洗前后质量对比)。

FDE 的经验:清洗规则本身是"业务知识"——比如"这个字段为 0 表示未填,不是真的 0"。这些知识要从客户业务人员那里挖出来,沉淀成规则。

四、特征工程:把数据变成模型可用的特征 ​

特征工程是 ML 的核心环节(风控、推荐等场景)。

特征类型

  • 统计特征:均值、方差、计数、比率;
  • 时序特征:滞后值、滑动窗口、趋势;
  • 频域特征:对振动/声音信号做 FFT;
  • 交叉特征:字段组合;
  • 嵌入特征:用模型把类别/文本转向量。

特征平台(Feature Store)

  • 统一管理特征定义、计算、服务;
  • 保证训练与推理特征一致(避免 training-serving skew);
  • 工具:Feast、Tecton、自建。

特征工程的工程化

  • 特征版本化;
  • 特征血缘(这个特征怎么算的);
  • 特征监控(分布漂移)。

五、数据质量监控:让数据"可信" ​

数据质量是 AI 的生命线——垃圾进,垃圾出。

数据质量维度

  • 完整性:该有的有没有;
  • 准确性:对不对;
  • 一致性:多源是否一致;
  • 时效性:新不新;
  • 唯一性:有没有重复;
  • 合规性:敏感数据处理对不对。

监控工具

  • Great Expectations:声明式数据质量断言;
  • Soda:数据质量监控;
  • Deequ(AWS):大规模数据质量。

监控实践

  • 数据管道每步加质量检查;
  • 不达标阻断/告警;
  • 质量看板(可视化数据健康度)。

可照抄(Great Expectations 质量检查):

python
import great_expectations as gx
df = ...  # 客户数据
# 期望:某字段非空率 > 95%,值在 [0,100]
# 不达标 → 告警/阻断下游

六、增量同步:百万级数据不能全量重建 ​

全量重建对百万级数据不可行,必须增量。

增量策略

  • 基于 CDC(binlog 变更);
  • 基于时间戳(updated_at);
  • 基于版本号;
  • 基于哈希对比。

增量到向量库(RAG)

  • 文档变更 → 重新切分/嵌入 → 更新对应向量;
  • 用文档哈希判断变更;
  • 删除/修改/新增分别处理;
  • 不能全量重建(太慢太贵)。

七、数据治理:分级、血缘与合规 ​

数据治理是 FDE 在强监管行业的必修课。

数据分级分类

  • 按敏感度(公开/内部/敏感/机密);
  • 决定存储/传输/访问/脱敏方式。

数据血缘(Data Lineage)

  • 记录数据"从哪来、经过什么处理、到哪去";
  • 用于影响分析、问题追溯、合规审计;
  • 工具:Apache Atlas、OpenLineage、自建。

合规

  • 个保法/数安法/等保;
  • 敏感数据脱敏;
  • 数据不出域;
  • 访问审计。

八、数据工具栈(2026 生产级) ​

批处理:Spark、Dask、Pandas; 流处理:Flink、Kafka、Debezium; 编排:Temporal、Prefect、Airflow; 转换:dbt(SQL 转换); 特征:Feast、Tecton; 质量:Great Expectations、Soda; 血缘:Apache Atlas、OpenLineage; 向量库:Milvus、Qdrant; 时序:InfluxDB、TDengine。

Stord FDE JD 明确要求 Temporal/Prefect/Airflow 经验——这印证数据编排是 FDE 核心技能。

九、客户现场的数据工程真实挑战 ​

挑战一:源系统没接口

  • 老旧 ERP/MES 只有数据库或导出文件;
  • FDE 要写各种适配器"抠"数据。

挑战二:口径不一致

  • 同一个"客户数",销售/财务/运营各算各的;
  • FDE 要拉通对齐口径(这往往涉及政治)。

挑战三:数据所有权

  • 数据分散在不同部门,谁都不愿给;
  • FDE 要协调(这考验软技能)。

挑战四:数据质量超预期地差

  • demo 时数据漂亮,真实数据一塌糊涂;
  • FDE 要边清洗边推进。

挑战五:实时性 vs 成本

  • 客户要实时,但实时管道成本高;
  • FDE 要权衡(准实时可能够)。

十、数据工程的 FDE 价值 ​

为什么 FDE 必须懂数据工程

  • 数据是 AI 的地基,地基不行 AI 白搭;
  • 数据工程占 70% 工作量,不懂就被困住;
  • 数据工程的"业务知识"(口径、规则)正是 FDE 的差异化;
  • 客户买的是"跑通的系统",而系统跑通的前提是数据通。

判断:一个不懂模型但精通数据工程的 FDE,在现场比一个精通模型但不懂数据的 FDE 更有用。这是反直觉但真实的。

本专题小结 ​

  • 数据工程占企业 AI 70% 工作量,客户的真实数据是烂泥潭;
  • 接入:批(Spark)/流(Flink+CDC)/多源,增量同步是关键;
  • 清洗:缺失/重复/格式/异常/编码,规则可配置+可追溯+幂等;
  • 特征工程:统计/时序/频域/交叉/嵌入,特征平台防 training-serving skew;
  • 质量监控:完整性/准确性/一致性/时效性,GX/Soda 每步检查;
  • 增量:CDC/时间戳/哈希,RAG 向量增量更新;
  • 治理:分级/血缘/合规,Atlas/OpenLineage;
  • 工具栈:Spark/Flink/Temporal/dbt/Feast/GX/Milvus;
  • 现场挑战:无接口/口径不一/所有权/质量差/实时成本;
  • FDE 懂数据工程比懂模型更实用。

本专题来源:Spark/Flink/dbt/Great Expectations/Temporal 文档、Stord FDE JD、用户库《FDE工程化工具链》《fde-delivery 30-engineer/120-deployment-runbook》、本书第 9 章。

本站由原始 Markdown 调研报告自动构建 · 原文未改动

FDE 调研报告 (2026)