_search 导出,每行一个 ES hit 文档)traces-{YYYY-MM-DD} 滚动索引 ┌────────────────┐
│ 埋点 ES (prod) │
└────┬───────────┘
│
┌────────────┴─────────────┐
│ │
[增量路径] [历史路径]
每日 ES → Hive 一次性 .json.gz 文件
ES Storage Handler 按天解压解析
映射表 SELECT Python 脚本
│ │
└────────────┬─────────────┘
│
【入仓阶段脱敏】
(按事件类型应用规则)
│
▼
┌──────────────────┐
│ raw 层(数仓) │
└──────────────────┘
两条路径最终落到两张 raw 表,schema 一致;脱敏规则共用同一份配置。
数仓默认 raw 层走 schema-on-read landing 范式(数据原样落、ods 阶段才做类型转换 / 脏数据识别)。本场景主动破例:
| §8.1 理由 | 是否适用 | 说明 |
|---|---|---|
| 1. 隔离源端类型变化 | ✗ | 埋点 schema 长尾,新事件 / 新字段频繁,要求协作通知 |
| 2. 同步阶段不可失败 | △ | 部分适用,需对解析失败做容错处理 |
| 3. 保留原始精度与原文 | ✗ | 合规要求就是要丢字段 |
| 4. 脏数据可观测 | △ | 事件本身可观测,脱敏后字段不可回溯(合规接受这代价) |
| 5. schema-on-read 范式契合 | ✗ | 合规要求物理拦截敏感字段,不能等 ods 读取阶段才处理 |
破例代价:
| 动作 | 含义 | 适用 |
|---|---|---|
drop |
字段直接删除,不入 raw | 高敏字段(地址、手机号、卡号等) |
mask |
字段保留但用脱敏函数处理 | 中敏字段(脱敏后的姓名、订单号末四位等) |
reject |
整事件不入 raw | 极敏感事件(如有) |
脱敏函数复用现有的 5 种:md5 / month_trunc / mask_middle / keep_first_n / keep_last_n。
所有脱敏规则集中在一份配置文件(conf/tracking-mask.ini)。
| 场景 | 处理 |
|---|---|
| 新事件 + 无敏感字段 | 默认入仓,无需通知 |
| 新事件 + 有敏感字段 | 强制走流程:埋点开发方注明 → 数仓更新配置 |
| 已有事件加敏感字段 | 同上 |
本方案仅覆盖 raw 层入仓 + 脱敏。后续阶段(不在本方案):
| dt | _c1 | |
|---|---|---|
| 1 | 20260407 | 1820000 |
| 2 | 20260409 | 1400000 |
| 3 | 20260408 | 1470000 |
为什么文件行数都是整万?是否设置了max_pages 上限。历史数据入仓时需打开限制。