带你玩转Logview: MaxCompute Logview参数详解和问题排查

摘要： 对于Logview上的诸多参数信息，究竟应该怎么“拨开云雾”，发现问题所在呢？又如何经过Logview了解每一个instance、task运行状态及资源占用状况，如何分析执行计划，分析query存在问题，找到Long-Tails task，让数据分析业务高效又省钱呢？本文中，阿里巴巴计算平台产品专家云花将为你们揭晓答案。

摘要：Logview是MaxCompute Job提交后查看和Debug任务的工具。经过Logview可看到一个Job的运行状态、运行结果以及运行细节和每一个步骤的进度。当Job提交到MaxCompute后，会生成Logview的连接，用户能够直接在浏览器上打开Logview连接，进入查看Job的信息，而对于Logview上的诸多参数信息，究竟应该怎么“拨开云雾”，发现问题所在呢？又如何经过Logview了解每一个instance、task运行状态及资源占用状况，如何分析执行计划，分析query存在问题，找到Long-Tails task，让数据分析业务高效又省钱呢？本文中，阿里巴巴计算平台产品专家云花将为你们揭晓答案。

直播视频回看，戳这里！https://yq.aliyun.com/webinar...
分享资料下载，戳这里！https://yq.aliyun.com/downloa...
更多精彩内容传送门：大数据计算技术共享计划 — MaxCompute技术公开课第二季

如下内容根据演讲视频及PPT整理而成。

本文将主要围绕如下4个方面进行分享：
什么是Logview
相关概念和原理
Logview参数详解
使用Logview排查问题
不少用户在使用MaxCompute的时候会遇到一些问题，可是却苦于不知道如何去定位这些问题，也不知道应该如何进行优化。所以，本文整理了一些Logview参数以及问题定位的相关知识与你们分享。

1、什么是Logview？

Logview是一个在MaxCompute上提交任务以后用来查看和Debug任务的工具，你们能够经过Logview看到任务的运行状态，包括任务的排队状况以及资源的使用状况，甚至在每一个节点上Instance运行的细节及其进度。当提交的任务出错了或者运行时间过长，就能够借助Logview分析具体的缘由，进而对任务进行精准优化。

2、相关概念和原理

在使用Logview的时候可能会遇到不少名词，这些名词都是MaxCompute特有的，所以在本部分中也进行简单介绍，帮助你们更好地理解Logview的运行原理。

MaxCompute系统架构

以下图所示的是MaxCompute的系统架构。从上往下看，首先最上层就是数据源和客户端接入的部分，各类外部数据源均可以经过外部传输的工具如Tunnel以及DataHub将数据同步到分布式文件存储系统盘古中。在客户端，用户可使用命令行工具、MaxCompute Studio以及DataWorks等开发完任务提交以后，以Restful API形式提交到HTTP服务，当HTTP服务接收到请求以后，先向用户中心作身份鉴权，所以整个接入层其实承载了数据上传下载、用户鉴权以及负载均衡等工做。接入层之下就是管理层，这也是MaxCompute最为核心的部分，这部分负责对用户空间和对象的管理、命令的解析与执行、对象的访问控制以及受权等功能，其主要有三种角色，即Workers、Scheduler以及Executor。MaxCompute的元数据实际上是存储在阿里云开放服务——分布式元数据服务上。

MaxCompute的计算集群就是架构在飞天系统之上的，而飞天系统的核心模块包括了分布式文件存储系统盘古、分布式资源调度系统伏羲、分布式协同服务女娲以及分布式监控系统神农、远程过程调用系统夸父、以及安全管理系统钟馗等。以上就是MaxCompute的基础架构，其最核心和复杂的逻辑就在管理层与伏羲之间的任务调度和管理。

MaxCompute元数据模型

其实MaxCompute之前还有个名字叫作ODPS，从2016年开始ODPS正式更名为MaxCompute，因此其实在Logview中出现的ODPS字样其实就是指MaxCompute。MaxCompute最多见的两种对象就是Job，也就是Instance，另一个就是ODPS Task。好比当提交一个SQL Query的请求，系统就会建立一个Instance，而当这个Instance在MaxCompute上执行的时候就会被分解成多个Task，可是多数状况下Instance与Task是一一对应的。这个Task有SQL类型的、有MR类型的，还有机器学习的。而在底层的分布式系统Fuxi上面也有Job和Task和Instance的概念，而这些须要和MaxCompute上的Task以及Instance的概念区分清楚。当ODPS Task提交到服务器上以后，每一个Task会被分解成为多个Fuxi Job，而每一个Fuxi Job会根据执行计划分解成不一样的执行阶段，好比Map、Reduce以及Join等。而每一个Task又会启动多个Instance来执行，至关于启动多个节点。

