数据仓库建设

Posted 2022-04-18 Mr.zhou_Zxy

数据仓库建设

一、数据仓库概念

1.数仓架构

​ 我们在谈到数据仓库，都会提到数仓架构，那么数仓架构到底是什么呢？首先，架构就是把一个整体工作按需切分成不同部分的内容，由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动。而数仓架构就可以理解为是构成数据仓库的组件以及之间的具有交互机制的关系。

​ 如上图所示，数仓的数据源可能来自业务系统的数据，或者外部获取的数据，或者从线下文件导入的数据。通过抽取工作，将这些数据存储到数仓的原始数据层中，并存储根据ETL、转换、处理等操作后的数据。在整个过程中，调度平台功能主要实现数据抽取和ETL等处理操作中需要定时完成的任务。而查询引擎功能主要实现快速的查询分析。报表展示功能主要是对数仓中最终的数据做结果展示。

2.数仓概念

​ 数据仓库的目的就是统筹企业中所有的可以使用的数据，构建面向分析的集成化的数据环境，并通过分析结果为企业提供决策支持。数据仓库本身而言，它是不生产数据，也不消费数据的。数据来源于外部，通过数仓中一系列的运算操作，并将数据提供给外部。

基本特征

​ 数据仓库是面向主题的(Subject-Oriented)、集成的(Integrated)、非易失的(Non-Volatitle)和时变的(Time-Variant)数据集合，用于支持管理决策。

1）主题性

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

2）集成性

​ 数据仓库中存储的数据大部分来源于传统的数据库，但并不是将原有数据简单的直接导入，而是需要进行预处理。进行预处理的原因主要是源数据一般会存在不完整以及数据格式不统一的现象。这些脏数据会造成数据仓库中数据的混乱，不利于数据分析和挖掘操作。所以在其进入数据仓库前必须进行抽取、清洗、转换，才能实现从面向事务转而面向主题的数据集合。所以数据集成是数据仓库建设中极其重要而又复杂的一步。

3）稳定性

​ 数据仓库中的数据主要是为决策者分析提供数据依据。决策依据的数据是不允许随意修改。数据的更新调整主要在数据集成环节完成，一旦进入数据仓库后，用户仅能通过分析工具进行查询和分析。

4）动态性

​ 数据仓库数据会随着时间变化而定时更新，这里就是采用调度工具定时调度执行任务。按照设定的时间， 哦那个原始数据平台中抽取数据，转换后集成到数据仓库。随着时间的变化，数据以更高的综合层次被不断综合，以适应趋势分析的要求。当数据超过数据仓库的存储期限，或对分析无用时，从数据仓库删除这些数据。关于数据仓库的结构和维护信息保存在数据仓库的元数据中，数据维护工作由系统根据其中的定义自动进行或者由系统管理员定期维护。

3.数仓建设的目的

​ 想要了解数仓建设的目的，首先了解没有数仓建设之前的状况。数仓的数据往往用来为后面的即席查询、分析系统、数据集市、报表系统、数据挖掘系统做准备。在没有数仓建设之前，他们确实是直接对业务系统的数据做如此的操作，但是这样简单的访问，却会造成大量的问题。比如：

• 部分的业务系统都设置有权限，出于安全原因你不能直接访问

• 业务系统每次做版本升级，相应的报表系统还要进行再次测试

• 企业中用于多个业务系统，那么对应的多个报表系统的维护问题

• 不同业务系统之间形成数据孤岛，不能进行数据互通

• 业务系统的数据格式等问题

• 业务系统的数据存在脏数据的问题

• 直接操作业务数据做分析，对数据而言也是一种危险

  从以上问题可知，虽然建设数仓初期会有大量的投入，但是当数仓步入正轨后，其效果和优势也是十分明显的。

4.OLAP和OLTP

OLTP

​ 联机事务处理OLTP，主要执行基本日常的事务处理，比如数据库记录的增删改查。

​ OLTP的特点：

• 1.实时性要求高，例如银行业务中的转账实时到账。

• 2.数据量小，一般生产库的数据量不是太大，而且回做相应的数据处理和转移。

• 3.交易一般是确定的，比如银行存取款的金额肯定是确定的，所以OLTP是对确定性的数据进行存取

• 4.高并发，并且要求ACID原则。比如两人同时使用一个银行卡账户，或者大型的购物网站秒杀活动QPS请求

  ACID：原子性(Atomicity),一致性(Consistency),隔离性(Isolation),持久性(Durability)

OLAP

​ 联机分析处理OLAP是数据仓库的主要应用，支持复杂的分析操作，侧重于决策支持，并且提供直观易懂的查询结果。典型的就是复杂的动态报表系统。

​ OLAP的特点：

• 1.实时性要求不是很高，最常见的就是天级更新数据，然后对应的数据报表
• 2.数据量大，因为OLAP支持的动态查询，所以用户也许要通过将许多数据统计后才能知道信息。
• 3.OLAP系统的重点是通过数据提供决策支持，所以查询都是动态的，自定义的。所以在OLAP中，维度的概念特别重要。一般会将所有关心的维度数据，存入对应的数据平台。

