数据仓库理论篇_思维导图模板

数据仓库理论篇

简介

数仓是一种思想，数仓是一种规范，数仓是一种解决方案

比喻：数据仓库可以理解就是一个使用仓库，数据就是这个仓库的货物数据仓库的开发人员就是这个仓库的管理员，所以数据仓库就是一个怎么管理好数据，使得数据规范的放在仓库中便于BI、AI等其他的使用数据的方面可以更好的使用仓库里面的数据，使得数据发挥出更好的价值，显而易见在一堆有规律，整齐的货物里面找一个东西，要比在没有整理的里面找更加有效率。

四大特性

主题性

数据仓库是一般从用户实际需求出发，将不同平台的数据源按设定主题进行划分整合，与传统的面向事务的操作型数据库不同，具有较高的抽象性。面向主题的数据组织方式，就是在较高层次对分析对象数据的一个完整、统一并一致的描述，能完整及统一地刻画各个分析对象所涉及的有关企业的各项数据，以及数据之间的联系。

集成性

数据仓库中存储的数据大部分来源于传统的数据库，但并不是将原有数据简单的直接导入，而是需要进行预处理。这是因为事务型数据中的数据一般都是有噪声的、不完整的和数据形式不统一的。这些“脏数据”的直接导入将对在数据仓库基础上进行的数据挖掘造成混乱。“脏数据”在进入数据仓库之前必须经过抽取、清洗、转换才能生成从面向事务转而面向主题的数据集合。数据集成是数据仓库建设中最重要，也是最为复杂的一步。

稳定性

数据仓库中的数据主要为决策者分析提供数据依据。决策依据的数据是不允许进行修改的。即数据保存到数据仓库后，用户仅能通过分析工具进行查询和分析，而不能修改。数据的更新升级主要都在数据集成环节完成，过期的数据将在数据仓库中直接筛除。

动态性

数据仓库数据会随时间变化而定期更新，不可更新是针对应用而言，即用户分析处理时不更新数据。每隔一段固定的时间间隔后，抽取运行数据库系统中产生的数据，转换后集成到数据仓库中。随着时间的变化，数据以更高的综合层次被不断综合，以适应趋势分析的要求。当数据超过数据仓库的存储期限，或对分析无用时，从数据仓库中删除这些数据。关于数据仓库的结构和维护信息保存在数据仓库的元数据(Metadata)中，数据仓库维护工作由系统根据其中的定义自动进行或由系统管理员定期维护。

数据处理方式

联机事务处理OLTP

联机事务处理，典型代表是关系型数据库(mysql)，它的数据存储在服务器本地的文件里

联机分析处理OLAP

联机分析处理，OLAP型数据库的典型代表是分布式文件系统(hive)，它的数据存储在HDFS集群里

主要区别

数据分析体系与其他业务类系统有着显著的不同。

1、基本含义不同：OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，记录即时的增、删、改、查，比如在银行存取一笔款，就是一个事务交易。OLAP即联机分析处理，是数据仓库的核心部心，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。典型的应用就是复杂的动态报表系统。

2、实时性要求不同：OLTP实时性要求高，OLTP 数据库旨在使事务应用程序仅写入所需的数据，以便尽快处理单个事务。OLAP的实时性要求不是很高，很多应用顶多是每天更新一下数据。

3、数据量不同：OLTP数据量不是很大，一般只读/写数十条记录，处理简单的事务。OLAP数据量大，因为OLAP支持的是动态查询，所以用户也许要通过将很多数据的统计后才能得到想要知道的信息，例如时间序列分析等等，所以处理的数据量很大。

4、用户和系统的面向性不同：OLTP是面向顾客的,用于事务和查询处理。OLAP是面向市场的,用于数据分析。

5、数据库设计不同：OLTP采用实体-联系ER模型和面向应用的数据库设计。OLAP采用星型或雪花模型和面向主题的数据库设计。

数据建模

简介

数据建模指的是对现实世界各类数据的抽象组织，确定数据库需要管辖的范围、数据的组织形式等直至转化成现实的数据库。

