读书笔记：为啥要有Hive？Hadoop上查询性能问题

因为提数需要用到Hive，于是阅读《Hive实战》，并整理成笔记，下面是来自我：一个数据开发路人甲的理解，如何不当欢迎留言或私信。

1. 再认识Hadoop

粗略地说，Hadoop是针对大数据处理的创新技术。而对于创新，书中提到了一个很有意思的认识框架“创新至少需要3个要素”：一种迫在眉睫的需求，一个可以识别的问题，和金钱。按照这里理论，书中给我们提供了一个新的认识Hadoop技术的角度：Hadoop为解决何种类型公司的何种业务需求？Hadoop要解决的什么类型的可识别问题？

1.1 Hadoop为解决何种类型公司的业务需求？Hadoop要解决的什么类型的可识别问题？

答案是最初是谷歌提出来了，为了解决互联网搜索公司的文件存储而设计的独特架构。主要解决的业务需求搜索引擎和广告业务的“海量文件的读写”。

我的理解就是，谷歌公司每天要处理大量的搜索数据量，根据我的电脑硬盘和优盘的购物经验（瞎推理），存储空间越大价格越贵，指数级别的贵。如果把巨巨巨量的数据存储分散地存储在相对小一些的硬件上，那么数据存储的成本就降下来啦。

到目前为止想的都很美，存储成本的问题解决了，但是却带来一个新的问题（如果是常规SQL模式）：分散存储的数据如何快速进行“增删改查”呢？（专业大佬看到这个的话勿喷啊，多虑了，应该也不会有人看吧）。直觉是你把新华字典思成一页页地放在不同的房间里（每个房间或者一栋房子里的所有房间称为一个存储节点），然后还想要像查一本完整的字典那样去查找，直觉告诉我这个很有难度（原谅我这个太完全贴合的理解）。这个就是Hadoop要解决的另一问题：如何对分布式存储的海量数据实现低延迟代价实现长时间的读写操作。

1.2 Hadoop的大数据解决方案

Hadoop对于海量数据的存储和“增删改查”的解决方案是：HDFS分布式文件系统（解决海量数据存储问题）和 MapReduce（解决海量分布式存储数据的“增删改查”）。

HDFS要解决的问题是在分布式存储节点越来越多的情况下，如何保证文件系统宕机的时间维持在一个可接受的范围。主要是硬件冗余设计：给分布式文件系统的每个节点（主节点）安排几个副节点，主节点挂了，副节点快速顶上。也就是说Hadoop就假定了每个存储节点是极不可靠的，为了防止一条鱼儿挂掉了，于是养了很多鱼。海王Hadoop！（具体如何实现已经超出我的认知需求了，毕竟我不是专业）

MapReduce就是专门用来操作和处理分布式存储的数据的（数据存储上“贪便宜”带来的技术提升创新）。

数据处理操作可以不负责任地理解为“增删改查”。必须要回忆一下传统的单机数据处理方式（参见计算机原理）是从磁盘中读取数据 --> 存储到内存 --> cpu进行处理。显然这个不适合海量的分布式存储系统，我的推测是没有一台电脑的内存够放下那么大量的数据。

MapReduce的解决方案是：Map 和 Reduce。以单词计数为例，见下图（如有侵权的话，请私信，必删）

图1 单词统计的MapReduce过程

Map的过程是将每个单词和对应的存储节点形成key-value的哈希映射，此过程并行处理，而且不需要进行节点间通信。因为如果需要节点间通信的话，就相当于在处理中引入依赖，这样就会造成线程的竞争或死锁的问题，所以特别适合处理大数据。也是hadoop的所谓“无共享”架构中充分利用专用IO资源（抄书）。
（在map之前，hadoop会将大文件切分成小块分给各个节点）

map之后是shuffle and sort，是对map输出的key-value分配给Reduce接收器。就是送快递，送给下一个阶段Reduce。

Reduce的功能是“合并同类项”，所以有Reduce的效果，故此得名。

1.3 MapReduce（主要关注机器学习模型部署有关的缺点）

