数据研发学习笔记01：数据仓库

本文主要围绕以下问题展开相应的数据研发相关知识的梳理与总结：

1. 数据仓库的作用和价值，与传统数据库的区别。
2. 什么是OLAP，什么是OLTP，之间的区别是什么？
3. 范式建模与星型模型的区别是什么？为什么在数据仓库领域不采用范式建模？
4. Google DataFlow模型是什么？有什么特点？用于解决什么问题？
5. 实时数仓和离线数仓的区别是什么？现在业内比较流行的实时数仓有哪些？他们之间的区别是什么？（【数仓】数据仓库的建设（二））

1 数据仓库

1.1 数据仓库由来

公司的业务系统很多，业务系统的历史数据不方便查询。不同的业务系统往往管理部门不同，地域不同。 能不能将所有这些数据集中起来， 再淘淘有没有有意义的业务规律。 数据仓库数据库往往很大，因为公司所有的数据集中得越多，越能淘到有价值的发现。

数据仓库产生的原因，事物处理环境不适宜决策支持系统（Decision Support System，DSS）：

操作型数据库是为已知和负载设计的，多支持事物的并发处理，需要并发控制和恢复机制，以确保一致性和事物的鲁棒性，数据仓库查询通常是复杂的，涉及大量的数据汇总级的计算，可能需要特殊的基于多维视图的数据组织、存取方法和实现方法，在操作库上处理OLAP查询，可能会大大降低操作任务的性能。

1.2 数据仓库定义

数据仓库（Data Warehouse）就是一个用以更好地支持企业或组织的决策分析处理的、面向主题的、集成的、不可更新的、随时间不断变化的数据集合，即为企业所有级别的决策制定过程提供所有类型数据支持的战略集合。

它是单个数据存储，出于分析性报告和决策支持目的而创建。为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。即数据仓库主要用于数据挖掘和数据分析，辅助领导做决策。

1.3 数据仓库特点

（1）集成性
　　数据仓库中存储的数据是来源于多个数据源，原始数据在不同数据源中的存储方式各不相同。要整合成为最终的数据集合，需要从数据源经过一系列抽取、清洗、转换的过程。

（2）稳定性
　　数据仓库中保存的数据是历史记录，不允许被修改。用户只能通过分析工具进行查询和分析。

（3）动态性
　　数据仓库数据会随时间变化而定期更新，不可更新是针对应用而言，即用户分析处理时不更新数据。

（4）主题性
　　传统数据库对应项目不同，数据仓库根据需求，将不同数据源的数据整合，所有数据都围绕某一主题。比如“分析某个地区人口的学历”、“企业的注册资本”这样类似地主题。

1.4 构建数据仓库

构建数据仓库的过程是将不同数据源的数据整合起来，通过对数据进行清洗，规范化数据；根据需求围绕一个主题进行构建；并且构建好的数据仓库不用于UPDATE，仅用于查询；构建好的数据仓库也方便获取数据，节省了一定的资源。

1.5 数据库和数据仓库的区别

数据库存储的是原始数据，没经过任何加工；而数据仓库是为了满足数据分析需要设计的，对源数据进行了ETL(Extract,Transform,Load)过程，数据抽取工作分抽取、清洗、转换、装载。

原始数据/操作型数据	导出数据/分析型数据
面向应用	面向主题
详细的	综合的或提炼的
为日常工作服务	为管理者服务
近期数据、在访问瞬间是准确的	历史数据、快照
可更新	不更新（修改）
重复运行	启发式运行
处理需求预先可知	处理需求预先不知道
非冗余性	存在冗余
对性能要求高	对性能要求宽松
一次访问一个单元	一次访问一个集合
静态结构：可变内容	结构灵活
访问频繁	访问较少

2 OLTP与OLAP

从数据操作到数据分析。

• 联机事务处理（Online Transaction Processing，QLTP）：支持联机事务处理数据库的关注点在于多用户并发环境下的数据一致性和完整性。强调数据的收集、数据库的更新操作，即向数据库中添加信息。

• 联机分析处理（Online Analysitical Processiong，OLAP）：指基于业务数据的决策分析。从数据库中获取信息并加以利用。

3 数据仓库的设计

3.1 数据库设计和数据仓库设计

• 在业务系统中使用的数据库，其中一般存储的是在线交易数据，是以业务单位组织数据并进行存储的。由于数据库是面向具体的应用，现在一般才有用关系模型的设计方法。通过关系模型以保证数据的原子性、一致性和完整性，消除数据冗余，一般采用复合范式的规则来约束设计。

• 而数据仓库从设计之初就是为了数据分析服务的，因此在数据组织上是以面向主题进行组织和存储的。是通过在多个维度上对历史数据进行观察和分析，为决策人员提供在该关注点（主题）上的辅助决策信息。因此，在设计上也不同于数据库的关系模型，而是采用多维分析数据模型。