将经过系统分析后抽象出来的概念模型转化为物理模型

访问性能：良好的模型能帮我们快速查询需要的数据，减少数据的IO吞吐

数据成本：减少数据冗余、计算结果复用、从而降低存储和计算成本

使用效率：改善用户使用数据的体验，提高使用数据的效率

数据质量：改善统计口径的不一致性，减少数据计算错误的可能性，提供高质量的、一致的数据访问平台

ER建模

三大范式

列不可再分

消除部分依赖

消除传递依赖

优点

规范性较好，冗余小，数据集成和数据一致性方面得到重视

缺点

需要全面了解企业业务、数据和关系；实施周期非常长，成本昂贵；对建模人员的能力要求也非常高，容易烂尾。

维度建模

维度建模以分析决策的需求构建模型，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。

事实表

事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、件数、金额等），例如，订单事件中的下单金额。

维度表

一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。例如：用户、商品、日期、地区等

维表的特征：
维表的范围很宽（具有多个属性、列比较多）
跟事实表相比，行数相对较小：通常< 10万条
内容相对固定：编码表
维度表可以看作用户分析数据的窗口,维度表中包含事实数据表中事实记录的特性,有些特性提供描述性信息,有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息。

维度表包含帮助汇总数据的特性的层次结构，维度是对数据进行分析时特有的一个角度，站在不同角度看待问题，会有不同的结果。

度量值

度量值是对一次行为的度量

优缺点

优点：技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，较好的大规模复杂查询的响应性能

缺点：维度表的冗余会较多，视野狭窄

案例分析

ER建模是面向应用，遵循第三范式，以消除数据冗余为目标的设计技术。

维度建模是面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计技术。

事实维度度量

https://zhuanlan.zhihu.com/p/68771422

维度建模表分类

在维度建模中，将度量称为“事实” ，将环境描述为“维度”。

今天张三买了一瓶两块的矿泉水

在这里：”今天“、“张三”、“买”、”矿泉水“是维度，“一瓶”，“两块”是事实

维度表

维度定义

从某个角度观察事实数据的窗口，存储的数据用来从某个角度描述事实。维度表可以看成是用户用来分析一个事实的窗口，它里面的数据应该是对事实的各个方面描述，比如时间维度表，它里面的数据就是一些日，周，月，季，年，日期等数据，维度表只能是事实表的一个分析角度。换句话说维度表可以看作是用户来分析数据的窗口，维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构。

维度的构成

维度的元素：维度的取值，即维度中的各个数据元素的取值。例如，地区维度中具体的成员有英国、法国、德国。

维度表设计原则

维度属性尽量丰富，为数据使用打下基础

维度越细，在为下游的数据中统计、分析和查询时效率就会变高

给出详实的、富有意义的文字描述

属性不应该是编码，而应该是真正的文字。在间里巴巴维度建模中，一般是编码和文字同时存在，比如商品维度中的商品ID 和商品标题、类目ID和类目名称等。 ID一般用于不同表之间的关联，而名称一般用于报表标签

区分数值型属性和事实

数值型宇段是作为事实还是维度属性，可以参考字段的一般用途。

如果通常用于查询约束条件或分组统计，则是作为维度属性

比如商品价格，可以用于查询约束条件或统计价格区间的商品数量，此时是作为维度属性使用的

如果通常用于参与度量的计算，则是作为事实。

也可以用于统计某类目下商品的平均价格，此时是作为事实使用的。

沉淀出通用的维度属性，为建立一致性维度做好铺垫

有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通过单表的不同宇段混合处理得到，或者通过对单表的某个字段进行解析得到。此时，需要将尽可能多的通用的维度属性进行沉淀。

退化维度

在维度类型中，有一种重要的维度称作为退化维度。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。

缓慢变化维

维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD），缓慢变化维一般使用代理健作为维度表的主健。

处理方式

直接覆盖原值 -- 不看历史数据，简单粗暴

拉链表 -- 需要在维度行再增加三列：有效日期、截止日期、行标识（可选）。

增加属性列

冗余维度

为了提升效率，把常用的维度冗余到事实表

事实表

事实表概念

