数据仓库详解

详解"/>

数据仓库详解

什么是数据仓库？

数据仓库是决策支持系统（dss）和联机分析应用数据源的结构化数据环境。数据仓库研究和解决从数据库中获取信息的问题。

数据仓库的特征：面向主题，集成性，稳定性，时变性，用于支持管理决策

面向主题：数据仓库中的数据是按照一定的主题域进行组织的，每一个主题对应一个宏观的分析领域。数据仓库排除对于决策无用的数据，提供特定主题的简明视图。

集成的：企业内不同业务部门数据的完整集成。

对于企业内所有数据的集成要注意一致性（假设财务系统中对于性别使用 F/M，而 OA 系统对性别使用 A/B，这就是数据不一致，如果想搭建企业级的数据仓库，需要数据具有一致性）。

稳定的：数仓里不存在数据的更新和删除操作。

变化的：数仓里会完整的记录某个对象在一段时期内的变化情况。

数据仓库的目标是实现集成、稳定、反映历史变化有组织有结构的存储数据的集合

基本架构

DM，DWS，DWD，ODS

ODS—脱敏/清洗—DWD—汇总—DWS—汇总/宽表—DM

三范式（关系型数据库）——目的：让字段拆分开，尽可能实现数据库没有冗余

而数仓会利用冗余换取查询的便利——宽表

OLTP和OLAP

操作型处理，叫联机事务处理 OLTP（On-Line Transaction Processing，），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。

分析型处理，叫联机分析处理 OLAP（On-Line Analytical Processing）一般针对某些主题的历史数据进行分析，支持管理决策。

周边技术架构

数据采集

功能	技术框架
数据采集	Datax，Sqoop，Flume
数据通道	Kafka，RabbitMQ
调度	Oozie，Azkaban

将目前主要的数据源分为数据库、日志、平面文件（在一些情况下你不能直接取抓取源数据库的数据，只能由源端数据的生成端按照一定格式将数据整理到文件中，然后采集到数据仓库中，总的来说，平面文件就是有一定格式的文件，其实日志也是平面文件的一种）三种。

采集对象	框架名称
数据库	Datax，Sqoop
日志	Flume，Logstash
平面文件	ftp，sftp，scp

数据通道

kafka：解耦合和峰值压力缓冲（消峰）

系统调度

• Oozie：Oozie 是一个重量级的任务调度系统，功能全面，但是需要进行大量的基于 XML 的配置，而且代码复杂度比较高。

  在实际工厂环境下如果使用 Oozie，复杂的配置会严重降低工作效率，因此往往会在上层封装一层 JavaEE，开发出一套 OM 界面，用户通过填写页面上的选项来完成配置，使得

  Oozie 的复杂配置对于用户是透明的。

• Azkaban 是由 Linkedin 开源的一个批量工作流任务调度器。用于在一个工作流内以一个特定的顺序运行一组工作和流程。Azkaban 使用 Properties 文件定义工作流，并提供一个易于使用的 web 用户界面维护和跟踪你的工作流。

  Azkaban 是一个轻量级的任务调度器，更适用于中小量任务的调度工作，如果不在意某些功能的缺失，Azkaban 是一个很不错的候选对象。

对比项	Oozie	Azkaban
功能	调度 Linux命令、MapReduce、Spark、Pig、Hive、Java 程序、脚本工作流任务，均可以定时执行工作流任务	调度 Linux命令、MapReduce、Spark、Pig、Hive、Java 程序、脚本工作流任务，均可以定时执行工作流任务
工作流定义	使用XML文件定义工作流	使用properties文件定义工作流
工作流传参	支持参数和EL表达式，如${fs:dirSize(myInputDIr)}	支持直接传参，如${input}
定时执行	定时执行任务基于时间和输入数据	定时执行任务基于时间
资源管理	暂无严格的权限控制	有较严格的权限控制，如用户对工作流进行读/写/执行等操作
工作流执行	作为工作流服务器运行，支持多用户和多工作流	有三种运行模式（solo server mode, two server mode, multiple executor
工作流管理	支持命令行、HTTP REST、Java API、浏览器操作工作流	mode），可以根据需要进行配置支持浏览器及 ajax方式操作工作流