数据库（DB）与数据仓库（DW）设计方法比较：

3.2 数据仓库设计的原则

数据仓库的设计是坚持“以数据驱动为中心，数据驱动和需求驱动相结合”的原则。

• 数据驱动：根据当前数据基础和质量等情况，进行数据源分析。
• 需求驱动：根据业务方向性需求、业务问题等，确定系统范围和需求框架。

3.3 数据仓库设计的三级模型

数据仓库设计的三级数据模型：

• 概念模型：“信息世界”中的信息结构，用E-R方法，以主题替代实体。
• 逻辑模型：直接反映了数据分析部门的实际需求和业务规划，同时对物理模型的设计和实现具有指导作用，一遵循第三范式，采用关系模型。其特点就是通过实体和实体之间的关系勾勒出整个企业的数据蓝图和规划。
• 物流模型：物流存储结构、存储方法。

（1）概念模型设计

• 确定边界：
  • 了解需求：需求类型、决策者关注点。
  • 确定数据覆盖范围。
  • 了解源数据状况。
• 确定主题域：
  • 确定系统包含的主题。
  • 确定各主题属性组合连接键。
  • 主题域之间的联系。
    
    （2）逻辑模型设计
• 将主题域包含的内容转化为主题域包含若干个数据组（表）。
• 将主题域之间的关系细化、转换为表与表之间的关系。
• 增加时间属性。
• 粒度层次划分（粒度：数据的综合程度，如日/周/月/季度/年度）。
  • 引入冗余：将存放于数据源多个表中的数据进行合理合并，减少查询中的连接操作，提高查询效率。
  • 增加派生数据：用户经常查询的数据需增加派生数据以减少查询时的计算量；增加不同粒度的汇总数据。
    
    （3）物理模型设计
• 存储结构：存取时间、存储空间利用率、维护代价等。
• 索引策略
• 数据存放位置：根据重要程度、使用频率和响应时间将数据分类，不同类数据分别存放在不同存储设备中；冗余存储。
• 存储分配：存储块、缓冲区大小和个数。

将逻辑模型转变为物流模型的步骤：
① 实体名（Entity）转变为表名（Table）。
② 属性名（Attribute）转换为列名（Column），确定列的属性（Property）。
③ 确定表之间连接主键和外键属性或属性组。

数据仓库的数据模型相对数据库更简单一些，根据事实表和维度表的关系，主要有星型结构模型和雪花型结构模型两种。

• 星型模型：是一种非规范化的结构，多维数据集的每一个维度都直接与事实表相连接，所以数据有一定的冗余。如，在商店维度表中，存在省A的城市B和省B的城市C两条记录，那么省A的信息分别存储了两次。
  
• 雪花型模型：是对星型模型的扩展，通过去除数据冗余，最大限度地减少数据库存储量以及联合较小的维度表来改善查询性能。

相对于星型结构的优点是：能够直接利用现有的数据库建模工具进行建模，提高工作效率；对维度表的变更更加灵活；由于不存在数据冗余，数据的装载速度更快。
缺点：表更多，维护复杂。

3.4 ETL

ETL是数据抽取（Extract）、转换（Transform）、加载（Load）的简写，它是将OLTP系统中的数据经过抽取，并将不同数据源的数据进行转换、整合，得出一致性的数据，然后加载到数据仓库中。

（1）数据抽取

简而言之就是把源数据的数据抽取到数据仓库中。因为抽取到数据仓库中的数据可能来自各种数据源，因此数据类型也是不尽相同。

• 逻辑抽取模式：分为全抽取和增量抽取两种。全量抽取适用于那些数据量比较小，并且不容易判断其数据发生改变的诸如关系表，维度表，配置表等；增量抽取，一般是由于数据量大，不可能采取全量抽取，或者为了节省时间而采用的抽取策略。
• 物理抽取模式：分为在线抽取和脱机抽取两种。在线抽取就是在事务处理系统使用业务数据库的同时抽取数据到数据仓库，虽然抽取的操纵会给业务系统性能带来一定的影响，适合于小数据量的抽取；脱机抽取就是在业务系统不工作的时候进行数据抽取。

（2）数据清洗

空值处理：一般的做法是根据其有无分析价值而定。

• 对于没有分析价值的空字段数据可直接忽略，不做清洗处理。
• 对于有分析价值的空字段数据就要根据实际情况进行相应的处理，转换为特定的值。

缺失值处理：