MaxCompute做业处理流程

首先，用户会在客户端提交一个SQL语句，客户端会经过Restful API形式提交到HTTP服务，HTTP服务的前端接收到这个请求以后会先去用户中心作鉴权，经过鉴权以后会根据所在集群信息转交给MaxCompute相应的Worker去执行。Worker则会解析这个请求，首先作API的鉴权，有了权限以后才会响应请求。Worker会判断做业类型，一种是同步任务，也就是说当Worker本身执行完就能够返回，好比SQL DDL以及Job的查询状态等，Worker会访问OTS获取元数据信息，而后交给Executor执行，执行完成以后就直接返回给客户端。另一种是异步任务，所谓异步任务就是对后续节点进行处理，须要提交到Fuxi去处理的任务，好比SQL的DML或者MR这类的任务请求。Worker会建立一个Instance而后交给Scheduler去执行，Scheduler负责对全部异步任务的调度，它会把Instance分解为Task并作全局的计算调度。当全部资源以及条件都知足Scheduler就会将Task交给Executor进行执行，Executor上其实封装了各类业务逻辑，好比SQL以及算法模块，Executor会根据不一样的做业类型拉取不一样的做业模块。当Executor空闲的时候会向Scheduler进行心跳上报并请求任务，当其拿到任务以后会根据任务类型启动一个相应的业务模块来执行。Executor会生成一个任务的执行计划，并将任务以及执行计划一块儿交给Fuxi进行执行。有时候提交到Fuxi的任务会出现回退的状况，好比第一次是按照Online Job的做业类型来提交的，到Fuxi以后可能会提交失败并回退到Scheduler，而后按照Offline的方式再提交一次，这样就会在Logview看到对应的状况。当Executor将Task提交给Fuxi以后，还会去监控Task的执行状态，当执行完成以后则会更新OTS里面的Task信息并汇报给Scheduler，Scheduler则会判断整个Instance是否执行完毕，若是执行完毕也会去更新OTS中的Instance信息，将其设置为Terminated，以上这些就是完整的做业处理流程。

3、Logview参数详解

分享完基本概念和理论以后就能够介绍Logview的参数了。主要的信息包括ODPS Instance，其涵盖了队列信息以及子状态信息，另一部分包括Fuxi Job，这能够进一步拆解成Task信息和Fuxi Instance信息。在整个任务结束以后能够看到其Summary以及Diagnosis诊断信息，此外还有上传下载的小功能。

ODPS Instance信息

下图中最上面的表中有这样的几个字段：URL、Project、InstanceID、Owner、StartTime、EndTime、Latency、Status以及Process等。URL是Endpoint的地址，Project存放项目的名称，InstanceID实际上是时间戳跟着随机字符串，这个时间戳是精确到毫秒的，而这个时间是UTC时间，与电脑提交任务的时间是不一致的。StartTime和EndTime分别是任务开始和结束的时间，Latency则是任务运行所消耗的时间。而对于Status而言，则有四种状态：Waiting状态表明任务正在ODPS中处理，还没提交到Fuxi中运行；Waiting List表明任务已经到了Fuxi，而且在Fuxi中排队，N表明排队的位置；Running表明在Fuxi中运行；Terminated表明运行已经结束了。在表格里面，只要Status不是Terminated的状态，只要双击就能打开Queue Detail和SubStatus History详细信息。

Queue Detail&SubStatus History信息

以下图所示最上面的Table是关于队列的信息，首先是Fuxi Job的name，SubStatus则是目前Job的运行状态，Progress是目前的执行进度。红框里面有两个字段，分别是WaitPOS和QueueLength，前者是目前排队的位置，后者是队列长度，根据这两个字段就能看到整个队列里面有多少任务在排队，这个任务排在第几位。Total Priority是其优先级，点击SubStatus History的图标能够打开下图中下侧的Table。对于SubStatus History而言着重介绍一下SubStatus Code以及其含义，在下图中列出了一些常见的SubStatus Code以及其对应含义。

