1.数据仓库
1.1数据仓库的概念
数据仓库(Data Warehouse)是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合,用于支持管理决策。
-
面向主题。操作型数据库的数据组织面向事务处理任务,而数据仓库中的数据按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点,一个主题通常与多个操作型信息系统相关。
-
集成。数据仓库的数据来自分散的操作型数据,将所需数据从原来的数据中抽取出来,进行加工与集成、统一与综合之后才能进入数据仓库。
-
相对稳定。数据仓库一般是不可更新的。数据仓库主要为决策分析提供数据,所涉及的操作主要是数据的查询。
-
反映历史变化。在构建数据仓库时,会每隔一定的时间(比如每周、每天或每小时)从数据源抽取数据并加载到数据仓库。
1.2数据仓库的结构
一个典型的数据仓库系统通常包含数据源、数据存储和管理、OLAP(Online Analytical Processing)服务器、前端工具和应用等4个部分。

1.3数据仓库和数据库之间的区别
特性 | 数据库 | 数据仓库 |
---|---|---|
擅长做什么 | 事务处理 | 分析、报告、大数据 |
数据从哪里来 | 从单个来源"捕获" | 从多个来源抽取和标准化 |
数据标准化 | 高度标准化的静态Schema | 非标准化Schema |
数据如何写 | 针对连续写入操作进行优化 | 按批处理计划进行批量写入操作 |
数据怎么存 | 针对单行型物理块的高吞吐写操作进行了优化 | 使用列式存储进行了优化,便于实现高速查询和低开销访问 |
数据怎么读 | 大量小型读取操作 | 为最小化I/O且最大化吞吐而优化 |
2.数据湖
企业在持续发展,企业的数据也不断堆积,虽然"含金量"最高的数据都存在数据库和数据仓库里,支撑着企业的运转。但是,企业希望把生产经营中的所有相关数据,历史的、实时的,在线的、离线的,内部的、外部的,结构化的、非结构化的,都能完整保存下来,方便"沙中淘金"。数据库和数据仓库都不具备这个功能,怎么办呢?
2.1 数据湖的概念
数据湖是一类存储数据自然、原始格式的系统或存储,通常是对象块或者文件。
数据湖通常是企业中全量数据的单一存储。全量数据包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据,各类任务包括报表、可视化、高级分析和机器学习等。
数据湖的本质,是由"数据存储架构+数据处理工具"组成的解决方案,而不是某个单一独立产品。
数据处理工具则分为两大类。
分类 | 关键信息 | 具体描述 | 工具示例 |
---|---|---|---|
第一类数据处理工具 | 解决数据 "搬到" 湖里的问题 | 定义数据源、制定数据访问和安全策略、移动数据、编制数据目录等,保障数据质量,避免数据湖变成 "数据沼泽" | Amazon Web Services 的 "Lake Formation",搭配 Amazon Glue 进行 ETL、编制数据目录,提高数据质量 |
第二类数据处理工具 | 从海量数据中 "淘金" | 对数据进行分析、挖掘、利用,提供给机器学习、数据科学类业务,进行离线分析、实时分析、交互式分析、机器学习等多种数据分析 | 无(未提及具体工具) |
2.2 数据湖与数据仓库的区别
特性 | 数据仓库 | 数据湖 |
---|---|---|
存放什么数据 | 结构化数据,抽取自事务系统、运营数据库和业务应用系统 | 所有类型的数据,结构化、半结构化和非结构化 |
数据模式(Schema) | 通常在数仓实施之前设计,但也可以在数据分析时编写 | 在分析时编写 |
性价比 | 起步成本高,使用本地存储以获得最快查询结果 | 起步成本低,计算存储分离 |
数据质量如何 | 可作为重要事实依据的数据 | 包含原始数据在内的任何数据 |
最适合谁用 | 业务分析师为主 | 数据科学家、数据开发人员为主 |
具体能做什么 | 批处理报告、BI、可视化分析 | 机器学习、探索性分析、数据发现、流处理、大数据与特征分析 |
2.3数据湖能解决的企业问题
在企业实际应用中,数据湖能解决的问题包括以下几个方面:
- 数据分散,存储散乱,形成数据孤岛,无法联合数据发现更多价值。
- 存储成本问题。
- SQL无法满足的分析需求。
- 存储、计算扩展性不足。
- 业务模型不定,无法预先建模
3.湖仓一体
因为数仓和数据库的出发点不同、架构不同,企业在实际使用过程中,"性价比"差异很大。

