数据仓库概览

1.基本概念

1.数据仓库架构

数据仓库环境包括操作型系统和数据仓库系统两个部分。操作型系统的数据由各种形式的业务数据组成，这些数据经过抽取、转换和装载（ETL）过程进入数据仓库系统。

架构方法

数据集市架构
Inmon企业信息工厂架构
Kimball数据仓库架构
混合型数据仓库架构

2.数据仓库概念

Data Warehouse，可简写为DW或DWH

数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持。处于分析性报告和决策支持目的而创建。

数据仓库本身并不”生产“任何数据，同时自身也不需要”消费“任何数据。因此被称之为仓库，而不是工厂。

基本特征

数据仓库是面向主题的、集成的、非易失的和时变的数据集合，用以支持管理决策。

面向主题的
主题是一个抽象的概念，是较高层次上的企业信息系统中的数据综合、归类并进行分析利用的抽象。
在逻辑意义上，是对应企业中某一宏观分析领域所涉及的分析对象。
集成的
通过对分散、独立、异构的数据库数据进行抽取、清理、转换和汇总便得到了数据仓库的数据，这样保证了数据层库内的数据关于整个企业的一致性。
需要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致等等。
非易失的（不可更新性）
数据仓库的数据反映的是一段相当长时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据。
数据经加工和集成进入数据仓库后是极少更新的，通常只需要定期的加载和更新。
时变的
数据仓库的用户不能修改数据，但并不是说数据仓库的数据是永远不变的。
数据仓库的数据是按照时间顺序追加的，都带有时间属性。

3.为什么需要数据仓库？

数据来源：数据仓库的数据来自各个业务应用系统。业务系统中的数据形式多种多样，可能是结构化数据也可以是文本、CSV等平面文件或Word、Excel文档中的数据、还可以是HTML、XML等自描述的半结构化数据。

数据去向：业务数据经过一系列的数据抽取、转换、清晰，最终以一种统一的格式装载进数据仓库。数据仓库里的数据作为分析用的数据源，提供给后面的即席查询、分析系统、数据集市、报表系统、数据挖掘系统等。

为什么不直接访问业务系统？

某些业务数据由于安全或其他因素不能直接访问
业务系统的版本变更很频繁
来源多个业务系统版本的表很难建立和维护
数据格式不统一，比如日期、数字的格式不统一
业务系统的表结构为事务处理性能而优化，有时并不适合查询与分析
会影响业务系统的性能

4.数据仓库与数据库的区别

OLTP（On-Line Transaction Processing）

操作型处理，叫做联机事务处理OLTP
称为面向交易的处理系统，是针对具体业务在数据库联机的日常操作
用户较为关心操作的响应时间、数据安全、完整和并发支持的用户数量等问题

OLAP（On-Line Analytical Processing）

分析型处理，叫做联机分析处理OLAP
一般针对某些主题的历史数据进行分析，支持管理决策
数据仓库在设计是有意引入冗余、依照分析需求、分析维度、分析指标进行设计
数据库是为了捕获数据而设计，数据仓库是为分析数据而设计

5.数据仓库分层架构

按照数据流入流出的过程，数据仓库架构分为：源数据、数据仓库、数据应用

源数据：此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。

数据仓库：也称为细节层，DW层的数据应该是一致的、准确的、干净的数据，即对原系统数据进行了清洗后的数据。

数据应用：前端应用直接读取的数据源；根据报表、专题分析需求而计算生成的数据。

数据仓库从各个数据源获取数据以及在数据仓库内的数据转换和流动都可以认为是ETL（抽取、转换、装载）的过程。

为什么需要对数据仓库进行分层？

清晰数据结构：每一层都有自己的作用域，使用表的时候更方便地定位
方便数据血缘追踪：快速利用血缘关系定位到问题
减少重复开发：规范数据分层，开发一些通用的中间层数据，减少极大的重复计算
把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤
屏蔽原始数据的异常：屏蔽业务的影响，不必改一次业务就需要重新接入数据

