这个问题有点大啊。。首先做什么事情之前，你得想清楚你为什么要做？做了之后，要达成什么样的目标？
比如，你的目标是
建设一个全面、准确、高效、易扩展、规范、易用、成本低 的数仓
那我问你，能具体说说吗？
1、要什么数据，有什么数据
2、无指标二义性和数据计算错误问题
3、完成业务方的需求要快
4、新业务进入后，可以无缝接入数仓
5、数据产品使用门槛低和使用数据的效率要高
6、存储资源、计算资源、人力资源消耗都要最低
说实话，这个愿景几乎不可能实现。。我们需要在性能、成本、效率和数据质量之间找到最佳平衡点
1、业务调研 业务调研是很重要的！不进行业务调研搭建数仓就是耍流氓！！！
业务调研主要是面向数据生产方，需要理解用户的业务过程，搞清楚业务过程中涉及到的数据系统
对业务过程进行拆解，弄清楚每一个环节会产生哪些数据，产生的数据进入到了哪个业务库
产出：业务数据矩阵 作用：宏观了解公司的业务
- 每一列：业务主题
- 每一行：行为数据主题
2、需求调研-不要闭门造车！！
分角色进行需求调研
- 管理层：大盘指标
- 产品：订单关键节点的指标
- 运营：画像数据
3、数据调研-兜底策略
4、指标体系 指标+维度 = 指标体系
基于需求调研，先构建北斗星指标，再慢慢迭代。
5、实施规范
模型规范
- 模型设计规范:
- 高内聚 低耦合 业务相近 粒度相同的数据设计到一个物理模型
- 核心模型和扩展模型分离 核心模型支撑核心业务 扩展模型支撑个性化业务
- 公共逻辑下沉且单一 公用的数据处理逻辑在底层进行封装实现
- 成本和性能平衡 适度冗余
- 数据可回滚 处理逻辑不变，在不同时间多次运行，数据结果确定不变
- 一致性 相同含义的字段在不同表的命名必须相同
2.模型调用原则：
- 禁止逆向调用：数据流向自下而上
- 尽量避免同层调用
- 优先使用公共层
- 避免跨层调用
命名规范
- 分层：ods dwd dws dwm app
- 表命名规范： 分层_业务域_数据域_业务描述_时间周期+存储策略 dwd_fyp_ord_order_df
- 业务域： 可以理解为一条业务线或产品线
- 主题域：用户域 user 商品域 product 商家域 merchant 订单域 order 交易域 trade 优惠券 coupon 积分 integral
- 时间周期：d w m 天、周、月
- 存储策略：f i 全量和增量
- 字段命名规范 cnt rate amt time date
- 脚本命名规范:同表命名规范一样
- 指标定义规范：时间周期+修饰词+原子指标 最近一天支付宝渠道的订单数 order_cnt_1d_alipay
开发规范
- 数据同步规范： 增量 全量快照 全量
- 具体开发规范：
- 节点名称和表名称相同,一个节点产出一张表
- 程序头注释、代码段注释、表注释、字段注释
- SQL中关键字用大写 SELECT FROM JOIN WHERE AND OR UNION AS 其余用小写
3.上线规范：CR
6、模型设计 维度表、明细事实表、汇总事实表的设计
不要想太多，建模就是建表，如何让你所设计的表让使用的人感觉到好用，直接通过 select * from 就可以得到数据，而不需要 join 等复杂操作
7、开发 写代码的时间是很短的。。
8、测试、上线 验证数据质量
9、运维 持续观测任务的稳定性和就绪时间
10、下线 使用率低模型考虑下线
总结：
数据仓库不是一劳永逸的，是需要不断迭代的，什么时候算建好了呢？公司倒闭的时候。。。哈哈哈哈哈
思考：
那你是如何衡量你所搭建的数仓的好坏呢？给公司带来了什么价值？你要知道，资本家是不关心你写了多少代码的，只看结果的。。。