总结

OLTP即联机事务处理，主要使用在业务系统中。

OLAP即联机分析处理，是数据仓库的核心部分。

5.数据仓库分层

​ 按照数据流入流出来看的话，大致可分为三层，分别是源数据层，数据仓库层，数据应用层。

源数据层

​ 一般是从业务系统抽取的数据、或者通过接口获取、或者通过线下导入，这里是无需做任何修改。

数据仓库层

​ 这一层可以成为细节层，DW层的数据应该是一致的、准确的、干净的数据，即对源数据进行了清洗后的数据

数据应用

​ 报表平台直接读取的数据源；根据报表、专题分析需求而计算生成的数据。

疑问解答？

​ 为什么要分层呢，这不是增加管理困难？

• 首先分层可以实现用空间换时间，通过大量的预处理来提升应用系统的用户体验，因此数据仓库回存在大量冗余的数据；不分层的话，如果源业务系统的业务规则发生变化，会影响整个清理过程，增加工作量。
• 其次通过数据分层管理可以简化数据清晰的过程，因为把原来一步的工作分到多个步骤去完成，相当于把一个复杂的工作拆分成多个简单的工作。

6.数仓架构演变

数据集市架构

​ 数据集市架构是按主题组织的数据集合，用于支持部门级别的决策。有两种类型的数据集市：独立数据集市和从属数据集市。

独立数据集市

​ 独立数据集市集中于部门所关系的单一主题域，数据以部门为基础部署，无需考虑企业级别的信息共享与集成。例如：营销部、人力资源部、制造部都有各自的数据集市。

​ 优点是：数据量小、周期短、见效快。

​ 缺点是：部门之间的指标不同、部门之间交互能力差、跨部分分析难

从属数据集市

​ 从属数据集市的数据来源于数据仓库。数据仓库里的数据经过整合、重构、汇总后传递给从属数据集市(也就是各个部门的数据集市)

​ 优点是：当数据仓库的查询性能出现问题，可以通过建立多个从属数据集市，减少数据仓库的压力。每个部门都能管理自己的数据集市。因为每个数据都来源于同一个数据仓库，有效消除数据不一致的问题。

Inmon企业工厂架构

​ 这个架构跟独立数据集市很像，主要区别在于在部门级数据集市之前添加了企业级数据仓库。而企业级数据仓库是一个细节数据的集成资源库。其中的数据以最低粒度级别被捕捉，存储在满足三范式涉及的关系数据库种。

Kimball数据仓库架构

​ 如上图所示，Kimball与Inmon两种架构的主要区别在于核心数据仓库的设计和建立。

​ Kimball的数据仓库包含高粒度的企业数据，使用多为模型设计，这也意味着数据仓库由星型模型的维度表和事实表构成。分析系统或者报表工具可以直接访问多维数据仓库里的数据。这里的数据集市跟Inmon架构中的数据集市不同，这里的数据集市是一个概念，只是多维数据仓库中的主题划分，并没有自己的物理存储，也可以说是虚拟的数据集市。

混合型数据仓库架构

所谓混合型架构，就是联合使用Inmon和Kimball这两种架构

​ 如上所示，这种架构将Inmon方法中的数据集市替换成一个多维的数据仓库，而数据集市则是多维数据仓库上的逻辑视图。

​ 优点是：既可以利用规范式设计消除数据冗余，保证数据的粒度够细；又可以充分利用多维结构来更灵活的在企业级数仓中实现分析和展示。

第一范式：要求消除拆分字段至原子字段，即不可再拆分

第二范式：要求消除部分函数依赖，实现完全函数依赖

第三范式：要求消除传递函数依赖

函数依赖：A列属性跟主键有关系

部分函数依赖：A列函数只跟主键的部分属性有关系

完全函数依赖：A列属性只跟主键的全部属性有关系

传递函数依赖：A列属性跟B列属性有关系，B列属性跟主键有关系

7.元数据管理

​ 元数据管理是企业数据治理的基础，是数据仓库的提升。元数据中定义了数据仓库的模式、来源、抽取以及转换规则，在整个数据仓库的基础之上，把各个松散的组件，组成一个有机的整体。

​ 元数据(MetaData)，又称为是中介数据、中继数据，为描述数据的数据。

​ 另一种解释就是：一组用于描述数据的数据组，该数据组的一切信息都描述了该数据的某方面的特征，则该数据组即可被称为元数据。

技术元数据

​ 技术元数据为开发和管理数据仓库的IT人员使用，它描述了与数据仓库开发、管理和维护相关的数据，包括数据源信息、数据转换描述、数据仓库模型、数据清洗、更新规则、数据映射、访问权限等。

业务元数据

​ 业务元数据为管理层和业务分析人员服务，从业务角度描述数据，包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等，帮助业务人员更好的理解数据仓库中哪些数据是可用的以及如何使用。

二、离线数仓建设核心