6.主要数据仓库架构

6.1 数据集市架构

数据集市是按照主题域组织的数据集合，用于支持部门级的决策。有两种类型的数据集市：

独立数据集市
从属数据集市

独立数据集市

独立数据集市集中于部门所关心的单一主题域，数据以部门为基础部署，无需考虑企业级别的信息共享与集成。例如，制造部门、人力资源部门和其他部门都由各自的数据集市。
优点
部门的业务相对于整个企业要更为简单，数据量也小，所以部门的独立数据集市具有周期短、见效快的特点
缺点
从业务角度看，当部门的分析需求扩展，或者需要分析跨部门或跨主题域的数据时，独立数据市场会显得不足
每个部门使用不同的技术，建立不同的ETL过程，处理不同的事务系统，而在多个独立的数据集市之间还会存在数据的交叉与重叠，甚至会有数据不一致的情况。

从属数据集市

从属数据集市的数据来源于数据仓库。数据层库的数据经过整合、重构、汇总后传递给从属数据集市。
优点：
性能：当数据层库的查询性能出现问题，可以考虑建议几个从属数据集市，将查询从数据仓库移出到数据集市。
安全：每个部门可以完全控制他们自己的数据
数据一致：因为每个数据集市的数据来源都是同一个数据仓库，有效消除了数据不一致的情况

6.2 Inmon企业工厂架构

企业级数据仓库：是该架构中的核心组件。企业级数据仓库是一个细节数据的集成资源库。其中的数据以最低粒度级别被捕获、存储在满足三范式设计的关系数据库中。

部门及数据集市：是面向主题数据的部门级视图，数据从企业级数据仓库获取。数据在进入部门数据集市时可能进行聚合。数据集市使用多维模型设计，用于数据分析。

6.3 Kimball数据仓库架构

Kimball的数据仓库包含高粒度的企业数据，使用多维模型设计，数据仓库是由星型模式的维度表和事实表构成的。分析系统或报表工具可以直接访问多维数据。

这里的数据集市是一个逻辑概念，只是多维数据仓库中的主题域划分，并没有自己的物理存储，只是一个虚拟的数据集市。

6.4 混合型数据仓库架构

联合使用Inmon和Kimball两种架构。

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

使用这种架构的好处是：既可以利用规范化设计消除数据冗余，保证数据的粒度足够细；又可以利用多维结构更灵活地在企业级实现报表和分析。

7.数据仓库元数据管理

元数据（Meta Data），主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态以及ETL的任务运行状态。

元数据是数据仓库管理系统的主要组成部分，元数据管理是企业数据仓库中的关键组件，贯穿数据仓库构建的整个过程，直接影响这数据仓库的构建、使用和维护。

元数据不仅定义了数据仓库中数据的模式、来源、抽取和转换规则等，而且是整个数据仓库系统运行的基础，元数据把数据仓库系统中各个松散的组件联系起来，组成了一个有机的整体。

8.数仓常见术语解析

8.1 数仓名词解释

实体：指依附的主体，就是分析的一个对象，比如分析商品的销售情况，如华为手机近半年的销售量是多少，那华为手机就是一个实体。

实体的存在是为了业务分析，作为分析的一个筛选的维度，拥有描述自己的属性，本身具有可分析的价值。

维度：维度就是看待问题的角度，分析业务数据，从什么角度分析，就建立说明样的维度。所以维度就是要对数据进行分析时所用的一个量。
度量：度量是业务流程节点上的一个数值。比如销量、价格、成本等等。

事实表的度量可分为三类：
完全可加
完全可加的度量是最灵活的，最有用的，比如说销量、销售额等，可进行任意维度汇总。
半可加
可以对某些维度进行汇总，但不能对所有维度汇总，差额是常见的半可加度量，除了时间维度外，可以跨所有维度进行加法操作。
不可见
还有一种是完全不可加的，例如：比率。

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

