数据仓库-如何构建数据仓库
这个问题有点大啊。。首先做什么事情之前,你得想清楚你为什么要做?做了之后,要达成什么样的目标?
比如,你的目标是
建设一个全面、准确、高效、易扩展、规范、易用、成本低 的数仓
那我问你,能具体说说吗?
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、下线 使用率低模型考虑下线
总结:
数据仓库不是一劳永逸的,是需要不断迭代的,什么时候算建好了呢?公司倒闭的时候。。。哈哈哈哈哈
思考:
那你是如何衡量你所搭建的数仓的好坏呢?给公司带来了什么价值?你要知道,资本家是不关心你写了多少代码的,只看结果的。。。
本文地址:https://blog.csdn.net/hsl971105/article/details/108186110