口径必须反复对齐
新旧表出现差异时，一个任务一个任务地验数，确认足够一致后才允许切换。
02
Data System Transformation Program
北斗星计划
把广告数仓和特征体系中的大量分散问题，组织成七项可推进、可汇报、可沉淀的重构工程。它覆盖底座、迁移、特征、实时、治理、质量和 AI 化研发流程。
我的角色总体规划、核心架构与项目推进
实施方式亲自写核心代码，带团队共同完成
目标水平效率、质量、成本向第一梯队靠齐
01 / Context
为什么要启动这项计划
当时的困难不是一个表或一个任务做得不好，而是整个体系缺少主干，也缺少能把问题系统解决的人。
- 临时表、零散表和烟囱式开发很多，想到哪做到哪。
- 维表抽象不足，大量场景直接读取 ODS 原始表。
- 相似逻辑在多个脚本中重复实现，同一指标口径却不一致。
- 请求、曝光等事件明细被重复存储，成本和性能不理想。
- 运营、算法和数据分析取数都很痛苦，很多人绕过数仓自己处理原始数据。
北斗星计划不是给七个零散任务起漂亮名字，而是把一组长期分散的数据问题变成共同目标、工程边界和推进节奏。
02 / Foundation
天枢星：先把数仓底座建对
这是七项工程中最重要的一项。没有统一底座，迁移、特征、实时、治理和质量都只能继续在旧问题上打补丁。
按主题建设极致分区表体系
不同主题分别建设一套表，每套表跨 ODS、DWD、DWS 等分层组织。它不是一张表解决所有问题，而是用统一方法构建清晰的数仓主干。
统一一致性维度和原子指标
广告主、广告计划、广告组、广告位、应用、用户、时间等维度统一抽象；曝光量、点击量、下载量、扣费量和转化量等原子指标在 DWS 层统一定义。
不仅交付表，也交付整个可理解系统
同时沉淀配套代码、业务流、数仓模型图、重建矩阵图、数据流图和可查询文档，让后来者能够看懂并继续维护。
03 / Migration
天璇星：在应用层尽量无感的前提下迁移
真正困难的不是新表怎么建，而是旧报表已经被使用方用习惯，底层替换时不能让应用层承担过大的改造成本。
蚂蚁搬家式分批迁移
先梳理依赖，再拆成多批推进；每批总结问题和经验，并快速复用到后续人员。
团队推进机制
项目早期一周跟踪两次，稳定后调整为一周一次；同时用进度、质量和资源优化等激励方式，让多人并行迁移时仍保持统一标准。
底层体系完成重建，应用层通过切换依赖逐步指向新数仓，尽量实现无感迁移。
04 / Workstreams
专项重构、治理、质量和 AI 化
底座与迁移构成主干，其余项目分别解决专项体系、长期秩序和研发效率问题。
特征体系 SQL 化
Scala 改为 Spark SQL，少数能力封装为 UDF，同时引入维度建模、治理和质量方法。
实时数仓标准化
用 FlinkSQL、实时模型和统一开发框架替代需求驱动的零散 Java 任务。
抑制先污染后治理
增量资产从出生就遵循规范，存量资产再通过迁移改造逐步扭转。
全生命周期质量
把评审、测试、发布、DQC、告警闭环和事故复盘串入整个研发流程。
AI 数据研发流程
通过专家 Skill 和智小数 AI 数据平台，把架构、开发、治理和运维逐步 AI 化，并已通过真实需求与团队使用验证。
05 / Leadership
技术之外，更重要的是把复杂工程做成
把散点问题组织成工程体系
建立统一名称、边界、主线和优先级，让团队知道为什么做、先做什么。
既做架构，也写关键代码
关键方案和核心代码亲自完成，同时让更多成员参与并在项目中成长。
让经验在多人之间复用
通过模板、评审、复盘和高频跟踪，让复杂项目不依赖个人各自发挥。
兼顾架构目标与迁移现实
不是追求一次性完美替换，而是在应用无感、口径可信和进度可控之间做工程判断。