埋点/行为日志到底该建一张宽表还是走事件溯源？聊聊你的取舍

背景

做了 10 年大数据平台，最近半年在多个团队里反复看到同一个争论：业务埋点（用户行为日志、操作流水、事件流）到底该怎么建模？我至少碰过三种流派，且每一种背后都站着一位"踩过坑的人"：

1. 扁平宽表派：一张 events 大表，几十个字段平铺，event_type 用枚举区分，新事件加字段。优点是查询简单、BI 工具直接拖，业务方 10 分钟上手；缺点是字段爆炸、每个事件类型实际用到的字段只有 1/3，schema 变更频繁，宽表动辄几百列。

2. 事件溯源派：一条事件一个 JSON payload，元数据（时间、user_id、event_type）外置，业务字段全塞 JSON。优点是 schema 演进自由、新增事件零 DDL；缺点是查询要 JSON_EXTRACT、索引难加、聚合性能差，BI 工具基本废。

3. 中间派：元数据宽表 + payload JSON 字段混用，高频字段抽出来建索引，低频字段留 JSON。灵活但心智负担重，团队里每个人对"哪些字段该抽出来"的判断不一致，半年后表结构又是一团浆糊。

我的倾向

我目前偏向 2 + 派生层 的组合：底层只保留 event_id / event_type / user_id / ts / payload(JSON) 五列不可变，作为唯一事实源；查询侧按业务域预生成派生表（比如"加购转化""留存"各自一张窄表，T+1 或准实时物化）。理由有三：

• 埋点事件的本质是只追加、不修改，事件溯源天然契合；
• 宽表最大的隐性成本不是查询慢，而是 schema 漂移——字段语义变了没人知道，数据质量无从谈起；
• 派生层可以按"谁查得最多"迭代，比宽表"猜哪些字段会被用"成本更低。

想听大家聊聊

1. 你们团队现在埋点表是宽表、JSON 还是混合？跑了多久后开始后悔？
2. 派生层是 T+1 离线物化、Flink 实时物化、还是查询时现算？各在你什么场景下翻过车？
3. 如果业务方坚持"我要在一张表里 SELECT"，你最后怎么妥协的？

欢迎贴具体的字段数、事件类型数、日增量，数字比形容词有说服力。