事实表中的每行数据代表一个业务事件。“事实”表示的是业务事件的度量值（可以统计次数、个数、金额等）

事实表中一条记录所表达的业务细节程度被称为粒度。通常粒度可以通过两种方式来表述：

一种是维度属性组合所表示的细节程度：

一种是所表示的具体业务含义。

相对维表来说，通常事实表要细长得多，行的增加速度也比维表快很多。

维度属性也可以存储到事实表中，这种存储到事实表中的维度列被称为“退化维度”。与其他存储在维表中的维度一样，退化维度也可以用来进行事实表的过滤查询、实现聚合操作等。

事实表设计原则

原则 1：尽可能包含所有与业务过程相关的事实

分析哪些事实与业务过程相关，是设计过程中非常重要的关注点；

在事实表中，尽量包含所有与业务过程相关的事实，即使存在冗余，由于事实通常是数字型，存储开销不会太大；

原则 2：只选择与业务过程相关的事实

如，订单的下单这个业务过程，事实表中不应该存在支付金额这个表示支付业务过程的事实；

原则 3：分解不可加性事实为可加的组件

如，订单的优惠率，应分解为订单原价金额与订单优惠金额两个事实存储在事实表中；

原则 4：在选择维度和事实之前必须先声明粒度

粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性；

每个维度和事实必须与所定义的粒度保持一致；

设计事实表时，粒度定义越细越好，一般从最低级别的原子粒度开始；

因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求；

原则 5：在同一个事实表中不能有多种不同粒度的事实

疑问：怎么判断不同事实的粒度是否相同？

粒度为票一级；（实际业务中，一个订单可以同时支付多张票）

票支付金额和票折扣金额，两个事实的粒度为 “票级”，与定义的粒度一致；

订单支付金额和订单票数，两个事实的粒度为 “订单级”，属于上一层订单级数据，与 “票级”事实表的粒度不一致，且不能进行汇总；

如果，以订单金额和订单票数这两个维度汇总总金额和总票数，会造成大量的重复计算；

原则 6：事实的单位要保持一致

如，订单金额、订单优惠金额、订单运费这 3 个事实，应该采用统一的计量单位，统一为元或者分，以方便使用；

原则 7：对事实的 null 值要处理

原因：在数据库中，null 值对常用数字型字段的 SQL 过滤条件都不生效；如，大于、小于、等于、大于或等于、小于或等于；

处理：用 0 代替 null ；

原则 8：使用退化维度提高事实表的易用性

事实表中存储各种类型的常用维度信息，较少下游用户使用时关联多个表的操作；

通过退化维度，可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等；

易用性：对事实表，更较少关联操作、过滤查询、控制聚合层次、排序数据、定义主从关系等；

事实表设计方法

1. 选择业务过程以及确定事实表类型

1. 比如淘宝的订单流转的业务过程有四个：创建订单，买家付款，卖家发货，买家确认收货

2. 明确了业务过程后，根据具体业务需求来选择与维度建模有关的业务过程。

3. 比如买家付款这个业务过程，那么事实表应只包括买家付款这一个业务过程的单事务事实表

4. 总而言之就是选择了哪些业务过程，那么所建立的事实表应为包含了所有业务过程的累积快照事实表

3. 声明粒度

1. 粒度声明非常重要，尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性

2. 比如一次购物车下单，一个父订单可能是购物车，一个子订单是每个商品的订单，那么订单事实表选择子订单粒度

4. 确定维度

1. 完成粒度声明意味着声明了主键，对应的维度组合就可以确定了

2. 应该选择能够清楚描述业务过程的维度信息

3. 例如订单事实表，粒度为子订单，相关的维度有卖家、买家、商品，收货人，时间等维度

5. 确定事实

1. 应该选择与业务过程有关的所有事实，且事实的粒度要和声明的粒度一致，比如在淘宝订单付款事务事实表中，同粒度的事实有子订单分摊的支付金额、邮费、优惠金额等

6. 冗余维度

1. 大数据的事实表设计中，冗余尽可能多的维度让下游方便使用，减少连表数量

事实表分类

