离线数仓建设及技术选型

• 离线数仓架构设计

1．建设数仓的目的

主要是增加数据计算的复用性。每次新增加统计需求时，不至于从原始数据进行计算，而是从半成品继续加工而成。

2. 数据仓库作用

整合企业业务数据，建立统一的数据中心；
产生业务报表，了解企业的经营状况；
为企业运营、决策提供数据支持；
可以作为各个业务的数据源，形成业务数据互相反馈的良性循环；
分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；
开发数据产品，直接或间接地为企业盈利；

3. 技术产品及选型

➢ 数据采集传输：Flume，Kafka，Sqoop

➢ 数据存储：MySql，HDFS（公司有云存储最好是上云）

➢ 数据计算：Hive，Tez， Spark

➢ 数据查询：Presto，Kylin

➢ 数据可视化： Superset

➢ 任务调度：Azkaban

➢ 集群监控：Zabbix

➢ 元数据管理：Atlas

4. 系统数据流程设计

5.框架版本选型

产品	版本
Hadoop	3.1.3
Flume	1.9.0
Kafka	2.4.1
Hive	3.1.2
Sqoop	1.4.6
Java	1.8
Zookeeper	3.5.7
Presto	0.189

 注意事项：框架选型尽量不要选择最新的框架，选择最新框架半年前左右的稳定版。

6.测试集群服务器规划

服务名称	子服务	服务器 hadoop102	服务器 hadoop103	服务器 hadoop104
HDFS	NameNode	√
	DataNode	√	√	√
	SecondaryNameNode			√
Yarn	NodeManager	√	√	√
	Resourcemanager		√
Zookeeper	Zookeeper Server	√	√	√
Flume(采集日志)	Flume	√	√
Kafka	Kafka	√	√	√
Flume（消费Kafka）	Flume			√
Hive	Hive	√
MySQL	MySQL	√
Sqoop	Sqoop	√
Presto	Coordinator	√
	Worker		√	√
Azkaban	AzkabanWebServer	√
	AzkabanExecutorServer	√
Druid	Druid	√	√	√
Kylin		√
Hbase	HMaster	√
	HRegionServer	√	√	√
Superset		√
Atlas		√
Solr	Jar	√
服务数总计		18	9	9

二、数仓分层及规范

2.1分层的作用

1）把复杂问题简单化

将一个复杂的任务分解成多个步骤来完成，每一层只处理单一步骤，比较简单、并且方便定位问题

2）减少重复开发

规范数据分层，通过中间层数据，能够减少极大的重复计算，增加一次计算结果的复用性

3）隔离原始数据

不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开

2.2 分层需求分析

我们这里从Hive(HDFS)的 ods 层读取用户业务数据，并进行简单处理，写回到Hive(HDFS) 作为 dwd 层。

2.3每层的职能

分层	数据描述	生成计算工具	存储媒介
ODS	原始数据，日志和业务数据	Hive	HDFS
DWD	根据数据对象为单位进行分流，比如订单、页 面访问等等。	Hive	HDFS
DIM	维度数据	Hive	HDFS
DWS	根据某个维度主题将多个事实数据轻度聚合， 形成主题宽表。	Hive	HDFS
DM	把Mysql中的数据根据可视化需要进行筛选聚合。	Hive	可视化展示

2.4分层命名规范

注：[]：可选项，可以省略

1. 源数据层（ODS）的命名规范如下：

分层	数据模型命名	Hive开发目录	备注
源数据层（ODS）	业务库表：ods_db+_+源系统库名+_+源表名去掉开头的tb+_+(周期后缀) ⽇志表： ods_log+_+数据来源名|主题名+_+ ⾃定义表名+_+(周期后缀)	ods Mysql库名 ods_log	ods_db_ community_product_ people_family_rel_ _all_d ods_log_md_app_org_d

1. 数据仓库层（DW）的命名规范如下：

分层	数据模型命名	Hive开发目录	备注
明细数据层（DWD）	dwd_{主题域名[_⼆级主题名]}_{⾃定义表名}_{周期后缀}	DWD	dwd_md_ap p_log_nocheat_d
汇总数据层(DWS)	dws_{主题域名[_⼆级主题名]}_ [summary|topic]_{⾃定义表名}_{周期后缀}	DWS summary：按照多维度聚合 topic：按照1个维度聚合	例1： dws_busines s_order_summary_all_d 例2： dws_inp_use r_app_browse_topic_all_d
维度数据层(DIM)	dim_{维度名}_{info}_{周期后缀}	DIM
临时表	作业中：表名后统⼀加"_tmp[_01]"  临时需求：tmp_	tmp_drop或删数据
视图	表名后统⼀加"_view"	应⽤场景kylin数据表等

1. 数据集市层（DM）的命名规范如下：

数据集市层 (DM)	dm_{主题域名[_⼆级主题名]|专题}_{⾃定义表名}_{周期后缀}	多主题的数据，可以使 ⽤专题名	例⼦1： dm_hive_or der_gmv_d(hive看板)
			例⼦2： dm_saas_ad _select_d(商家⼴告)

2.5表命名规范

    2.5.1整体原则

表名字要求采⽤⼩写

作业名同表名⼀致

周期后缀：标识增全量、调度周期：

周期后缀标识 （增全量、调度周期）	解释
_h	按⼩时分区（处理⼩时增量）
_all_h	按⼩时分区（处理⼩时全量）
_d	数据按天分区（处理⽇增量）
_all_d	数据按天分区（处理⽇全量）
_m	按⽉分区（处理⽉增量）
_all_m		按⽉分区（处理⽉全量）
_rt		实时增量
_all_rt		实时全量量

     

2.6字段规范

2.6.1命名规范：