选择合适的粒度级别是数据仓库建设好坏的重要关键内容
要接受的分析类型、可接受的数据最低粒度和能存储的数据量
粒度的层次定义越高，就越不能在该仓库中进行更细致的分析
如果存储资源有一定的限制，就只能采用较高的数据粒度划分
数据粒度划分策略一定要保证：数据的粒度确实能满足用户的决策分析

口径：口径就是取数逻辑（如何取数），比如要取的数是10岁以下儿童中男孩的平均身高，这就是统计的口径。
指标：指标是口径的衡量值，也就是最后的结果。比如最近七天的订单量，一个促销活动的购买转化率。
原子指标：基本业务事实，没有业务限定、没有维度。比如订单表中的订单量、订单总金额都算原子指标
派生指标：维度+修饰词+原子指标。店铺近一天订单支付金额中店铺是维度，近一天是一个时间类型的修饰词，支付金额是一个原子指标。
维度：观察各项指标的角度
修饰词：维度的一个或某些值，比如维度性别下，男和女就是修饰词
衍生指标：比如某一个促销活动的转化率就是衍生指标，需要促销投放人数指标和促销订单数指标进行计算得出。
标签：是认为设定、根据业务场景需求，对目标对象运用一定的算法得到的高度精炼的特征标识。
自然键：由现实中以及存在的属性组成的键，在业务概念中是唯一的，并具有一定的业务含义，比如商品ID，员工ID
持久键：保持永久性不会发生变化。自然键和持久键区别：员工ID和员工的身份证号码，员工ID是可以改变的。
代理键：就是不具有业务含义的键。代理键有许多其他的称呼：无意义键、整数键、非自然键、人工键、合成键等。代理键的作用仅仅是连接维度表和事实表。
退化维度：就是那些看起来像是事实表的一个维度关键字，但实际上并没有对应的维度表。
下钻：下钻可以理解成增加维的层次，可以由粗粒度到细粒度来观察数据。
上卷：上卷可以理解为删掉维的某些层，由细粒度到粗粒度观察数据的操作或沿着维的层次向上聚合汇总数据。
数据集市：Data Mart，也叫做数据市场，数据集市就是满足特定的部门或者用户的需求，按照多维的方式进行存储，包括定义维度、需要计算的指标、维度的层次等，生成面向决策分析需求的数据立方体。其实就是从数据仓库中抽取出来的一个小合集。

8.2 数仓名词之间关系

实体表、事实表、维度表之间的关系

维度表：维度表可以看成是用户来分析一个事实的窗口，里面的数据应该是对事实的各个方面描述，比如时间维度表、地域维度表，维度表是事实表的一个分析角度。
事实表：事实表其实就是通过各种维度和一些指标值的组合来确定一个事实的，比如通过时间维度，地域组织维度，指标值可以去确定在某时某地的一些指标值怎么样的事实。
实体表：实体表就是一个实际对象的表，实体表放的数据一定是一条条客观存在的事物数据，比如说各种商品，它就是客观存在的，所以可以将其设计一个实体表。实时表只描述各个事物，并不存在具体的事实，所以也有人称实体表是无事实的事实表。
举个例子：比如说手机商场中有苹果手机，华为手机等各品牌各型号的手机，这些数据可以组成一个手机实体表，但是表中没有可度量的数据。某天苹果手机卖了15台，华为手机卖了20台，这些手机销售数据属于事实，组成一个事实表。这样就可以使用日期维度表和地域维度表对这个事实表进行各种维度分析。

指标与标签的区别

概念不同
指标是用来定义、评价和描述特定事物的一种标准或方式。比如：新增用户数、累计用户数、用户活跃率等是衡量用户发展情况的指标；
标签是人为设定的、根据业务场景需求，对目标对象运用一定的算法得到的高度精炼的特征标识。可见标签是经过人为再加工后的结果，如网红。
构成不同
指标名称是对事物质与量两方面特点的命名；指标取值是指标在具体时间、地域、条件下的数量表现，如人的体重，指标名称是体重，指标的取值就是120斤；
标签名称通常都是形容词或形容词+名词的结构，标签一般是不可量化的，通常是孤立的，除了基础类标签，通过一定算法加工出来的标签一般都没有单位和量纲。如将超过200斤的称为大胖子。
指标最擅长的应用是监测、分析、评价和建模。
标签最擅长的应用是标注、刻画、分类和特征提取。