事务型事实表

以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。

一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

单事务事实表：

单事务事实表，顾名思义，即针对每个业务过程设计一个事实表，这样设计的优点不言而喻，可以方便地对每个业务过程进行独立的分析研究。

多事务事实表：

多事务事实表，将不同的事实放到同一个事实表中，即同一个事实表包含不同的业务过程，多事务事实表在设计时有两种方法进行事实的处理：

周期型快照事实表

周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，以具有规律性的、可预见的时间间隔记录事实。

例如每天或每月的总销售金额，或每月的账户余额等。

累积型快照事实表

累积快照事实表用于跟踪业务事实的变化，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点。

例如数据仓库中可能需要累积或者存储订单从下单开始，到订单商品被打包、运输、签收等各个业务阶段的时间点数据，来跟踪订单生命周期的进展情况。

数据组织类型

维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。

星型模型

一个事实表拥有着多个维度表，每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。

存在数据冗余问题。

例如：地域表湖南省株洲市天元区，湖南省株洲市石峰区，湖南省和株洲市信息分别存储了两次，即存在冗余

雪花模型

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。

优点 : 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。

雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的维度表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。如图，将地域维表又分解为国家，省份，城市等维表。

星座模型

星座模型是由星型模型延伸而来，星型模型是基于一张事实表而星座模式是基于多张事实表，并且共享维度表信息，这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故亦被称为星系模型

对比

模型选择

模型的选择跟数据和需求有关系，跟设计没关系。

星型还是雪花，取决于性能优先，还是避免冗余、灵活更优先。

实际企业开发中，一般不会只选择一种，需要根据情况灵活组合，甚至并存（一层维度和多层维度都保存）。

整体来看，更倾向于维度更少的星型模型。尤其是大型数据仓库项目，减少表连接的次数，可以显著提升查询效率。

维度建模步骤

选择业务> 声明粒度 > 选择维度 > 确定事实

选择业务：选择感兴趣的业务线，如下单，支付，退款，活动。

维度建模是紧贴业务的，所以必须以业务为根基进行建模，那么选择业务过程，顾名思义就是在整个业务流程中选取我们需要建模的业务，根据运营提供的需求及日后的易扩展性等进行选择业务。

比如商城，整个商城流程分为商家端，用户端，平台端，运营需求是总订单量，订单人数，及用户的购买情况等，我们选择业务过程就选择用户端的数据，商家及平台端暂不考虑。业务选择非常重要，因为后面所有的步骤都是基于此业务数据展开的

声明粒度：一行代表信息：一条订单？一天的订单？一周的订单？选择最小粒度

先举个例子：对于用户来说，一个用户有一个身份证号，一个户籍地址，多个手机号，多张银行卡，那么与用户粒度相同的粒度属性有身份证粒度，户籍地址粒度，比用户粒度更细的粒度有手机号粒度，银行卡粒度，存在一对一的关系就是相同粒度。

为什么要提相同粒度呢，因为维度建模中要求我们，在同一事实表中，必须具有相同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据建立不同的事实表。并且从给定的业务过程获取数据时，强烈建议从关注原子粒度开始设计，也就是从最细粒度开始，因为原子粒度能够承受无法预期的用户查询。

但是上卷汇总粒度对查询性能的提升很重要的，所以对于有明确需求的数据，我们建立针对需求的上卷汇总粒度，对需求不明朗的数据我们建立原子粒度。

确认维度：维度退化：谁。什么时间什么地点

维度表是作为业务分析的入口和描述性标识，所以也被称为数据仓库的“灵魂”。在一堆的数据中怎么确认哪些是维度属性呢，如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性往往是维度属性，数仓工具箱中告诉我们牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开，并且要确保维度表中不能出现重复数据，应使维度主键唯一

确认事实：度量值：如个数，件数，金额

事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。

维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实。

数据仓库分层

数仓分层原因

用空间换时间

通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量的冗余数据；

增强扩展性

不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大

分层管理

通过数据分层管理可以简化数据清洗的过程，因为把原来的一步工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误时，往往我们只需要局部调整某个步骤即可。

