链接：https://pan.baidu.com/s/1tagyV47i9pybscMBGMC7eQ 

提取码：dfhg 

 

1.1 数据体系建设介绍

背景：简单点描述：报表太多，仓库表太多，我们要清理使用频率低的，但是，那些该清理，那些不该清理，仓库中茫茫一片”大海“，你不认识我，我也不认识你，怎么办？大家都站着别动（现有仓库不变），记录一下办个身份证（建设数据体系）。（体系建设过程就是给每个表办身份证的过程，体系建设的核心是7个葫芦娃只能有一张身份证（业务合并），其中6娃由于隐身时间太长，大家都给忘了（下线机制），那么6个葫芦娃一张身份证）；

 

一 现有问题：

1 层级不规范，和行业不对标；

2 宽表字段不够全面；

3 部分主题表缺失，eg:电商日志；

4 字段不够规范：同一业务名称在不同表中对应不同的名称；

5 表名不够规范：没有主题划分，存储策略和计算周期没有明显标识；

6 上层表xxdm表复用性太低（名称不规范，不能见名思义，各个开发人员之间的复用比较低）；

7 主题划分不明显：一堆乱麻，都是基于需求，没有业务建模的概念；

 

二 基于现有问题我们做了那些改进

1 行业对标，采用ods(数据贴源层)->dwd(仓库基础层)->dws(业务线汇总层)->ads(数据应用用层)的层级对应关系;

2 合理冗余字段；

3 全面思考主题，补充不全的主题（主要是打点部分，做了合理的拆分）；

4 字段做了严格规范，id字段规范，名称按照关键字列表（语雀）命名，统一业务名称（不同的表对应相同的名称）；

A 名称：同一业务名称在不同表中对应不同的名称；

B 数据类型：金额：double（单位：元，秒等的规范）

C 值类型：eg:布尔类型混乱：目前：1 是 0否，

5 表名不同层级对应不同规范：eg:表名= 层次_业务线_数据主题_表名_存储策略_计算周期    （dws_xx_device_info_detail_a_d）

数据主题：包括用户user、订单order等

表名：表名要能准确描述业务数据的特征。

存储策略：增量I（分区表），全量A（非分区表），快照 S（分区表），拉链H（分区表）(暂时没有需要)

计算周期：年\半年\季\月\周\日\时 Y\HY\Q\M\W\D\H。

6 统一规范（指标系统的建设）--待我们去深入思考（可作为单独的项目）属于我们的前景展望；

7 划分多个主题：(用户设备，流量/日志，会员，订单，小课（存在依赖关系，后续开发），轻课)，在表设  计层面，既有分主题的宽表，也有全部主题的宽表；

 

三 我们现在已经有的（两部分，第一部分：数据表，第二部分：文档沉淀）:

1 用户设备，流量/日志，会员，订单，小课，轻课的基础宽表；

2 dws数据字典（详见石墨文档，语雀超链接没发先怎么用，后续超链接问题解决后会转移到语雀）；

3 规范文档：

1> 数仓命名规范文档（表命名规范，字段命名规范，脚本命名规范）

2> 数仓开发手册

3> 数仓分层

4> 数仓关键字列表（后期会做关键词分类）

4 数仓表上线记录

5 数仓表下线记录

6 数据接入模板（mysql部分已经实现模板化）：一个库一个模板

⚠️ 文档会不断完善，不断扩充，语雀文档是对所有知识点/规范唯一解释（如果不是，那就想办法让他是）；

 

四 我们后续会做的

1 完善体系：根据业务继续补充

1> 已有：用户设备，流量/日志，会员，订单，轻课（大语文）

2> 小课（存在依赖关系，后续开发）

2 上层表开发：

1> 原则：复用性高，延展性要好；

    怎么开发？？？

步骤1：确定需要迁移的报表：

步骤2：确定迁移报表涉及到的指标能否从现有基础表中直接汇总开发，如果不能，转入步骤3

    (从基础表--> 中间表)

步骤3: 开发中间表：两个原则：1 满足现有报表，2 最大化的尝试去满足其他报表

步骤4: 开发类似报表：1 能否从现有中间表直接开发，如果不能，分析维度，是否可以合并，合并，如果不能，开发新表

(中间表--> 中间宽表)

步骤5: 数据校验（对比BDP）：

3 数据下沉：

如果多个中间表中存在同一个数据字段，并且每个中间表都是同样的计算逻辑（一般情况是一致的，如果不一致，想办法一致），该字段映射自同一张 底层表 ，那么这个字段可以下沉到底层表。

 

五 未来会做的

1 业务建模（提高业务前瞻性）；

2 调度体系（头脑风暴了各种调度工具，例如：azkaban不是特别合适，还没有出结果）

3 血缘关系（希望通过平台化的方式实现）