1.数仓分层

数仓分层的原则：

• 空间换时间，通过大量的预处理来提升应用系统的用户体验
• 便于数据分析，屏蔽底层复杂业务，将简单、完整、有效的数据暴漏给分析层
• 削弱底层业务变动对整体模型的影响
• 高内聚低耦合，主题之内数据高内聚，主题之间数据低耦合
• 层次分明，便于管理，为数据仓库大规模开发奠定基础

1.数据源层：ODS(Operational Data Store)

​ ODS层，是最接近数据源中数据的一层，为了考虑后续需要追加数据的问题，这一层不对数据做任何处理。

2.数据仓库层：DW(Data Warehouse)

​ 数据仓库层是我们在做数据仓库的时候要设计的最核心的一层。在这里，从ODS层中获得的数据按照主题建立各种数据模型。DW层又细分为DWD(Data Warehouse Detail)、DWM(Data Warehouse Middle)、DWS(Data Warehouse Service)

1）数据明细层：DWD

​ 该层一般保持和ODS层一样的数据粒度，并提供一定的数据质量保证。DWD层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、不规范数据、状态不一致数据、命名不规范数据都会被处理。

​ 同时，为提高数据明细层的易用性，该层会采用一些维度退化的手法，将维度退化至事实表，减少事实表和维表之间的关联。

​ 在该层也会做部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性。

tips:维度退化：当一个维度没有数据仓库需要的任何数据时，就可以退化维度。需要把退化的维度的相关数据迁移到事实表中，然后删除退化的维度

2）数据中间层：DWM(Data WareHouse Middle)

​ 该层会在DWD层的数据基础上，数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。

​ 直观来讲，就是对通用的核心维度进行聚合操作，算出对应的统计指标

​ 在实际的计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题。因此一般的做法是，在DWM层先计算多个小的中间表，然后再拼接成一个DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据再放在DWS层亦可。

tips:根据企业宽窄界定，可有可无

3）数据服务层：DWS(Data WareHouse Service)

​ DWS层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，基于DWD层上的基础数据，整合汇总分析某一个主题域的服务数据，一般是宽表。DWS层应覆盖80%的应用场景，又称为数据集市或宽表。

​ 按照业务划分，如主题域流量、订单、用户等，生成的字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据并发。

​ 一般来讲，该层的数据表相对较少，一张表会涵盖较多的业务内容，由于其字段较多，因此一边拿会称该层的表为宽表。

4）数据应用层：APP(Application)

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

5）维度表：DIM(Dimension)

​ 如果维表过多，也可以针对维表设计单独的一层，维表主要包含两部分数据：

​ **高基数维度数据：**一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级别或者上亿级别。

​ **低基数维度数据：**一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。

2.数仓建模

​ 数仓建模主要是在DW层进行数仓建模，所以DW层是数仓建设的核心层。

​ 常见的建模方法有范式建模、维度建模、实体类建模，从不同的角度看待业务问题。

1）范式建模法

​ 范式建模法其实是我们在构建数据模型常用的一种方法，该方法的主要由Inmon所提倡，主要解决关系型数据仓库的数据存储，利用的一种技术层面上的方法。目前，在关系型数据库中的建模方法，大多数采用的第三范式建模法。

​ 范式是符合某一级别的关系模式的集合。构造数据库必须遵循一定的规则，而在关系型数据库中这种规则就是范式，这一过程也被成为规范化。在数据仓库的模型设计中，一般采用第三范式。而第三范式要满足以下条件：

• 每个属性值唯一，不具有多义性
• 每个非主属性必须完全依赖于整个主键，而非主键的一部分
• 每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中。

​ 如上图所示，根据Inmon的观点，数据仓库模型的建设方法和业务系统的业务数据模型类型。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以堪称是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例化

2）维度建模法

​ 维度模型是数据仓库领域另一位大师Ralph Kimall所倡导，他的《数据仓库工具箱》是数据仓库领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快完成分析需求，同时还有较好的大规模复杂查询的响应性能。

​ 在维度建模中最为典型的就是星型模型，还有在特殊场景用到的雪花模型和星座模型。

​ 维度建模中比较重要的概念就是事实表和维度表。其最简单的描述就是，按照事实表、维度表来构建数据仓库、数据集市。

3）实体建模法

​ 实体建模法并不是数据仓库建模常见的一种方法，它来源于哲学的一个流派。从哲学的意义上说，客观时间应该是可以细分的，客观世界应该可以分成由一个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务划分为一个个的实体，而每个实体之间的关系，以及针对这些关系的说明，就是我们数据建模需要做的工作。

​ 如上图所示，虽然实体法粗看有些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成三个部分，实体、事件、说明 。

3.维度建模详解

​ 目前在互联网公司中最常用的建模方法就是维度建模。维度建模适用于分析性数据库、数据仓库、数据集市(小型数据仓库)建模的方法。在开始建模之前，应先了解维度建模中表的类型和维度建模的模式，有利于我们更深刻的理解。

维度建模中表的类型

