点一下关注吧！！！非常感谢！！持续更新！！！

目前已经更新到了：

• Hadoop（已更完）
• HDFS（已更完）
• MapReduce（已更完）
• Hive（已更完）
• Flume（已更完）
• Sqoop（已更完）
• Zookeeper（已更完）
• HBase（已更完）
• Redis （已更完）
• Kafka（已更完）
• Spark（已更完）
• Flink（已更完）
• ClickHouse（已更完）
• Kudu（已更完）
• Druid（已更完）
• Kylin（已更完）
• Elasticsearch（已更完）
• DataX（已更完）
• Tez（已更完）
• 数据挖掘（已更完）
• Prometheus（已更完）
• Grafana（已更完）
• 离线数仓（正在更新…）

章节内容

上节我们完成了如下的内容：

• 基本概念 数仓特征
• 数据库进行对比

数据集市

数据仓库（DW）是一种反映主题的全局性数据组织，但全局性数据仓库往往太大，在实际应用中他们按部门或业务分别建立反映各个子主题的局部性数据组织，即数据集市（Data Mart），有时也称它为数据仓库。
数据集市：是按照主题域组织的数据集合，用于支持部门级的数据分析与决策。如在商品销售的数据仓库中可以建立多个不同主题的数据集市：

• 商品采购数据集市
• 商品库存数据集市
• 商品销售数据集市

数据集市仅仅是数据仓库的某一部分，实施难度大大降低，并且能够满足企业内部部分业务部分的迫切需求，在初期获得了较大的成功。但随着数据集市的不断增多，这种架构的缺陷也逐步显现。企业内部独立建设的数据集市由于遵循不同的标准和建设原则，以至于多个数据集市的数据混乱和不一致，形成众多的数据孤岛。

业务发展到一定阶段，出现多个事业部门。每个事业部门都有各自的数据，事业部之间的数据往往都是各自存储的，各自定义的。每个事业部的数据就像一个个孤岛一样无法（或者极其困难）和企业内部的其他数据进行连接互动，这样的情况被称为数据孤岛，简单来说就是数据间缺乏关联性，彼此无法兼容。

建模方法

数据模型就是数据组织和存储方法，它强调业务、数据存取和使用角度合理存储数据。有了适合的基础数据存储环境的模型，能获得以下好处：

• 性能：良好的数据模型能够帮助我们快速查询所需要的数据，减少数据的I/O吞吐
• 成本：良好的数据模型能极大的减少不必要的数据冗余，也能实现计算结果复用，极大的降低数据系统中的存储和计算成本。
• 效率：良好的数据模型能极大的改善使用使用数据的体验，提高使用数据的效率
• 质量：良好的数据模型能够改善数据统计口径不一致性，减少数据计算错误的可能性。

大数据系统需要数据模型的方法来帮助更好的组织和存储数据，以便在性能、成本、效率和质量之间取得最佳的平衡。

ER模型

数据仓库之父Bill Inmon提出的建模方法是从全企业的高度设计一个3NF模型，用实体关系（Entity RelationShip，ER）模型描述企业业务，在范式理论上符合3NF。数据仓库中的3NF与OLTP系统中的3NF的区别在于，它是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象的抽象。其具体有以下几个特点：

• 需要全面的了解整个企业业务和数据
• 实施周期非常的长
• 对建模人员的能力要求非常高

采用ER模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策，其建模步骤分为三个阶段：

• 高层模型：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况
• 中层模型：在高层模型的基础上，细化主题的数据项
• 物理模型（也叫底层模型）：在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等等

维度模型

维度模型是数据仓库领域的Palph Kimball 大师所倡导的，他的《数据仓库工具箱》是数据仓库工程领域最流行的数据仓库建模经典。
维度模型从分析决策的需求出发构建模型，为分析需求服务，重点关注用户如何更快的完成需求分析，同时具有较好的大规模复杂查询的响应性能。其典型的代表是星型模型，以及在一些特殊场景下的雪花模型。
其设计主要分为以下步骤：

• 选择需要进行分析决策的业务过程，业务过程可以是：单个业务事件，比如交易的支付、退款的。某个事件的状态，比如当前的账户余额等。一系列相关业务事件组成的业务流程。
• 选择数据的粒度，在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。
• 识别维表，选择好粒度之后，就需要基于此粒度设计维度表，包括维度属性，用于分析时进行分组和筛选。
• 选择事实，确定分析需要衡量的指标

现代企业业务变化快、人员流动频繁、业务知识功底不够全面，导致ER模型设计产出周期长。大多企业实施数据仓库的经验说明：在不太成熟、快速变化的业务面前，构建ER模型的风险非常大，不太适合去构建ER模型。而维度建模对技术要求不高，快速上手，敏捷迭代，快速交付，更快速完成分析需求，有较好的大规模复杂查询的响应性能。

数仓分层

数据仓库更多代表的是一种对数据的管理和使用的方式，它是一整套包括了数据建模、ETL（数据抽取、转换、加载）、作业调度等在内的完整的理论体系流程。数据仓库在构建过程中通常需要进行分层处理。业务不同，分层的技术处理手段也不同。
分层的主要原因是在管理数据的时候，能对数据有一个更加清晰的掌控。详细来讲，主要有下面几个原因：

• 清晰的数据结构：每一个数据分层都有它的作用域，在使用表的时候能更方便的定位和理解。
• 将复杂的问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的问题，比较简单和容易理解，而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的地方开始修复。
• 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够极大减少重复计算
• 屏蔽原始数据的异常：屏蔽业务的影响，不必改一次业务就重新接入数据
• 数据血缘的追踪：最终给业务呈现的是一个能直接使用业务表，但是它的来源很多，如果有一张来源表出问题了，借助血缘最终能够快速准确的定位到问题，并清楚它的危害范围。

数仓的常见分层一般为3层，分别为：

• 数据操作层
• 数据仓库层
• 应用数据层（数据集市层）。

当然根据研究人员经验或者业务，可以分为更多不同的层，只要能达到流程清晰，方便查数即可。

ODS

ODS（Operation Data Store 数据准备区），数据仓库源头系统的数据表通常会原封不同的存储一份，这称为ODS层，也称为准备区。它们是后续数据仓库加工数据的来源。ODS层数据的主要来源包括：

• 业务数据库，可用DataX、Sqoop等工具来抽取，每天定时抽取一次，在实时的应用中，可用Canal监听MySQL Binlog，实时接入变更的数据。
• 埋点日志，线上系统会打入各种日志，这些日志一般以文件的形式保存，可以用Flume定时抽取
• 其他数据源，从第三方购买的数据，或是网络爬虫的数据

DW

DW（Data WareHouse 数据仓库层），包含DWD、DWS、DIM层，由ODS层数据加工而成，主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。

• DWD（Data WareHouse Detail 细节数据层），是业务与数据仓库的隔离层，以业务过程为建模驱动，基于每个具体的业务过程特点，构建细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当地冗余，也即宽表化处理。
• DWS（Data WareHouse Service 服务数据层），基于DWD的基础数据，整合汇总成分析某个主题域的服务数据。以分析的主题为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表。
• 公共维度层（DIM）：基于维度建模理念思想，建立一致性维度
• TMP层：临时层，存放计算过程中临时产生的数据

ADS

ADS（Application Data Store）应用数据层，基于DW数据，整合汇总成主题域的服务数据，用于提供后续的业务查询等。

简单总结

数据仓库层次的划分不是固定不变的，可以根据实际需求进行适当裁剪或者是添加，如果业务相对简单和独立，可以将DWD、DWS进行合并。