阅读(4374)
目前数据平台使用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我们可以获取到以下信息：
QueryStr：
HadoopJobName：
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服务为单点。原文链接:
阅读排行榜问题：菜鸟提问：前端的进度条是如何控制后台执行进度的？
描述: 菜鸟的我弱弱的问一句：
我们在网上很常见的那种进度条，比如你打开一个东西，进度条就显示正在打开的百分比进度，我知道有很多假的，但是那种真的，进度条不会循环的走，就按照百分比进度走，走到头了东西也打开了。
我就很好奇，前台的这个进度条是如何控制后台进度的，我很笨的想是不是前台不断的向后台发请求去看进度啊？但是就算是发请求了，后台怎么知道自己要执行到什么时候能结束，那个百分比又是如何算出来的呢
最主流的做法是怎么做的呢？用的什么技术。
谢谢大家了。解决方案1:粗暴点就做个长轮询在那里写进度到文件中去，客户端再用轮询读这个文件解决方案2:后台执行进度是如何控制前端的进度条的.解决方案3:ajax&websocket
以上介绍了“菜鸟提问：前端的进度条是如何控制后台执行进度的？”的问题解答，希望对有需要的网友有所帮助。
本文网址链接：/itwd/1184688.html
上一篇： 下一篇：1293人阅读
问题驱动的软件测试管理（18）
测试进度监控，特别是测试执行进度监控，是测试过程中的关键测试活动。做好测试执行进度监控，测试团队首先需要明确测试计划中定义的测试目标、测试范围、计划的测试执行进度、资源与风险等；其次在测试过程中获取和分析当前的测试状态和信息；然后根据上述两者之间的差异，选择和定义合适的应对活动，并不断跟踪和修正应对活动的有效性。具体的测试控制包括：
1）更新项目风险和产品风险、测试优先级和/或测试计划。
2）增加资源或增加测试的工作量。
3）推迟版本发布时间。
4）降低或加强测试出口准则。
测试执行进度监控的开展，需要在测试过程中收集各种度量信息。本文将从风险、测试、覆盖率、缺陷和信心5个维度，说明如何基于它们实施测试执行进度监控的：
1）风险是测试计划重要的组成部分，特别采用基于风险的测试策略的时候，风险对测试的重要性更加突出。在测试执行进度监控过程中，需要关注质量风险、管理风险和剩余风险，例如：早期识别的质量风险，通过不断的测试执行测试用例得到了减轻；目前剩余风险还有多少等。
2）测试，这里主要指的是测试用例，包括测试用例设计进度、测试用例执行进度等。针对测试用例执行度量，主要包含了计划的测试用例、成功执行的测试用例数、失败的测试用例数、被阻塞的测试用例数等。根据这些数据和趋势就可以分析与评估测试执行进度与测试计划之间有没有偏差。
3）覆盖率。主要包括针对需求的覆盖率、平台的覆盖率、测试类型的覆盖率等度量，分析这些信息与趋势，有助于评估与测试计划之间的偏差，并采取合适的应对手段。
4）缺陷。缺陷是测试过程的重要输出，也是测试执行进度的关键度量信息，主要包括：已解决的缺陷数目、已提交的缺陷数目、缺陷发现总数的趋势图、缺陷分类（基于发现的阶段、模块、根本原因、引入阶段等）、缺陷修复的时间等。
5）信心。包括测试用例的通过率、缺陷发现的趋势图，同时包括测试人员对被测对象的主管质量信心。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：176052次
积分：3485
积分：3485
排名：第7548名
原创：108篇
评论：96条
(1)(2)(6)(2)(1)(5)(3)(4)(7)(7)(10)(19)(2)(1)(1)(4)(4)(4)(4)(6)(14)(2)