一、MaxCompute作业基本概念
MaxCompute有很多专业术语，logview 中内容直接沿用了这些术语，为了便于理解logview ，首先需要理解相关概念。
控制集群：
- Job/Instance/MaxCompute Instance：代表用户提交的作业，每个作业具有instanceId 进行唯一标示。
- Task/MaxCompute Task：作业在运行时所属的类型，例如SQL task， LOT Task，Graph Task 等，一般一个Instance 只有一个Task，所以logview 2.0 隐藏了该信息。（1.0 是有的）
计算集群：
- Fuxi：作业实际计算层，以fuxi job -》 fuxi task -》 fuxi instance 层级递进。
- DAG 图：fuxi task 具有依赖关系，连接所有 fuxi task 构成了有向无环图。
- Operator：fuxi task 内部的算子，例如TableScan，TableSink，是数据处理的逻辑。
二、Logview 的生成过程
Logview 是用于查看MaxCompute作业的工具，可以展示作业实际执行的每一处细节。当作业运行出错，运行变慢等都需要通过logview进行定位。
LogviewURL结构：logview域名 + MaxCompute endpoint + project + instanceId + token + other parameters，例如：https://logview.aliyun.com/logview/?h=http://service.cn.maxcompute.aliyun.com/api&p=huadong_1_test&i=20201103031620528g3e7n4pr2&token=eEdUUEI0SWh3ZUFVS043SitFT21PUm5mQ3RvPSxPRFBTX09CTzoxNzY3OTc2MDA5NDY4MDcxLDE2MDY5NjUzODAseyJTdGF0ZW1lbnQiOlt7IkFjdGlvbiI6WyJvZHBzOlJlYWQiXSwiRWZmZWN0IjoiQWxsb3ciLCJSZXNvdXJjZSI6WyJhY3M6b2RwczoqOnByb2plY3RzL2h1YWRvbmdfMV90ZXN0L2luc3RhbmNlcy8yMDIwMTEwMzAzMTYyMDUyOGczZTduNHByMiJdfV0sIlZlcnNpb24iOiIxIn0=
有效期：和logview 1.0 一样，2.0 也有有效期，一般是30天。
三、Logview 原理
Logview 跟常规web应用一样，由前后端组成，前端渲染页面，后端汇总MaxCompute 各种运行信息。
Logview 1.0 原理非常简单，就是一个页面展示+代理，所有页面展示的内容都是调用MaxCompute 的restful api 实现，2.0 实现稍微复杂些，数据源更加丰富，支持一些定制化任务展示。
四、Logview 1.0 VS 2.0
logview 2.0 相比于1.0 重新升级页面风格，简化作业查看流程，提供1.0 原有数据前提下，增强了DAG 展示、作业回放等功能。
1.0 vs 2.0
相比于logview1.0 ，2.0 隐藏了MaxCompute task 信息，因为MaxCompute 作业默认只有一个MaxCompute task，直接展示fuxi job/fuxi task 信息。
4.1 上部为功能区
包含三个按钮，打开本地离线logview文件，返回1.0，保存离线logview文件。注意2.0和1.0 的离线文件不兼容。
4.2 左侧为基本信息
重点可以看Queue字段，如果发生排队，该字段显示排队位置。
4.3 右侧为多Tab 页面结构
新增了SubStatusHistory 和OperationHistory Tab， subStatusHistory跟1.0 subStatus相同。OperationHistory 可以显示哪些人对该作业进行过操作，例如看被谁kill了。
4.3.1 JobDetail Tab
上部分为DAG图，下部分为Fuxi Job-》Fuxi Task -》 Fuxi Instance。
这里重点关注DAG图，默认为Fuxi Task 层图，双击进入Operator层，支持进度图/热度图，作业回放。作业回放原理是将作业运行时间划分成120帧，每一帧计算出对应的进度/热度等，连续播放120帧。可以快速查看出关键fuxi task。注意running 时不支持回放功能。
4.3.2 Result Tab
Result tab 有多种模式，select 语句的结果， 作业运行失败原因展示。
result 结果支持以文本和表格两种方式展示，可通过设置以下flag 修改，默认为表格展示方式。
set odps.sql.select.output.format=HumanReadable;
4.3.3 substatusHistory Tab
| Waiting for scheduling | 作业已提交，等待MaxCompute 框架调度，一般很短 |
|---|---|
| Waiting for cluster resource | 框架发现fuxi 计算集群没资源，直接等 |
| Waiting for concurrent task slot | project 级别流控，project 可以设置并行提交sql个数，弹内不限制，公共云限制，有限制后这个就是流控。 |
| Waiting for data replication | 等待数据复制 |
| Waiting for execution slot | 这个是系统级别流控 |
| Waiting for cleaning up of previous task attempt | 等待清理执行历史完成 |
| Waiting for execution | 从父进程队列拿出来分发给子进程执行过程，一般很快。 |
| Waiting lazy package launching | |
| Updating package version | |
| Preparing for execution | 明确知道交给子进程，如果子进程出问题才会时间长。 |
| Task is executing | 作业在框架处理中 |
| SQLTask is initializing | sql 作业初始化中 |
| SQLTask is compiling query | sql 作业编译中 |
| SQLTask is optimizing query | sql 作业优化query，如果执行计划复杂，优化时间会稍长，但过长可能就是bug |
| SQLTask is splitting data sources | sql 作业优化中，切分data sources |
| SQLTask is generating execution plan | sql 作业生成执行计划中，时间长可能是读取分区太多，或者小文件太多 |
| SQLTask is submitting execution plan | sql 作业提交执行计划 |
| Job has been submitted | 作业提交计算集群 |
| Offline Job Waiting for running | 提交后发现fuxi 集群quota组没资源，是等第一份资源，本来以为有，实际提交后发现没了，就会等待。只会出现一次，后面就算没资源也不会显示了。 |
| Offline Job is running | fuxi 作业执行中， 如果运行中没资源，会一直是该状态，比如高优先级作业抢占资源，导致部分fuxi instance 起不来，状态是ready |
| Offline Job is failed | fuxi 作业执行失败 |
| Offline Job is succeed | fuxi 作业执行成功 |
| SQLTask is updating meta information | SQL作业更新元数据信息，生成动态分区时，可能会稍长 |
| SQLTask is finishing | SQl 作业执行结束 |
| Online Job is cancelled by fuxi | service mode 模式被取消 |
| Task rerun | 作业重跑，可能是service mode 失败，采用offline job，也可能是数据跨集群复制 |
| Online Job Waiting for running | service mode 等待运行 |
| Online Job is running | service mode 模式运行中 |
| Online Job is failed | service mode 模式执行失败 |
| Online Job is succeed | service mode 模式运行成功 |
| Online Job is cancelled by fuxi | service mode 模式作业被取消 |
| Task key-path executing finished | 作业关键路径完成，但是detailstatus 等尚未完成 |
| Task key-path is finished | Task关键路径完成 |
| Instance key-path is finished | Instance 关键路径完成 |
| Task execution is finished | task处理完成，生成detailStatus |
| Instance execution is finished | 作业处理完成 |
| Execution failed | 作业执行失败 |
五、使用logview分析作业
5.1 分析运行出错作业
作业运行失败时，通过logview 查看result 可以查看出错信息，对于失败的作业，打开logview 默认会跳转到result tab。常见失败包括:
(1) sql 语法错误，此时不会有DAG 和fuxi jobs，因为还没有提交到计算集群执行
(2) 用户udf 出错，调查步骤result -》 DAG 确定出问题的udf -》 查看stdout/stderror等
(3) 除明确提示的错误，其他问题多数需要找MaxCompute 值班同学排查。
5.2 分析运行慢作业
5.2.1 编译阶段
首先，查看作业排队情况， 如果queue > 0 ，说明等待资源，排队中，一般除了增加计算资源，只能找出占用大户，评估是否可以kill 掉，让出资源。
其次，就算作业运行起来了， queue = 0， 可能还会存在等计算资源情况， 比如高优先级作业抢占， 此时表现是subStatus 为OfflineJob is Running 或OfflineJob waiting for run，查看fuxi instance 状态，有大量waiting 或ready 状态。
对于结束后的作业如何分析当时是否等资源可以通过latency chart ，理想的latency chart， 底部应该是一条直线，说明作业同时启动了，如果是条斜线说明存在等资源情况。
5.2.2 运行阶段
后面就是运行中慢了，可能有几种情况数据倾斜，数据膨胀，UDF执行效率低，作业发生重跑。
数据倾斜
【特征】task 中大多数 instance 都已经结束了，但是有某几个 instance 却迟迟不结束（长尾）。如下图中大多数（358个）instance 都结束了，但是还有 18 个的状态是 Running，这些 instance 运行的慢，可能是因为处理的数据多，也可能是这些instance 处理特定数据慢。
解决方法：根据业务数据实际情况打散热点key，具体参见 https://help.aliyun.com/document_detail/102614.html?spm=a2c4g.11186623.3.3.462c66604eqnSi
数据膨胀
【特征】task 的输出数据量比输入数据量大很多。
比如 1G 的数据经过处理，变成了 1T，在一个 instance 下处理 1T 的数据，运行效率肯定会大大降低。输入输出数据量体现在 Task 的 I/O Record 和 I/O Bytes 这两项：
解决思路:
(1) 检查代码是否有 bug：
JOIN 条件是不是写错了，变成笛卡尔积了；
UDTF 是不是有问题，输出了太多数据。
(2) 避免join引起的数据膨胀。
比如：两个表 join，左表是人口数据，数据量很大，但是由于并行度足够，效率可观。右表是个维表，记录每种性别对应的一些信息（比如每种性别可能的坏毛病），虽然只有两种性别，但是每种都包含数百行。那么如果直接按照性别来 join，可能会让左表膨胀数百倍。要解决这个问题，可以考虑先将右表的行做聚合，变成两行数据，这样 join 的结果就不会膨胀了
UDF执行效率低
【特征】某个 task 执行效率低，且该 task 中有用户自定义的扩展。甚至是 UDF 的执行超时报错：“Fuxi job failed - WorkerRestart errCode:252,errMsg:kInstanceMonitorTimeout, usually caused by bad udf performance”。
首先确定udf位置，点看慢的fuxi task， 可以看到operator graph 中是否包含udf，例如下图说明有java 的udf
通过查看logview 中fuxi instance 的stdout 可以查看该operator 运行速度，正常情况 Speed(records/s) 在百万或者十万级别。
解决方法：
(1) 检查 UDF 是否有 bug。
(2) 使用内置函数替换自定义udf，内置函数一般效率更高。
(3) 将 UDF 函数进行功能拆分，部分用内置函数替换。函数无法实现的再用 UDF。
(4) 优化 UDF 的 evaluate 方法，将重复计算提取到初始化中。
作业重跑
有的MaxCompute 作业打开了service mode 功能，默认会优先使用service mode 模式，可以在project 级别设置
（"odps.service.mode.enable.odps2": "true"），如果service mode 失败，比如instance 个数超过1000，或者运行超过10分钟，就会退回以Offline模式重跑。
5.2.3 结束阶段
有时会发现fuxi task 都已经运行结束但是作业依然没有结束情况，此时可能是合并小文件或动态分区元数据更新。
大小低于64MB的文件被认为是小文件，过多的小文件既会影响存储效率，也会降低计算速度，为了避免系统产生过多小文件，SQL 作业在结束时会针对一定条件自动触发合并小文件的操作，及Merge job。
解决方法：https://help.aliyun.com/document_detail/117430.html?spm=5176.11065259.1996646101.searchclickresult.67a35a8fsLWgmr
六、常见问题
1. 为什么我的作业没有显示DAG图？
a.例如grant，drop table 等语句不需要启动fuxi job ，因此就没有DAG图。
b.algoTask 类型作业默认不展示DAG图。
c.语法错误情况，由于尚未启动fuxi job ，也没有DAG图。
2. 为什么DAG 图双击不能看operator 图？
a.只有SQL，SQLRT 类型作业支持查看Operator 图。
b.logview 依赖执行计划画图，如果获取执行计划失败，logview 依然可以用fuxi task 名字画DAG图，此时需要联系MaxCompute 值班同学调查。
3. DataWorks，MaxCompute 优先级问题？
MaxCompute 作业优先级与DataWorks 优先级相反， 9 - DataWorks = MaxCompute instance 优先级，logview 显示的是MaxCompute 优先级（1～8）， 数字越低优先级越高。
4. fuxi task instance 个数变来变去怎么回事？
fuxi instance 个数默认不需要配置，可以通过输入数据多少自动设置。HBO 可以动态修改instance个数，如果sql 有改动会导致hbo失效，此时instance个数就会发生变化，等运行一段时间hbo重新生效就会正常。
Map数根据splitsize 默认256M
Reduce 跟表的bucket ，上游的map数共同决定。
hbo 会动态调整worker 个数，可以运行中调整，比如发现多了，可以自动调小。
5.fuxi instance 的时间为啥不是fuxi task 的开始时间，主要是花费什么时间？
如果计算资源不够，fuxi instance 就会等待，此时就会发上fuxi instance 的开始时间晚于task 开始时间
6.查看stdout /stderror 报错文件找不到，提示被回收
由于stdout /stderror 是保存在MaxCompute 运行作业的临时目录中，时间一长就会被回收，回收快慢取决于所在集群繁忙程度，一般一天内是能看到，如果回收过快可以找MaxCompute 值班同学协调排查。
7.Fuxi task 种类？
fuxi task 包括M，R， J， C，C是condition map join ，会在运行时动态决定使用哪种join算法。
七、参考文档
1.SQL 调优 https://help.aliyun.com/document_detail/102614.html?spm=a2c4g.11186623.3.3.462c66604eqnSi
2.Join 长尾优化 https://help.aliyun.com/document_detail/143996.html?spm=a2c4g.11186623.6.1089.60f23de8zeVxHA
3.其他计算长尾优化 https://help.aliyun.com/document_detail/51020.html?spm=a2c4g.11186623.6.1090.48c61a61RDoLNZ