• 在数据仓库的任务调度中，如果表 A 失败，对于 Azkaban，那么所有的任务全部停止， 发送报警消息，对于 Oozie，表 A 失败后立即发送报警消息，只有依赖于这个任务的任务会受到影响，其他的任务不受影响，继续运行，错误修复后，可以再次启动之前报错的任务， 完成任务，单一任务的失败不会影响系统的整体运行。

Hive

parquet和orc区别

• 列式存储：查询的时候不需要扫描全部的数据，而只需要读取每次查询涉及的列，这样可以将I/O消耗降低N倍，另外可以保存每一列的统计信息(min、max、sum等)，实现部分的谓词下推。
  由于每一列的成员都是同构的，可以针对不同的数据类型使用更高效的数据压缩算法，进一步减小I/O。
  由于每一列的成员的同构性，可以使用更加适合CPU pipeline的编码方式，减小CPU的缓存失效。
• 嵌套数据格式：使用关系数据库存储结构化数据，而关系数据库支持的数据模型都是扁平式的，而遇到诸如List、Map和自定义Struct的时候就需要用户自己解析，但是在大数据环境下，数据的来源多种多样，例如埋点数据，很可能需要把程序中的某些对象内容作为输出的一部分，而每一个对象都可能是嵌套的，所以如果能够原生的支持这种数据，查询的时候就不需要额外的解析便能获得想要的结果。例如在Twitter，他们一个典型的日志对象（一条记录）有87个字段，其中嵌套了7层。随着嵌套格式的数据的需求日益增加，目前Hadoop生态圈中主流的查询引擎都支持更丰富的数据类型，例如Hive、SparkSQL、Impala等都原生的支持诸如struct、map、array这样的复杂数据类型，这样促使各种存储格式都需要支持嵌套数据格式。
• 若论对 Hive（以 MapReduce 为执行引擎）的支持 Orc 是最好的，但是若论对 Spark 等 Hadoop 生态圈中更多的技术框架，Parquet 的支持是最好的，而 Spark 作为 Hive 的执行引擎时性能非常好，因以我们这里毫无疑问地选择了 Parquet。

执行引擎

Hive的执行引擎包括MapReduce，Spark和Tez。

就性能而言，MapReduce 性能最差， Tez 与 spark 接近，但论社区的活跃程度和技术的成熟度来说 Tez 是不如 Spark 的，因此我们选择 spark。

Spark 目前也有两大分支，即 SparkCore（RDD）和 SparkSQL（DataFrame/DataSet）， 对于这两个分支性能上也有很大差异的。

经过测试，SparkCore 的性能是 MapReduce 的两倍左右，而 SparkSQL 的性能是

SparkCore 的两倍左右，数据量越大，上述的性能差异会越明显，因此 Hive 数据仓库的执行引擎确定为 SparkSQL。

Hbase

框架基础

数据仓库建模基本理论

建模目标

数据仓库建模的目标是通过建模的方法更好的组织、存储数据，以便在性能、成本、效率和数据质量之间找到最佳平衡点。

• 访问性能：能够快速查询所需的数据，减少数据 I/O；
• 数据成本：减少不必要的数据冗余，实现计算结果数据复用，降低大数据系统中的数据成本和计算成本；
• 使用效率：改善用户应用体验，提高使用数据的效率；
• 数据质量：整合所有数据源的数据，改善数据统计口径的不一致性，减少数据计算错误的可能性，提供高质量的、一致的数据访问平台。

上述的四点之间是存在冲突的，为了提高访问性能，可能会提高数据冗余（减少 ）， 计口径不一致的风险，我们的目的是通过合理的设计在性能、成本、效率和数据质量之间找到平衡点。

E-R实体模型（几乎所有的OLTP）

实体，属性，关系

维度建模

将数据仓库中的表划分为事实表和维度表两种类型。