数仓分层优点

清晰数据结构

每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。

方便数据血缘追踪

简单来说，我们最终给业务呈现的是一个能直接使用业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。

减少重复开发

规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。

把复杂问题简单化

将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

屏蔽原始数据的异常

屏蔽业务的影响，不必改一次业务就需要重新接入数据

数仓分层明细

数据分层每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上数据分为三个层

原始数据层ODS

Operate data store（操作数据存储层）

该层最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就经过ETL之后，装入ODS层。

数据仓库层DW

Data warehouse（数据仓库）

该层从ODS层中获得的数据按照主题建立各种数据模型。

例如以研究人的旅游消费为主题的数据集中，可以结合航空公司的登机出行信息和银联系统的刷卡记录进行结合分析，产生数据集。

四个概念：维（dimension）、事实（Fact）、指标（Index）和粒度（ Granularity）。

维度

维度表是事实表不可或缺的组成部分。维度表包含业务过程度量事件有关的文本环境。他用来描述与"谁、什么、哪里、何时、如何、为什么"有关的事件。

事实

事实涉及来自业务过程的度量，基本都以数量值表示。一个事实表行与粒度存在一对一关系。

指标

指标是业务流程节点上的一个数值。比如销量，价格，成本等等。

粒度

粒度就是业务流程中对度量的单位，比如商品是按件记录度量，还是按批记录度量。

数据服务层ADS

Application Data Service(应用数据服务)。

该层主要是提供数据产品和数据分析使用的数据，一般会存放在ES、MySQL等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。

例如：我们经常说的报表数据，一般就放在这里

模型层级

阿里巴巴的数据团队把表数据模型分为三层：操作数据层（ODS）、公共维度模型层（CDM）和
应用数据层（ADS），公共维度模型层包括明细数据层（DWD）和汇总数据层（DWS）。

操作数据层（ODS）

把操作系统数据几乎无处理地存放在数据仓库系统中。

公共维度模型层（CDM）

存放明细事实数据、维表数据及公共指标汇总数据，其中明细事实数据、维表数据一般根据ODS层数据加工生成：公共指标汇总数据一般根据维表数据和明细事实数据加工生成。

CDM层又细分为DWD层和DWS层，分别是明细数据层和汇总数据层，采用维度模型方法作为理论基础，更多地采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性：同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。

应用数据层（ADS）

存放数据产品个性化的统计指标数据，根据CDM层与ODS层加工生成。

ETL

概念描述

ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。

五大模块

数据抽取、数据清洗、库内转换、规则检查、数据加载。

各模块可灵活进行组合，形成ETL处理流程。

模块介绍

数据抽取【Extract】

确定数据源，需要确定从哪些源系统进行数据抽取

定义数据接口，对每个源文件及系统的每个字段进行详细说明

确定数据抽取的方法：是主动抽取还是由源系统推送？是增量抽取还是全量抽取？是按照每日抽取还是按照每月抽取？

数据清洗转换【Transform】

通常的做法是从业务系统到ODS做清洗，将脏数据和不完整数据过滤掉，在从ODS到DW的过程中转换，进行一些业务规则的计算和聚合。

数据清洗

数据清洗的任务是过滤那些不符合要求的数据，将过滤的结果交给业务主管部门，确认是否过滤掉还是由业务单位修正之后再进行抽取。

不符合要求的数据主要是有不完整的数据、错误的数据、重复的数据三大类。

数据转换

数据转换的任务主要进行不一致的数据转换、数据粒度的转换，以及一些商务规则的计算。

空值处理：可捕获字段空值，进行加载或替换为其他含义数据，或数据分流问题库

数据标准：统一元数据、统一标准字段、统一字段类型定义

数据拆分：依据业务需求做数据拆分，如身份证号，拆分区划、出生日期、性别等

数据验证：时间规则、业务规则、自定义规则

数据替换：对于因业务因素，可实现无效数据、缺失数据的替换

数据关联：关联其他数据或数学，保障数据完整性

数据装载【Load】

装载主要是将经过转换的数据装载到数据仓库里面，可以通过直连数据库的方式来进行数据装载，可以充分体现高效性。

