目录
背景
1：数据存在孤岛，烟囱式开发。导致指标混乱，重复开发，数据冗余。
2：数据分布在不同数据库或者所有都杂在一起，层次不清晰。
3：数据没有沉淀，很多时候重复计算导致数据冗余
4：定义不规范，没有统一规范。
这个时候数仓就应运而生。
面临问题 解决方案
表命名逻辑不清晰 逻辑分层（约定表名）
数据孤岛，烟囱式开发 维度建模（主题域划分，沉淀中间结果）
找表难 数据地图（查看表，元数据，数据血缘关系）
指标定义混乱，存在重复 指标字典（命名规范管理，统一口径规则） DB表全量同步，效率低下 增量表（设计拉链表，订阅Binlog日志）
各部门自建数仓 共享数仓（共享DW层，自建DM层）
数仓架构演进
经典数仓架构----------------------->1990年提出的数仓概念
随着数据量急速增多演变如下
离线大数据架构-------------------->互联网时代数据量爆炸，且诞生了很多大数据工具
随着实时需求的增加演变如下
lambda架构------------------------->在原有功能上增加了实时的功能
因为业务需求以及希技术栈统一演变如下
kappa架构---------------------------->流批一体，业务核心转向实时
离线数仓架构
核心就是通过离线方式将数据导入数仓中。数据处理方式常用的就是MR，HSql，SparkSql以及一些集成组件比如DataX，kettle，Sqoop等。
案例
Lambda数仓架构
案例
问题点
1：同样的需求开发维护两套代码逻辑，批和流两套逻辑代码都 需要开发和维护，并且需要维护合并的逻辑，需同时上线。
2：资源浪费，同样的计算逻辑计算两次，整体资源占用会增多。
3：数据具有二义性：两套计算逻辑，实时数据和批量数据容易对不上。准确性难以分辨，且不好排查。
Kappa数仓架构
架构选型
实际上大部分公司还是会采用Lambda架构，并不是很多任务需要很实时，而且有些财力人力不支持。
数仓整体架构（图片来自网络）
数仓分层架构（图片来自网络）
主题域划分
可以按照如下方式划分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端+登陆人数
指标管理流程图
数仓建库表规范
如果数据量非常大，每一层表很多。则根据数仓分层建库，比如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。
基于数据湖数仓架构
数据湖的未来
数据湖技术选型
市面上目前常规的有三个数据湖技术组件
开源产品对比
产品热度
一般来说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进行二次开发
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
