数据仓库理论篇
数据仓库Data Warehouse - 数仓是一种思想，数仓是一种规范，数仓是一种解决方案
数据仓库之父Bill Inmon将数据仓库描述为一个面向主题的、集成的、随时间变化的、非易失的数据集合，用于支持管理者的决策过程。 数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持。数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。
主题是一个抽象概念，简单地说就是与业务相关的数据的类别，每一个主题基本对应一个宏观的分析领域。数据仓库则是辅助人们分析数据的设计
数据处理方式
数据处理大致可以分为两大类：
联机事务处理OLTP（On-Line Transaction processing） 联机分析处理OLAP（On-Line Analytical Processing）
OLTP（联机事物处理）
面向于业务(事务)的,主要用于捕获数 据,主要对数据进行CURD操作,存储最近业务 使用数据,交互性强,存储数据量较小。并且满足三范式。
OLAP(联机分析处理)
面向于主题的,主要用于数据分析,对数据进行查询操作,存储过去既定发生过 的数据(历史数据),交互性弱但存储数据量比较 大 可以进行复杂的聚合计算
数据建模
数据建模指的是对现实世界各类数据的抽象组织（就是对数据的一种抽象管理方式），确定数据库需管辖的范围、数据的组织形式等直至转化成现实的数据库。
将经过系统分析后抽象出来的概念模型转化为物理模型
ER模型（关系）
用实体加关系描述的数据模型
特点：规范性较好，冗余度小，但不适合分析数据
遵循三范式： - 列不可再分 - 所有的列必须依赖于主键 - 如果有部分列不依赖于主键，就将这些列重新构建一张表优点：
规范性较好，冗余小，数据集成和数据一致性方面得到重视
缺点：
需要全面了解企业业务、数据和关系；实施周期非常长，成本昂贵；对建模人员的能力要求也非常高。
维度建模
以分析决策的需求构建模型，主要完成用户如何快速完成分析需求 冗余度比较高
维度建模中的重要概念： 事实表: 事实表就是对应主题的表，一般事实表都是由一坨主键聚集而成 表中的每行数据代表一个业务事件 数据非常大定时更新，不保留历史数据 事实表中的每行：具有可加性的数值型的度量值 与维表相连接的外键 通常有两个或两个以上外键: 事务型事实表 周期型快照事实表 累积型快照事实表 维度表: 在分析事实表时，结合了其它表来进行分析，这个其他表就是维度表，是时间的辅助描述信息 一般是对事实的描述信息，一张表对应世界中一个对象或概念 选择业务 > 定义粒度 > 选择维度 > 确定事实 度量值: 度量值是对一次行为的度量 实时发生的对应的一些数据记录 （如一个事件的个数，金额等）
维度建模表分类
在维度建模中，将度量称为“事实” ， 将环境描述为“维度”。
例：今天张三买了一瓶两块的矿泉水 在这里：”今天“、“张三”、“买”、”矿泉水“是维度，“一瓶”，“两块”是事实
维度表
维度表概念:
-
维度是维度建模的基础和灵魂。在维度建模中，将度量称为“事实”，将环境描述为“维 度”，维度是用于分析事实所需要的多样环境。
例如，在分析交易过程时，可以通过买家、卖家、商品和时间等维度描述交易发 生的环境。
-
维度所包含的表示维度的列，称为维度属性。维度属性是查询约束条件、分组和报表
标签生成的基本来源，是数据易用性的关键。
例如，在查询请求中，获取某类目的商品、正常状态的商品等，是通过约束商品 类目属性和商品状态属性来实现的； 统计淘宝不同商品类目的每日成交金额，是通过商品维度的类目属性进行分组 的； 我们在报表中看到的类目、BC类型（B指天猫，C指集市）等，都是维度属性。
所以维度的作用一般是查询约束、分类汇总以及排序等。
-
维度表特征
维度表的范围很宽（具有多个属性、列比较多）
跟事实表相比，行数较少，（通常小于10万条）
内容相对固定
辅助我们分析事实数据，维度的列成为维度的属性，这些也是将要分析数据的重点 特征 维度表的范围很宽，有可能将多维的数据叠加到一起。方便计算 和事实表相比行数比较少--商品 内容相对固定
维度表设计原则
1.维度属性尽量丰富,为数据使用打下基础 上游维度丰富，下游计算才会灵活
2.给出详实的、有意义的文字描述
3.区分数值型属性和事实
4.沉淀出通用的维度属性，为建立一致性维度做好铺垫
5.退化维度(DegenerateDimension) 去除表与表之间的关联数据，直接替换成指定数据
6.缓慢变化维(Slowly Changing Dimensions)
维度的属性会随着时间变化 a直接覆盖原来的值 b拉链表增加三列（有效日期，截止日期，行标识） c增加属性列7.冗余维度.
把常用的维度冗余到事实表
维度设计方法
有则选择，无则创建 -选择或创建维度
选择主维度表
确定相关维度
确定维度属性
第一个阶段是从主维表中选择维度属性或生成新的维度属性
第二个阶段是从相关维表中选择维度属性或生成新的维度属性
维度设计高级主题
-
维度整合
-
垂直整合
-
存储的是相同的数据集，但是存储在不同的表中
-
-
水平整合
-
判断数据是否交叉（重复）去重
-
没有交叉就将信息放在一张表中，需要保留原来的主键信息
-
-
-
水平拆分
-
可以按照类别或类型进行细分
-
-
垂直拆分
-
反规范化处理
-
常用为主，较少为辅
-
事实表
事实表概念
事实表中的每行数据代表一个业务事件。“事实”表示的是业务事件的度量值（可以统计次数、个数、金额等）
粒度: 这个事件发生的一个频度[天- 小时- -分钟] 用什么来衡量？
度量值: 一个变化的数值
可加:页面的PV可以根据时间维度区划维度用户分类维度
半可加:有些维度可以累加，有些维度不可以累加
不可加:空气湿度23.5%及格率0.75 相对维表来说，通常事实表要细长得多,行的增加速度也比维表快很多。
事实表设计原则
原则1:尽可能包含所有与业务过程相关的事实
原则2:只选择与业务过程相关的事实
原则3:分解不可加性事实为可加的组件
原则4:在选择维度和事实之前必须先声明粒度
原则5:在同-个事实表中不能有多种不同粒度的事实---年级班级学校
原则6:事实的单位要保持一致--- 元角分
原则7:对事实的null值要处理
原则8:使用退化维度提高事实表的易用性
事实表设计方法
-
选择业务过程以及确定事实表类型
比如淘宝的订单流转的业务过程有四个：创建订单，买家付款，卖家发货，买家 确认收货
-
明确了业务过程后，根据具体业务需求来选择与维度建模有关的业务过程。
比如买家付款这个业务过程，那么事实表应只包括买家付款这一个业务过程的单 事务事实表 总而言之就是选择了哪些业务过程，那么所建立的事实表应为包含了所有业务过 程的累积快照事实表
-
声明粒度
粒度声明非常重要，尽量选择最细级别的原子粒度，以确保事实表的应用具有最 大的灵活性 比如一次购物车下单，一个父订单可能是购物车，一个子订单是每个商品的订 单，那么订单事实表选择子订单粒度
-
确定维度
完成粒度声明意味着声明了主键，对应的维度组合就可以确定了 应该选择能够清楚描述业务过程的维度信息 例如订单事实表，粒度为子订单，相关的维度有卖家、买家、商品，收货人，时 间等维度
-
确定事实
应该选择与业务过程有关的所有事实，且事实的粒度要和声明的粒度一致，比如 在淘宝订单付款事务事实表中，同粒度的事实有子订单分摊的支付金额、邮费、 优惠金额等
-
冗余维度
大数据的事实表设计中，冗余尽可能多的维度让下游方便使用，减少连表数量
事实表分类
-
事务型事实表： 一次操作即可完成(有一条记录就做一条记录) 如一笔订单 一笔支付记录
-
周期型快照事实表：定时更新实时数据 保留固定时间间隔的数据 如每周销售额
-
累积型快照事实表：需要多次操作才能完成 如送快递 从发出到签收 经过多次时间更新才能完成
数据组织类型
维度建模按数据组织类型划分可分为
星型模型、雪花模型、星座模型。
星型模型
是一种多维的数据关系，它由一个事实表（Fact Table）和一组维表（Dimension Table）组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。
事实表直接来连接维度表，维度表不再分；查询效率高，数据冗余性也高。
雪花模型
他是有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上。
事实表直接连接主维度表，主维度表连接子维度表。冗余性低、灵活度高、查询效率低。
星座模型
多个事实表共享维度表，类似多个星型模型连在一起,减少中间的维表，增加数仓的容量。
模型的选择跟数据和需求有关，跟设计无关， 按实际需求选择
维度建模步骤
-
选择业务处理过程 > 声明粒度 > 选择维度 > 确定事实选
-
选择业务：选择感兴趣的业务线，如下单，支付，退款，活动 。
-
声明粒度：一行代表信息：一条订单？一天的订单？一周的订单？ 选择最小粒度
-
确认维度：维度退化：谁 。 什么时间 什么地点
-
确认事实：度量值：如个数，件数，金额
数据仓库分层
数仓分层原因：
空间换时间：通过预处理来提升用户效率
增加扩展性：不分层，当源业务系统的规则发生变化会影响整个数据清洗
分层管理：通过数据分层简化数据清洗过程，将复杂的工作分成多个步骤
数仓分层优点：
清晰数据结构 方便数据血缘追踪 减少重复开发 把复杂问题简单化 屏蔽原始数据的异常
原始数据层ODS
从各个地方抽取来的源数据 进行简单分类
数据仓库层DW
从ODS层获取的数据按照主题建立各种数据模型
数据服务层ADS
生成具体的报表 供使用者进行分析阿里数仓进化史
ETL
概念：
ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。
-
抽取(Extract) 、
-
将各个系统中的数据统- -汇 聚到ODS过程-买菜
-
-
清洗转换(Transform)
-
清洗掉脏数据，无效数据,对敏感数据空值进行转换
-
-
加载 (Load)
-
将操作之后的数据载入到DW中
-
五大模块： 数据抽取、数据清洗、库内转换、规则检查、数据加载。 各模块可灵活进行组合，形成ETL处理流程。
ETL工具
加载策略
系统日志分析方式：
通过分析数据库自身的日志来判断变化的数据。
触发器方式：
直接进行数据加载利用增量日志表进行增量加载
时间戳方式：
在源表上增加一个时间戳字段，系统中更新修改表数据的时候，同时修改时间戳字段的值。
全表比对方式：
全表比对即在增量抽取时，ETL 进程逐条比较源表和目标表的记录，将新增和修改的记录读取出来。
源系统增量（delta）数据直接或者转换后加载：
日常的 ETL 更新中，还会遇到目标表的数据来源来自于多张源表，通过关键字段的拼接进行更新操作。
如果多张源表都有时间戳字段，可以利用时间戳进行增量更新，另外还可以采用全表比对的方式进行增量更新。
常见概念描述
-
数据仓库:数据仓库是一个功能概念,历史数据的集合体.使用维度建模.存储介质为分布式文件系统 日常倾向于OLAP -
数据集市:数据集市是一个结构概念,小型的数据仓库,多个数据集可以组成数据仓库 面向对象的业务和对应的主题---教务医务图书 -
数据孤岛:业务系统之间各自为政、相互独立造成的数据孤岛,体现在业务不集成流程不互通、数据不共享。在大数据中要打破孤岛，实现数据共享 -
数据湖-数据洋--数据水洼:数据湖是一种数据存储理念，存储企业各种各样的原始数据的大型仓库,包括结构化、非结构、二进制图像、音频、视频等等。 HUDI --- Detal Lake -
数据中台:数据中台是一个逻辑概念,使数据对内优化管理提高业务，对外可以数据合作价值释放 -
宽表窄表:-
宽表：字段比较多的数据库表，方便我们计算
-
窄表：减少了数据的冗余度，相对来说数据就少
-
大数据架构
互联网大数据平台
大数据平台由上到下，可分为三个部分：
数据采集、数据处理、数据输出与展示。
Lambda架构
-
优点：
-
它具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性。 批处理层(Batch Layer)速度处理层(Speed Layer)响应查询的服务层(Serving Layer) 数仓的分层主要是应用于批处理操作，速度处理一般操作很少分层直接计算出最后的结果
-
-
缺点：
-
架构师需要维护两个复杂的分布式系统，井且保证他们逻辑上产生相同的结果输出到服务层中。 -般情况下要维护两套代码，当业务发生变化，实时和离线的计算代码都需要重新编写
-
Kappa架构
速度处理层(Speed Layerf响应查询的服务层(Serving Layer) 每次开启一个新的业务从0开始计算，当新的计算 的数据虽达到老的计算的数据量，就用新的结果
Flume
Flume概述
Flume是一个分布式、可靠、和高可用的海量日志聚合的系统，支持在系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。
Flume： 是一个数据采集工具；可以从各种各样的数据源（服务器）上采集数据传输（汇聚）到大数据生态的各种存储系统中（Hdfs、hbase、hive、kafka）；
Flume使用场景
线上数据一般主要是落地（存储到磁盘）或者通过socket传输给另外一个系统，这种情况下，你很难推动线上应用或服务去修改接口，实现直接向kafka里写数据，这时候你可能就需要flume这样的系统帮你去做传输。
Flume的体系架构
Client（客户端）：Client生产数据，运行在一个独立的线程。
Event（事件）： 一个数据单元，消息头和消息体组成。（Events可以是日志记录、 avro 对象等。）
Flow（流）： Event从源点到达目的点的迁移的抽象。
Agent（代理）： 一个独立的Flume进程(一个Agent就是一个进程)，包含组件Source、 Channel、 Sink。（Agent使用JVM 运行Flume。每台机器运行一个agent，但是可以在一个agent中包含多个sources和sinks。）
Source（源）： 数据收集组件。（source从Client收集数据，传递给Channel）
Channel（通道）： 中转Event的一个临时存储，保存由Source组件传递过来的Event，将数据退送给sink端。（Channel连 接 sources 和 sinks ，这个有点像一个消息队列。）
Sink（存储）： 从Channel中读取并移除Event， 将Event传递到持久化系统或者FlowPipeline中的下一个Agent（如果有的话（Sink从Channel收集数据，运行在一个独立线程。）
selector（选择器）：作用于source端，然后决定数据发往哪个目标
interceptor（拦截器）：flume允许使用拦截器拦截数据，允许使用拦截器链，作用于source和sink阶段
Flume的组件详解
Flume特性
-
复杂流动：Flume允许用户进行多级流动到最终目的地，也允许扇出流（一到多）、扇入流(多到一)的流动和故障转移、失败处理。
Flume优点
当收集数据的速度超过将写入数据的时候，也就是当收集信息遇到峰值时，这时候收集的信息非常 大，甚至超过了系统的写入数据能力，这时候，Flume会在数据生产者和数据收容器间做出调整， 保证其能够在两者之间提供平稳的数据。
Flume的管道是基于事务，保证了数据在传送和接收时的一致性.
Flume是可靠的，容错性高的，可升级的，易管理的，并且可定制的（可以根据生产需要自行定义 一个数据来源端或者终点端）。
除了日志信息，Flume同时也可以用来接入收集规模宏大的社交网络节点事件数据，比如 Facebook、Twitter、电商网站如亚马逊等。
支持多路径流量，多管道接入流量，多管道接出流量，上下文路由等。
Flume执行流程
1 Source 接受数据
2 Channel Processor（通道处理器） 处理 Event
3 Channel Processor 将 Event 传递给 interceptor链对 Event 进行过滤操作
4 过滤完之后再把 Event 发送回 Channel Prodessor
5 Channel Processor把 Event 发送给Channel selectors
6 Channel selector返回Event 属于哪个Channel
7 根据 第6步返回的结果，将Event发送到指定的Channel
8 SinkProcessor从Channel中拉去数据
9 最后把数 据Sink出去
Flume事务
-
推送事务流程
doPut: 把批数据写入到临时缓冲区putList
doCommit: 检查Channel容量是否足够，如果容量足够则把putList里的数据发送到Channel
doRollBack:如果Channel容量不够，则把数据回滚到putList
-
拉取事务流程
doTake:把数据读取到临时缓冲区takeList
doCommit:检查数据是否发送成功，成功的话，则把event从takeList中移除
doRollBack:如何发送失败，则把takeList的数据回滚数据到Channel
-
可靠
只有当sink接收到，数据落地完成的信息之后，才会将数据从通道中删除。
事件在每个代理上的一个通道中上游。然后将事件传递到流中的下一个代理或终端存储库（如HDFS）。仅将事件存储在下一个代理程序的通道或终端存储库中之后，才将其从通道中删除。这就是Flume中单跳消息传递语义如何提供流的端到端可靠性的方式。
数据传输的方式不是byte，而是一个个的event Flume使用事务性方法来确保事件的可靠传递。源和接收器分别在事务中封装存储在通道中或由通道提供的事务中提供的事件的存储/检索。这确保了事件集在流中从点到点可靠地传递。在多跳流的情况下，来自上一跳的接收器和来自 下一跳的源均运行其事务，以确保将数据安全地存储在下一跳的通道中。
-
可恢复
当数据丢失了，只有从存储在磁盘的方式，才能将数据找回 事件在通道中上演，该通道管理从故障 中恢复。Flume支持持久的文件通道，该通道由本地文件系统支持。还有一个内存通道可以将 事件简单地存储在内存队列中，这虽然速度更快，但是当代理进程死亡时，仍保留在内存通道 中的任何事件都无法恢复。