湖仓一体是一种新型的开放式架构,打通了数据仓库和数据湖,将数据仓库的高性能及管理能力与数据湖的灵活性融合了起来,底层支持多种数据类型并存,能实现数据间的相互共享,上层可以通过统一封装的接口进行访问,可同时支持实时查询和分析,为企业进行数据治理带来了更多的便利性。
"湖仓一体"架构最重要的一点,是实现"湖里"和"仓里"的数据/元数据能够无缝打通,并且"自由"流动。湖里的"新鲜"数据可以流到仓里,甚至可以直接被数据仓库使用,而仓里的"不新鲜"数据,也可以流到湖里,低成本长久保存,供未来的数据挖掘使用。
"湖仓一体"架构具有以下特性:
特性 | 描述 |
---|---|
事务支持 | 为业务系统提供并发的读取和写入,对事务的 ACID 支持,确保数据并发访问的一致性、正确性(在 SQL 访问模式下) |
数据治理 | 支持各类数据模型的实现和转变,如星型模型、雪花模型等,保证数据完整性,具备健全的治理和审计机制 |
BI 支持 | 支持直接在源数据上使用 BI 工具,加快分析效率,降低数据延时,相比在数据湖和数据仓库分别操作两个副本更具成本优势 |
存算分离 | 使系统能够扩展到更大规模的并发能力和数据容量 |
开放性 | 采用开放、标准化的存储格式(如 Parquet 等),提供丰富的 API 支持,可让各种工具和引擎(包括机器学习和 Python、R 等)高效地直接访问数据 |
4.Hive概述
4.1 传统数据仓库面临的挑战
随着大数据时代的全面到来,传统数据仓库面临着巨大的挑战,主要包括以下几个方面。
-
**无法满足快速增长的海量数据存储需求。**目前企业数据增长速度非常快,动辄几十TB的数据,已经大大超出了Oracle/DB2等传统数据仓库的处理能力。这是因为传统数据仓库大都基于关系数据库,关系数据库横向扩展性较差,纵向扩展性有限。
-
**无法有效处理不同类型的数据。**传统数据仓库通常只能存储和处理结构化数据,但是,随着企业业务的发展,企业中部署的系统越来越多,数据源的数据格式越来越丰富,很显然,传统数据仓库无法处理如此众多的数据类型。
-
**计算和处理能力不足。**由于传统数据仓库建立在关系数据库基础之上,因此,会存在一个很大的痛点,即计算和处理能力不足,当数据量达到TB量级后,传统数据仓库基本无法获得好的性能。
4.2 Hive简介
Hive是一个构建于Hadoop顶层的数据仓库工具
-
某种程度上可以看作是用户编程接口,本身不存储和处理数据
-
依赖分布式文件系统HDFS存储数据
-
依赖分布式并行计算模型MapReduce处理数据
-
定义了简单的类SQL 查询语言------HiveQL
-
用户可以通过编写的HiveQL语句运行MapReduce任务
-
是一个可以提供有效、合理、直观组织和使用数据的模型
Hive具有的特点非常适用于数据仓库:
特点 | 功能 |
---|---|
采用批处理方式处理海量数据 | Hive需要把HiveQL语句转换成MapReduce任务进行运行;数据仓库存储的是静态数据,对静态数据的分析适合采用批处理方式,不需要快速响应给出结果,而且数据本身也不会频繁变化。 |
提供适合数据仓库操作的工具 | Hive本身提供了一系列对数据进行提取转化加载的工具,可以存储、查询和分析存储在Hadoop中的大规模数据;非常适合数据仓库应用程序维护海量数据、对数据进行挖掘、形成意见和报告等。 |
4.3 Hive与Hadoop生态系统中其他组件的关系