维度和指标区别与联系

维度就是数据的观察角度，即从哪个角度去分析问题，看待问题。
指标就是从维度的基础上去衡量这个结果的值。

自然键与代理键在数仓的使用区别

维度表的唯一主键应该是代理键而不应该是自然键，因为业务库会变动

数据集市和数据仓库的关系

数据集市是企业级数据仓库的一个子集，面向部门级业务，并且只面向某个特定的主题。
数据集市和数据仓库的主要区别：数据仓库是企业级的，能为整个企业各个部门运行提供决策支持手段；数据集市则是一种微型的数据仓库，也称之为部门级数据仓库。

2.离线数仓建设理论

数据仓库的核心是展现层和提供优质的服务。ETL 及其规范、分层等所做的一切都是为了一个更清晰易用的展现层。

2.1 数仓分层原则

便于数据分析，屏蔽底层复杂业务
底层业务变动要对上层需求变
动的冲击要小
高内聚松耦合，主题内要高内聚，主题之间要松耦合
构建仓库基础数据层，使底层业务数据整合工作与上层应用工作相隔离

分层

ODS层

ODS 层，是最接近数据源中数据的一层，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的 DWD 层来做。

DW层

数据仓库层

DWD：数据明细层

DWD 层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理。
该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。

DWM/DWB：数据中间层

在 DWD 层的数据基础上，数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。
就是对通用的核心维度进行聚合操作，算出相应的统计指标。

DWS：数据服务层

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

APP层（ADS层）

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

DIM层

高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。

2.2 数仓建模方法

建模是在数据源层的下一层进行建设，在上节的分层架构中，就是在DW层进行数仓建模，所以DW层是数仓建设的核心层。

2.2.1 范式建模法

Third Normal Form, 3NF

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

一般采用第三范式。一个符合第三范式的关系必须具有以下三个条件 :

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

2.2.2 维度建模法

Dimensiomal Modeling

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

典型的代表是我们比较熟知的星形模型（Star-schema），以及在一些特殊场景下适用的雪花模型（Snow-schema）。

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

2.2.3 实体建模法

Entity Modeling

在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。

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

2.3 维度建模详解

2.3.1 表的类型

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

特征：是一堆主键的集合，每个主键对应维度表中的一条记录，客观存在的，根据主题确定出需要使用的数据
事实表表示对分析主题的度量。比如一次购买行为我们就可以理解为是一个事实。
明细表（宽表）：为了分析方便，可以事实表中的一个字段切割提取多个属性出来构成新的字段，因为字段变多了，所以称为宽表，原来的成为窄表。

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

每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键
事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。

事实表种类

事务事实表

事务事实表记录的事务层面的事实，保存的是最原子的数据，也称”原子事实表“。
事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务记录一条记录。

周期快照事实表

周期快照事实表以具有规律性、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等。
周期快照事实表记录的是重复的可预测到的时间间隔的事实。
典型的例子如销售日快照表、库存日快照表等。它统计的是间隔周期内的度量统计，如历史至今、自然年至今、季度至今等等。

累计快照事实表

周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。
累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。
例如订单累计快照事实表会有付款日期，发货日期，收货日期等时间点。
而累计快照适用于较短周期，有着明确的开始和结束状态的过程，如一个订单执行的过程，并记录过程中每个步骤的执行时间，使分析人员对执行的过程有整体的把握。

2.3.2 维度建模的三种模式

星型模式

星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。
星形模式的维度建模由一个事实表和一组维表成
特点
维表只和事实表关联，维表之间没有关联；
每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；
以事实表为核心，维表围绕核心呈星形分布

雪花模式

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

星座模式

星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。
前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

2.3.3 维度建模过程

