目录
背景
面临问题 解决方案
数仓架构演进
离线数仓架构
案例
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数仓架构
案例
问题点
同样的需求开发维护两套代码逻辑，批和流两套逻辑代码都 需要开发和维护，并且需要维护合并的逻辑，需同时上线。
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来做，介绍文章如下
如果想要自研也可以，其实做血缘其实就是知道表与表之间关系，是如何转化得来的。核心其实就是拦截解析任务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进行二次开发