​ 维度建模中的表主要为两种：事实表和维度表

1. 事实表：必然存在的一些数据，像采集的日志文件，订单表，都可以作为事实表

   特征：是一堆主键的集合，每个主键对应维度表中的一条记录，客观存在的，根据主题确定出需要使用的数据

2. 维度表: 维度表就是所分析的数据的一个量，维度表就是以合适的角度来创建的表，分析问题的一个角度：时间、地域、终端、用户等角度。

1）事实表

​ 发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。最低的粒度级别来看，事实表对应一个度量事件，反之亦然。事实表表示对分析主题的度量。比如一次购买行为我们就可以理解为是一个事实。

​ 如上图所示：订单表就是一个事实表，他记录的就是现实中的一个操作性的事件。从这里可以看出，表里并没有存储具有实际意义的数据。这些主键的集合，通过每一个主键都可以获取一个相关维度的数据。事实表的度量通常是数值类型，且记录数会不断增加，表数据规模迅速增长。

1.1）事实表-明细表(宽表):

​ 事实表的数据中，有些属性共同组成了一个字段(糅合在一起)，比如年月日时分秒构成了事件，当需要根据某一属性进行分组统计的时候，需要截取拼接之类的操作，效率极低，如：

​

create_time
2022-03-17 10:12:11

​ 为了方便根据其中某一属性进行分组统计(例如按照月统计生成单数)，可以在事实表中的一个字段切割提取多个属性构成新的字段，因为字段变多了，所以称为宽表，原来的为窄表。又因为宽表的信息更加清洗明细，所以也可以称其为明细表。

year	month	day	hour	m	s
2022	03	17	10	12	11

1.2）事实表分类

• 事务事实表

  表中的一行对应空间或时间上某点的度量事件。就是一行数据中必须有度量字段，什么是度量，就是指标，比如说销售金额，销售数量等这些可加或者半可加就是度量值。另一点就是事务表都包含一个与维度关联的外键。并且度量值必须和事务粒度保持一致。

• 周期快照事实表

  周期事实表就是每行都带有时间值字段，代表周期，通常时间值都是标准周期，如某一天，某周，某月。粒度是周期，而不是个体的事务，也就是说一个周期快照事实表中数据可以是多个试试，打死你同属于一个周期内。

• 累计快照事实表

  周期快照事实表是单个周期内的数据，而累计快照事实表是由多个周期数据组成的，每行汇总了过程从开始到结束之间的度量。每行数据都相当于管道或者工作流，有事件的起点、过程、终点，并且每个关键步骤都包含日期字段。如累计快照事实表的一行就算一个订单，当订单产生时插入一行，订单发生变化时，这一行就被修改。

• 无事实的事实表

  在事实表中我们说到，事实表度量都是数字化的，但是可能会存在少数没有数字化的值但是很有价值的字段，无事实的事实表就是为这种数据准备的，利用这种事实表可以分析发生了什么。

• 聚集事实表

  聚集，就是对原子粒度的数据进行简单的聚合操作，目的就是为了提高查询性能。如我们需要是查询全国所有门店的总销售额，我们原子粒度的事实表中每行是每个分店每个商品的销售额，聚集事实表就可以先聚合每个分店的总销售额，这样汇总所有门店的销售额时计算的数据量就会小很多。

• 合并事实表

  这种事实表遵循一个原则，就是相同粒度，数据可以来自多个进程，但是只要他们属于相同的粒度，就可以合并成为一个事实表，这类事实表特别适合经常需要共同分析的多过程度量。

2）维度表

​ 每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键。维度表通常比较宽，是扁平化非规范表，包含大量的低粒度的文本属性。

​ 维度表表示你要对数据进行分析时所用的一个量，比如你要分析产品销售情况，你可以选择按类别来分析，或按区域分析。每个类别就构成了一个维度。上图中的用户表、商品表】时间表这些都属于维度表，这些表都有一个唯一的主键，然后在表中存放详细的数据信息。

​ 总的来说，在数据仓库中不需要遵守规范化的设计原则。因为数据仓库的主导功能就算面向分析，以查询为主，不涉及数据更新的操作。事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。

• 维度表结构

  维度表谨记一条原则，包含单一主键列，但是有时因业务复杂，也可能出现联合主键，请尽量避免。如果无法避免也要确保是单一的，这很重要。如果维度表主键不是单一的，和事实表关联时会出现数据发散，导致最后错误的结果。维度表通常比较宽，包含大量的低粒度文本属性。

• 跨表钻取

  跨表钻取意思是当每个查询的行头都包含相同的一致性属性时，使用不同的查询能够针对两个或者更多的事实表进行查询

  钻取可以改变维度的层次，变换分析的粒度。它包括上钻/下钻：

  上钻(roll-up)(忽视维度)：上卷是沿着维的层次向上聚集汇总数据。例如，对产品销售数据，沿着事件维上钻，可以求出所有产品在所有地区每月(或季度或年或全部)的销售额

  下钻(drill-down)(细化维度)：下钻是上钻的逆操作，它是沿着维的层次向下，查看更详细的数据。

