大数据中台架构以及建设全流程二（Daas层设计）

目录

背景

面临问题                                解决方案

数仓架构演进

离线数仓架构

案例

 Lambda数仓架构

案例

​

问题点 

Kappa数仓架构

架构选型

数仓整体架构（图片来自网络）​

数仓分层架构（图片来自网络）

 主题域划分

维度建模

需求标准化

 维度及指标规范管理

指标管理流程图

数仓建库表规范

字段规范

实时数仓

实时数仓1.0

​缺点：

实时数仓2.0

实时数仓3.0

数据地图

血缘关系

数据湖

离线数仓痛点

实时数仓痛点

数据湖vs数仓

写实模式和读诗时模式

基于数据湖数仓架构

数据湖的未来

 数据湖技术选型

---

背景

1：数据存在孤岛，烟囱式开发。导致指标混乱，重复开发，数据冗余。

2：数据分布在不同数据库或者所有都杂在一起，层次不清晰。

3：数据没有沉淀，很多时候重复计算导致数据冗余

4：定义不规范，没有统一规范。

这个时候数仓就应运而生。

面临问题                                解决方案

表命名逻辑不清晰                                        逻辑分层（约定表名）

数据孤岛，烟囱式开发                                 维度建模（主题域划分，沉淀中间结果）

找表难                                                           数据地图（查看表，元数据，数据血缘关系）

指标定义混乱，存在重复                              指标字典（命名规范管理，统一口径规则）                 DB表全量同步，效率低下                            增量表（设计拉链表，订阅Binlog日志） 

各部门自建数仓                                             共享数仓（共享DW层，自建DM层）

数仓架构演进

经典数仓架构----------------------->1990年提出的数仓概念

随着数据量急速增多演变如下

离线大数据架构-------------------->互联网时代数据量爆炸，且诞生了很多大数据工具

随着实时需求的增加演变如下

lambda架构------------------------->在原有功能上增加了实时的功能

因为业务需求以及希技术栈统一演变如下

kappa架构---------------------------->流批一体，业务核心转向实时

离线数仓架构

核心就是通过离线方式将数据导入数仓中。数据处理方式常用的就是MR，HSql，SparkSql以及一些集成组件比如DataX，kettle，Sqoop等。

案例

 Lambda数仓架构

案例

问题点 

        1：同样的需求开发维护两套代码逻辑，批和流两套逻辑代码都 需要开发和维护，并且需要维护合并的逻辑，需同时上线。

        2：资源浪费，同样的计算逻辑计算两次，整体资源占用会增多。

        3：数据具有二义性：两套计算逻辑，实时数据和批量数据容易对不上。准确性难以分辨，且不好排查。

Kappa数仓架构

        Lambda架构解决了实时性的问题，随着业务的发展，很多业务都以实时性为主，再加上Flink等引擎的成熟，为了解决Lamdba架构的问题，提出了Kappa架构。

Lambda vs Kappa

架构选型

 实际上大部分公司还是会采用Lambda架构，并不是很多任务需要很实时，而且有些财力人力不支持。

数仓整体架构（图片来自网络）

数仓分层架构（图片来自网络）

1、ods：操作数据层（Operational Data Store），脏数据清理，加密数据等，全量数据存储。

2、dwd：明细数据层（Data Warehouse Detail），维度合并实时表，提高明细表易用性。稳定的维度可以选择退化，异变的选择不退化。或者只保留维度组件采用星型模型。

3、dwm：中间层层（Data Warehouse Middle），可有可无，根据实际情况创建。存储中间过程数据。

4、dws：汇总数据层（Data Warehouse Summary），数据大宽，构建公共指标体系。

5、ads：应用数据层（Application Data Store）个性化产品指标数据

6、dim，维度数据层

 主题域划分

可以按照如下方式划分2主题域

负责人:xxx           时间:2021-xx-xx          xx     xx
	业务主题 数据主题		全平台	中台	表单	小程序	App	...
张三	交易	新增卖家	√	√	√	√	√
		新增买家	√	√	√	√	√
		交易额	√	√	√	√	√
李四	用户	注册用户	√	√		√	√
		活跃用户	√	√			√
王五	产品	设备		√	√
		物料		√	√
		备件		√	√

维度建模