维度建模源自数据集市（数据集市(Data Mart) ，也叫数据市场，数据集市就是满足特定的部门或者用户的需求，按照多维的方式进行存储，包括定义维度、需要计算的指标、维度的层次等，生成面向决策分析需求的数据立方体。），主要面向分析场景。

• 事实表，用来存储事实的度量（measure）及指向各个维的外键值。事实表往往包含三个重要元素（维度表外键，度量数据，事件描述信息）
• 维度表， 用来保存该维的元数据，即维的描述信息，包括维的层次及成员类别等。每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。

建模方法总结

• ER 模型常用于 OLTP 数据库建模，应用到构建数仓时更偏重数据整合，站在企业整体考虑，将各个系统的数据按相似性、一致性合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。
  • ER模型的特点：需要全面梳理企业所有的业务和数据流，实施周期长，对建模人员要求高。
• 维度建模是面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模型。
  • 不需要完整的梳理企业业务流程和数据；
  • 实施周期根据主题边界而定，容易快速实现 demo

三种模式（星型，雪花，星座）

• 星型模式由事实表和维度表组成，一个星型模式中可以有一个或多个事实表，每个

  事实表引用任意数量的维度表。星型模式的物理模型像一颗星星的形状，中心是一个事实表， 围绕在事实表周围的维度表表示星星的放射状分支，这就是星型模式这个名字的由来。

  星型模式将业务流程分为事实和维度。事实包含业务的度量，是定量的数据，如销售价格、销售数量、距离、速度、重量等是事实。维度是对事实数据属性的描述，如日期、产品、客户、地理位置等是维度。一个含有很多维度表的星型模式有时被称为蜈蚣模式，显然这个名字也是因其形状而得来的。蜈蚣模式的维度往往只有很少的几个属性，这样可以简化对维度表的维护，但查询数据时会有更多的表连接，严重时会使模型难于使用，因此在设计中应该尽量避免蜈蚣模式。

• 雪花模式是一种多维模型中表的逻辑布局，其实体关系图有类似于雪花的形状，因此得名。

  与星型模式相同，雪花模式也是由事实表和维度表所组成。所谓的“雪花化”就是将行星模型中的维度表进行规范化处理。当所有的维度表完成规范化后，就形成了以事实表为

  中心的雪花型结构，即雪花模式。将维度表进行规范化的具体做法是，把低基数的属性从维度表中移除并形成单独的表。基数指的是一个字段中不同值的个数，如主键列具有唯一值， 所以有最高的基数，而像性别这样的列基数就很低。

  在雪花模式中，一个维度被规范化成多个关联的表，而在星型模式中，每个维度由一个单一的维度表所表示。一个规范化的维度对应一组具有层次关系的维度表，而事实表作为雪花模式里的字表，存在具有层次关系的多个父表。

• 数据仓库由多个主题构成，包含多个事实表，而维表是公共的，可以共享，这种模式可以看做星型模式的汇集，因而称作星系模式或者事实星座模式。