选择业务过程

在整个业务流程中选取我们需要建模的业务，根据运营提供的需求以及日后的易扩展性等进行选择业务。

声明粒度

在同一事实表中，必须具有相同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据建立不同的事实表。
建议从原子粒度开始设计，也就是从最细粒度开始，因为原子粒度能够承受无法预期的用户查询。

确认维度

牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开，并且要确保维度表中不能出现重复数据，应使维度主键唯一

确认事实

事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。
最实用的事实就是数值类型和可加类事实。

3.离线数仓建设实战

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

4.实时计算概念

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

实时计算的三个特征：

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

4.1 实时计算应用场景

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

1. 实时智能推荐

智能推荐会根据用户历史的购买或浏览行为，通过推荐算法训练模型，预测用户未来可能会购买的物品或喜爱的资讯。

对个人来说，推荐系统起着信息过滤的作用，对Web/App服务端来说，推荐系统起着满足用户个性化需求，提升用户满意度的作用。

推荐系统本身也在飞速发展，除了算法越来越完善，对时延的要求也越来越苛刻和实时化。利用Flink流计算帮助用户构建更加实时的智能推荐系统，对用户行为指标进行实时计算，对模型进行实时更新，对用户指标进行实时预测，并将预测的信息推送给Web/App端，帮助用户获取想要的商品信息。

另一方面也帮助企业提升销售额，创造更大的商业价值。

2. 实时欺诈检测

在金融领域的业务中，常常出现各种类型的欺诈行为，例如信用卡欺诈，信贷申请欺诈等，而如何保证用户和公司的资金安全，是近年来许多金融公司及银行共同面对的挑战。

随着不法分子欺诈手段的不断升级，传统的反欺诈手段已经不足以解决目前所面临的问题。以往可能需要几个小时才能通过交易数据计算出用户的行为指标，然后通过规则判别出具有欺诈行为嫌疑的用户，再进行案件调查处理，在这种情况下资金可能早已被不法分子转移，从而给企业和用户造成大量的经济损失。

而运用Flink流式计算技术能够在毫秒内就完成对欺诈行为判断指标的计算，然后实时对交易流水进行实时拦截，避免因为处理不及时而导致的经济损失。

3. 舆情分析

有的客户需要做舆情分析，要求所有数据存放若干年，舆情数据每日数据量可能超百万，年数据量可达到几十亿的数据。

而且爬虫爬过来的数据是舆情，通过大数据技术进行分词之后得到的可能是大段的网友评论，客户往往要求对舆情进行查询，做全文本搜索，并要求响应时间控制在秒级。

爬虫将数据爬到大数据平台的Kafka里，在里面做Flink流处理，去重去噪做语音分析，写到ElasticSearch里。大数据的一个特点是多数据源，大数据平台能根据不同的场景选择不同的数据源。

4. 复杂事件处理

对于复杂事件处理，比较常见的集中于工业领域，例如对车载传感器，机械设备等实时故障检测，这些业务类型通常数据量都非常大，且对数据处理的时效性要求非常高。

通过利用Flink提供的CEP进行时间模式的抽取，同时应用Flink的Sql进行事件数据的转换，在流式系统中构建实施规则引擎，一旦事件触发报警规则，便立即将告警结果通知至下游通知系统，从而实现对设备故障快速预警检测，车辆状态监控等目的。

5. 实时机器学习

实时机器学习是一个更宽泛的概念，传统静态的机器学习主要侧重于静态的模型和历史数据进行训练并提供预测。很多时候用户的短期行为，对模型有修正作用，或者说是对业务判断有预测作用。

对系统来说，需要采集用户最近的行为并进行特征工程，然后给到实时机器学习系统进行机器学习。如果动态地实施新规则，或是推出新广告，就会有很大的参考价值。

4.2 实时计算总览

数据同步：