strep1：数据调研，需求分析（确定业务模块，数据域。比如用户域，产品域，交易域）

strep2：构建维度*事实总线矩阵（明确业务过程（业务总做，比如点检，保养，开关机，商品场景下的下单，支付等），业务过程与维度之间关系）

step3：维度*事实模型设计（构建dw事实明细表，DM主题明细）

step4：明确统计指标

        原子指标=业务过程+度量 比如登陆人数，支付订单数，执行开关机操作人数

        派生指标=时间周期+修饰词+原子指标，比如最近七天全平台登陆人数，最近一天执行开关机操作人数。最近一个月App端登陆人数

step5：Ads层指标结果表设计，一般在关系型数据库或者Nosql数据库等查询比较快的DB

维度总线矩阵构建方式如下

负责人:xxx           时间:2021-xx-xx          xx     xx	一致性维度
	维度 数据域*业务过程		省市区	销售渠道	性别	行业分类	...
张三	设备	开关机	√	√		√	√
		点检	√	√		√	√
		保养	√	√		√	√
李四	用户	注册用户	√	√		√	√
		活跃用户	√	√		√	√
王五	产品	设备	√	√		√
		物料	√	√		√
		备件	√	√		√

需求标准化

标准化流程

 维度及指标规范管理

派生指标=时间周期+修饰词+原子指标

举个栗子：过去一个月App端登录用户数 = 过去一个月（时间周期）+App端+登陆人数

日期周期：派生指标的日期聚合粒度；如：当天，过去7天，过去30天，其中以「当天」最为普遍

修饰词：用于对原子指标的修饰，包含对业务的修饰、场景修饰等；如：阿里、手机、回收都属于

修饰词

原子指标：指标的最细颗粒度描述，规则为：业务动作+度量值；如：支付+订单数=支付订单数

指标管理流程图

数仓建库表规范

        如果数据量非常大，每一层表很多。则根据数仓分层建库，比如dw_公司名_dim，dw_公司名_dwd，dw_公司名_ods。每一层一个库。

        如果表并不多，其实也可以把所有层的放到一个库里面。根据表明区别层级。

业务规范	数据模型层次	数据库名字	含义	物理表命名规范	数据存储格式	样例
业务数据	ODS	dw_xxx_ods	数据贴源层，数据从各业务数据库来。 保持不变	ods_数据源_更新方式_时间粒度	Text	ods_mysql_inc_1d/ods_mysql_full_1d
数据仓库	DWD	dw_xxx_dwd	经过etl后的基础事实明细表	dwd_数据源_业务过程_更新方式_时间粒度 如果是多数据源聚合而得 dwd_业务过程_更新方式_时间粒度	Parquet+snappy	dwd_msql_login_inc_1d
	DWM	dw_xxx_dwm	根据业务主题分析的中间过程表	dwm_业务主题_更新方式_时间粒度
	DIM	dw_xxx_dim	维度字典	dim_维度类型_更新方式_时间粒度	Text	dim_city_full_1d
数据集市	DWS	dw_xxx_dws	按数据/主题专题进行分析的轻度汇总数据	dws_业务主题域_业务过程_更新方式_时间粒度	Parquet+snappy	dws_eqp_check_full_1d(设备主题，维修过程)
数据产品	ADS	dw_xxx_ads	数仓提供给业务方使用的数据，可直接同步dws层也可以再通过dws聚合而来	ads_业务主题域/数据主题域_业务过程_更新方式_时间粒度	Text/Parquet	ads_运营数据分析_full_30d

字段规范

实时数仓

实时数仓1.0

缺点：

        1：Kafka无法支持海量数据存储

        2：Kafka无法支持Olap查询

        3：Kafka无法像离线数据那样维护血缘关系

        4：Kafka无法支持数据更新删除

实时数仓2.0

 数据实时跟离线各走各只是数据全部统一落地到数据湖（常用技术栈比如Hudi）中，一次性解决了1.0的所有缺点。还能自动合并小文件节省存储空间。

实时数仓3.0

3.0跟20其实就是统一了技术栈，流批一体，使用flink或者sparkstreaming都可以。

好处是Sql统一，技术栈统一。

数据地图

