【策划架构】数据仓库：运营分析的分层数仓设计

设计初衷

运营分析的原始诉求是"查个数"，但原始游戏库直接扛分析查询的代价惨重：一条跨 30 天的留存查询在游戏库上跑 4 秒，期间拖慢正常玩法落库。分层数仓把"游戏库"与"分析库"的职责切开：原始层存真相、明细层理结构、汇总层供报表——报表只碰汇总层，分析下钻才进明细层，游戏库从分析负载中解放出来。

数值模型

三层结构：原始层 ODS（每日同步的游戏库原表镜像，不做加工，保留 90 天）；明细层 DWD（清洗脱敏后的规范化明细：统一时间口径、剔除测试账号、敏感字段脱敏，保留 1 年）；汇总层 ADS（按主题预聚合的日表：留存表、充值表、经济流水表，永久保留）。查询路由：日报与看板只查 ADS（单表毫秒级），专项分析查 DWD（秒级），数据追溯查 ODS（原始凭据）。层数与成本：三层存储的体积比约为 ODS 100%、DWD 80%、ADS 2%，汇总层用 2% 的体积承接 90% 的查询流量。数值验证：日报查询从游戏库的 4 秒降到 ADS 的 0.2 秒，游戏库峰值负载下降 35%。

配置示例

分层参数单独一节。配置如下：

[Warehouse]
OdsKeepDays = 90
DwdKeepDays = 365
AdsKeep = forever
CleanTestAccount = 1

路由参数单独一节。配置如下：

[QueryRoute]
ReportLayer = ADS
DrillLayer = DWD
TraceLayer = ODS

扩展思路

变种方向：一是指标字典入仓，每个 ADS 表字段关联指标口径定义，查数先查定义；二是血缘追踪，ADS 指标回溯到 DWD 加工规则再回溯到 ODS 原始表，数据异常时沿血缘定位；三是自助分析，运营用可视化工具直接查 ADS，不写 SQL 也能拼出自定义报表。设计纪律一条：明细层的清洗规则变更必须重刷历史——口径改了历史没重刷，ADS 的时间序列就出现假拐点，比没有数据更误导决策。