• 退化维度

  退化维度就是将维度退回的事实表中。因为有时维度除了主键没有其他内容，虽然也是合法的维度键，但是一般都会退回到事实表中，减少关联次数，提高查询性能。

• 多层次维度

  多数维度包含不止一个自然层次，如日期维度可以从天的层次到周到月到年的层次。所以在有些情况下，在同一维度中存在不同层次。

• 维度表空置属性

  当给定维度行没有被全部填充时，或者当存在属性没有被应用到所有维度行时，将产生空置维度属性。上诉两种情况，推荐采用描述性字段代替空值，如使用unknown或not applicable替换空置。

• 日历日期维度

  在日期维度表中，主键的设置不要使用顺序生成的id来表示，可以使用更有意义的数据表示，比如将年月日合并起来表示，即YYYYMMDD，或者更加详细的精度。

维度建模的三种模式

1）星型模型

​ 星型模型是最常用的维度建模方式。星型模型**以事实表为中心，所有维度表直接连接在事实表上，像星星一样，故称为星型模型。**星型模型的维度建模由一个事实表和一堆维度表组成，且具有以下特点：

• 维表只和事实表关联，维表之间没有关联
• 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键
• 以事实表为核心，维表围绕核心呈星型分布。

2）雪花模型

​ 雪花模型是对星型模型的扩展。雪花模型的维度表可以拥有其他维度表，虽然这种模型相比星型模型更加规范，但是由于这种模型不易理解，维护成本高，而且性能方面需要关联多层维度表，性能也比星型模型要低。所以一般不是很常用。

3）星座模型

​ 星座模型是星型模型延伸而来，**星型模型是基于一张事实表，而星座模型是基于多张事实表，而且共享维度信息。**星型模型和星座模型都是多维表对应单事实表但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大多数维度建模都是采用星座模型。

维度建模过程

​ 在维度建模的时候，表的类型主要分为事实表和维度表；模式有星型模型、雪花模型和星座模型。但是在实际业务中，如果拿到一堆的数据，怎么进行数据建设呢？

数仓工具箱中的维度建模四步走：

1）选择业务过程

​ 维度建模是紧贴业务的，所以必须以业务为根基进行建模，那么选择业务过程，顾名思义就是在整个业务流程中选取我们需要建模的业务，根据运营提供的需求以及日后的易扩展性等进行选择业务。比如商城，整个商城流程分为商家端、用户端、平台端，运营需求是总订单量，订单人数，及用户购买情况。我们选择业务过程就选择用户端的数据，商家及平台端暂不考虑。业务选择非常重要，因为后面所有的步骤都是基于此业务数据展开的。

2）声明粒度

​ 先举个栗子：对于用户来说，一个用户有一个身份证号，一个户籍地址，多个手机号，多张银行卡。那么与用户粒度相同的粒度属性有身份证粒度，户籍地址粒度；比用户粒度更细的粒度有手机号粒度，银行卡粒度，存在一对一的关系就是相同粒度；为什么要提相同粒度呢？因为维度建模中要求我们，在同一事实表中，必须具有相同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据建立不同的事实表。并且从给定的业务过程获取数据时，强烈建议从关注原子粒度开始涉及，也就是从最细粒度开始，因为原子粒度能够承受无法预期的用户查询。但是上卷汇总粒度对查询性能的提升很重要，所以对于有明确需求的数据，我们建立针对需求的上卷汇总粒度，对需求不明朗的数据我们建立原子粒度。

3）确认维度

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

4）确认事实

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

三、离线数仓建设实战

技术是为业务服务，业务是为公司创造价值，离开业务的技术是毫无意义的

1.业务介绍

​ 需要针对不同需求的用户开发不同的产品，所以公司内部有很多条业务线，但是对于数据部门来说，所有数据线的数据都是数据源。对数据的划分不只根据业务进行，而是结合数据的属性。

2.早期规划

​ 之前开发是不同业务线对应不同的数据团队，每个数据团队互不干扰，这种模式比较简单，只针对自己的业务线进行数仓建设及报表开发即可。

​ 但是随着业务的发展，频繁迭代及跨部门的垂直业务单元原来越多，业务之间的出现耦合的情况，这时再采用这种烟囱开发就出现了问题：

​ 例如权限问题，公司对数据管理比较严格，不同的数据开发组没有权限共享数据，需要其他的业务线权限需要上报审批，比较耽误时间；

​ 还有重复开发的问题，不同业务线会出现相同的报表需求，如果每个业务方都开发各自的报表，太浪费资源。所以对于数据开发而言，需要对各个业务线的数据进行统一管理，所以就有了数据中台的出现。

3.数据中台

​ 数据中台的建设是根据每个公司的业务需求而搭建的，不同的业务，对中台的理解有所不同。公司内部开发的敏捷数据中台，主要从数据技术和计算能力的服用，到数据资产和数据服务的服用，数据中台以更大价值带宽，快精准直接赋能业务。提供一个统一化的管理，打破数据孤岛，追溯数据血缘，实现自助化及高复用度。

