此文档是为了系统管理员准备的,他们需要配置Hive Metastore高可用服务。
重要提示:
支持HiveMetastore本身的关系型数据库也应该使用数据库系统所定义的最佳实践提供高可用性。
本节提供关于Hive Metastore高可用(HA)的用例和故障转移场景的信息。
用例
Metastore HA解决方案被设计用来处理metastore服务故障。当一个部署的metastore宕机时,metastore服务可能持续相当长的时间不可用,直到服务被重新拉起。为了避免这种服务中断情况,需要部署Hive Metastore HA模式。
部署场景
Hortonworks建议同时在多个主机上同时部署metastore服务。每个HiveMetastore客户端将读取配置参数hive.metastore.uris以获取metastore服务器的一个列表,客户端将与它进行通信。
需要注意的是,Hive Metastore本身背后的关系型数据库应该使用数据库系统定义的最佳实践部署为高可用。
在安全集群的情况下,对每个metastore服务器,在hive-site.xml文件中添加如下配置参数:
故障转移场景
一个Hive metastore客户端总是使用第一个URI来连接metastore服务器。如果metastore服务器变得不可访问,客户端就会随机从列表中获取一个URI并尝试连接它。
多个HiveServer2(HS2)实例将自己的信息注册到ZooKeeper,然后客户端就可以通过ZooKeeper找到一个要访问的HS2。当一个客户端请求HS2实例时,ZooKeeper就会从注册的HS2中随机选择一个返回。
建议在以下场景中开启:
l 高可用
如果在ZooKeeper中注册了多个HS2实例,只要还有一个HS2实例活着,ZooKeeper会将HS2链接信息传递给正在运行的实例,客户端可以成功连接。(必须手动重启失败的实例)
l 负载均衡
如果有超过一个在ZooKeeper中注册的HS2实例,ZooKeeper通过随机传递一个链接到HS2实例来响应客户端请求。这确保了所有HS2实例的工作负载大致相同。
目前还没有处理的工作:
l 自动故障转移
如果在连接客户端时,HS2实例失败,则会话丢失。由于这种情况需要在客户端处理,所以没有自动故障转移;客户需要使用ZooKeeper重新连接。
HS2实例在ZooKeeper的名称空间下注册。当一个HiveServer2实例运行时,它通过在ZooKeeper中添加一个znode来注册自己信息。znode名称的格式为:
/
serverUri=
sequence=
znode存储HS2服务器的数据,格式为:主机:端口
服务器实例在znode上设置一个watch(观察,监视);当znode被修改时,该watch会向服务器发送一个通知。这个通知帮助HS2服务实例跟踪其是否在新客户端连接可用的服务器列表上。
当一个HiveServer2实例从ZooKeeper中注销时,它会从新的客户端连接的服务器列表中删除(服务器上客户端会话不受影响)。当服务器上的最后一个客户端会话关闭时,服务器就关闭了。
为了注销一个单独的HiveServer2,可以执行命令:
hive --service hiveserver2 deregister
如下图所示,在大多数数据库使用的传统client/server模型中,不需要ZooKeeper的查询执行:
1. 给JDBC/ODBC驱动一个存在的HS2实例的host:port信息
建立一个session,多个查询执行。
2. 客户端提交一个查询给HS2,然后HS2提交查询到Hadoop执行。
3. 查询的结果写到临时文件中。
4. 客户端驱动从HS2(从临时文件中返回)获取记录。
通过ZooKeeper的查询执行利用服务动态发现的优势。因此,客户端驱动需要知道如何使用此功能。
动态发现通过ZooKeeper包括一个额外的间接步骤实现。如下图所示。
1. 在ZooKeeper上注册多个HiveServer2实例
2. 客户端驱动连接到ZooKeeper ensemble:
jdbc:hive2://
zooKeeperNamespace= 在下图中, 注释: 在实际企业级应用中,ZooKeeper运行在一组叫ensemble的集群上。ZooKeeper通过复制来获得高可用性。同时,只要ensemble中大部分机器运作,就可以提供服务。在2n+1个节点的ensemble中,可以承受n台机器故障。 3. ZooKeeper随机返回注册的一个HiveServer2节点的 4. 客户端驱动程序无法连接到返回的HiveServer实例,并按照前面的部分(没有ZooKeeper)那样处理。 参考:bk_hadoop-high-availability