Fuxi Job的两种做业类型

前面也提到了Fuxi Job有两种做业类型，分别是Online Job和Offline Job，这两种Job到底有什么区别呢？首先，对于Offline的做业而言，当每次提交做业时在Fuxi上都会有一个环境准备的时间，对于大数据量而且不须要返回查询结果的做业比较合适。而对于小数据量而且实时做业要求比较高的做业是不合适的。因此Fuxi提供了Service Mode这种准实时的做业形式，首先会有一个服务去预先申请计算一些资源并加载出来，好比会预先分配一万个Instance，当有做业提交过来的时候会根据做业规模分配一些Instance进行执行，这样就省去环境准备的时间，因此就会比较快，这就是两种类型做业的主要差别。

对于FuxiJob的命名规则而言，如上图所示“odps/”后面的部分就是<project_name>_<instanceId>_<task_type>_<odps_task_index>_<task_history>_<fuxi_job_index>_<jobtail>。

ODPS Task信息

以下图所示的是ODPS Task信息，上面的表格的第一个字段是TaskName，Type指的是做业类型，Status指的是运行状态，双击Rusult会输出做业的整个结果集，双击Detail信息则会打开整个Fuxi Job的详细Table。

Fuxi Job Detail信息

Fuxi Job详细信息主要分为三个部分，最左侧是任务的执行计划，这个执行计划是在Executor里面生成的，执行计划就是将一个任务分红不一样的Stage来执行，每一个Stage的均可以看作一个图上的点，而Stage之间的依赖关系就能够看作图的边，这样就构成一个有向无环图。在下图例子中，将Fuxi Job分解成了四个Map的Task，两个Join的Task，还有3个Reduce的Task。举例而言，对于J3_1_2这个Task而言，须要在M1和M2执行完成以后才会执行，也就是说M1和M2的输出就是J3_1_2的输入，而且在名字上也能够体现其依赖关系，也就是说命名实际上是和执行计划相关的。下图中右上方这部分就是每一个Task的详细信息，也是每一个Stage的详细信息。图中下面部分则是每一个Instance的详细信息。

Fuxi Task Detail信息

对于Fuxi Job Detail信息而言，又有哪些须要关注呢？第一个字段就是TaskName，其和执行计划的生成是相关的。后面的字段Fatal/Finished/TotalInstCount，在表格里面Fatal表示严重错误个数，所以被标红了；Finished表示已经结束的Instance的个数，后面的TotalInstCount指的是为每一个Task启动的总Task数量。下一个字段I/O Records指的是输入和输出的记录的个数，I/O Bytes指的是输入和输出的字节数。FinishedPercentage指的是进度条，Status则指的是每一个Task的运行状态。

Fuxi Instance Detail信息

Fuxi Instance是整个做业流中最小的颗粒，在以下图所示的Demo中是一个Map的做业详细信息。首先看All字段，这个字段后面有一个数字415，这说明为M3_2这个Task启动了415个Instance，其左侧的Terminated、Running、Ready以及Failed分别是相应状态的实例个数。而SmartFilter则会给出最先结束、最晚结束、运行时间最短和运行时间最长的四个Instance，将其筛选处理方便观察。Latency Chart则是以图表的形式展现全部的Instance的运行时长分布，而在Latency里面则是最长运行时间和最短运行时间以及平均运行时长，其实这三个时间对于分析长尾任务是很是有用的。在每一个Instance的表格里面详细信息里面有一个StdOut，这是每一个Instance在执行过程当中打印的信息，而StuErr则是当Instance失败的时候能够用来查看出错缘由的。

Fuxi Job Detail信息 之 Summary信息

FuxiJob的Summary是在整个Job运行完以后才能查看的信息，主要包括Job消耗的CPU、内存、Job输入的表名以及记录数和字节数。此外，Job的运行时间单位是秒。Fuxi Task的Summary信息则主要包括Instance数量、Task运行时间、全部Instance里面的最大、最小和平均运行时间。

Tips：用Summary信息作计量计费参考