从机器学习（ML）模型的1）读取数据、2）特征工程、3）模型预测和4）预测结果保存共四个过程分析Hadoop的优缺点。

（1）MapReduce
优点：根据1.2可知MapReduce善于以并行的方式处理大数据（可以处理大数据，不代表能快速处理），然后汇总结果。
缺点：1）它不适合处理实时查询（不能做到毫秒级数据读和写）。这个会给ML模型的应用造成困难，无法快速向ML模型装载数据，严重制约了ML模型的性能。2）存储大量小文件的话，它会占用 NameNode大量的内存来存储文件、目录和块信息。这样是不可取的，因为NameNode的内存总是有限的。这个制约了ML模型的第2、4过程，因为商品的销量数据预测中，如果预测的是接下来3天的商品销量，那么需要的历史数据中必然会有很多小文件，这些小文件势必会占用NameNode大量内存，进而制约hadoop的性能。

2. Hadoop和Spark不适合ML模型系统的部署

综上分析，ML模型需要的是：

能够并发、快速响应的即席查询，方便ML模型快速装载所需要的数据。一个ML模型可能要装载几百个甚至更多属性的数据，文件系统要快速并发响应ML模型对这些属性数据的读取请求。
有效处理大小文件。无论是海量文件，还是小文件都能够实现即席查询，并装载到ML模型中。
支持快速特征工程计算。多线程并行处理和计算图等等之类的技术，加速特征工程的计算。
列存储地即席写入。每个特征结果能够快速写入文件系统，而且是以列存储的形式。

这块知识又超出我的能力范围了（我觉得这个过程有一部分就是ETL），不过现在能够确定的是Hadoop不适合，对我当前的工作来说，这就够用的了。

同时Spark也是不合适的，据我的百度和知乎结果，spark长时间运行会有性能不稳定的缺点，原因可能有：处理大数据时中间计算结果会经常性超过RAM内存。性能不稳定是不够格来提供服务的，所以spark也要pass掉。

下图是基于Hadoop的生态系统：

（备注一下，引用https://blog.csdn.net/wdr2003/article/details/79692886，他也是转载的，但是我没找到原文链接）

至于现有的什么数据架构适合零售销量预测模型，这个需要大佬来提点啦。

3. Hive

Hive是为了解决使用SQL语言来操作Hadoop上数据的问题。因为不这样的话，我们就需要自己编写MapReduce程序来实现hadoop上的数据操作。而通过SQL语言来完成数据处理，这样会很方便。

前面提到MapReduce并不是Hadoop上唯一的数据处理方法，它更擅长数据批处理，而不是即席查询。而Hive是实现Hadoop上即席查询的数据处理技术之一。Hive拥有SQL的声明性语言和MapReduce的并行数据处理能力。

从2中内容可知，即大数据的即席查询是制约MapReduce在ML模型部署上的最大环节，的确关于大数据查询引擎方面也有很多技术：Impala、Shark、Stinger和Presto等（见参考链接2）。

3.1 python与Hive

3.1.1 使用pyhive连接Hive

流程：创建连接，获取游标，执行sql语句，获取结果，关闭连接。

from pyhive import hive  # or import hive
#第一个步，连接到hive
conn = hive.connect(host='172.16.182.82', port=10000,username='root',database='gdl')
#第二步，建立一个游标
cursor = conn.cursor(arraysize=100)
#第三部，执行查询语句
cursor.execute('SELECT * FROM gdl.gdl_cust_info_all limit 20')#第四步，获取结果集（如果有)
#获取一行数据
print cursor.fetchone()
#获取所有行的数据
print cursor.fetchall()
# 返回的查询结果的metadata#获取结果的meta，字段列表(包括数据类型)
print cursor.description#返回当前的行号
print cursor.rownumber#第五步，关闭游标
cursor.close()
#第六步，关闭连接
conn.close()

3.1.2 使用pandas处理获得的数据