工具 | 依赖关系或特点 | 具体描述 |
---|---|---|
Hive | 依赖于 HDFS 存储数据 | HDFS 是高可靠性的底层存储,用于存储海量数据 |
Hive | 依赖于 MapReduce 处理数据 | MapReduce 对海量数据进行处理,实现高性能计算,HiveQL 语句编写的处理逻辑会转化为 MapReduce 任务运行 |
Pig | 作为 Hive 的替代工具 | 是一种数据流语言和运行环境,适合在 Hadoop 和 MapReduce 平台上查询半结构化数据集,常用于 ETL 过程,将外部数据装载到 Hadoop 集群并转换为期望的数据格式 |
HBase | 提供数据的实时访问 | 一个面向列的、分布式的、可伸缩的数据库,功能与 Hive 互补,Hive 主要处理静态数据(如 BI 报表数据) |
4.4 Hive与传统数据库的对比分析
Hive在很多方面和传统的关系数据库类似,但是它的底层依赖的是HDFS和MapReduce,所以在很多方面又有别于传统数据库。
对比项目 | Hive | 传统数据库 |
---|---|---|
数据插入 | 支持批量导入 | 支持单条和批量导入 |
数据更新 | 不支持 | 支持 |
索引 | 支持 | 支持 |
分区 | 支持 | 支持 |
执行延迟 | 高 | 低 |
扩展性 | 好 | 有限 |
5.Hive系统架构
Hive主要由以下3个模块组成,用户接口模块、驱动模块以及元数据存储模块:

模块 | 详情 |
---|---|
用户接口模块 | 包括 CLI、Hive 网页接口(Hive Web Interface,HWI)、JDBC、ODBC、Thrift Server 等,用于实现外部应用对 Hive 的访问。 CLI 是 Hive 自带命令行客户端工具,Hive 3.0 以上版本中 Beeline 取代了 CLI。 HWI 是 Hive 的简单网页。 JDBC、ODBC 和 Thrift Server 提供编程访问接口,Thrift Server 基于 Thrift 软件框架开发,提供 Hive 的 RPC 通信接口。 |
驱动模块(Driver) | 包括编译器、优化器、执行器等,执行引擎可以是 MapReduce、Tez 或 Spark 等。 当采用 MapReduce 作为执行引擎时,负责把 HiveQL 语句转换成一系列 MapReduce 作业,对输入进行解析编译、优化计算过程并按步骤执行。 |
元数据存储模块(Metastore) | 是一个独立的关系数据库,通常与 MySQL 数据库连接创建 MySQL 实例,也可是 Hive 自带的 derby 数据库实例。 主要保存表模式和其他系统元数据,如表的名称、表的列及其属性、表的分区及其属性、表的属性、表中数据所在位置信息等。 |
6.Hive工作原理
6.1 SQL语句转换成MapReduce作业的基本原理
1.用MapReduce实现连接操作

Map阶段
在Map阶段,表 user
中记录 (uid, name)
映射为键值对 (uid, <1, name>)
,表 order
中记录 (uid, orderid)
映射为键值对 (uid, <2, orderid >)
,其中 1,2 是表 user
和 order
的标记位。
例如:
(1, Lily)
映射为(1, <1, Lily>)
(1, 101)
映射为(1, <2, 101>)
Shuffle、Sort阶段
在Shuffle、Sort阶段,(uid, <1, name>)
和 (uid, <2, orderid >)
按键 uid
的值进行哈希,然后传送给对应的Reduce机器执行,并在该机器上按表的标记位对这些键值对进行排序。
例如:
(1, <1, Lily>)
、(1, <2, 101>)
和(1, <2, 102>)
传送到同一台Reduce机器上,并按该顺序排序(2, <1, Tom>)
和(2, <2, 103>)
传送到同一台Reduce机器上,并按该顺序排序
Reduce阶段
在Reduce阶段,对同一台Reduce机器上的键值对,根据表标记位对来自不同表的数据进行笛卡尔积连接操作,以生成最终的连接结果。
例如:
(1, <1, Lily>)
∞(1, <2, 101>)
得到(Lily, 101)
(1, <1, Lily>)
∞(1, <2, 102>)
得到(Lily, 102)
(2, <1, Tom>)
∞(2, <2, 103>)
得到(Tom, 103)
2.用MapReduce实现分组操作