这里与你们分享一个Tips，就是如何用Summary信息作计量计费参考，好比在这里执行的是一个MapReduce做业，其计费方法是MR任务当日计算费用=当日总计算时0.46元(RMB)，则任务的计算时=任务运行时间(小时)任务调用的核数量。而在Summary信息里面就可以直接拿到CPU的计算时，而不须要用公式计算了。而对于SQL计算而言，计算公式为：一次SQL计算费用 = 计算输入数据量 SQL复杂度 SQL价格。而输入数据量与SQL复杂度都可以经过cost sql <SQL Sentence>这个命令来计算。对于计量计算而言，更多的内容请参考官网上的信息。

Diagnosis信息

Diagnosis是诊断信息，其是在做业执行完成以后能够点击小红点进而打开以下图所示的表格。Diagnosis主要会诊断三类信息，分别是对资源的诊断、对数据倾斜的诊断以及对从新运行的诊断，每类信息会给出对于问题的说明和问题严重等级，而且会给出改进意见。

Logview信息的导入导出

Logview的信息能够导入和导出，由于其信息只能在系统中保留7天，若是想要长期保存就须要导出信息。你们能够点击Logview右上角的小图标将Logview信息保存到本地，当须要分析的时候再点击“望远镜”小图标，从本地将Logview信息上传上去就能够还原出Logview的信息。

4、使用Logview排查问题
常见的问题有这样几种，首先就是任务一直在排队等待或者任务直接运行失败了，而最多见的状况就是任务执行时间太长了，一直跑不完。其实大多数慢任务的缘由都是由于长尾，而大多数长尾都是由于数据倾斜带来的。这不只将会影响数据分析结果的产出，还会拉高数据资源的消费，所以对于这种状况必需要进行优化。

1. 任务出错了
对于出错任务而言，从控制台输出就能够看到出错的缘由，若是想要查看更加详细的信息，则能够打开Logview去查看ODPS的Result信息，若是失败了能够看到Status变成红色了。当双击Result以后就能够看到报错输出的总体信息。在出错信息里面会有错误码，而错误码与详细错误的对照表能够在官网找到。因此查看出错任务的方式有两种，一种是在做业结束以后查看其Result信息，另一种方式则是去查看Instance的StdErr信息。

2. 慢任务诊断
(1) 做业排队
对于慢任务诊断而言，可能看到一种现象就是做业一直在排队或者在控制台看到Fuxi Job一直在Waiting。进一步在Logview里面查看，发现Status究竟是Waiting仍是Waiting List，这样就能够发现其到底在哪里排队，若是状态是Waiting List则能够进一步地看其详细队列长度究竟是多少，排到了第几位。还能够在SubStatus里面看到其子状态的信息。

对于慢任务而言，不少用户反映不可以知道究竟是哪个做业是慢任务，所以在这里为你们介绍两种查看慢任务的方法：一种是“show p”，能够查看全部示例信息；而“top instance”能够查看当前正在执行的做业，而运行时间最长的做业可能就是阻塞队列致使其余任务排队的任务。对于因为资源抢占所致使的问题，能够作以下的优化：
对于后付费用户而言，能够根据做业特性把相对稳定的周期性常规任务放到预付费资源组去执行，能够保证资源不被抢占。
对于预付费用户而言，若是并行执行多个做业，最好合理安排做业执行时间，让做业错峰执行，临时任务则建议在后付费资源组执行。而关于做业排队的缘由分析，能够参照云栖社区的一些相关资源文档。

(2) 大量小文件问题
大量小文件的存在也会致使任务执行很慢，好比在做业开始执行的时候，执行计划可能以下图中第一张所示，有两个Map以及一个Join还有一个Reduce，当Reduce的Task执行以后，发现系统自动增长一个MergeTask，这就是由于系统在作合并小文件的操做。

其实，分布式文件系统的数据文件是按照块来存储的，盘古的块大小就是64M，因此若是文件小于64M就能够称为小文件。小文件的产生主要有这样的3种缘由：(1)当Reduce计算过程当中会产生大量小文件;(2)Tunnel数据采集过程当中会生成小文件;(2)Job执行过程当中生成的各类临时文件、回收站保留的过时文件等。而由于小文件过多，就会致使在Map阶段读取的数据出现分布不均匀的状况，进而引发长尾。若是存在大量的小文件，除了会浪费资源并下降磁盘空间利用率以外，还会影响总体的执行性能，所以从存储和性能两方面考虑都须要将计算过程当中的小文件都合并。其实MaxCompute系统已经作了不少的优化，系统会自动分配一个Fuxi的MergeTask来作小文件的合并，可是其实还有不少状况下产生的小文件没有被合并。所以，MaxCompute提供了一些参数帮助用户进行小文件的合并。