在进行大数据治理时候，当然希望能够通过筛选，查询得到数据表的分类，建表语句，字段类型，血缘关系详细信息等。要做这么一个管理界面，其实是从建表源头时候就要控制通过页面建表，能够获取表的所有基础信息以及字段信息。

血缘关系

使用开源组件atlas来做，介绍文章如下

数据治理之元数据管理的利器——Atlas入门宝典 - 独孤风 - 博客园 (cnblogs.com)。

如果想要自研也可以，其实做血缘其实就是知道表与表之间关系，是如何转化得来的。核心其实就是拦截解析任务sql进行解析，但是挺麻烦，有开源的为什么不用开源的呢。

数据湖

前面不论离线数仓还是实时数仓，都存在一些问题。

1：技术栈不统一:

2：想要纯实时就数据无法更新修改，且无法存储大量数据:

3：不支持非结构化数据，依赖etl过程处理成结构化。（实际上有些数据当时并不知道该怎么用，只是想留存下来以后使用）比如日志，音频，图片。

离线数仓痛点

1：字段变更后，历史数据涉及到重跑覆盖。利用数据湖的读诗时模式可以解决

2：lambda架构数仓merge成本太高需使用额外uperset存储，不同存储之间涉及数据打通

3：实时分支里面，kafka无法保留海量数据，基于历史数据分析不好做。

实时数仓痛点

数仓方案1.0

 痛点：没有模型，数据不能复用，浪费资源

数仓2.0

优点：数据模型可复用，整体延迟低。

痛点：kafka无法存储海量数据，默认存储7天，且无法基于中间层模型进行分析。 

数据湖vs数仓

数据湖

1:数据价值无需提前明确

2：数据存储之后才需要定义schema

3：存储原始数据，可存储结构化，半结构化数据

4：低成本开销获得容量扩展

5：敏捷简单数据集成，支持编程框架

6：灵活构建，成本低，可复用资产

数仓

1：数据价值必须提前明确

2：数据存储之前必须定义好schema

3：只存储清洗后数据，结构化数据

4：中等成本开销能获得较大容量扩展

5：仅能支持统计，报表以及传统bi

6：重量级构建，时间成本高。

写实模式和读诗时模式

写时模式----------------->数据在写入前需定义好Schema，数据都按照schema写入。

读时模式----------------->数据在写入时候不需要定义schema，在需要时候再定义schema使用。有点类似dataframe

所以数据湖可以无成本修改schema，同一套数据不同的schema。

基于数据湖数仓架构

数据湖的未来

事务支持

企业内部许多数据管道通常会并发读写数据。对ACID事务的支持确保了多方并发读写数据时的一致性问题

•Schema enforcement and governance(模式实施和治理)

未来能更好的管理元数据，schema管理和治理，不让数据湖变成沼泽地

•BI支持

Lakehouse可以直接在源数据上使用BI工具

•开放性

使用的存储格式是开放式和标准化的（如parquet），并且为各类工具和引擎，包括机器学习和Python/R库，提供API，

以便它们可以直接有效地访问数据

•支持从非结构化数据到结构化数据的多种数据类型

•支持多种工作负载

包括数据科学、机器学习以及SQL和分析

•端到端流

为了构建Lake house，需要一个增量数据处理框架，例如Apache Hudi。

 数据湖技术选型

市面上目前常规的有三个数据湖技术组件

 开源产品对比

 产品热度

 一般来说Hudi比较流行。

使用案例

使用Apache Spark和Apache Hudi构建分析数据湖 - 知乎

数据查询平台

        当我们有了数仓，以及在开发和使用数仓过程中我们需要对数据进行查询，校验，使用。总不能每次都打开shell界面进去查询，这样不便于权限管理以及展示。

        所以我们需要一个平台提供给各部门使用，能够查看HDFS文件，sql查询数仓，Hive元数据查询。

目前市面上常用的组件有Hue

gethue.com（测试页面）

界面如下

 该组件基本满足日常需求，且功能很丰富满足大部分公司使用。

但是也有一些缺点

1：没有汉化版本

2：功能过多，使用成本高

3：HDFS不支持中文

4：HDFS个别压缩文件格式不支持浏览

5：HDFS查询不支持高可用

6：HiveSql不支持高可用

7：SparkSql不支持高可用

8：Hive和sparkSql元数据未打通

需要基于Hue进行二次开发