Map阶段
在Map阶段,表 score
中记录 (rank, level)
映射为键值对 (<rank, level>, count(rank, level))
。
-
对于
score
表的第一片段,有两条记录(A, 1)
,映射后为(<A, 1>, 2)
。 -
对于
score
表的第二片段,有一条记录(A, 1)
,映射后为(<A, 1>, 1)
。
Shuffle、Sort阶段
在Shuffle、Sort阶段,键值对 (<rank, level>, count(rank, level))
按键 (<rank, level>)
的值进行哈希,然后传送给对应的Reduce机器执行,并在该机器上按 (<rank, level>)
的值对这些键值对进行排序。
(<A, 1>, 2)
和(<A, 1>, 1)
传送到同一台Reduce机器上,按到达顺序排序。(<B, 2>, 1)
传送到另一台Reduce机器上。
Reduce阶段
在Reduce阶段,对Reduce机器上的这些键值对,把具有相同 (<rank, level>)
键的所有 count(rank, level)
值进行累加,生成最终结果。
(<A, 1>, 2)
和(<A, 1>, 1)
累加后得到(A, 1, 3)
。(<B, 2>, 1)
最终结果为(B, 2, 1)
。
9.6.2 SQL查询转换成MapReduce作业的过程
当用户向Hive输入一段命令或查询时,Hive需要与Hadoop交互工作来完成该操作。
首先,驱动模块接收该命令或查询编译器。
接着,对该命令或查询进行解析编译。
然后,由优化器对该命令或查询进行优化计算。最后该命令或查询通过执行器进行执行。
执行器通常的任务是启动一个或多个MapReduce任务,有时也不需要启动MapReduce任务,像执行包含*的操作(如select * from 表)时。

7.Hive HA工作原理
在Hive HA中,在Hadoop集群上构建的数据仓库是由多个Hive实例进行管理的,这些Hive实例被纳入一个资源池中,并由HAProxy提供一个统一的对外接口。客户端的查询请求首先访问HAProxy,由HAProxy对访问请求进行转发。HAProxy收到请求后,会轮询资源池里可用的Hive实例,执行逻辑可用性测试。

8.Impala
8.1 Impala简介
Impala是由Cloudera公司开发的新型查询系统,它提供SQL语义,能查询存储在Hadoop的HDFS和HBase上的PB级大数据。Impala最开始是参照 Dremel系统进行设计的,Impala的目的不在于替换现有的MapReduce工具,而是提供一个统一的平台用于实时查询。
Impala与其他组件的关系:

比较项 | Hive | Impala |
---|---|---|
数据交互 | 可与 HDFS 和 HBase 交互 | 可与 HDFS 和 HBase 交互 |
执行引擎与任务类型 | 采用 MapReduce 作为执行引擎,主要用于处理长时间运行的批处理任务,如批量提取、转化、加载类型的任务 | 通过类似商用并行关系数据库的分布式查询引擎,大大降低延迟,主要用于实时查询 |
SQL 语法等 | 和 Impala 采用相同的 SQL 语法、ODBC 驱动程序和用户接口 | 和 Hive 采用相同的 SQL 语法、ODBC 驱动程序和用户接口 |
8.2 Impala系统架构
组成部分 | 描述 | 具体模块及特点 |
---|---|---|
Impalad | 是 Impala 的进程,负责协调客户端提交查询的执行、给其他 Impalad 分配任务、汇总其他 Impalad 的执行结果,还能执行其他 Impalad 分配的任务,对本地 HDFS 和 HBase 里的部分数据进行操作 | 包含 Query Planner、Query Coordinator 和 Query Exec Engine 3 个模块;与 HDFS 的数据节点(HDFS DN)运行在同一节点上,基于 MPP 架构完全分布式运行 |
State Store | 负责收集集群中各个 Impalad 进程的资源信息用于查询调度,跟踪 Impalad 的健康状态及位置信息 | 创建 statestored 进程,通过多个线程处理 Impalad 的注册订阅并保持心跳连接;各 Impalad 缓存 State Store 信息,State Store 离线时 Impalad 进入恢复模式并反复注册,State Store 重新加入集群后自动恢复正常并更新缓存数据 |
CLI | 给用户提供执行查询的命令行工具 | 同时提供 Hue、JDBC 及 ODBC 使用接口 |

