FDE Training · Module 08

08

数据链路与可观测性

模块 08 · 数据链路与可观测性

本章目标：让客户 AI 系统上线稳定、出问题看得见、花多少钱算得清。分三块：数据管道（怎么把客户数据喂进来）、监控告警（出啥事第一时间知道）、成本观测（大模型 token 烧多少、怎么控）。

8.1 数据管道：ETL / ELT

8.1.1 为什么 FDE 要管数据

客户那堆原始数据（Excel、数据库、日志、文档）不会自己变成 AI 能用的。你要做：抽（Extract）→ 转（Transform）→ 载（Load），也就是 ETL。

对比两个词：

ETL：先"转"再"载"（数据量大、复杂加工时常见，先算好再入库）。
ELT：先"载"再"转"（现代数仓用，先原样倒进去再在库里处理，更灵活）。

8.1.2 一次典型的客户数据接入

抽取：连接客户数据库 / 读 CSV / 读对象存储 / 接日志。
清洗：去重、补空、规范日期、修编码、去掉敏感冗余。
转换：算字段、拆表、映射字段名、脱敏（配合模块 07）。
装载：写入你的数据库 / 向量库。

import pandas as pd

def etl_orders(raw_path, out_path):
    df = pd.read_csv(raw_path)
    df = df.drop_duplicates(subset=["order_id"])       # 去重
    df["amount"] = df["amount"].fillna(0)              # 补空
    df["date"] = pd.to_datetime(df["date"], errors="coerce")  # 规范日期
    df = df[df["date"].notna()]                         # 丢脏数据
    df.to_parquet(out_path)

8.1.3 数据质量是大前提（AI 项目尤其）

客户常说"数据我都有"，但实际脏乱差。进模型的脏数据 = 模型学脏、答得脏。
一定要有数据质量校验：跑之前查空值率、重复率、格式错例，出一份质量报告给客户看。
清洗规则的坑：改对了字段却把业务含义改错——要客户业务确认映射。

（提一句：高吞吐/复杂场景会用到 Flink/Spark，但 FDE 先掌握 pandas/db/脚本清洗就能处理绝大多数现场数据。）

8.2 监控告警：Prometheus / Grafana，日志 ELK/Loki

8.2.1 三类可观测性（面试必背）

Metrics（指标）：数字——请求数、延迟、错误率、GPU 用率。
Logs（日志）：一条条记录——出错细节。
Traces（链路）：一次请求跨服务的完整路径。

指标看趋势，日志查细节，链路串全貌。 三者结合才能定位。

8.2.2 一套最务实的落地

Prometheus 抓指标 + Grafana 画仪表盘，是开源标配。
日志：收集进 ELK(ES/Logstash/Kibana) 或 Loki。
你也可以"轻量起步"：所有服务打印结构化日志（JSON）到统一文件 → 定时扫 → 告警。先跑起来，再上全套。

8.2.3 指标定义：AI 项目特有的一套（重点）

除了通用（延迟、错误率、QPS），AI 项目要盯：

P95 延迟：大多数请求多久返回（别只看平均，P95 更能反映体验和卡顿）。
错误率：接口/模型调用失败占比。
Token 成本：每请求平均 token、总消耗（见 8.3）。
召回率：RAG 检索命中的质量（配合模块 06）。
GPU 利用率 / 显存：模型服务资源是否吃紧。

8.2.4 告警别乱设

阈值要合理：一有波动就告警会"狼来了"，没人看。
分级：P0 服务挂 → 立刻告警；P2 磁盘剩 30% → 提前预警。
每条告警要能定位：带服务名、请求 id、日志入口。

8.3 成本观测：大模型 token 是钱（客户最敏感）

8.3.1 为什么单独立一节

大模型按 token 计费，跑起来烧钱是真金白银。客户最常问 FDE 的问题之一就是"这个月模型花了多少钱、花到哪了"。你必须能答清。

8.3.2 做三件事

