【数仓】数据仓库的建设（二）

前言：

前文说了一些数据仓库的基础概念和模型，本文继续往下说吧！

【数仓】数据仓库的思考（一）：https://blog.csdn.net/lsr40/article/details/105576047

 

1、数仓的目标（能完成什么事情）

当工作中遇到以下的事情：

-1.数据分层混乱，不知道从何查起

-2.数据指标维度不统一，业务/数据分析部门要数据，只能找数据开发口口相传

-2.数据建设缺乏规范，表结构字段定义不统一，字段含义模糊，数据任务、数据表维护成本高。

-3.重复计算同一个数据，浪费资源

通过搭建数仓，我们要完成的就是，数据分层，维度划分，指标口径确认，表名和字段统一（字段加注释），尽可能消除重复计算

不过要怎么量化目标完成了多少，好像不太容易

2、数仓的迭代

由于数仓是个大工程，很难一次性做完整

初期：稳定性和可用性

可用性就不说了，稳定性就是鲁棒性，提供的服务如果经常性的出问题，那么给使用者的印象就大打折扣，包括服务（hdfs，hive等相关组件的稳定），数据约定的推送时间，数据本身内容的稳定（数据质量）等

后期：高效性和易用性

高效我觉得就是上手成本，it行业，人流动性还是蛮高的，新来一个人，是否能快速熟悉数据的来源和流程，指标的生成规则，这是数仓的一个目的所在，易用性就是后期我们可能把很多东西做成服务了，比如元数据管理，数据质量监控，甚至自定义生成报表，那么这些服务的操作是否简便，是否容易上手，是评判数仓是否成熟的一个标准。

所以做数仓，并不只是把数据分层，整合，更关键的还要有配套的服务，元数据管理，数据质量监控，数据处理推送（界面化操作），数据流程报警等等，要完善整个数仓的生态环境，并不是一朝一夕立刻就能做完的。

 

3、数仓建设规范

百度下，各种图都有，我就来说说每层我想的东西吧！

-1.命名规范（建表/字段注释）

当然我也只是提出我们的方案，并不是说全世界都得统一，逻辑上说得通就行

表名规范：

ODS 落地层：

ods开头_原表名_其他信息（尽量保持字段和格式一直，方便检查数据问题）

DW层：（可以在表名中带上D,W,M,Y来标识表的日期维度）

（1）、DW明细层：dws_[日期维度]_主题域_其他信息

（2）、DW聚合层：dwa_[日期维度]_主题域_聚合维度_其他信息

DIM维度层：

dim_通用/主题域_维度_其他信息

TMP临时表：

tmp_[所属程序名/或者操作者缩写]_[自定义序号1…10]_主题域_其他信息

字段规范：

（1）、每个字段都要写注释

（2）、字段名禁止使用数据库保留字

（3）、小写字母，采用下划线分割

（4）、同一个字段在不同表，命名和类型统一

（5）、HIVE中尽量使用String

（6）、有小数点的字段，保留小数据后10位（这个可以根据各自产品需求，但是尽量统一，否则在做一些聚合操作的时候会有误差）

 

-2.任务资源等级规范

涉及亏损资产->重要任务->上游关键数据->上游非关键->非上游非关键

 

-3.分层规范

首先，数仓层内部的划分不是为了分层而分层，它是数据仓库经过了建模和 ETL 之后真正开始对外提供服务的地方，因此数仓层内的划分更应该符合使用者的思维习惯。DW 内的分层没有最正确的，只有最适合你的。

从业务层面看，数据仓库的核心是展现层和提供优质的服务。ETL 及其规范、分层等所做的一切都是为了一个更清晰易用的展现层。

要考虑的是分层问题（为什么有这个层吗，去掉是否有影响，是否每个层次都有需要解决的问题）

ODS层（数据接入原始数据层）

1、整合多种数据源到一个统一的地方

2、表字段格式和原表一样，方便差错

DW层（数仓层）

星型模型还是雪花，还是DataVault还是宽表

宽表：除非这个业务线以后基本不动，维度基本不增加，不然不要轻易使用宽表，后续加字段等七七八八操作很难受
而且结果表，可能尽量也不要使用宽表，否则就会有些历史数据（要跟产品或者业务方沟通好）
例如：有一条数据3月的时候名字叫ad，4月改名叫钙奶，那么用户在搜索数据的时候，根据名字搜索，通过现在叫钙奶来搜索3月份结果数据，结果查无此人，但是通过id却又搜索的到（因为用户是拿名字搜索的）

另外3种模型各有优劣吧，如果不是有特殊需求，建议星型模型

 

DM层（数据集市层高）

主题域划分

各种主题域各自开发（根据业务的理解划分）
例如：消费行为，通话行为，流量互联网分析，可以拆分成3个主题进行维护，可以有各种不同维度的产出

权限设置

虽然前两层有时候也会提供给外部查询（例如：ods数据）但是本质上来说，尽量让用户查询dm层，所以dm层就要设置相应的权限，库，表，甚至字段，可以参考sentry或者ranger等框架，更简单的就是hdfs设置不同用户的权限（目录的wrx权限）
 

TMP层（有些中间表可能可以复用，或者报错时用来回溯）

跑ETL的时候是否有中间表，是否需要保存部分的表，放在统一的地方，对用户不可见（基本是用来回溯报错，或者差量新增更新的）

 

所以本文我把什么是一个好的数仓，数仓产品如何迭代，还有数仓的分层和规范都说了，我再重复下，好的数仓设计，应该是减少人力成本，减少口头扯皮，更清晰明了的提供获取数据的方式给数据需求方，是一套高效，易用易上手的服务（是一整套服务哦，因为我后面还要说元数据管理和数据质量监控的事情，这两个也颇为重要！）

 

如果有什么还需要补充的或者各位有疑惑的，可以给我留言，相互探讨下

菜鸡一只，正在努力提升自己！留给自己一句话：不破不立！