首先能够查看小文件的数量，也就是判断本身的表里面是否存在不少小文件。能够用“desc extended TableName”命令就能够输出小文件数量。若是小文件数量不少就能够经过如图中下面的SQL来整合小文件。

为了不小文件的操做，能够给出一些相关建议。好比在Reduce过程当中产生的小文件建议可使用insert overwrite向原表写入数据，或者把数据写入新表以后，将原表删除。其次，为了不在Tunnel的数据采集过程当中产生小文件，能够调用Tunnel SDK。也就是在上传数据的时候最好等到Buffer达到64M的时候再进行提交，不要过于频繁地进行提交。在导入分区表的时候建议为表设置生命周期，对于过时的数据能够进行自动清理。而针对大量临时表的状况，也能够加上生命周期，到期以后进行自动回收。对于小文件的优化，在官网文档中也有更加详细的介绍。

(3)数据倾斜致使长尾任务

数据倾斜致使长尾任务也会致使慢做业。其实数据倾斜就是由于数据分布不均匀，少数的Fuxi Instance处理的数据量远远超过其余的Instance，所以致使长尾任务。在MaxCompute的Logview里面，将鼠标放在Longtails标签上面就能够看到提示“Latency is more than twice average”，也就是说运行时间超过平均的两倍，就将其定义为长尾任务。

经过Logview有两种方式查看其是否属于长尾任务，第一种方法就是查看Long-Tails的Fuxi Instances的Max Lantency。若是括号里面的数量大于0，那就说明已经出现了长尾，点击标签以后就会将全部长尾Instance列出来，而且能够查看其各类信息。另一种查看长尾任务的方法就是查看Fuxi Job的Summary信息以及Diagnosis信息，经过分析Summary能够查看长尾分布在哪一个阶段。若是instance time的max和avg两个值相差很大就说明出现了长尾；而对于input records而言，若是输入数据量的max和avg相差也很大就说明发生了数据倾斜。在Diagnosis信息里面专门有一项是检查数据倾斜和长尾的，因此经过系统所给出的信息就可以查看出是否出现了长尾仍是数据倾斜，也同时给出了一些改进意见。

最后与你们分享对于不一样种类的数据倾斜分别能够作哪些优化。在Join阶段出现的数据倾斜是由于Join Key分布不均匀，致使某一个Key的值数据量特别大，会被分配到同一个Instance上进行处理，这个Instance处理时间就会比较长，所以形成长尾。好比用一个大表来join一个小表或者在key中有大量的空值都会形成Join阶段的数据倾斜，对于这种状况可使用Map Join进行优化，其原理是将Join操做提早到Join阶段进行，其实就是将小表里的数据加载到执行Join操做的程序内存中，因此就加速了Join的执行，而Map Join比普通Join性能要好不少，对于有空值的状况，建议先过滤掉空值而后补上随机数，至关于对Key作从新分配，而后再进行Join。第二种则是因为Group By致使的数据倾斜，其产生缘由也是因为Group By后面的Key分布不均匀致使的，这里有两种优化方法，一种是设置方倾斜的参数，另一种则是对Key加上随机数进行从新分配。第三种是因为使用Distinct形成的数据倾斜，因为Distinct是对于字段作去重的操做，那么这样就没办法在Map的Shuffle阶段就根据GroupBy作一次聚合操做来减小数据传输，它只能将全部的数据全都传入到Reduce端来处理，因此当Key的数据发生了不均匀的时候就会致使Reduce端出现长尾，针对这种状况能够用Count + GroupBy代替Distinct。最后一种就是因为动态分区带来的长尾，若是动态分区过多的时候就可能形成小文件过多，而为了整理小文件，系统会在启动一个Reduce的Task对数据进行整理，若是动态分区写入数据有倾斜就会产生长尾，在这种状况下就尽可能不要使用动态分区，在insert的时候最好指定相应的分区。对于优化这部分，你们也能够在官网上找到更加详细的连接。

原文连接

本文为云栖社区原创内容，未经容许不得转载。