• 删除缺失值记录。当数据量很大时，可以删除存在有缺失值的数据行。
• 用固定的值填充。这样处理会导致数据的偏离。
• 用缺失单元列的未缺失值平均值填充。
• 用缺失单元列的未缺失值的众数填充。
• 根据缺失值单元行的其他单元值填充。比如客户的婚姻状况单元缺失，但是客户的性别、年龄、职业单元有数据，则可以根据同样性别、年龄、职业的客户的婚姻状况值填充。
• 把缺失值当做该属性的一个取值。比如在决策树分析中常常将缺失值视同该属性的一种取值。
• 利用已有的完整事例构建挖掘模型，然后使用这个模型为每个缺失值预测最有可能的值。

（3）数据转换

数据转换的基本任务是要完成数据的选择、分离/合并、转化、汇总和丰富。

数据转换主要类型包括格式修正、字段解码、计算值和导出值、单个字段的分离、信息的合并、特征集合转化、度量单位的转化、日期/时间转化、汇总和键的重新构造。（可以使用转换工具）

（4）数据装载

初始装载：在初始装载的时候，由于数据仓库中的表都是空的，这时候只要对数据仓库中的所有表进行数据插入即可。

完全刷新：如果数据仓库中已经装载了部分数据，通常在数据量较少的情况下，可以先将目标数据库的数据全部清空，然后全部重新从数据源加载进来。

增量装载：对于已经存在目标数据库中的数据都是历史数据，对于数据源中的数据我们只应该考虑新修改的记录和新插入的记录。所以增量处理实质上就是处理变化的数据。

4 离线数仓和实时数仓

4.1 离线数仓

离线大数据架构的特点：

• 数据源通过离线的方式导入到离线数仓中；
• 数据处理采用MapReduce、Hive、SparkSQL等离线计算引擎。
  

离线数仓分层：

4.2 实时数仓

实时数仓Lambda架构：

实时数仓Kappa架构：




Lambda架构与Kappa架构的对比

4.3 两者区别

• 从架构上：实时数仓与离线数仓有比较明显的区别，实时数仓以Kappa架构为主，而离线数仓以传统大数据架构为主。Lambda架构可以认为是两者的中间态。目前业界所说的实时数仓大多是Lambda架构，这是需求决定的。
• 从建设方法上：实时数仓和离线数仓基本还是沿用传统的数仓主题建模理论，产出实时宽表。另外实时数仓中实时流数据的join有隐藏时间语义，在建设中需注意。
• 从数据保障看：实时数仓因为要保证实时性，所以对数据量的变化较为敏感。在大促等场景下需要提前做好压测和主备保障工作，这是与离线数据的一个较为明显的区别。
  

5 分布式计算 Google Dataflow

5.1 概述

Google Cloud Dataflow是一种构建、管理和优化复杂数据处理流水线的方法，集成了许多内部技术，如用于数据高效并行化处理的Flume和具有良好容错机制流处理的MillWheel。

The Dataflow Model 是 Google Research 于2015年发表的一篇流式处理领域的有指导性意义的论文，它对数据集特征和相应的计算方式进行了归纳总结，并针对大规模/无边界/乱序数据集，提出一种可以平衡准确性/延迟/处理成本的数据模型。

Dataflow模型的思想集中体现在论文《The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing》

• 该模型处理的是大规模的、无界的、乱序的数据；
• 在处理这种数据的同时，需要兼顾正确性、时间延迟和资源消耗；
• 该模型是可实现的。

什么是“无界”数据
Google的大佬们认为，当我们提**“流式”（stream）这个词时，实际上表达的意思就是在源源不断的连续数据上进行处理。反之，当我们提“批量”（batch）这个词时，就意味着在有限的一块或多块数据上进行处理，亦即“有界”。论文中倾向于用无界/有界来代替流式/批量**，因为后者听起来像是在描述计算引擎的语义，而前者才是数据本身的特征。

对无界数据的处理必然要及时输出结果，否则就毫无意义。而输出的结果天然是有界数据，因此在Dataflow模型中，批量处理可以作为流式处理的一个子问题，目的是达到批流融合。这与传统Lambda架构（官网在这里）相比无疑是先进的，因为后者需要维护两套不同的组件分别用来做流式和批量处理，非常繁琐。

什么是“乱序”数据
我们都理解在数据的生成、采集、传输过程中，不可避免地会带来各种各样的延迟，这就意味着处理无界数据时，其顺序很有可能与业务逻辑的原始顺序不同。举个浅显的例子：某用户在7时55分浏览了某商品的详情页面，然后在7时56分加入购物车，57分下单购买，但日志队列中的顺序可能会变成“下单→加入购物车→浏览”。

在Lambda架构下的批量处理中，乱序数据造成问题的可能性往往很小。但是在Dataflow的批流融合构想下，必须正确地处理乱序数据才能保证整个大数据服务的正确性，因此非常重要。下面就来深入地看看Dataflow如何解决论文题目中的这些要点。

5.2 事件时间与处理时间