在上面这张架构图中，数据从Web平台中产生，通过数据同步系统导入到大数据平台，由于数据源不同，这里的数据同步系统实际上是多个相关系统的组合。数据库同步通常用 Sqoop，日志同步可以选择 Flume等，不同的数据源产生的数据质量可能差别很大，数据库中的格式化数据直接导入大数据系统即可，而日志和爬虫产生的数据就需要进行大量的清洗、转化处理才能有效使用。

数据存储：

该层对原始数据、清洗关联后的明细数据进行存储，基于统一的实时数据模型分层理念，将不同应用场景的数据分别存储在 Kafka、HDFS、Kudu、 Clickhouse、Hbase等存储中。

数据计算：

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

实时应用：

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

元数据管理及数据治理：

1. 元数据及指标管理：主要对实时的Kafka表、Kudu表、Clickhouse表、Hive表等进行统一管理，以数仓模型中表的命名方式规范表的命名，明确每张表的字段含义、使用方，指标管理则是尽量通过指标管理系统将所有的实时指标统一管理起来，明确计算口径，提供给不同的业务方使用；

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

以上架构只是大数据平台通用的数据模型，如果要具体的建设，需要考虑以下情况，业务需求需要实时还是准实时即可，数据时效性是秒级还是分钟级等。

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

4.3 实时架构

两种技术架构Lambda和Kappa

4.3.1 Lambda

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

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

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

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

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

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

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

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

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

那Lambda架构有没有缺点呢？

Lambda架构经历多年的发展，其优点是稳定，对于实时计算部分的计算成本可控，批量处理可以用晚上的时间来整体批量计算，这样把实时计算和离线计算高峰分开，这种架构支撑了数据行业的早期发展，但是它也有一些致命缺点，并在大数据3.0时代越来越不适应数据分析业务的需求。缺点如下：

使用两套大数据处理引擎：维护两个复杂的分布式系统，成本非常高。
批量计算在计算窗口内无法完成：在IOT时代，数据量级越来越大，经常发现夜间只有4、5个小时的时间窗口，已经无法完成白天20多个小时累计的数据，保证早上上班前准时出数据已成为每个大数据团队头疼的问题。
数据源变化都要重新开发，开发周期长：每次数据源的格式变化，业务的逻辑变化都需要针对ETL和Streaming做开发修改，整体开发周期很长，业务反应不够迅速。

4.3.2 Kappa

Kafka的创始人Jay Kreps认为在很多场景下，维护一套Lambda架构的大数据处理平台耗时耗力，于是提出在某些场景下，没有必要维护一个批处理层，直接使用一个流处理层即可满足需求，即下图所示的Kappa架构：

这种架构只关注流式计算，数据以流的方式被采集过来，实时计算引擎将计算结果放入数据服务层以供查询。可以认为Kappa架构是Lambda架构的一个简化版本，只是去除掉了Lambda架构中的离线批处理部分；

Kappa架构的兴起主要有两个原因：

Kafka不仅起到消息队列的作用，也可以保存更长时间的历史数据，以替代Lambda架构中批处理层数据仓库部分。流处理引擎以一个更早的时间作为起点开始消费，起到了批处理的作用。
Flink流处理引擎解决了事件乱序下计算结果的准确性问题。

Kappa架构相对更简单，实时性更好，所需的计算资源远小于Lambda架构，随着实时处理的需求在不断增长，更多的企业开始使用Kappa架构。但这不意味着kappa架构能够取代Lambda架构。

Lambda和kappa架构都有各自的适用领域；

例如流处理与批处理分析流程比较统一，且允许一定的容错，用Kappa比较合适，少量关键指标（例如交易金额、业绩统计等）使用Lambda架构进行批量计算，增加一次校对过程。
还有一些比较复杂的场景，批处理与流处理产生不同的结果（使用不同的机器学习模型，专家系统，或者实时计算难以处理的复杂计算），可能更适合Lambda架构。

5.实时数仓建设核心

5.1 实时计算初期问题

早期开发形式

