5.0 KiB
5.0 KiB
title, author, date
| title | author | date |
|---|---|---|
| 标准数仓治理与指标平台建设 · 会议要点 | Get达人 | 2026-08-20 |
一、新老数仓职责划分
财务域数仓迁移完成后，新老数仓将划分为两大独立模块，职责边界清晰、互不干扰：
- 新数仓：负责输出所有报表类统计数据，报表统一从新库出。
- 老数仓：保留 API 服务能力，以及直接写入业务库的数据同步能力；API 调用和回写业务库的数据都从老库走。
二、财务域迁移的多重意义
优先选择财务域作为首个治理对象，有三层考虑：
- 标准化基础好：财务域的指标口径本身具备较高的标准化程度，治理起来起点高、阻力小。
- 数据分布有代表性：财务数据存储在老数仓，对全域数据治理有很强的参考价值，能验证老数仓侧的治理路径。
- 打样沉淀经验：通过财务域迁移和标准化治理，输出可复用的标准模板，后续家庭域及其他业务域直接参照该模板推进，降低重复试错成本。
三、业务牵引的数仓标准化技术改造
摒弃纯技术驱动的自下而上五层整合方案（预估周期长达 3 年，极端评估甚至 10 年），转为以业务痛点为核心的迭代推进思路：
- 核心原则：以业务作为牵引去做治理，技术内部的混乱只要不影响业务使用，就不强行清理，在服务业务的过程中逐步解决。
- 推进节奏：一周一迭代，在增量开发过程中同步发现并解决存量问题，持续优化。
- 性价比导向：不做无意义的纯技术改造。比如带 V 与非带 V 指标只是技术命名差异，业务用户只关心数据是否可用，不需要投入大量人力强行改造所有非带 V 指标，只需要把口径梳理对齐、确保输出准确即可。
- 对外统一出口：标准数仓的对外输出统一通过指标平台呈现，业务侧不需要感知底层是新库还是老库、是带 V 还是非带 V，只看指标是否统一、是否有争议、交互是否更快。
四、家庭域的改造方式
家庭域的治理参照财务域的标准模板推进，但不搞一刀切：
- 已有基础：家庭域此前已经完成过一次改造，具备相对标准的基础，不需要强行清除所有存量老数据。
- 治理思路：在整理指标接口的过程中逐步发现问题、解决问题，而不是先全部推翻重建。
- 案例参考：此前嘉玲在整理下单量指标时，发现该指标口径与商城侧未统一，完成对齐后彻底解决了该指标的复用争议。家庭域指标治理就参照这个思路——以指标口径对齐为核心，遇到问题再针对性治理底层数据。
- 不强改技术属性：不追求把所有非带 V 指标都改成带 V，改起来人力成本太高，业务侧也感知不到差异。核心是把指标口径治理到能对得上。
五、指标口径问题作为业务牵引，驱动指标治理与数仓标准化
项目发起的源头，是业务侧反馈大量指标口径不一致，影响高层决策，同时指标复用率低。这一业务痛点成为整个数仓治理和标准化的核心牵引：
- 指标平台先行：先把公司级、部门级所有指标统一收口，确保所有对外输出的指标口径完全对齐，再同步推进技术内部的治理工作。
- 流程化守护：通过固定流程持续守护指标口径的一致性，每周迭代优化，在增量开发中同步解决存量问题。
- 治理路径反转：传统路径是先做技术治理（ODS→DWD→DWS 逐层往上），再输出指标；现在反过来——从业务最关心的指标口径问题切入，用指标梳理倒逼底层数据治理，每一步都有明确的业务价值反馈。
- 年底目标：完成财务域、家庭域等多个业务域的指标改造，实现全公司指标信息化统一管理，对外输出标准数仓治理的落地成果。
六、ODS 贴源层问题对查表智能体效果的影响
OBS 贴源层存在一批未标注表名的数据表，直接影响跑表智能化功能的使用效率：
- 问题表现：查表智能体在检索目标表时，因为缺少表名标注，无法快速精准定位，导致查表成功率和效率下降。
- 处理方式：结合查表智能体的上线进度，优先补全这批缺失的表名，避免后续长期遇到查表定位失败的问题。
- 治理逻辑：这也是"业务牵引治理"思路的体现——不是先花几年把所有底层表都规范一遍，而是哪个环节影响了业务功能（查表智能体），就优先治理哪个环节，及时反馈、及时调整。
待办事项
- 老谢：跟进性能优化相关工作，对接相关人员推进治理板块高资源占用任务的优化
- 相关负责人：补全 OBS 天贴源层缺失的表名，保障查表智能体的正常使用
- 相关人员：借助 AI 工具读取所有客户级任务的运行数据，生成性能优化解决方案