我们首先要分辨清楚Dataflow中最重要的一对基础概念，即事件时间（event time）和处理时间（processing time），说起来也很简单：

• 事件时间就是数据产生一瞬间的时间戳，比如调用某接口时的时间戳；
• 处理时间就是数据进入流式处理程序的时间戳。

下图示出事件时间和处理时间的关系。在理想情况下，数据总能及时地被处理，两者的关系应该是如虚线所示。但由于各种延迟的存在，实际情况更多地表现为红色粗箭头，两者之间会有一些差距（skew）。

将事件时间和处理时间区别对待，并且采用事件时间作为时间特征，是Dataflow的一大进步。

5.3 Dataflow三大模型

Dataflow将上述无界数据的处理问题分解为4个子问题来考虑：

• 需要产出什么 [What results are being computed]；
• 计算什么时间的数据 [Where in event time they are being computed]；
• 在哪些时机物化/输出结果 [When in processing time they are materialized]；
• 后到的数据如何修正之前的结果 [How earlier results relate to later refinements]。

这样一来就清晰多了。为了解决上面的4个子问题，Dataflow提出了以下这些方案：

• 窗口模型（windowing model），支持基于乱序的事件时间的窗口操作，用于解决Where问题；
• 触发模型（triggering model），能够将数据结果与事件的时间特性绑定，解决When问题；
• 增量更新模型（incremental processing model），能够将后到的数据融合到窗口和触发模型中，解决How问题。
• 至于最基本的what问题，当然是用户自己要考虑的。

（1）窗口模型

对无界数据的处理必然要及时输出结果，否则就毫无意义。那么要处理哪个时间范围的数据呢？通过窗口就可以将无界数据时域地划分为一个个的有限数据集，进而能在其上做分组、聚合、连接等比较高级的操作。下图示出乱序事件时间的一种窗口。

也就是说，Dataflow通过窗口模型将传统流处理中的(key, value)二元组改进为(key, value, event_time, window)四元组。

常见的开窗方式有三种，即固定（fixed/tumbling）窗口，滑动（sliding）窗口，会话（session）窗口，如下图所示。

固定窗口显然是最简单的，比如一个5分钟的固定窗口：[7:00, 7:05), [7:05, 7.10), [7:10, 7.15), …。滑动窗口对我们来说也是老熟人，例如一个窗口时长1小时，滑动时长10分钟的滑动窗口就是以下的时间区间：[7:00, 8:00), [7:10, 8:10), [7:20, 8:20), …。

会话窗口则不那么常见一些，它是Google在实践中总结出来的，通俗地说就是在一个key连续出现时才形成窗口，如果该key持续不出现超过一定时长，之后再出现就被划分到下一个窗口。这种方式比较灵活，并且容易想到它可以用于用户行为检测、异常检测等方面。

（2）触发模型

如果我们不采用事件时间作为时间特征，而用处理时间的话，就没有必要考虑触发模型，因为窗口的边界与数据没关系。但是一旦用事件时间，由于数据会迟到，窗口的边界就会模糊，也就是无从知道窗口里的数据是否已经齐活了，触发结果的物化变成了一道难题。所以在这里又引入了一个重要的概念，就是水印（watermark）。

水印本质上是个时间戳，对一个无界数据源而言，水印T就表示已经接收到所有t <= T的数据，其他t > T的数据都将被视为迟到，接下来就可以进行输出。在讲解事件时间和处理时间时，图中的红色箭头就是实际的水印时间。

显然，如果没有延迟的数据，或者我们能对输入数据有完整的感知，那么水印就是理想的（ideal）。但无界数据源本身决定了我们不可能完整感知到输入数据的特征，所以水印的设定大多是启发式（heuristic）的，亦即根据历史指标尽量保证窗口内数据的完整性，但不能确保100%可靠，太快和太慢都不行。当然，也可以根据业务情况，采用更加简单暴力的方式（如周期性打水印、计数打水印）等，优势是比较灵活，不过就更加不可靠了。

（3）增量更新模型

既然启发式水印不能确保100%可靠，那么就必须用迟到数据修正之前窗口的正确性，亦即增量更新，也叫做回填（backfill）。Dataflow原生定义了以下三种回填策略：

• 丢弃（discarding）：一旦窗口已经触发过了，就不再（在内存中）保留窗口的数据，所有超过水印的数据也都不算数；
• 累积（accumulating）：窗口触发过之后，保留窗口数据一段时间，超过水印的数据在该时间内仍然会进入窗口。保留的时间就是允许迟到时间（allowed lateness）。
• 累积与回撤（accumulating & retracting）：在累积的基础上，先撤回对上一次窗口操作的结果的修改，再输出新的结果。这是由于某些下游操作决定的，比如下游有累积计数操作，如果不撤回（即减去上一次的结果）的话，本次窗口的结果就不对了。