• 如何选择？

  • 冗余：雪花模型符合业务逻辑设计，采用 3NF 设计，有效降低数据冗余；星型模型的维度表设计不符合 3NF（如果是雪花模型改造成了星型模型，那么肯定不符合3NF，因为一定发生了表的整合，即降维，一定有传递依赖，但是，并不是所有的星型模型都不符合3NF，很多星型模型的表是符合3NF 的），反规范化，维度表之间不会直接相关，牺牲部分存储空间。（雪花模型的维度之间是有关联的）

  • 性能：雪花模型由于存在维度间的关联，采用 3NF 降低冗余，通常在使用过程中，需要连接更多的维度表，导致性能偏低；星型模型反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度表连接数，性能较雪花模型高。（ 星型表的数据冗余大，是用存储空间换取效率 ）（ BI 的一些工具对于星型模型的支持更规范化 ）

  • ETL：雪花模型符合业务 ER 模型设计原则，在 ETL 过程中相对简单，但是由于附属模型的限制，ETL 任务并行化较低（由于雪花模型中有很多的维度依赖，在 ETL 的时候， 需要在保持 3NF 的前提下对数据进行清洗，即对数据一致性/规范化的处理，例如数据来自于多个业务系统，各个系统对于用户的定义不一致，此时要对每个业务定义的用户数据进行规范化处理，在 3NF 的限制下必然会降低并行度）；星型模型在设计维度表时反范式设计，所以在 ETL 过程中整合业务数据到维度表有一定难度，但由于避免附属维度，可并行化处理（不用关注太多的关联关系，避免了维度表之间的关联关系，并行度较高，注意，一般场景下星型模型的并行化程度更高，并不是所有场景）。

  • Hive 的分析通过 MapReduce 实现，每多一个 Join 就会多出一个 MapReduce 过程，对于雪花模型，由于存在着很多维度表之间的关联，这就会导致一次分析对应多个 MapReduce 任务，而星型模型由于不存在维度表的关联，因此一个 MapReduce 就可以实现分析任务。

    MapReduce 本身是一个支持高吞吐量的任务，它的每个任务都要申请资源、分配容器、节点通信等待，需要 YARN 的调度，由于相互关联的维度表本身会很小，join 操作用时很少，

    YARN 调度的时长可能都大于实际运算的时长，因此我们要尽可能减少任务个数，对于 Hive 来说就是尽可能减少不必要的表的关联。还有一点，雪花模型中拆分出的维度表，每个表对应至少一个文件，这就涉及到 I/O 方面的性能损耗。

    因此，我们要采用适当的数据冗余，避免不必要的表之间的关联。

    在实际项目中，不会刻意地去考虑雪花模型，而是刻意地去考虑星型模型，特别是大数据领域的建模，倾斜于使用数据冗余来提高查询效率，倾向于星型模型；雪花模型只会应用在一些我们要求模型的灵活性，要求保证模型本身稳定性的场景下，但是雪花模型并不是首选。

数据仓库分层理论

CIF层次架构

CIF 层次架构（信息工厂）通过分层将不同的建模方案引入到不同的层次中，CIF 将数据仓库分为四层。

• ODS（Operational Data Store）：操作数据存储层，往往是业务数据库表格的一对一映射，将业务数据库中的表格在ODS重新建立，数据完全一致。
• DWD（Data Warehouse Detail）：数据明细层，在 DWD 进行数据的清洗、脱敏、统一化等操作，DWD 层的数据是干净并且具有良好一致性的数据。
• DWS（Data Warehouse Service）：服务数据层（公共汇总层），在 DWS 层进行轻度汇总，为 DM 层中的不同主题提供公用的汇总数据。
• DM（Data Market）：数据集市层，DM 层针对不同的主题进行统计报表的生成。

功能详解

• ODS：ODS 层中的数据全部来自于业务数据库，ODS 层的表格与业务数据库中的表格一一对应，就是将业务数据库中的表格在数据仓库的底层重新建立一次，数据与结构完全一致。

  由于业务数据库（OLTP）基本按照 ER 实体模型建模，因此 ODS 层中的建模方式也是ER 实体模型。

• DWD：DWD 层要做的就是将数据清理、整合、规范化，脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理。DWD 层应该是覆盖所有系统的、完整的、干净的、具有一致性的数据层。

  在 DWD 可能会用到 ER 或者维度模型。在 DWD 层会抽取出公共维度，例如区域等。也就是说 DWD 层是一个非常规范的，高质量的，可信的数据明细层。

• DWS：DWS 层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，会针对度量值进行汇****总，目的是避免重复计算。往往在 DWS 层建立宽表，例如订单总金额，可能在原始数据中没有这个数据，进入 DWS 层后可以统计出订单总金额，避免重复地拿订单明细数据去计算。DWS 层建议使用维度建模，因为数据仓库的主要应用是进行数据分析。

• DM：DM 层为数据集市层，面向特定主题，例如订单主题、物流主题等。在 DM 完成报表或者指标的统计，DM 层已经不包含明细数据，是粗粒度的汇总数据，因此 DM 层会被当成 BI 或者 OLAP 的底层模型。