​ 以上解释比较抽象，可以以实际项目开发来分析数据中台的便利性。比如在整个流程中，首先是数据采集，不同的数据通过Sqoop、DataX、Kettle、Nifi等工具采集到大数据平台中，然后进行数仓搭建，最后产出报表数据，放到可视化系统中展示，最终把整个流程写成脚本放到调度平台进行自动化执行(例如Azkaban,Dolphin)。

​ 有了数据中台之后就不需要那么繁杂的事情，直接进行数仓搭建，产生报表即可，无需将精力浪费在数据源、可视化展示及调度。并且可以直观的查看数据血缘关系，计算表之间的血缘。如下图所示：

数据中台的异构数据系统可以非常简单的进行查询，比如Hive的表关联mysql的表。可透明屏蔽异构数据系统交互方式，轻松实现跨异构数据系统透明混算。

​ 异构数据系统原理是数据中台提供虚拟表之间的映射，终端用户无需关心数据的物理存放位置和底层数据源的特性，可直接操作数据，体验类似操作一个虚拟数据库。

4.数仓建设

​ 数仓建设是根据公司的业务发展以及现有的数据中台进行，数仓的建设离不开公司的业务。

智能数仓规划

​ 数仓建设核心思想：从涉及、开发、部署和使用层面，避免重复建设和指标冗余建设，从而保障数据口径的规范和统一，最终实现数据资产全链路关联、提供标准数据输出以及建立统一的数据公共层。

​ 数仓建设主要从两个方面，规模和规范，所有业务进行统一化。

1）模型

​ 所有业务采用统一的模型体系，从而降低研发成本，增强指标服用，并且能够保证数据口径的统一

2）模型分层

​ 结合公司业务，后期新增需求增多，所以分层不宜过多，并且需要清晰明确各自职责，要确保数据层的稳定又屏蔽对下游影响，所以采用分层结构：

数据分层架构

1）数据流向

遵循模型开发时分层结构，数据从ods->dw-dm-app这样正向流动，可以放置因数据引用不规范而造成数据链路混乱及SLA时效难保障等问题，同时保证血缘关系简单化，能够轻易追踪数据流向。在开发时应避免以下情况出现：

​ 1.数据链路引用不正确，如ods-dm-app，出现这种情况说明明细层没有完全覆盖数据；如ods-dw_app，说明轻度汇总主题划分未完全覆盖。减少跨层引用，才能提高中间表的复用性，理想的数仓模型设计应当具备：数据模型可复用，完善且规范。

​ 2.尽量避免一层的表引用当前层的表，如DW层的表生成DW层的表，这样会影响ETL效率。

​ 3.禁止出现反向依赖，如DW表依赖于DM表

2）规范

​ 2.1）表命名规范

​ 1.对于ods,dm,app层表名：类型_主题_含义，如：dm_xxsh_user

​ 2.对于dw层表名：类型_主题_维度_表含义,如：dw_xxsh_fact_users(事实表)、dw_xxsh_dim_users(维度表)

​ 2.2）字段命名规范

​ 构建词根，词根是维度和指标管理的基础，划分为普通词根与专有词根

​ 1.普通词根：描述事物的最小单位，如：sex-性别

​ 2.专有词根：具备行业专属或公司内部规定的描述题，如：xxsh-公司内部对某个产品的称呼

​ 3.脚本命名规范：脚本名称：脚本类型.脚本共用.[库名].脚本名称，如hive.hive.dm.dm_xxsh_users

​ 脚本常用类型：1.hive sql 2.shell脚本 3.python脚本

5.数据层具体实现

1）数据源层ODS

数据源层主要将各个业务数据导入到大数据平台，作为业务数据的快照存储。

2）数据明细层DW

事实表中的每行对应一个度量，每行中的数据是都是特定级别的细节数据，称为粒度。维度建模的核心原则就是同一事实表中所有度量必须具有相同的粒度。这样才能确保不会出现重复计算度量的问题。

维度表一般都是单一主键，少数是联合主键，注意维度表不要出现重复的数据，否则和事实表关联会出现数据发散的问题。

有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下往往是事实字段。如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性往往是维度属性。但是还要结合具体业务进行最终的判断是事实还是维度。

3）数据轻度汇总层 DM

此层命名为轻度汇总层，就代表这一层已经开始对数据进行汇总，但是不是完全汇总，只是对相同粒度的数据进行关联汇总，不同粒度但是有关系的数据也可以进行汇总，此时需要将粒度通过聚合等操作进行统一。

4）数据应用APP层

数据应用层的表是提供给用户使用的，数仓建设到此就接近尾声了，接下来就根据不同的需求进行不同的取数，如直接进行不同的取数，如直接进行报表展示，或提供给数据分析的同事的数据，或其他业务支撑。

6.总结

7.实际生产中注意事项