8.3 Impala查询执行过程
步骤 | 具体内容 | 详细描述 |
---|---|---|
第 1 步:注册和订阅 | Impalad 进程向 State Store 提交注册订阅信息,State Store 的 statestored 进程处理注册订阅 | 当用户提交查询前,创建 Impalad 进程负责协调客户端查询;State Store 创建 statestored 进程,通过多个线程处理 Impalad 的注册订阅信息 |
第 2 步:提交查询 | Impalad 的 Query Planner 解析 SQL 语句生成解析树,再变成 PlanFragment 发送到 Query Coordinator | 用户通过 CLI 客户端提交查询到 Impalad 进程;Query Planner 进行解析工作,PlanFragment 由 PlanNode 组成,可分发到单独节点执行,每个 PlanNode 表示一个关系操作及执行优化所需信息 |
第 3 步:获取元数据与数据地址 | Query Coordinator 从 MySQL 元数据库获取元数据,从 HDFS 名称节点获取数据地址,得到相关数据所在的数据节点 | Query Coordinator 分别从不同位置获取元数据和数据地址信息,确定存储查询相关数据的所有数据节点 |
第 4 步:分发查询任务 | Query Coordinator 初始化相应 Impalad 上的任务,将查询任务分配给存储查询相关数据的数据节点 | Query Coordinator 针对存储有查询相关数据的各个数据节点,在对应的 Impalad 上初始化并分配查询任务 |
第 5 步:汇聚结果 | Query Executor 通过流式交换中间输出,Query Coordinator 汇聚来自各个 Impalad 的结果 | Query Executor 以流式方式处理中间输出数据,Query Coordinator 将各个 Impalad 产生的结果进行汇总 |
第 6 步:返回结果 | Query Coordinator 把汇总后的结果返回给 CLI 客户端 | Query Coordinator 将最终汇总的结果反馈给最初提交查询的 CLI 客户端 |

8.4 Impala与Hive的比较
1.Hive 与 Impala 的不同点
比较维度 | Hive | Impala |
---|---|---|
查询特点 | 架构基于 Hadoop,采用批处理方式,作业提交和调度开销大,不适合大规模数据集的低延迟快速查询,适合长时间批处理查询分析 | 适合实时交互式 SQL 查询 |
执行模式 | 以 MapReduce 为执行引擎,依赖 MapReduce 计算框架,执行计划是管道型的 MapReduce 任务模式 | 执行计划呈现为完整的执行计划树,能自然地将执行计划分发到各个 Impalad 执行查询 |
数据处理能力 | 执行时若内存无法容纳所有数据,会借助外存确保查询按顺序执行完成 | 内存无法容纳数据时不使用外存,更适合处理输出数据量较小的查询请求,对于大数据量的批量处理,Hive 更具优势 |
2.Hive 与 Impala 的相同点
比较维度 | 详情 |
---|---|
数据存储 | 使用相同的存储数据池,均支持将数据存储于 HDFS(支持 TEXT、RCFILE、PARQUET、AVRO、ETC 等格式的数据)和 HBase(存储表中记录) |
元数据 | 使用相同的元数据 |
SQL 处理 | 对 SQL 的解释处理方式相似,都通过词法分析生成执行计划 |