用量统计：每次调用记录 model、输入token、输出token、用户/租户、时间。
成本归因：能按"用户、部门、功能、租户"拆账，知道钱花哪了。
用量限流 & 告警：超预算自动限流/提醒，防止失控。

def record_usage(user, model, in_tok, out_tok):
    cost = in_tok * PRICE_IN[model] + out_tok * PRICE_OUT[model]
    log_event("llm_usage", user_id=user, model=model,
              in_tokens=in_tok, out_tokens=out_tok, cost=round(cost, 4))
    # 也可以写入 DB/时序库，供日报/月报和告警统计

8.3.3 省钱的工程手段（面试加分）

缓存命中：相同/相似问题直接读缓存（模块 01 Redis）。
压缩上下文：只带必要历史 + RAG 精简片段（模块 03/04）。
小模型兜底：简单意图用便宜小模型，难问题才上大模型。
用量分档：给不同角色/租户不同的用量配额。

补充：缓存三大问题与消息队列削峰（面试高频）——缓存不是“装上 Redis 就万事大吉”，三个经典坑：穿透（查不存在的 key、每次都打到库，用布隆过滤器/空值缓存防）、击穿（热点 key 瞬间失效、并发全压到库，用互斥锁防）、雪崩（大批 key 同时失效或 Redis 挂，过期时间加随机 + 集群高可用）。而消息队列能削峰解耦的原理是：上游把请求写进队列、下游按自身能力匀速消费，突发流量不会打死服务（削峰）；生产者和消费者只认队列、不改对方实现（解耦）。批处理式的大量数据导入和缓存回填，靠这一套都能摊平。落地后还要记得给高频查询字段建索引，具体 SQL 优化去数据库页看。

8.4 模块练习

写一个 ETL 脚本：读一个 CSV，做去重/补空/日期规范化/丢弃脏数据，并输出一份数据质量报告。
给你的服务加结构化日志（JSON，含 request_id），并把调用大模型的 token/耗时/成功与否打进去。
用 Prometheus + Grafana（或用你顺手的手段）做两个指标看板：P95 延迟 + 错误率。
实现"用量统计 + 成本归因"：记录每次 LLM 调用，能按用户汇总出成本。
设定三级告警规则（服务挂/高错误率/预算超支），各配一条"一眼能定位"的告警信息模板。

8.5 本章面试题

"ETL 和 ELT 区别？你现场常用哪种？" → 答：ETL 先转换再入库，适合加工重、数据量大；ELT 先入再转，适合现代数仓、灵活。现场看下游需求选；清洗逻辑重我多用 ETL。
"客户数据特别脏，你第一件事做什么？" → 答：先做数据质量评估——空值率、重复率、格式错例，出一份质量报告与客户核对映射关系，别直接开发。数据不对，下游模型全错。
"怎么判断 AI 服务那天出问题了？" → 答：看指标(P95延迟、错误率、GPU、token成本)的趋势异常 → 结合日志和链路定位到具体请求/服务 → 分级告警第一时间提醒，而不是等客户反馈。
"大模型烧钱，你怎么帮客户控成本？" → 答：用量统计 + 成本归因 + 限流告警；工程上做缓存命中、压缩上下文、轻模型兜底、用量分档。核心是"看得清 + 控得住"。
"Prometheus 和 Grafana 各负责什么？" → 答：Prometheus 负责采集和存指标（Time Series），Grafana 负责可视化仪表盘；两者配合展示趋势。日志(Loki/ELK)和链路(Traces)另外负责细节与全貌。

8.6 小结

数据链路：抽 → 洗 → 转 → 载；数据质量是 AI 的天花板，先出质量报告。
可观测性三件套：Metrics（趋势）/ Logs（细节）/ Traces（全貌），缺一不可。
监控 + 分级告警，别等客户说"你挂了"才知道。
大模型成本是客户最敏感的：用量统计 + 成本归因 + 限流告警 + 省钱四招。
下一章进入 FDE 区别于普通后端的核心：需求拆解、方案设计与产品化。