Hive概述
1.1 数据仓库概述
数据仓库之父比尔·恩门，1991年提出
数据仓库就是为了解决数据库不能解决的问题而提出的。那么数据库无法解决什么样的问题呢？这个我们得先说说什么是OLAP和OLTP。(重点)
1.2 OLTP和OLAP（重点）
1.2.1 OLTP
OLTP（OnLine Transaction Processing 联机事务处理） 。简单一些，就是数据库的增删查改。举个例子，你到银行，去取一笔钱出来，或者转账，或者只是想查一下你还有多少存款，这些都是面向“事务”类型的操作。这样的操作有几个显著的特点:
首先要求速度很快， 基本上都是高可靠的在线操作（比如银行）， 还有这些操作涉及的数据内容不会特别大（否则速度也就相应的降低）， 最后，“事务”型的操作往往都要求是精准操作，比如你去银行取款，必须要求一个具体的数字，你是不可能对着柜台员工说我大概想取400到500快之间吧，那样人家会一脸懵逼。
1.2.2 OLAP
这个东西又是上面发明关系型数据库的科德发明的。OLAP略有复杂，但这里我举一个简单的例子，大家就很容易理解了。
比如说，沃尔玛超市的数据库里有很多张表格，记录着各个商品的交易记录。超市里销售一种运动饮料，我们不妨称之为红牛。数据库中有一张表A，记录了红牛在一年的各个月份的销售额；还有一张表B，记录了红牛每个月在美国各个州的销售额：；甚至还有一张表C，记录了这家饮料公司在每个州对红牛饮料的宣传资金投入；甚至后来沃尔玛又从国家气象局拿到了美国各个州的一年365天每天的天气表D。好，最后问题来了，请根据以上数据分析红牛在宣传资金不超过三百万的情况下，什么季节，什么天气，美国哪个州最好卖？凭借我们的经验，可能会得出，夏季的晴天，在美国的佛罗里达，最好卖，而且宣传资金投入越高销售额应该也会高。可能这样的结论是正确的，但决策者想要看到的是确凿的数据结论，而不是“可能”这样的字眼。
科学是不相信直觉的，如果我们人工进行手动分析，会发现这个要考虑的维度实在太多了，根本无法下手，何况这才四五个维度，要是更多了怎么办？OLAP就是为了解决这样的问题诞生的，但糟糕的是，传统数据库是无法满足OLAP所需要的数据信息的。
1.3 数据仓库概念
1.3.1 概述
数据库的大规模应用，使得信息行业的数据爆炸式的增长，为了研究数据之间的关系，挖掘数据隐藏的价值，人们越来越多的需要使用OLAP来为决策者进行分析，探究一些深层次的关系和信息。但很显然，不同的数据库之间根本做不到数据共享，就算同一家数据库公司，数据库之间的集成也存在非常大的挑战（最主要的问题是庞大的数据如何有效合并、存储）。
1988年，为解决企业的数据集成问题，IBM的两位研究员（Barry Devlin和Paul Murphy）创造性地提出了一个新的术语：数据仓库（Data Warehouse）。看到这里读者朋友们可能要问了，然后呢？然后…然后就没然后了。就在这个创世纪的术语诞生了之后，IBM就哑火了，只是将这个名词作为市场宣传的花哨概念，并没有在技术领域有什么实质性的研究和突破。
然而，尽管IBM不为所动，其他企业却在加紧对数据仓库的研究和开发，大家都想在这个领域寻找到第一桶金。终于，到了1992年，后来被誉为“数据仓库之父”的比尔 恩门（Bill Inmon）给出了数据仓库的定义，二十多年后的今天他的定义依然没有被时代淘汰。我们来看看他是怎么定义的：数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理中的决策制定。
对于数据仓库的概念我们可以从两个层次予以理解：
首先,数据仓库用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库; 其次,数据仓库是对多个异构的数据源有效集成,集成后按照主题进行了重组,并包含历史数据,而且存放在数据仓库中的数据一般不再修改。
我们可以不用管这个定义，简单的理解，其实就是我们为了进行OLAP，把分布在各个散落独立的数据库孤岛整合在了一个数据结构里面，称之为数据仓库。
这个数据仓库在技术上是怎么建立的读者朋友们并不需要关心，但是我们要知道，原来各个数据孤岛中的数据，可能会在物理位置（比如沃尔玛在各个州可能都有自己的数据中心）、存储格式（比如月份是数值类型，但但天气可能是字符类型）、商业平台（不同数据库可能用的是Oracle数据库，有的是微软SQL Server数据库）、编写的语言（Java或者Scale等）等等各个方面完全不同，数据仓库要做的工作就是将他们按照所需要的格式提取出来，再进行必要的转换（统一数据格式）、清洗（去掉无效或者不需要的数据）等，最后装载进数据仓库（我们所说的ETL工具就是用来干这个的）。这样，拿我们上面红牛的例子来说，所有的信息就统一放在了数据仓库中了。
自从数据仓库出现之后，信息产业就开始从以关系型数据库为基础的运营式系统慢慢向决策支持系统发展。这个决策支持系统，其实就是我们现在说的商务智能（Business Intelligence）即BI。
可以这么说，数据仓库为OLAP解决了数据来源问题，数据仓库和OLAP互相促进发展，进一步驱动了商务智能的成熟，但真正将商务智能赋予“智能”的，正是我们现在热谈的下一代技术：数据挖掘。
1.3.2 数据仓库特点(重点)
面向主题
面向主题特性是数据仓库和操作型数据库的根本区别。
操作型数据库是为了支撑各种业务而建立。
而分析型数据库则是为了对从各种繁杂业务中抽象出来的分析主题(如用户、成本、商品等)进行分析而建立；所谓主题：是指用户使用数据仓库进行决策时所关心的重点方面，如：收入、客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不是像业务支撑系统那样是按照业务功能进行组织的。
集成性
集成性是指数据仓库会将不同源数据库中的数据汇总到一起；
具体来说，是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。
企业范围
数据仓库内的数据是面向公司全局的。比如某个主题域为成本，则全公司和成本有关的信息都会被汇集进来；
历史性
较之操作型数据库，数据仓库的时间跨度通常比较长。前者通常保存几个月，后者可能几年甚至几十年；
时变性
时变性是指数据仓库包含来自其时间范围不同时间段的数据快照。有了这些数据快照以后，用户便可将其汇总，生成各历史阶段的数据分析报告；
数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。
2.4 数据仓库的趋势
-
实时数据仓库以满足实时化&自动化决策需求；
-
大数据&数据湖以支持大量&复杂数据类型（文本、图像、视频、音频）；
2.5 数据仓库的发展
数据仓库有两个环节：数据仓库的构建与数据仓库的应用。
早期数据仓库构建主要指的是把企业的业务数据库如ERP、CRM、SCM等数据按照决策分析的要求建模并汇总到数据仓库引擎中，其应用以报表为主，目的是支持管理层和业务人员决策（中长期策略型决策）。
随着业务和环境的发展，这两方面都在发生着剧烈变化。
随着IT技术走向互联网、移动化，数据源变得越来越丰富，在原来业务数据库的基础上出现了非结构化数据，比如网站log，IoT设备数据，APP埋点数据等，这些数据量比以往结构化的数据大了几个量级，对ETL过程、存储都提出了更高的要求；
互联网的在线特性也将业务需求推向了实时化，随时根据当前客户行为而调整策略变得越来越常见，比如大促过程中库存管理，运营管理等（即既有中远期策略型，也有短期操作型）；同时公司业务互联网化之后导致同时服务的客户剧增，有些情况人工难以完全处理，这就需要机器自动决策。比如欺诈检测和用户审核。
总结来看，对数据仓库的需求可以抽象成两方面：实时产生结果、处理和保存大量异构数据。
1.6 数据仓库建设方法论
1）面向主题
从公司业务出发，是分析的宏观领域，比如供应商主题、商品主题、客户主题和仓库主题
2）为多维数据分析服务
数据报表；数据立方体，上卷、下钻、切片、旋转等分析功能。
3）反范式数据模型
以事实表和维度表组成的星型数据模型
数据仓库层的划分：
二、Hive学习
2.1 什么是hive?（面试题）
1:hive是基于hadoop的数据仓库建模工具之一（后面还有TEZ，Spark）。
2:hive可以使用类sql方言，对存储在hdfs上的数据进行分析和管理。传入一条交互式sql在海量数据中查询分析结果的工具。
2.2 对于hive的理解
1、Hive是基于Hadoop的一个数据仓库工具，可以将 结构化的数据文件 映射为一张表(类似于RDBMS中的表)，并提供类SQL查询功能；Hive是由Facebook开源，用于解决海量结构化日志的数据统计。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL ），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言，称为 HQL ，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。
2、Hive是SQL解析引擎，它将SQL语句转译成M/R Job然后在Hadoop的yarn上的执行。
3、Hive的表其实就是HDFS的目录，按表名把文件夹分开。如果是分区表，则分区值是子文件夹，可以直接在M/R Job里使用这些数据。
4、Hive相当于hadoop的客户端工具，部署时不一定放在集群管理节点中，可以放在某个节点上。
可以将Hive理解为一个：将 SQL 转换为 MapReduce 任务的工具
所以Hive不存储数据，自己也没有任何计算功能，只是相当于类SQL语句与Hadoop文件之间的一个解释器。他本质上只是一个对HDFS上的文件进行索引与计算的工具。他需要依赖Hadoop的Yarn来进行资源分配，也需要Hadoop的MapReduce来提供计算支持。后面我们就会知道，hive在进行数据计算时，不仅可以用MapReduce来支持，也可以集合其他更灵活，更高效的大数据计算框架（比如spark Spark SQL）
2.3 Hive的使用场景
从上面的理解介绍可以简单掌握Hive的特点：
优点：
1、使用SQL语法查询，不用再去写复杂的MapReduce程序，减少开发成版本，上手快。
2、基于MapReduce算法，所以在处理大数据时，优势非常明显
3、可以支持自定义函数，计算能力强
缺点：
1、Hive的执行延迟比较高，这是因为启动并运行一个MapReduce程序本身需要消耗非常多的资源
2、Hive的HQL语句表达能力有限，并且他是基于模板实现的，所以通常不够智能化，很多复杂的大数据计算无法支持，比如迭代式计算
3、Hive处理大数据量非常擅长，但是处理小数据量就没有优势了。
针对与优点和缺点总结：
所以，Hive通常适用于大数据的OLAP场景，做一些面向分析，允许有延迟的数据挖掘工作，并且结合其他组件也可以做一些数据清洗之类的简单数据处理工作。Hive是针对数据仓库来进行设计的，这种场景下，通常是读多写少。并且数据都是来自外部的HDFS,所以Hive中不建议做数据的修改操作，所有的数据最好是在加载的时候就已经确定好了。
2.4 Hive的整体架构
用户接口 CLI(Common Line Interface)：Hive的命令行，用于接收HQL，并返回结果；JDBC/ODBC：是指Hive的java实现，与传统数据库JDBC类似；WebUI：是指可通过浏览器访问Hive。
Thrift Server：Hive可选组件，是一个软件框架服务，允许客户端使用包括Java、C++、Ruby和其他很多种语言，通过编程的方式远程访问Hive；
元数据管理(MetaStore)
解释器 (SQLParser) ：使用第三方工具（antlr）将HQL字符串转换成抽象语法树（AST）；对AST进行语法分析，比如字段是否存在、SQL语义是否有误、表是否存在；
编译器 (Compiler) ：将抽象语法树编译生成逻辑执行计划；
优化器 (Optimizer) ：对逻辑执行计划进行优化，减少不必要的列、使用分区等；
执行器 (Executr) ：把逻辑执行计划转换成可以运行的物理计划；
Hive通过CLI，JDBC/ODBC或HWI接受相关的Hive SQL查询，并通过Driver组件进行编译，分析优化，最后编程可执行的MapReduce任务。
