您的足迹:首页 > Hive >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服务为单点。
本博客所有文章如无特别注明均为原创。作者:数据为王复制或转载请以超链接形式注明转自 数据为王
原文地址《Hive SQL运行状态监控(HiveSQLMonitor)

相关推荐


  • blogger

发表评论

路人甲 表情
看不清楚?点图切换 Ctrl+Enter快速提交

网友评论(0)