如上图所示，拿到数据源后，会经过数据清洗，扩维，通过Flink进行业务逻辑处理，最后直接进行业务输出。把这个环节拆开来看，数据源端会重复引用相同的数据源，后面进行清洗、过滤、扩维等操作，都要重复做一遍，唯一不同的是业务的代码逻辑是不一样的。

随着产品和业务人员对实时数据需求的不断增多，这种开发模式出现的问题越来越多：

数据指标越来越多，“烟囱式”的开发导致代码耦合问题严重。
需求越来越多，有的需要明细数据，有的需要 OLAP 分析。单一的开发模式难以应付多种需求。
每个需求都要申请资源，导致资源成本急速膨胀，资源不能集约有效利用。
缺少完善的监控系统，无法在对业务产生影响之前发现并修复问题。

5.2 实时数仓建设

分层是一种非常有效的数据治理方式，所以在实时数仓如何进行管理的问题上，首先考虑的也是分层的处理逻辑。

实时数仓的架构：

从上图中我们具体分析下每层的作用：

数据源：在数据源的层面，离线和实时在数据源是一致的，主要分为日志类和业务类，日志类又包括用户日志，埋点日志以及服务器日志等。
实时明细层：在明细层，为了解决重复建设的问题，要进行统一构建，利用离线数仓的模式，建设统一的基础明细数据层，按照主题进行管理，明细层的目的是给下游提供直接可用的数据，因此要对基础层进行统一的加工，比如清洗、过滤、扩维等。
汇总层：汇总层通过Flink的简洁算子直接可以算出结果，并且形成汇总指标池，所有的指标都统一在汇总层加工，所有人按照统一的规范管理建设，形成可复用的汇总结果。

实时数仓和离线数仓的分层非常类似，比如数据源层，明细层，汇总层，乃至应用层，他们命名的模式可能都是一样的。但仔细比较不难发现，两者有很多区别：

与离线数仓相比，实时数仓的层次更少一些：
从目前建设离线数仓的经验来看，数仓的数据明细层内容会非常丰富，处理明细数据外一般还会包含轻度汇总层的概念，另外离线数仓中应用层数据在数仓内部，但实时数仓中，app 应用层数据已经落入应用系统的存储介质中，可以把该层与数仓的表分离。
应用层少建设的好处：实时处理数据的时候，每建一个层次，数据必然会产生一定的延迟。（减少延迟）
与离线数仓相比，实时数仓的数据源存储不同：
在建设离线数仓的时候，基本整个离线数仓都是建立在 Hive 表之上。但是，在建设实时数仓的时候，同一份表，会使用不同的方式进行存储。比如常见的情况下，明细数据或者汇总数据都会存在 Kafka 里面，但是像城市、渠道等维度信息需要借助 Hbase，MySQL 或者其他 KV 存储等数据库来进行存储。

5.3 Lambda架构的实时数仓

下图是基于 Flink 和 Kafka 的 Lambda 架构的具体实践，上层是实时计算，下层是离线计算，横向是按计算引擎来分，纵向是按实时数仓来区分：

5.4 Kappa架构的实时数仓

Kappa架构相当于去掉了离线计算部分的Lambda架构，具体如下图所示：

Kappa架构从架构设计来讲比较简单，生产统一，一套逻辑同时生产离线和实时。但是在实际应用场景有比较大的局限性，因为实时数据的同一份表，会使用不同的方式进行存储，这就导致关联时需要跨数据源，操作数据有很大局限性，所以在业内直接用Kappa架构生产落地的案例不多见，且场景比较单一。

对于实时数仓来说，怎么去解决数据重算问题？

Kappa 架构在这一块的思路是：首先要准备好一个能够存储历史数据的消息队列，比如 Kafka，并且这个消息队列是可以支持你从某个历史的节点重新开始消费的。接着需要新起一个任务，从原来比较早的一个时间节点去消费 Kafka 上的数据，然后当这个新的任务运行的进度已经能够和现在的正在跑的任务齐平的时候，你就可以把现在任务的下游切换到新的任务上面，旧的任务就可以停掉，并且原来产出的结果表也可以被删掉。