开发者学堂课程【SaaS 模式云数据仓库系列课程 —— 2021数仓必修课：MaxCompute Logview2.0 参数详解及常见问题】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/55/detail/1045
MaxCompute Logview2.0 参数详解及常见问题
内容简介：
一、MaxCompute 作业基本概念
二、Logview 的生成过程
三、Logview 原理
四、Logview 1.0 VS 2.0
五、使用 Logview 分析作业
六、常见问题
七、参考文档
一、MaxCompute 作业基本概念
MaxCompute 有很多专业术语，logview 中内容直接沿用了这些术语，为了便于理解logview ，首先需要理解相关概念。
控制集群∶
· Job/Instance/MaxCompute Instance ∶代表用户提交的作业，每个作业具有instanceld 进行唯一标示。
·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∶ uxi task 内部的算子，例如 TableScan，TableSink，是数据处理的逻辑。
二、Logview 的生成过程
Logview 是用于查看 MaxCompute 作业的工具，可以展示作业实际执行的每一处细节。
当作业运行出错，运行变慢等都需要通过 logview 进行定位。
LogviewURL 结构∶
logview 域名+MaxCompute endpoint+project+ instanceld+ token+other parameters，
例如∶https∶//logview.aliyun.com/logview/?
h=http://service.cn.maxcompute.aliyun.com/api&p=huadong_1_test&i=20201103031620528 g3e7n4pr2&token=eEdUUEI0SWh3ZUFVS043SitFT21PUm5mQ3RvPSxPRFBTX09CTzoxNzY 3OTc2MDA5NDY4MDcxLDE2MDY5NjUzODAseyJTdGF0ZW1IbnQiOIt7IkFjdGIvbil6WyJvZHBz OlJIYWQiXSwiRWZmZWNOljoiQWxsb3ciLCJSZXNvdXJjZS6WyJhY3M6b2RwczoqOnByb2pIY 3RzL2h1YWRvbmdfMV90ZXNOL2luc3RhbmNIcy8yMDIwMTEwMzAzMTYyMDUyOGczZTduNH ByMiJdfVOsIIZIcnNpb24iOilxIn0=
有效期∶和logview 1.0一样，2.0 也有有效期，一般是30天。
三、Logview 原理
Logview 跟常规 web 应用一样，由前后端组成，前端渲染页面，后端汇总MaxCompute 各种运行息。
Logview 1.0 原理非常简单，就是一个页面展示+代理，所有页面展示的内容都是调用 MaxComput 的 restful api 实现，2.0 实现稍微复杂些，数据源更加丰富,支持一些定制化任务展示。
四、Logview 1.0 VS 2.0
logview 2.0 相比于 1.0 重新升级页面风格，简化作业查看流程，提供1.0 原有数据前提下，增强了DAG 展示、作业回放等功能。
（3）substatusHistory详解
Waiting for scheduling 作业已提交，等待 MaxCompute 框架调度，一般很短
Waiting for cluster resource框架发现fuxi 计算集群没资源,直接等
Waiting for concurrent task slotproject级别流控，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明确知道交给子进程，如果子进程出问题才会时间长。
五、使用 Logview 分析作业
5.1分析运行出错作业
作业运行失败时，通过 logview 查看 result 可以查看出错信息，对于失败的作业，打开 logview 默认会跳转到 result tab。
常见失败包括∶
● sql 语法错误，此时不会有 DAG 和 fuxi jobs ，因为还没有提交到计算集群执行
● 用户 udf 出错，调查步骤 result -》DAG 确定出问题的udf-》查看stdout/stderror等
● 除明确提示的错误，其他问题多数需要找 MaxCompute 值班同学排查。
5.2分析运行慢作业
编译阶段
首先，查看作业排队情况， 如果 queue>0，说明等待资源，排队中，一般除了增加计算资源，只能找出占用大户，评估是否可以kill 掉，让出资源。
其次，就算作业运行起来了，queue = 0，可能还会存在等计算资源情况，比如高优先级作业抢占，此时表现是subStatus 为OfflineJob is Running 或 OfflineJob waiting for run ,查看 fuxi instance状态，有大量 waiting 或ready 状态。
对于结束后的作业如何分析当时是否等资源可以通过 latency chart ，理想的latency chart ，底部应该是一条直线，说明作业同时启动了，如果是条斜线说明存在等资源情况。
运行阶段
后面就是运行中慢了， 可能有几种情况数据倾斜，数据膨胀。UDF执行效率低。作业发生重跑。
数据倾斜
【特征】task 中大多数 instance 都已经结束了，但是有某几个 instance 却迟迟不结束（长尾）。如下图中大多数（358个）instance 都结束了，但是还有 18 个的状态是 Running，这些 instance 运行的慢，可能是因为处理的数据多，也可能是这些 instance 处理特定数据慢。
解决方法∶
根据业务数据实际情况打散热点key，具体参见
https://help.aliyun.com/document_detail/102614.html?spm=a2c4g.11186623.3.3.462c66604egnSi
数据膨胀
【特征】task 的输出数据量比输入数据量大很多。
比如 1G 的数据经过处理，变成了 1T，在一个 instance 下处理 1T 的数据，运行效率肯定会大大降低。输入输出数据量体现在 Task 的I/O Record 和I/O Bvtes 这两项∶
解决思路∶
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 模式重跑。
结束阶段
有时会发现 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 个数，如果 sgl 有改动会导致 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.462c66604egnSi
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
