淘先锋技术网

首页 1 2 3 4 5 6 7

这个问题有点大啊。。首先做什么事情之前,你得想清楚你为什么要做?做了之后,要达成什么样的目标?

 

比如,你的目标是

建设一个全面、准确、高效、易扩展、规范、易用成本低 的

那我问你,能具体说说吗?                        

1、要什么数据,有什么数据

2、无指标二义性和数据计算错误问题

3、完成业务方的需求要快

4、新业务进入后,可以无缝接入数仓 

5、数据产品使用门槛低和使用数据的效率要高 

6、存储资源、计算资源、人力资源消耗都要最低

 

说实话,这个愿景几乎不可能实现。。我们需要在性能、成本、效率和数据质量之间找到最佳平衡点

1、业务调研    业务调研是很重要的!不进行业务调研搭建数仓就是耍流氓!!!

业务调研主要是面向数据生产方,需要理解用户的业务过程,搞清楚业务过程中涉及到的数据系统

对业务过程进行拆解,弄清楚每一个环节会产生哪些数据,产生的数据进入到了哪个业务库

产出:业务数据矩阵    作用:宏观了解公司的业务

  • 每一列:业务主题
  • 每一行:行为数据主题

2、需求调研-不要闭门造车!!

分角色进行需求调研

  • 管理层:大盘指标
  • 产品:订单关键节点的指标
  • 运营:画像数据

3、数据调研-兜底策略

4、指标体系      指标+维度 = 指标体系 

基于需求调研,先构建北斗星指标,再慢慢迭代。

5、实施规范

模型规范

  1. 模型设计规范:
  • 高内聚 低耦合   业务相近 粒度相同的数据设计到一个物理模型
  • 核心模型和扩展模型分离   核心模型支撑核心业务  扩展模型支撑个性化业务
  • 公共逻辑下沉且单一  公用的数据处理逻辑在底层进行封装实现
  • 成本和性能平衡     适度冗余
  • 数据可回滚   处理逻辑不变,在不同时间多次运行,数据结果确定不变
  • 一致性   相同含义的字段在不同表的命名必须相同

 

     2.模型调用原则:

  • 禁止逆向调用:数据流向自下而上 
  • 尽量避免同层调用
  • 优先使用公共层
  • 避免跨层调用

命名规范

  1. 分层:ods dwd dws dwm app
  2. 表命名规范: 分层_业务域_数据域_业务描述_时间周期+存储策略  dwd_fyp_ord_order_df
  3. 业务域: 可以理解为一条业务线或产品线
  4. 主题域:用户域 user 商品域 product 商家域 merchant 订单域 order 交易域 trade 优惠券 coupon 积分 integral 
  5. 时间周期:d w m   天、周、月 
  6. 存储策略:f i   全量和增量
  7. 字段命名规范  cnt rate amt time date 
  8. 脚本命名规范:同表命名规范一样
  9. 指标定义规范:时间周期+修饰词+原子指标   最近一天支付宝渠道的订单数   order_cnt_1d_alipay

开发规范

  1. 数据同步规范: 增量 全量快照  全量
  2. 具体开发规范:
  • 节点名称和表名称相同,一个节点产出一张表
  • 程序头注释、代码段注释、表注释、字段注释
  • SQL中关键字用大写 SELECT FROM JOIN WHERE AND OR UNION AS 其余用小写

     3.上线规范:CR

6、模型设计  维度表、明细事实表、汇总事实表的设计

不要想太多,建模就是建表,如何让你所设计的表让使用的人感觉到好用,直接通过 select * from 就可以得到数据,而不需要 join 等复杂操作

7、开发   写代码的时间是很短的。。

8、测试、上线     验证数据质量

9、运维   持续观测任务的稳定性和就绪时间

10、下线   使用率低模型考虑下线

总结:

数据仓库不是一劳永逸的,是需要不断迭代的,什么时候算建好了呢?公司倒闭的时候。。。哈哈哈哈哈

思考:

那你是如何衡量你所搭建的数仓的好坏呢?给公司带来了什么价值?你要知道,资本家是不关心你写了多少代码的,只看结果的。。。