1. 原则：字段名尽量详细，易于理解
2. ⼩写：表的字段名字要求采⽤⼩写
3. 继续使⽤原业务系统字段：字段数据、意义没有改变时，原则上，可以使⽤原业务系统字段名字
4. 英⽂字段名组成：[is]_[修饰词]＋字段描述词＋[后缀/度量]＋[时间周期词]，强烈建议保留后缀
5. 中⽂名组成：[时间周期词]＋[修饰词]＋字段描述词＋[度量]
6. 必须以字⺟开头
7. 字段名由字⺟、下划线、数字组成
8. 字段英⽂名⻓度尽量控制在30个字符以内
9. 表⽰是否的字段，⽤is_含义，例如，deal是否可预订，is_apt、is_prepay等。

业务含义是动词时，尽量不⽤使⽤其分词命名,如is_paid，应为is_pay定义：是（1）⾮（0）或 肯（1）否（0），存0、1

1. 基础字段命名：⽤num, amt, cnt, id, type等简写做后缀，如”order_cnt”表⽰订单数

量，“product_id”标⽰产品ID

1. DW内部：相同含义的字段名称、数据类型在正常情况下须保持⼀致，减少使⽤过程中的混淆，避免造成数据流转时不能被抽取或数据截断情况

2.6.2分区字段命名规范

         时间分区命名：

分区名统⼀命名为dp，格式统⼀要求（ods_db前缀的表分区名pt，由于阿⾥产品原因）：

分区类型	分区名及格式	备注
⽇分区	dp=yyyy-mm-dd
⽉分区	dp=yyyy-mm
⼩时分区	hh=00..23	第⼀个⼩时00，最后⼩时23
分钟分区	hhmm=0000..2350	10分钟举例

2.6.3 字段类型

字段类型只使⽤以下⼏种：

int 数量、次数、⼈数等整数字段

bigint 数量、次数、⼈数等整数字段 double ⾦额、⽐率等⼩数字段

string  订单编号、SKU编号、描述类信息、⽇期等字符字段

不使⽤⽐int⼩的数字类型

不使⽤unsigned

2.6.4 ⾼频词根术语

字段的中⽂名称和英⽂名称⽬前由⾼频词根术语表构成，随着数据仓库表和集市应⽤的增加，会不断对字段词根数据字典进⾏完善。如果发现词根数据字典不能满⾜建模需要，则需要通知数仓⼩组进⾏增加。

1. 字段标准化规范简要原则：

时间精确到天的数据统⼀命名：xxx_date（xxx：create、pay...）时间精确到秒的数据统⼀命名：xxx_time（xxx：create、pay...）属性值和外键值命名统⼀：

字段值为外键id的数据统⼀命名：xxx_id（type→type_id）字段值为属性值的数据统⼀命名：xxx（type_id->type） 应⽤id统⼀命名：app_id

单表多个相同含义字段命名⽅式：前缀_xxx（如order_type、coupon_type）产品统⼀命名：（pid）->product_id

⽤⼾ip统⼀命名：

单表只有⼀个ip字段，命名ip单表多个ip字段，命名 功能_ip

地区外键统⼀命名：sy_district_id

⽇期外键统⼀命名：sy_date时间外键统⼀命名：sy_time

字段类型统⼀，在不同表中相同和相似字段的类型统⼀（如时间统⼀为string类型）

业务含义统⼀，业务含义相同的表和字段的统⼀。相同的表：将业务关系⼤、源系统影响差异⼩的的表进⾏整合。如帖⼦、短评都属于帖⼦业务，只是类型不同。

系统字段：sys统⼀表⽰⼿机系统，app_version表⽰app版本等。

公共字段值统⼀与默认值对于多个表都有的字段，进⾏字段值的格式的统⼀。

             2.7模型设计规范

            2.7.1物理模型设计规

           2.7.1.1数仓建模⽅法

分类	说明	新氧是否使⽤	使⽤分层
范式建模法	抽象整合多系统数据，属性标准化，隔离业务系统的影响。多系统场景时建议增加。	否
维度建模法	分星型模式、雪花模型两种。 按照事实表、维表来构建数据仓库、数据集市。	使⽤星型模式	DW层、DM层
事实(实体)建模法	客观世界应该可以分成由⼀个个实体，以及实体与实体之间的关系组成。数仓抽象实体(业务)模型、实体之间关系的模型。	使⽤	DWD层

2.7.1.2通⽤原则

1、模型必须明确注释，标⽰含义

2、不允许依赖上层模型。注意：务必优先从本层或次⼀层获取，尽量减少跨层查询。

3、禁⽌重复建模，注重复⽤，应先在现有模型中搜寻表使⽤或扩展现在模型，如⾮必要避免新增模型，同⼀粒度下相同含义的模型只能有⼀张；

4、注重抽象，如果多个作业的上游重合度较⾼，有相似的加⼯逻辑，可考虑是否将这段业务逻辑抽象成数据模型，⽅便维护同时保障数据⼀致性

5、避免在底层进⾏不同主题间的耦合，将关联放到数据产品和报表中，避免就绪晚的主题影响核⼼数据的产出。

6、不推荐拉链表，使⽤快照表

三、技术选型规范（包括实时开发）

         1.开发语⾔选择

全局考虑后续程序的维护性、开放性、团队技术储备、成本、⼈员流动等因素，特别是关键作业。选择技术语⾔优先级：SQL > Java

        2.技术框架选择

1. 引⼊新技术上线、新业务上线、不同于现有作业处理⽅案，都要召开部⻔评审会（总监

+dba+leader）。

评审会完成⼯作：技术⽅案选型、开发规范、开发demo、模块分⼯

1. 除现有成熟框架外，不得擅⾃应⽤新技术

更新中。。。。。。