在应用的时候可以随时调整数据抽取工作的运行方式，可以灵活的集成到其他管理系统中。

ETL工具

ETL是数据整合解决方案，说小了，就是倒数据的工具。

ETL工具（sqoop，DataX，Kettle，canal，StreamSets）

sqoop

是Apache开源的一款在Hadoop和关系数据库服务器之间传输数据的工具。

将一个关系型数据库（MySQL ,Oracle等）的数据导入到Hadoop的HDFS中，也可以将HDFS的数据导出到关系型数据库中。

sqoop命令的本质是转化为MapReduce程序。

sqoop分为导入（import）和导出（export）

策略分为table和query

模式分为增量和全量。

DataX

DataX是阿里巴巴集团内被广泛使用的离线数据同步工具/平台

实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、DRDS 等各种异构数据源之间高效的数据同步功能。

Kettle

一款国外免费开源的、可视化的、功能强大的ETL工具，纯java编写

可以在Windows、Linux、Unix上运行，数据抽取高效稳定。

canal

canal是阿里巴巴旗下的一款开源项目，纯Java开发。

基于数据库增量日志解析，提供增量数据实时订阅和消费，目前主要支持了MySQL，也支持mariaDB。

StreamSets

是大数据实时采集ETL工具，可以实现不写一行代码完成数据的采集和流转。

通过拖拽式的可视化界面，实现数据管道(Pipelines)的设计和定时任务调度。

创建一个Pipelines管道需要配置数据源(Origins)、操作(Processors)、目的地(Destinations)三部分。

常见概念描述

数据仓库

概念

数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理中的决策制定。

特点

首先，数据仓库用于支持决策，面向分析型数据处理，它不同于企业现有的操作型数据库;

其次，数据仓库是对多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。

应用场景

一般都是作为商业智能系统、数据仪表盘等可视化报表服务的数据源。

数据仓库是一个功能概念，是将企业的各业务系统产生的基础数据，通过维度建模的方式，将业务数据划分为多个主题（集市）统一存储，统一管理。

数据集市

概念

数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局。数据集市可以分为两种:

分类

独立数据集市，这类数据集市有自己的源数据库和ETL架构；

非独立数据集市，这种数据集市没有自己的源系统，它的数据来自数据仓库。

应用场景

数据集市是数仓之上更聚焦的业务主题合集，更偏向于应对业务数据快速高效应用的需求，一般用于商业智能系统中探索式和交互式数据分析应用。

数据集市是一个结构概念，它是企业级数据仓库的一个子集主要面向部门级业务，并且只面向某个特定的主题。

数据孤岛

业务系统之间各自为政、相互独立造成的数据孤岛体现在业务不集成、流程不互通、数据不共享。

数据湖

如果将数据仓库视为瓶装水的商店——经过清洁、包装和结构化以便于饮用——那么数据湖就是处于更自然状态的一大片水体。数据湖的内容从源头流入，填满湖，湖的各种用户可以来检查、潜入或取样。

数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统，它按原样存储数据，而无需事先对数据进行结构化处理。一个数据湖可以存储结构化数据（如关系型数据库中的表），半结构化数据（如CSV、日志、XML、JSON），非结构化数据（如电子邮件、文档、PDF）和二进制数据（如图形、音频、视频）。

数据湖是一个存储库，它允许存储大量的原始数据，也就是说，没有按照特定的模式进行准备、处理或操作的数据。

数据湖的一个关键特征是不会拒绝任何数据，这意味着结构化格式和非结构化数据格式都可以存储。

什么是“湖仓一体”

Data Lakehouse（湖仓一体）是新出现的一种数据架构，它同时吸收了数据仓库和数据湖的优势，数据分析师和数据科学家可以在同一个数据存储中对数据进行操作，同时它也能为公司进行数据治理带来更多的便利性。

Data Lakehouse的出现试图去融合数仓和数据湖这两者之间的差异，通过将数仓构建在数据湖上，使得存储变得更为廉价和弹性，同时lakehouse能够有效地提升数据质量，减小数据冗余。