​ 实际环境中不能像测试环境一样随意，很容易造成生产事故。所以每一步操作都必须要小心，以下为简单列出的注意事项：

• 请勿操作自己管理及授权表之外的库表
• 未经授权，请勿操作生产环境中其他人的脚本及文件
• 在修改生产环境脚本前，无比自行备份到本地
• 请确认自己的修改操作能迅速回滚
• 生产环境中表名及字段等所有命名请遵循命名规则

四、实时计算

​ 实时计算一般是针对海量的数据进行的，并且要求秒级。由于大数据兴起之时，Hadoop并没有给出实时计算的解决方案，随后的Stromberg，SparkStreaming，Flink等实时计算框架应运而生，而Kafka、ES的兴起也使得实时计算领域的技术越来越得到完善，而随着物联网，机器学习等技术的推广，实时流式计算在这些领域得到充分的应用。

实时计算的三个特征：

• 1.无限数据：无线数据指的是一种不断增长的，基本上无限的数据集。这些通常被称为“流数据”，而与之相对的是有限的数据集。
• 2.无界数据处理：一种持续的数据处理模式，能够通过处理引擎重复的去处理上面的无线数据，是能够突破有限数据处理引擎的瓶颈。
• 3.低延迟：延迟是多少并没有明确的定义，但是我们都知道数据的价值将随着时间的流式降低，时效性将是需要持续解决的问题

现在大数据应用比较火爆的领域，比如推荐系统在实践之初受技术所限，可能要一分钟，一小时，甚至更久对用户进行推荐，这远远不能满足需要，我们需要更快的完成对数据的处理，而不是进行离线的批处理。

1.实时计算应用场景

​ 随着实时技术趋于成熟，实时计算应用越来越广泛，以下仅列举常见的各种实时计算的应用场景。

1）实时智能推荐

​ 智能推荐会根据用户历史的购买或浏览行为，通过推荐算法训练模型，预测用户未来可能会购买的物品或喜爱的咨询。对个人来说，推荐系统起着信息过滤的作用，对Web/App服务端来说，推荐系统起着满足用户个性化需求，提升用户满意度的作用。推荐系统本身也在飞速发展，除了算法越来越完善，对时延的要求也越来越苛刻和实时化。利用flink流计算帮助用户构建更加实时的智能推荐系统，对用户行为指标进行实时计算，对模型进行实时更新，对用户指标进行实时预测，并将预测的信息推送给Web/App端，帮助用户获取想要的商品信息，另一方面也帮助企业提升销售额，创造更大的商业价值。

2）实时欺诈检测

​ 在金融领域的业务中，常常出现各种类型的欺诈行为，例如信用卡欺诈，信贷申请欺诈登，而如何保证用户和公司的资金安全，是近年来许多金融公司及银行共同面对的调整。随着不法分子欺诈手段的不断升级，传统的反诈手段不足解决目前所面临的问题。以往可能需要几个小时才能通过交易数据计算出用户的行为指标，然后通过规则判别具有欺诈行为嫌疑的用户，再进行案件调差处理，在这种情况虾资金可能早被不发分子转移，从而给企业和用户造成德莱昂的经济损失。而运用flink流式计算技术能够在毫秒内就完成欺诈行为判断指标的计算，然后实时对交易流水进行实施拦截，避免因为处理不及时而导致经济损失。

3）舆情分析

​ 有的客户要做舆情分析，要求所有数据存放若干年，舆情数据每日数据量可能超百万，年数据量可达到几十亿的数据。而且爬虫爬过来的数据是舆情，通过大数据技术进行分词之后得到的可能是大段的网友评论，客户往往要求爬到大数据平台的Kafka里，在里面做Flink流处理，去重去噪做语音分析，写道ES里。大数据的一个特点是多数据源，大数据平台能根据不同的场景选择不同的数据源。

4）复杂事件处理

​ 对于复杂事件处理，比较常见的集中于工业领域，例如对车载传感器，机械设备登实时故障检测，这些业务类型通常数据量都非常大，且对数据处理的时效性要求更高。通过利用flink提供的CEP进行事件模式的抽取，同时应用Flink的SQL进行事件数据的转换，在流式系统中构建实施规则引擎，一旦事件触发报警规则，便立即将告警结果通知至下游系统，从而实现对设备故障快速预警监测，车辆状态监控等目的。

5）实时机器学习

​ 实时机器学习是一个更宽泛的概念，传统静态的机器学习主要侧重于静态的模型和历史数据进行训练并提供越策。很多时候用户的短期行为，对模型有修正作用，或者说对业务判断有预测作用。对系统来说，需要采集用户最近的行为并进行特征工程，然后给到实时机器学习系统进行机器学习。如果动态的实施新规则，或者推出新广告，就会很有参考价值。

2.实时计算流程

1）数据同步

