Hive SQL运行状态监控（HiveSQLMonitor）

Hive SQL运行状态监控（HiveSQLMonitor）

引言

 

目前数据平台使用Hadoop构建，为了方便数据分析师的工作，使用Hive对Hadoop MapReduce任务进行封装，我们面对的不再是一个个的MR任务，而是一条条的SQL语句。数据平台内部通过类似JDBC的接口与HiveServer进行交互，仅仅能够感知到一条SQL的开始与结束，而中间的这个过程通常是漫长的（两个因素：数据量、SQL复杂度），某些场景下用户需要了解这条SQL语句的执行进度，从而为我们引入以下几个问题：

 

（1）通过JDBC接口执行一条SQL语句时，这条SQL语句被转换成几个MR任务，每个MR任务的JobId是多少，如何维护这条SQL语句与MR任务的对应关系？

（2）如何获取MR任务的运行状态，通过JobClient？

（3）通过HiveServer是否可以获取到上述信息？

 

思路

 

当我们在终端下执行命令“hive”后，会看到有如下输出：

 

 

Hive有会话（Session）的概念，而 这次会话中的所有日志消息将会输出到这个日志文件中，包含SQL语句的执行日志，查看这个日志文件可以看到以下信息：

 

 

 

QueryStart行日志包含QUERY_STRING、QUERY_ID。

 

 

TaskStart行日志包含TASK_ID、QUERY_ID。

 

 

TaskProgress行日志包含TASK_HADOOP_PROGRESS、TASK_ID、QUERY_ID、TASK_HADOOP_ID，其中TASK_HADOOP_PROGRESS中可以获取到map、reduce进度。

 

 

TaskEnd行日志包含TASK_HADOOP_PROGRESS、TASK_ID、QUERY_ID、TASK_HADOOP_ID。

 

 

QueryEnd行日志包含QUERY_STRING、QUERY_ID。

 

由上可知，QueryStart、TaskStart、TaskProgress、TaskEnd（一个复杂的Query可能会产生多个Task）、QueryEnd覆盖整个查询的执行过程，通过对这些行日志的解析，我们就可以获取到Hive SQL的执行状态。

 

此外，还有SessionStart、SessionEnd，由于使用过程中发现SessionEnd日志有时不被输出，因此没有使用这两个状态。

 

会话的日志文件存储在HiveServer的本地磁盘中，而实际应用中我们有多台HiveServer提供服务，因此我们需要能够统一收集所有HiveServer的会话日志。

 

通过对Hive源码的分析发现，每次Hive执行语句时都会执行一些“Hook”（PreHook），代码如下：

 

 

通过会话日志、PreHook，我们基本可以整理出以下思路：

 

在PreHook中启动线程监听会话日志的输出（类型Linux的tailf），将这些日志信息统一收集到某一服务中，统一处理后做进度展示。

 

实现

 

我们构建了一个Rest API服务，一部分用于接收由PreHook发送的会话日志信息，另一部分用于对外提供进度展示。

 

PreHook要求实现接口ExecuteWithHookContext，如下：

 

 

通过hookContext我们可以获取到以下信息：

 

QueryId：

 

 

QueryStr：

 

 

HadoopJobName：

 

 

Jobs：

 

 

HistFileName：

 

 

为了保证后续对会话日志的接收，我们需要在查询执行伊始就将上述信息发送给Rest API服务，如下：

 

 

 

然后就是对会话日志的输出监听（即tailer），我们使用Apache Commons IO中的Tailer完成些功能，如下：

 

 

Tailer实际上启动一个后台线程，并通过listener完成数据行的处理，而一次会话中可能执行多条查询语句，而每一次执行查询语句时都会导致PreHook的执行，因此我们需要避免同一会话中对histFileName多次“tailf”,需要维护已被“tailf”的文件，而且Tailer实例是需要被“stop”的，多数时候无法获取到SessionEnd数据行，需要通过其它方式能够终止会话已经消失的Tailer线程。为此专门设计了TailerTracker（单例，即TAILER_TRACKER）。

 

TailerTracker维护着一个记录列表：

 

 

 

 

维护着成对的tailer与listener实例，其中listener实例中维护着对应tailer实例中最后一次新数据产生的时间，如果tailer实例在设定的时间内都没有新数据产生，则应该对其执行stop，核心代码如下：

 

 

判断某一个会话文件是否已经被“tailer”，代码如下：

 

 

标记一个会话文件已经被“tailer”，代码如下：

 

 

会话日志数据行的输出实际由FileTailerListener（继承自TailerListenerAdapter）完成，代码如下：

 

 

每处理一行数据，都要更新一下时间戳lastHandleTime，而QueryStart、QueryEnd、TaskStart、TaskProgress、TaskEnd的数据行会通过不同的Rest API Post。

 

至此，HiveServer的会话日志收集过程完毕，而Rest服务则需要通过这些收集到的数据完成Hive SQL进度跟踪。

 

我们在通过JDBC接口与HiveServer交互时，是无法获取到QueryId的，但是我们可以通过属性mapred.job.name设置Hive SQL执行时的MR JobName，JobName代表查询名称，需要唯一，同时我们需要维护JobName与QueryId的对应关系。

 

在Rest服务内部设计实现ProgressController，用以维护JobName与QueryId的对应关系，同时使用QueryId跟踪Hive SQL执行进度，核心变量如下：

 

 

目前Hive SQL的进度记录仅仅在内存里维护（超过一定时间后，这些进度信息便不再有价值），因此需要控制内存中进度记录的数量，这一点是通过记录每一条SQL相关进度信息的最后更新时间（lastUpdateTime）来实现的，过期即被清除。

 

lastUpdateTime：维护JobName（即某个查询）记录最后更新时间；

 

jobNameToQueryId：维护JobName与QueryId的对应关系；

 

querys：维护QueryId与Hive SQL执行进度（QueryProgress）的对应关系。

 

QueryProgress内部结构如下：

 

 

queryId：查询ID；

 

sql：查询语句；

 

jobs：查询被转换成MapRecude Job的数量；

 

taskProgresses：维护TaskId与MapReduce的执行进度的对应关系；

 

startTime：查询的起始时间；

 

stopTime：查询的终止时间；

 

state：查询状态。

 

TaskProgress内部结构如下：

 

 

taskId：TaskId（Stage-1、Stage-2、...）；

 

taskHadoopId：Task对应的Hadoop MapReduce Job Id；

 

map：Hadoop MapReduce map进度百分比值；

 

reduce：Hadoop MapReduce reduce进度百分比值；

 

startTime：Task起始时间；

 

stopTime：Task截止时间；

 

state：Task运行状态。

 

当收到query/init的请求时，执行ProgressController queryInit方法，代码如下：

 

 

当收到query/start的请求时，执行ProgressController queryStart方法，代码如下：

 

 

 

当收到task/start的请求时，执行ProgressController taskStart方法，代码如下：

 

 

当收到task/progress的请求时，执行ProgressController taskProgress方法，代码如下：

 

 

当收到task/end的请求时，执行ProgressController taskEnd方法，代码如下：

 

 

当收到query/end的请求时，执行ProgressController queryEnd方法，代码如下：

 

 

其中ProgressController还承担着定时清理的工作，代码如下：

 

 

进度示例

 

 

 

不足

 

Hive SQL执行进度数据维护在内存中，而且Rest服务为单点。