在lakehouse的构建中，ETL起了非常重要的作用，它能够将未经规整的数据湖层数据转换成数仓层结构化的数据。

数据中台

概念

数据中台是指通过企业内外部多源异构的数据采集、治理、建模、分析，应用，使数据对内优化管理提高业务，对外可以数据合作价值释放，成为企业数据资产管理中枢。数据中台建立后，会形成数据API，为企业和客户提供高效各种数据服务。

数据中台 VS 数据仓库

数据仓库的主要场景是支持管理决策和业务分析，而数据中台则是将数据服务化之后提供给业务系统，目标是将数据能力渗透到各个业务环节，不限于决策分析类场景。

数据中台的建设包含数据仓库的完整内容，数据中台将企业数据仓库建设的投入价值进行最大化，以加快数据赋能业务的速度，为业务提供速度更快、更多样的数据服务。数据中台也可以将已建好的数据仓库当成数据源，对接已有数据建设成果，避免重复建设。当然也可以基于数据中台提供的能力，通过汇聚、加工、治理各类数据源，构建全新的离线或实时数据仓库。

宽表窄表

宽表

从字面意义上讲就是字段比较多的数据库表。

通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。

由于把不同的内容都放在同一张表存储，宽表已经不符合三范式的模型设计规范，随之带来的主要坏处就是数据的大量冗余，与之相对应的好处就是查询性能的提高与便捷。

这种宽表的设计广泛应用于数据挖掘模型训练前的数据准备，通过把相关字段放在同一张表中，可以大大提高数据挖掘模型训练过程中迭代计算时的效率问题。

窄表

严格按照数据库设计三范式。尽量减少数据冗余，但是缺点是修改一个数据可能需要修改多张表。

方便扩展，能适应各种复杂的数据结构（树形、继承等），无论有多少配置，都不用修改表结构。但代码逻辑可能需要包装一下。

大数据架构

互联网大数据平台

简介

大数据平台里面向用户的在线业务处理组件用褐色标示出来，这部分是属于互联网在线应用的部分，其他蓝色的部分属于大数据相关组件，使用开源大数据产品或者自己开发相关大数据组件。

大数据平台由上到下，可分为三个部分：数据采集、数据处理、数据输出与展示。

数据采集

将应用程序产生的数据和日志等同步到大数据系统中，由于数据源不同，这里的数据同步系统实际上是多个相关系统的组合。数据库同步通常用 Sqoop，日志同步可以选择 Flume，打点采集的数据经过格式化转换后通过 Kafka 等消息队列进行传递。

不同的数据源产生的数据质量可能差别很大，数据库中的数据也许可以直接导入大数据系统就可以使用了，而日志和爬虫产生的数据就需要进行大量的清洗、转化处理才能有效使用。

数据处理

这部分是大数据存储与计算的核心，数据同步系统导入的数据存储在 HDFS。MapReduce、Hive、Spark 等计算任务读取HDFS上的数据进行计算，再将计算结果写入HDFS。

MapReduce、Hive、Spark 等进行的计算处理被称作是离线计算，HDFS存储的数据被称为离线数据。在大数据系统上进行的离线计算通常针对（某一方面的）全体数据，比如针对历史上所有订单进行商品的关联性挖掘，这时候数据规模非常大，需要较长的运行时间，这类计算就是离线计算。

除了离线计算，还有一些场景，数据规模也比较大，但是要求处理的时间却比较短。比如淘宝要统计每秒产生的订单数，以便进行监控和宣传。这种场景被称为大数据流式计算，通常用Storm、Spark Steaming 等流式大数据引擎来完成，可以在秒级甚至毫秒级时间内完成计算。

数据输出与展示

大数据计算产生的数据还是写入到HDFS中，但应用程序不可能到HDFS 中读取数据，所以必须要将HDFS 中的数据导出到数据库中。数据同步导出相对比较容易，计算产生的数据都比较规范，稍作处理就可以用Sqoop之类的系统导出到数据库。

应用程序就可以直接访问数据库中的数据，实时展示给用户，比如展示给用户关联推荐的商品。

