数据体系（Data Platform）

目标：让数据从“可采集”→“可信”→“可复用”→“可决策”

P0（数据基础）
├── 数据采集 / 埋点体系
├── 数据中台（数据湖 / 数据仓库）
├── ETL / ELT 平台（Airflow）

P1（数据可信）
├── 元数据平台（Data Catalog）
├── 指标平台
├── 数据质量平台（DQ）

P2（数据服务）
├── 数据 API 平台
├── 报表平台（BI）
├── 数据可视化平台

P3（数据资产化）
├── 数据资产管理
├── 数据权限与安全治理
├── 特征平台（Feature Store）

中间件体系的本质不是“技术选型”，而是“运行能力抽象”：

数据采集 / 埋点体系

下面我把 数据采集 / 埋点体系 当成一个可独立建设、可规模化演进的数据基础平台来详细展开，而不是只讲“前端埋点怎么打”。

你可以把这一套理解为：企业所有“行为、状态、事件”的统一入口层。

一、先给一个“正确认知”

1. 什么是数据采集 / 埋点体系

数据采集 / 埋点体系，本质上是把企业里“正在发生的一切”，用统一、结构化、可治理的方式记录下来。

它覆盖的不是只有用户点击，而是：

用户行为
系统行为
业务事件
技术事件
状态变化

二、埋点体系的整体分层架构

一个成熟的采集体系，至少要有 7 层：

事件定义层（规范）
  ↓
埋点实现层（SDK / Agent）
  ↓
采集接入层（Gateway）
  ↓
数据校验 & 预处理
  ↓
实时 / 离线通道分流
  ↓
消息队列 / 流平台
  ↓
落地存储（ODS / 实时表）

三、事件定义层（最容易被忽略，但最重要）

1. 事件不是“随便打的日志”

错误做法：

想到什么打什么
字段临时加
名字随意

正确做法：事件是“数据产品”，必须先定义、后上线。

2. 事件模型（强烈建议）

（1）基础事件结构

{
  "event_name": "order_submit",
  "event_time": "2025-12-15T10:00:00Z",
  "event_type": "behavior",
  "user_id": "12345",
  "trace_id": "xxx",
  "properties": {
    "order_id": "O123",
    "amount": 99.9,
    "channel": "app"
  }
}

（2）事件三要素

要素	说明
Who	谁触发
When	何时
What	做了什么
Context	环境上下文

3. 事件分类体系（非常关键）

类型	示例
行为事件	点击、浏览、下单
业务事件	支付成功、审核通过
系统事件	服务启动、配置变更
运维事件	发布、扩容、回滚
风险事件	异常登录、风控命中

四、埋点实现层（SDK / Agent）

1. 前端埋点

模式对比

模式	特点
代码埋点	精准、可控
可视化埋点	快、但风险高
无埋点	自动化，质量依赖规则

成熟实践：

核心链路代码埋点 + 辅助页面可视化

2. 后端埋点

常见方式

业务代码显式埋点
AOP / Filter
中间件拦截（RPC / MQ）

后端事件更重要的原因

更稳定
更可信
不依赖前端

3. 日志型埋点（技术体系必备）

应用日志
访问日志
审计日志

建议：

日志即事件
结构化 JSON
自动采集

五、采集接入层（Ingestion Gateway）

1. 为什么一定要有接入层

没有接入层的后果：

SDK 直连 MQ
数据格式不可控
无法限流
无法灰度

2. 接入层能力

能力	说明
协议适配	HTTP / gRPC
认证	AppKey / Token
限流	防刷、防雪崩
灰度	新事件灰度
版本兼容	多 SDK 共存

六、数据校验 & 预处理

1. Schema 校验

事件是否已注册
字段类型是否合法
必填字段是否缺失

2. 预处理能力

公共字段补齐
字段重命名
枚举值映射
脱敏（手机号 / 身份证）

3. 坏数据处理

丢弃
降级
旁路存储（DLQ）

七、实时 & 离线通道设计

1. 为什么要分流

场景	要求
实时风控	毫秒级
实时大盘	秒级
BI 分析	分钟 / 小时

2. 典型架构

Ingestion
  ├── Kafka (Realtime)
  └── Kafka / HDFS (Offline)

八、消息队列 / 流平台设计

1. Topic 设计规范

按 事件域 而不是业务系统
控制 Topic 数量
分区按 user_id / trace_id

2. 顺序 & 幂等

同一用户事件有序
EventID 去重

九、落地存储（ODS / 实时表）

1. ODS 设计原则

只做轻处理
保留原始字段
可重放

2. 实时表

实时指标
实时画像
实时告警

十、埋点治理体系（99% 的公司缺失）

1. 埋点资产管理

事件目录
字段字典
使用情况

2. 质量监控

指标	说明
上报量	是否异常
延迟	SLA
丢失率	数据可靠性
字段完整率	质量

3. 变更治理

事件版本
向后兼容
下线流程

十一、常见“坑位总结”

前端埋点过重，后端几乎没有
事件没有 Owner
指标依赖隐式字段
埋点变更没有评审
数据问题无法追责

十二、与你背景的强关联（重点）

结合你在 监控 / 告警 / 根因分析 方向的积累：

数据体系（Data Platform）
数据采集 / 埋点体系