一、Hive产生背景
直接使用MapReduce处理大数据，将面临以下问题：
- MapReduce 开发难度大，学习成本高(wordCount => Hello World)
- Hdfs文件没有字段名、没有数据类型，不方便进行数据的有效管理
- 使用MapReduce框架开发，项目周期长，成本高
Hive是基于Hadoop的一个数据仓库工具，可以将 结构化的数据文件 映射为一张表(类似于RDBMS中的表)，并提供类SQL查询功能；Hive是由Facebook开源，用于解决海量结构化日志的数据统计。
- Hive本质是：将 SQL 转换为 MapReduce 的任务进行运算
- 底层由HDFS来提供数据存储
- 可以将Hive理解为一个：将 SQL 转换为 MapReduce 任务的工具
数据仓库(Data Warehouse)是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，主要用于管理决策。(数据仓库之父比尔·恩门，1991年提出)。
- 数据仓库的目的：构建面向分析的、集成的数据集合；为企业提供决策支持
- 数据仓库本身不产生数据，数据来源与外部
- 存储了大量数据，对这些数据的分析和处理不可避免的用到Hive
二、Hive和RDBMS对比
由于 Hive 采用了类似SQL 的查询语言 HQL(Hive Query Language)，因此很容易将Hive 理解为数据库。其实从结构上来看，Hive 和传统的关系数据库除了拥有类似的查询语言，再无类似之处。
查询语言相似。HQL <=> SQL 高度相似
由于SQL被广泛的应用在数据仓库中，因此，专门针对Hive的特性设计了类SQL的查询语言HQL。熟悉SQL开发的开发者可以很方便的使用Hive进行开发。
数据规模。Hive存储海量数据；RDBMS只能处理有限的数据集；
由于Hive建立在集群上并可以利用MapReduce进行并行计算，因此可以支持很大规模的数据；而RDBMS可以支持的数据规模较小。
执行引擎。Hive的引擎是MR/Tez/Spark/Flink；RDBMS使用自己的执行引擎Hive中大多数查询的执行是通过 Hadoop 提供的 MapReduce 来实现的。而RDBMS通常有自己的执行引擎。
数据存储。Hive保存在HDFS上；RDBMS保存在本地文件系统 或 裸设备Hive 的数据都是存储在 HDFS 中的。而RDBMS是将数据保存在本地文件系统或裸设备中。
执行速度。Hive相对慢（MR/数据量）；RDBMS相对快；
Hive存储的数据量大，在查询数据的时候，通常没有索引，需要扫描整个表；加之Hive使用MapReduce作为执行引擎，这些因素都会导致较高的延迟。而RDBMS对数据的访问通常是基于索引的，执行延迟较低。当然这个低是有条件的，即数据规模较小，当数据规模大到超过数据库的处理能力的时候，Hive的并行计算显然能体现出并行的优势。
可扩展性。Hive支持水平扩展；通常RDBMS支持垂直扩展，对水平扩展不友好
Hive建立在Hadoop之上，其可扩展性与Hadoop的可扩展性是一致的（Hadoop集群规模可以轻松超过1000个节点）。而RDBMS由于 ACID 语义的严格限制，扩展行非常有限。目前最先进的并行数据库 Oracle 在理论上的扩展能力也只有100台左右。
数据更新。Hive对数据更新不友好；RDBMS支持频繁、快速数据更新Hive是针对数据仓库应用设计的，数据仓库的内容是读多写少的。因此，Hive中不建议对数据的改写，所有的数据都是在加载的时候确定好的。而RDBMS中的数据需要频繁、快速的
进行更新。
三、HIVE的优缺点
3.1优点
学习成本低。Hive提供了类似SQL的查询语言，开发人员能快速上手；
处理海量数据。底层执行的时MapReduce任务；
系统课水平扩展。底层基于Hadoop;
功能可以扩展。Hive允许用户自定义函数；
良好的容错性。某个节点发生故障，HQL仍然可以正常完成；
统一的元数据。元数据包括：有哪些表、表有什么字段、字段是什么类型；
3.2缺点
HQL表达能力有限；
迭代计算无法表达；
Hive的执行效率不高（基于MR的执行引擎）；
Hive自动生成的MapReduce作业，某些情况下不够智能；
Hive的调优困难；
四、Hive架构
2-1-1 Hive概述
原文：https://www.cnblogs.com/lizhao01/p/14493384.html