Lambda架构

简介

Lambda 架构（Lambda Architecture）是由Twitter工程师南森·马茨（Nathan Marz）提出的大数据处理架构。这一架构的提出基于马茨在BackType和Twitter上的分布式数据处理系统的经验。

Lambda架构使开发人员能够构建大规模分布式数据处理系统。它具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性。

Lambda 架构总共由三层系统组成：批处理层（Batch Layer），速度处理层（SpeedLayer），以及用于响应查询的服务层（Serving Layer）。

批处理层

批处理层存储管理主数据集（不可变的数据集）和预先批处理计算好的视图。

速度处理层

速度处理层会实时处理新来的大数据。

速度层通过提供最新数据的实时视图来最小化延迟。速度层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。

服务层

批处理层和速度层处理完的结果都输出存储在服务层中，服务层通过返回预先计算的数据视图或从速度层处理构建好数据视图来响应查询。

Lambda缺点

Lambda 架构也存在着一些不足，主要表现在它的维护很复杂。

使用 Lambda 架构时，架构师需要维护两个复杂的分布式系统，并且保证他们逻辑上产生相同的结果输出到服务层中。

维护Lambda架构的复杂性在于我们要同时维护两套系统架构：批处理层和速度层。我们已经说过了，在架构中加入批处理层是因为从批处理层得到的结果具有高准确性，而加入速度层是因为它在处理大规模数据时具有低延时性。

改进批处理层的系统让它具有更低的延时性，又或者是改进速度层的系统，让它产生的数据视图更具准确性和更加接近历史数据

Kappa架构

简介

Kappa架构是由LinkedIn的前首席工程师杰伊·克雷普斯（Jay Kreps）提出的一种架构思想。克雷普斯是几个著名开源项目（包括 Apache Kafka 和 Apache Samza 这样的流处理系统）的作者之一，也是现在Confluent大数据公司的CEO。

克雷普斯提出了一个改进Lambda架构的观点

我们能不能改进Lambda架构中速度层的系统性能，使得它也可以处理好数据的完整性和准确性问题呢？

我们能不能改进Lambda架构中的速度层，使它既能够进行实时数据处理，同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据呢？

像Apache Kafka这样的流处理平台是具有永久保存数据日志的功能的，通过平台的这一特性，我们可以重新处理部署于速度层架构中的历史数据。

部署

第一步，部署 Apache Kafka，并设置数据日志的保留期（Retention Period）。这里的保留期指的是你希望能够重新处理的历史数据的时间区间。

例如，如果你希望重新处理最多一年的历史数据，那就可以把 Apache Kafka 中的保留期设置为 365 天。如果你希望能够处理所有的历史数据，那就可以把 Apache Kafka 中的保留期设置为“永久（Forever）”。

第二步，如果我们需要改进现有的逻辑算法，那就表示我们需要对历史数据进行重新处理。

我们需要做的就是重新启动一个Apache Kafka作业实例（Instance）。这个作业实例将从头开始，重新计算保留好的历史数据，并将结果输出到一个新的数据视图中。我们知道Apache Kafka的底层是使用Log Offset来判断现在已经处理到哪个数据块了，所以只需要将Log Offset设置为 0，新的作业实例就会从头开始处理历史数据。

第三步，当这个新的数据视图处理过的数据进度赶上了旧的数据视图时，我们的应用便可以切换到从新的数据视图中读取。

第四步，停止旧版本的作业实例，并删除旧的数据视图。

与Lambda架构不同的是，Kappa架构去掉了批处理层这一体系结构，而只保留了速度层。你只需要在业务逻辑改变又或者是代码更改的时候进行数据的重新处理。

Kappa缺点

因为Kappa架构只保留了速度层而缺少批处理层，在速度层上处理大规模数据可能会有数据更新出错的情况发生，这就需要我们花费更多的时间在处理这些错误异常上面。

Kappa架构的批处理和流处理都放在了速度层上，这导致了这种架构是使用同一套代码来处理算法逻辑的。所以Kappa架构并不适用于批处理和流处理代码逻辑不一致的场景。