import pandas as pd
from pyhive import hiveconn = hive.connect('192.168.72.135')
cursor = conn.cursor()
sql = "select * from t2 where city='Shanghai'"
cursor.execute(sql)
res = cursor.fetchall()
df = pd.DataFrame(res, columns=['id', 'name', 'year', 'city'])df1 = pd.read_sql(sql, conn, chunksize=3)
for chunk in df1:print(chunk)

参考自链接，至此，实现了使用python利用Hive读取HDFS上的数据文件了，并且转换为pandas。这个为后续的数据清洗和特征工程打好了基础。

3.2 Hive的知识点和查询性能优化

这部分整理Hive的组成架构和运转过程，并且思考数据查询优化的可能方法和思路。

3.2.1 Hive架构和优势

Hive不是一个独立工具，而是依靠各种组件来实现数据的读和写。其中的原理和机制的具体描述见这个链接
其中，关键一点是现在的Hive是默认Tez执行引擎，取代了MapReduce。带来的好处是：由于避免了代价高昂的shuffle过程，有采用高效的Map连接，从而避免了磁盘IO。还有其他优化的地方，使得基于Tez的查询引擎的执行速度比MapReduce快100倍。

3.2.2 schema-on-read和数据模型

Hive不是一个数据库，而是一个接口，一个可以查询存储在HDFS上数据文件的接口。所以是schema-on-read模式。

Hive的数据模型有表、列、行和分区，这些定义在Hive Metastore层。除此之外，Hive还有一个特别的数据模型：“桶”。

3.2.3 Hive支持的数据类型

（1）基本数据类型（关系型数据库中常见类型）

数值型：存放正负数和浮点数
日期和时间（date）：存放时间值
字符型（string）：存放字符和字符串
布尔型（boolean）
二进制型–二进制数的可变长数组

（2）复合集（collection）：（关系型数据库中不常见的数据类型）

数组（ARRAY）：元素类型相同，可以通过索引访问；
Map：无序的key-value集合
结构体（STRUCT）：类似C中的结构体，是个含有多个字段的对象，每个字段可以是任何数据类型。
联合体（UNIONTYPE）：将不同数据类型元素存放在同一个字段的不同行。

3.2.4 Hive的查询性能调优

从上面的分析我们大概能猜得到，Hive的即席查询的响应时间会比较慢。但是通过一系列复合方法，可以减少涉及两个大表的单个查询执行时间，从475秒缩短到49秒以下。

这一系列的方法是：使用Tez执行引擎、基于列的文件存储格式ORC、批量引擎批量行处理的矢量化查询执行（不再是默认的执行引擎一次然后处理一行）、基于代价优化引擎CBO来生成一个最优的执行计划。

Tez执行引擎：通过减少操作和限制写入磁盘的中间数据量来提高查询性能。主要是将Reduce的生成的中间数据直接传递个下一个Reduce，避免了重新写回HDFS，节省了磁盘的I/O性能。
ORC格式：是按照列存储在磁盘上，而不是行。这样特别适合只需要以列形式的数据读取。比如做特征工程的时候。相比于行存储的好处是，避免了不必要的磁盘访问。
矢量化查询执行：按照每批1024行读取数据，并且一次性对1024个数据执行操作。已经证明，对于典型的查询操作（扫描、筛选、聚合和连接），矢量化的执行模式可以将查询速度提高一个数量级。
查询执行计划：使用基于CBO来生成一个最优的查询执行计划。Hive驱动程序的执行流程如下图，其中查询优化器生成的执行计划最终决定了将要在Hadoop集群上执行的任务。对机器学习预测模型的性能影响最大，因为生成正确或错误的执行计划，可能会有几秒到几个小时不等的额外执行时间。

参考

https://www.cnblogs.com/wakerwang/p/9541317.html
https://cloud.tencent.com/developer/article/1106103
https://zhuanlan.zhihu.com/p/34276555
https://pypi.org/project/PyHive/
https://www.zhihu.com/question/269333988
《Hive实战》[美]斯科特-肖, [南非]安德烈亚斯-弗朗斯瓦-富穆尔恩，[印]安库尔-古普塔，[美]戴维-杰卢姆加德，唐富年译