​ 数据从Web平台中产生，通过数据同步系统导入到大数据平台，由于数据源不同，这里的数据同步系统实际上是多个相关系统的组合。数据库同步通常使用Sqoop、Kettle、nifi等，日志同步可以选择使用Flume等，不同的数据源产生的数据质量可能相差很大。数据库中产生的结构化数据，可以直接导入到大数据系统即可。但是日志和爬虫产生的半结构化和非结构化数据，都需要经过大量的清洗、转换处理才能有效的使用。

2）数据存储

​ 数据存储部分主要是对原始数据、清洗关联后的明细数据进行的存储操作，基于统一的实时数据模型分层理念，将数据依次存放至各层。以及将不同应用常见的数据可以分别存储在Kafka、HDFS、Kudu、Hive、ClickHouse、Hbase、ES中进行应用。

3）数据计算

​ 计算层主要使用Flink、Spark、Presto以及Clickhouse自带的计算能力等四种计算引擎，Flink计算引擎主要用于实时数据同步，流式ETL、关键系统秒级实时指标计算场景，Spark SQL主要用于复杂多维分析的准实时指标计算需求场景，Presto和ClickHouse主要满足多维自助分析、对查询响应时间要求不太高的场景。

4）实时应用

​ 以统一查询服务对各个业务数据场景进行支持，业务主要包括实时大屏、实时数据产品、实时OLAP、实时特征等。

当然一个好的大数据平台不能缺少元数据管理以及数据治理：

5）元数据指标管理

​ 主要对实时的Kafka表、kudu表、clickhouse表、hive表等进行统一管理，以数仓模型中表的命令方式规范表的命名，明确每张表的字段含义、使用方，指标管理则是尽量通过指标系统将所有的实时指标统一管理，明确计算口径，提供给不同的业务方使用；

6）数据质量及血缘分析

​ 数据质量分为平台监控和数据监控两个部分，血缘分析则是主要对实时数据依赖关系、实时任务的依赖关系进行分析。

以上列举的架构流程只是通用的数据模型，如果要具体的建设，需要考虑一下情况，业务需求需要实时还是准实时即可，数据时效性是妙计还是分钟级等。

• 在调度开销方面，准实时数据是批处理过程，因此仍然需要调度系统支持，调度频率较高，而实时数据却没有调度开销；
• 在业务灵活方面，因为准实时数据是基于ETL或OLAP引擎实现，灵活性优于流计算的方式；
• 在对数据晚到的容忍度方面，因为准实时数据可以基于一个周期内的数据进行全量计算，因此对数据晚到的容忍度也是比较高的，而实时数据使用的是增量计算，对于数据晚到的容忍度更低一些；
• 在适用场景方面，准实时数据主要用于有实时性要求但不太高、涉及多表关联和业务变更频繁的场景，如交易类型的实时分析，实时数据则更适用于要求高、数据量大的场景，如实施特征、流量实时分析等场景；

3.实时架构

​ 在某些场景中，数据的价值随着时间的推移而逐渐减少。所以在传统大数据离线数仓的基础上，逐渐对数据的实时性提出了更高的要求。

​ 于是随着诞生了大数据实时数仓，并衍生出两种架构Lamdba和Kappa。首先看一下两者简单的对比。

对比项	Lambda架构	Kappa架构
实时性	实时	实时
计算资源	批和流同时运行，资源开销大	只有流处理，仅针对新需求开发阶段运行两个作业，资源开销小
重新计算时吞吐	批式全量处理，吞吐较高	流式全量处理、吞吐较批处理低
开发、测试	每个需求都需要两套不同代码、开发、测试、上线难度较大	只需实现一套代码、开发、测试、上线难度相对较小
运维成本	维护两套系统(引擎)、运维成本大	只需维护一套系统、运维成本小

Lambda架构

​ Lambda架构，数据从底层的数据源开始，经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算：

• 一条线是进入流式计算平台(例如Storm、Flink或者SparkStreaming)，实时计算一些指标
• 另一条线进入批量数据处理离线计算平台(例如Mapreduce、Hive、Spark SQL),计算T+1的相关业务指标，这些指标需要隔日才能看到

为什么Lambda架构要分成两条线计算？

​ 假设整个系统只有一个批处理层，会导致用户必须等待很久才能获取计算结果，一般有几个小时的延迟。电商数据分析部分只能查看前一天的统计分析结果，无法获取当前的结果，这对于实时决策来说有一个巨大的时间鸿沟，很可能导致管理者错过最佳的决策时机。

​ Lambda架构属于较早的一种架构方式，早期的流处理不如现在这样成熟，在准确性、扩展性和容错性上，流处理层无法直接取代批处理层，只能给用户提供一个近似结果，还不能给用户提供一个一致准确的结果。因此Lambda架构中，出现了批处理和流处理并存的现象。

在Lambda架构中，每层都有自己所肩负的任务。

1.批处理层存储管理主数据集(不可变的数据集)和预先批处理计算好的视图：

​ 批处理层使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图。输出通常存储在只读数据库中，更新则完全取代现有预先计算好的视图。

2.流处理层会实时处理新来的数据

​ 流处理层通过提供最新数据的实时视图来最小化延迟。流处理层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但他们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后ÿ