HiveServer2 和 HiveMetastore 梳理

本文重新回顾一下Hive的两个核心服务：HiveServer2 和 HiveMetastore(HMS)。很多人会简单地把HiveServer2当成Hive的JDBC/ODBC服务，不启动HiveServer2服务，就没有10000端口，JDBC/ODBC客户端就连接不上Hive。从使用者的角度理解这就够了。如果要deep dive一下，HiveServer2的功能不止这些。我们知道：如果把Hive整体当做一个黑盒，则它的输入是用户提交的sql，它的输出是提交后的MR作业，用一句概括Hive的功能就是：将sql语句“转译”成MR作业，这实际上也正是HiveServer2的主要工作内容。更加细致一点的表述是：一般客户端会使用Hive的JDBC驱动连接到Hiveserver2（Hiveserver2通过Thrift RPC框架实现的JDBC服务端），然后将SQL语句提交给Hiveserver2，Hiveserver2会进行SQL的解析、编译和优化，在这个过程中Hiveserver2需要跟HiveMetastore服务通信以得到数据库和数据表的元数据，HiveMetastore服务会将数据库的元数据信息存储到数据库中。最终Hiveserver2将SQL编译为MapReduce作业运行在MapReduce/Tez/Spark分布式计算引擎上。HiveMetastore和HiveServer2都是独立运行的服务，对外提供基于Thrift协议的服务接口。

以下是不同平台和视角绘制的Hive架构图，基本都是一致的：

上述4张图描述的已经非常清晰了，我们再详细介绍一下Hive Driver。从这些图上可知：似乎Hiveserver2的主要工作都由这个Driver包揽了，尤其是编译，优化和执行都是由Driver主导和协调的。实际上，这里的Driver是Hive中的一个重要的类：org.apache.hadoop.hive.ql.Driver，也就是说这已经进入到了Hive的内部设计细节了，设计者设计各种重要的业务实体，抽象各种概念，将不同的职责委派给合适的类，所以回到话题本身，Driver类确实是Hiveserver2中的一个核心的类，组织与串联了SQL提交后到转译为MR作业的关键操作，但是从大的架构层面上， 我们可以认为这是HiveServer2的职责和工作内容。

接下来，我们分别看一下HiveServer2和HiveMetastore的进程和端口情况：

• HiveServer2的进程和端口

• HiveMetastore的进程和端口

不同于，HiveServer2，HiveMetastore的进程有一点隐秘，使用jps罗列进程时是看不到Metastore相关进程的，改使用ps aux | grep metastore可以查到对应进程！之所以jps中看不到是因为metastore服务的主类是org.apache.hadoop.util.RunJar，使用jps时，仅仅显示为RunJar，所以很容易被忽视。

Hive Metastore占用9083端口对外提供服务，这个9083正是在hive-site.xml中的：

  <property>
    <name>hive.metastore.uris</name>
    <value>thrift://xxx.xxx.xxx.xxx:9083</value>
  </property>

---

参考：

https://www.interviewbit.com/blog/hive-architecture/