学习工具
通过MaxCompute官方文档和DataWorks官方文档了解相关产品的最新功能和使用方式
MaxCompute官方文档：MaxCompute官方文档
DataWorks官方文档：DataWorks官方文档
一、logview排查作业
在日常的开发过程中我们偶尔会发现某些任务突然耗时比较长，或者某些任务突然挂掉需要排查原因。Logview将用来协助我们完成这件事情。
Logview是MaxCompute Job提交后查看和Debug任务的工具。通过Logview可看到一个Job的运行状态、运行结果以及运行细节和每个步骤的进度。当Job提交到MaxCompute后，会生成Logview的链接，用户可以直接在浏览器上打开Logview链接，进入查看Job的信息，而对于Logview上的诸多参数信息，究竟应该怎么发现问题所在呢？又如何通过Logview了解每个instance、task运行状态及资源占用情况，如何分析执行计划，分析query存在问题。下面主要介绍如何去使用Logview。
1、Logview参数详解
主要的信息包括ODPS Instance，其涵盖了队列信息以及子状态信息，另外一部分包括Fuxi Job，这可以进一步拆解成Task信息和Fuxi Instance信息。在整个任务结束之后可以看到其Summary以及Diagnosis诊断信息，此外还有上传下载的小功能。
（1）ODPS Instance信息
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详细信息。
（2）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以及其对应含义。
（3）ODPS Task信息
ODPS Task信息，上面的表格的第一个字段是TaskName，Type指的是作业类型，Status指的是运行状态，双击Rusult会输出作业的整个结果集，双击Detail信息则会打开整个Fuxi Job的详细Table。
（4）Fuxi Job Detail信息
Fuxi Job详细信息主要分为三个部分，最左侧是任务的执行计划，这个执行计划是在Executor里面生成的，执行计划就是将一个任务分成不同的Stage来执行，每个Stage的都可以看做一个图上的点，而Stage之间的依赖关系就可以看做图的边，这样就构成一个有向无环图。
（5）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的运行状态。
（6）Fuxi Instance Detail信息
Fuxi Instance是整个作业流中最小的颗粒，其左侧的Terminated、Running、Ready以及Failed分别是相应状态的实例个数。而SmartFilter则会给出最早结束、最晚结束、运行时间最短和运行时间最长的四个Instance，将其筛选处理方便观察。Latency Chart则是以图表的形式展示所有的Instance的运行时长分布，而在Latency里面则是最长运行时间和最短运行时间以及平均运行时长，其实这三个时间对于分析长尾任务是非常有用的。在每个Instance的表格里面详细信息里面有一个StdOut，这是每个Instance在执行过程中打印的信息，而StuErr则是当Instance失败的时候可以用来查看出错原因的。
（7）Fuxi Job Detail信息 之 Summary信息
FuxiJob的Summary是在整个Job运行完之后才能查看的信息，主要包括Job消耗的CPU、内存、Job输入的表名以及记录数和字节数。此外，Job的运行时间单位是秒。Fuxi Task的Summary信息则主要包括Instance数量、Task运行时间、所有Instance里面的最大、最小和平均运行时间。
2、Logview排查问题

（1）任务出错
对于出错任务而言，从控制台输出就可以看到出错的原因，如果想要查看更加详细的信息，则可以打开Logview去查看ODPS的Result信息，如果失败了可以看到Status变成红色了。当双击Result之后就可以看到报错输出的整体信息。在出错信息里面会有错误码，而错误码与详细错误的对照表可以在官网找到。所以查看出错任务的方式有两种，一种是在作业结束之后查看其Result信息，另外一种方式则是去查看Instance的StdErr信息。
**（2）慢作业诊断
a、作业排队**
对于慢任务诊断而言，可能看到一种现象就是作业一直在排队或者在控制台看到Fuxi Job一直在Waiting。进一步在Logview里面查看，发现Status到底是Waiting还是Waiting List，这样就可以发现其到底在哪里排队，如果状态是Waiting List则可以进一步地看其详细队列长度到底是多少，排到了第几位。还可以在SubStatus里面看到其子状态的信息。
对于慢任务而言，如果不能够知道到底是哪一个作业是慢任务，可以采取两种方法：一种是“show p”，可以查看所有示例信息；而“top instance”可以查看当前正在执行的作业，而运行时间最长的作业可能就是阻塞队列导致其他任务排队的任务。对于由于资源抢占所导致的问题，可以做如下的优化：
• 对于后付费用户而言，可以根据作业特性把相对稳定的周期性常规任务放到预付费资源组去执行，可以保证资源不被抢占。
• 对于预付费用户而言，如果并行执行多个作业，最好合理安排作业执行时间，让作业错峰执行，临时任务则建议在后付费资源组执行。
b、大量小文件
大量小文件的存在也会导致任务执行很慢，比如在作业开始执行的时候，执行计划图中当Reduce的Task执行之后，发现系统自动增加一个MergeTask，这就是因为系统在做合并小文件的操作。
其实，分布式文件系统的数据文件是按照块来存储的，盘古的块大小就是64M，所以如果文件小于64M就可以称为小文件。小文件的产生主要有这样的3种原因：(1)当Reduce计算过程中会产生大量小文件;(2)Tunnel数据采集过程中会生成小文件;(2)Job执行过程中生成的各种临时文件、回收站保留的过期文件等。而因为小文件过多，就会导致在Map阶段读取的数据出现分布不均匀的情况，进而引起长尾。如果存在大量的小文件，除了会浪费资源并降低磁盘空间利用率之外，还会影响整体的执行性能，因此从存储和性能两方面考虑都需要将计算过程中的小文件都合并。其实MaxCompute系统已经做了很多的优化，系统会自动分配一个Fuxi的MergeTask来做小文件的合并，但是其实还有很多情况下产生的小文件没有被合并。因此，MaxCompute提供了一些参数帮助用户进行小文件的合并。
c、合并小文件
首先可以查看小文件的数量，也就是判断自己的表里面是否存在很多小文件。可以用“desc extended TableName”命令就可以输出小文件数量。如果小文件数量很多就可以通过如图中下面的SQL来整合小文件。
ALTER TABLE tablename [PARTITION] MERGE SMALLFILES;
d、如何避免小文件产生
为了避免小文件的操作，可以给出一些相关建议。比如在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信息里面专门有一项是检查数据倾斜和长尾的，所以通过系统所给出的信息就能够查看出是否出现了长尾还是数据倾斜，也同时给出了一些改进意见。
二、MaxCompute CU管家
MaxCompute管家为系统运维人员提供作业、存储资源查询、配额组设置等功能。使用MaxCompute管家前，您需要购买MaxCompute包年包月CU资源。
1、进入MaxCompute管家
执行如下步骤进入MaxCompute管家。
（1）登录DataWorks控制台。
（2）单击左侧导航栏计算引擎列表 > MaxCompute，进入 计算引擎列表-MaxCompute页面，并选择您所在的Region。
（3）单击包年包月区域的CU管理，进入MaxCompute管家页面。

2、概览
概览页面可以按照不同的配额组和时间段查看当前使用CU、总CU、当前存储量、CU资源使用趋势、存储使用趋势。
配额组：指定需要查看的配额组信息。默认为空，表示查看全部配额组。您可以在配额组后选择需要查询的时间段，默认为最近24小时。
当前使用CU：指定配额组下全部的项目在搜索截止时刻的CU资源使用量。
总CU：配额组为空时（即选择所有配额组）：总CU=（搜索截止时刻的订单预留CU）+（搜索截止时刻的订单非预留CU）。
配额组非空时（即指定单个配额组）：总CU=（搜索截止时刻的指定配额组预留CU最大配额）+（搜索截止时刻的指定配额组非预留CU最大配额）。
当前存储量：指定配额组下全部的项目在搜索截止时刻的存储使用量。
申请CU趋势：指定配额组下的全部项目在搜索时段内作业计划申请的CU资源量（包括预留CU资源和非预留CU资源）。
已用CU趋势：指定配额组下的全部项目在搜索时段内作业实际使用的CU资源量（包括预留CU资源和非预留CU资源）。
总CU趋势：指定配额组在搜索时间段内总CU资源的使用量（包括预留CU资源和非预留CU资源）。
存储大小趋势：指定配额组下的全部项目在搜索时间段内存储使用量。
3、查看作业运行情况
作业运行情况每2分钟采集一次。
（1）单击左侧导航栏上的作业，进入作业快照页面。
（2）选择需要查询的配额组以及时间段，查看选择时间段内当前配额组下所有作业情况。支持查看历史作业快照。
（3）在概览页面，单击CU资源使用趋势图上的任意一点可跳转至该时刻下指定配额组对应全部项目内的作业历史快照。
（4）终止作业，对于没有必要继续运行的作业，主账号可以单个或批量终止提交的作业。批量终止作业时，一次不能超过10个。在包年包月作业列表页面，单击作业列表上方的终止作业，在终止作业页面，输入将要终止作业对应instance Id列表和备注信息。
4、查看作业快照操作记录
MaxCompute管家支持查看作业快照操作的记录，目前最多保存7天的操作记录。单击左侧导航栏作业。单击作业快照操作记录页签，查看作业快照操作记录。
5、查看存储资源消耗
您可以通过包年包月项目列表页面，了解存储的消耗情况。 存储量每1个小时采集一次。
（1）单击左侧导航栏上的项目，进入包年包月项目列表页面，列表中会显示项目的已用存储量。您也可以通过右上角的筛选器筛选配额组查看存储量。

（2）单击指定项目名称，查看项目某段时间的存储水位。

（3）选择查看的时间段。单击时间下拉框，选择开始时间和结束时间后，单击OK。
6、查看CU资源消耗
您可以通过包年包月配额组列表页面，查看CU资源消耗。 计算资源CU每2分钟采集1次。
（1）单击左侧导航栏上的配额，进入包年包月配额组列表页面。

（2）单击指定的资源组名称，查看资源消耗情况。

（3）选择查看的时间段。单击时间下拉框，选择开始时间和结束时间后，单击OK。
7、配额组设置
您可以在包年包月配额组列表页面，进行相关配额组设置，例如，新建配额组、修改和删除配额组。
8、修改项目配额组
支持将项目当前指定的配额组修改为其它配额组，新建的配额组即可通过该功能进行资源隔离。
（1）单击项目，进入包年包月项目列表页面。
（2）选择需要修改配额组的项目名称，单击其后的修改，进入修改配额组信息页面。
（3）在Quota名称的下拉框中，选择配额组。

（4）单击执行，完成修改。
9、注意事项
CU过小无法发挥计算资源及管家的优势。
如果禁用主账号的AccessKey，会导致相应的子账号无法使用MaxCompute管家。
三、数据备份和恢复
日常开发过程中会存在误删表数据这个时候应该怎么去恢复呢？MaxCompute提供数据备份与恢复功能（目前处于公测阶段），系统会自动备份数据的历史版本（例如被删除或修改前的数据）并保留一定时间，您可以对保留周期内的数据进行快速恢复，避免因误操作丢失数据。
1、数据备份相关命令
查看所有表的备份数据：show history for tables;
查看指定表的备份数据：show history for table ;
查看已删除表的备份数据：show history for table table_name ('id'='xxxx');
查看分区表的备份数据：show history for table table_name ('id'='xxxx');
查看分区的备份数据：show history for table table_name partition_spec;或show history for table table_name PARTITION('id'='xxxx');
2、数据恢复相关命令
恢复已删除的表：restore table table_name ('id'='xxxxx'); 如果存在同名的表，您需要将同名的表重命名后才能执行恢复操作。
恢复表至指定版本：restore table table_name to LSN 'xxxx';
恢复表至指定版本，并命名为新表或将数据更新到不同名的表中：restore table table_name to LSN 'xxxx' as new_table_name;
恢复分区表：restore table table_name ('id'='xxxxx');
恢复分区：restore table table_name PARTITION('id'='xxxx')[PARTITION('id'='xxxx')];
恢复分区至指定版本，并命名为新表：restore table table_name partition_spec1[partition_spec2 ]to LSN 'xxxx' as new_table_name;
**四、类型转换
1、支持的数据类型**
当前Maxompute一共支持3个数据类型版本。1.0数据类型版本、2.0数据类型版本和Hive兼容数据类型。
MaxCompute设置数据类型版本属性的参数共有3个：
odps.sql.type.system.odps2：MaxCompute 2.0数据类型版本的开关，属性值为True或False。
odps.sql.decimal.odps2：MaxCompute 2.0的Decimal数据类型的开关，属性值为True或False。
odps.sql.hive.compatible：MaxCompute Hive兼容模式（即部分数据类型和SQL行为兼容Hive）数据类型版本的开关，属性值为True或False。
在新增项目时MaxCompute可以对3个版本的数据类型进行选择。
当我们开启2.0数据类型版本需要注意以下问题：
• 部分隐式类型转换会被禁用。例如，STRING->BIGINT、STRING->DATETIME、DOUBLE->BIGINT、DECIMAL->DOUBLE、DECIMAL->BIGINT有精度损失或者报错的风险。禁用类型可以通过CAST函数强制进行数据类型转换。
• VARCHAR类型常量可以通过隐式转换为STRING常量。
2、谨慎修改类型flag
根据以往客户经验，有客户任务每天都是正常执行的。突然某一天凌晨任务失败，导致依赖作业都在等待。排查发现是有账号需改了数据类型的flag，导致部分数据类型转换失败任务报错。所以在日常的开发过程中需要谨慎设置数据类型的fla。以免造成任务报错。
五、权限控制
日常开发中MaxCompute的项目空间所有者（Project Owner）或安全管理员需要对项目空间进行日常安全运维和数据安全保障，如何去合理的控制权限是一个非常关键的环节。
权限控制包括MaxCompute安全模型，DataWorks的安全模型。当通过DataWorks使用MaxCompute，而DataWorks的安全模型不满足业务安全需求时，需要合理地将两个安全模型结合使用。
1、MaxCompute和DataWorks权限关系
通过MaxCompute的安全模型进行权限控制，并不会影响成员在DataWorks界面上的操作。但是通过DataWorks的用户角色分配，则有可能影响成员的MaxCompute资源权限。
可以参考这个文档：
https://help.aliyun.com/document_detail/105012.html?spm=a2c4g.11186623.6.913.3a7c713fH2gG3k
2、MaxCompute管理员Admin
一个企业使用多款阿里云产品，MaxCompute是其中一个产品，用的是同个主账号，主账号不是由使用MaxCompute的大数据同学管理，大数据同学使用的是子账号。大数据同学日常需要给MaxCompute项目 操作新增子账号（add user），新的子账号授权（grant xx on project/table）等操作，即日常权限管理。
但是MaxCompute项目权限管理默认只有owner可以操作，而MaxCompute项目的owner只能是主账号。当我们使用子账号开通MaxCompute并创建项目，项目的owner依然是对应的主账号。DataWorks中，子账号拥有项目空间的“项目管理员”或“安全管理员”角色，都只是拥有对应DataWorks的操作权限，并不能操作MaxCompute 项目的权限管理。所以需要指定一个子账号作为大数据MaxCompute的权限管理账号，让主账号给该子账号授admin role
--如主账号是bob@aliyun.com，作为日常权限管理的子账号是Allen
grant admin TO ram$bob@aliyun.com:Allen;
注意：
admin可以满足常用的一些日常权限管理，但并不能代替owner做所有管理，此时还是必须要owner才能进行操作。
3、MaxCompute超级管理员
主账号不是大数据团队管理，使用MaxCompute员工都只持有子账号，而project的owner只能为主账号，但是很多MaxCompute的权限管理还需要owner才可以操作（如项目级别的flag设置，package跨项目资源共享配置等），因此非常需要一个子账号拥有超级管理员权限。
（1）关于super_administrator role
Super_Administrator role：MaxCompute内置的管理角色，拥有操作项目内所有类型资源的权限和管理类权限，具体权限请参考文档管理角色。
该角色可由project owner指派给子账号，子账号获得该角色后，即可代替owner对该project在进行数据开发过程中所需的各种管理操作，包括常用的项目级别的flag设置以及所有权限管理操作。
（2）指派子账号为超级管理员
前提建议：
• 可以将有权限创建project的子账号指派为super_administrator role，这样该账号既可以很好的管理DataWorks项目的同时管理对应的Max Compute project。
如何授权子账号可创建project可参考子账号创建project子账号创建project
• 建一个project只能指派一个子账号为super_administrator role，其他需要有基本的权限管理可以指派admin role
• 需要注意明确该子账号持有人的职责，建议一个子账号对应一个开发者，避免账号共用，以便能更好的保障数据安全。
确认好具体哪个子账号可以用户超级管理员（同时该子账号可以创建项目空间），子账号创建好project，此时projec的owner依然是主账号，主账号可以通过以下方式将super_administrator role 授权给该子账号。
• 通过MaxCompute客户端授权：
假设主账号用户bob@aliyun.com是项目空间project_a的Owner，Allen是bob@aliyun.com中的RAM子账号。
打开项目空间project_a。
use project_a;
为项目空间project_a添加RAM子账号Allen。
add user ram$bob@aliyun.com:Allen;
为子账号Allen授权Super_Administrator角色权限。
grant super_administrator TO ram$bob@aliyun.com:Allen;
为子账号Allen授权Admin角色权限。
grant admin TO ram$bob@aliyun.com:Allen;
• 通过DataWorks授权：
a、 登录DataWorks，进入工作空间配置页面。
b、添加子账号为项目空间成员(已经添加过可忽略)。
1) 单击左侧导航栏上的成员管理，进入成员管理页面。
2) 单击右上角的添加成员。
3) 在添加成员页面，从待添加账号列表中选择需要添加的组织成员显示在已添加账号列表中。
4) 勾选角色并单击确定。
c、 为子账号授权Super_Administrator角色。
1) 单击左侧导航栏MaxCompute高级配置。
2) 单击左侧导航栏自定义用户角色。
3) 单击需要授权角色后的成员管理，从待添加账号列表中选择需要添加的组织成员显示在已添加账号列表中。
20/jpeg/36371/1580893560423-d5235e7c-b42f-4809-805b-faa68d5c9d08.jpeg)
单击确定，完成账号授权。
• 子账号查看自身的权限：
cmd中执行 show grants;,如果有Super_Administrator 这个role，说明已经赋权成功。
（3）成员、权限管理
拥有super_administrator 角色的子账号本身已经拥有所有project资源的查询和操作权限，所以无须再给自身授权。以下给出针对其他成员和成员权限管理的建议。
成员管理
•MaxComopute 支持云账号和RAM子账号（子账号只能为Project owner的子账号），为了更好的保障数据安全，建议project中添加的user均为owner主账号的RAM子账号。主账号可控制子账号，如人员转岗离职等，主账号可以注销或更新对应的子账号。
若通过DataWorks进行项目成员管理，只能添加owner的RAM子账号。
• RAM子账号只能通过主账号添加（这个不是MaxCompute可以改变的事实），所以对于某project 成员即使拥有super_administrator 角色的超级管理员，也只能先需要主账号先创建好其他子账号才可以将其他子账号添加到project中。
• 建议只添加需要在当前project进行数据开发（即会在当前project执行job）的user，对于有数据交互业务需求的user，建议通过package方式进行跨project资源共享，避免把user添加到project增加成员管理的复杂度。
• 员工转岗或离职，先把对应子账号在project里remove掉，然后再通知owner注销子账号。如果是拥有super_administrator 角色的子账号持有者转岗或离职，则需要由主账号进行remove以及注销账号。
权限管理
• 建议通过角色进行权限管理，即权限和role关联，role和user关联。
• 建议实施最小够用原则，避免权限过大造成安全隐患。
• 跨project使用数据时，建议通过package方式实现，避免资源提供方增加成员管理成本，只需要管理package。
权限审计
可以通过MaxCompute的元数据服务Information_Schema服务提供的相关视图进行权限审计。
4、跨项目访问资源和函数
这篇文章通过3种方式介绍跨项目访问函数和资源，可以参考使用：
https://developer.aliyun.com/article/741262?groupCode=maxcompute
5、如何仅给某个子账号所有表的select权限
（1）在项目工作空间中创建一个自定义角色
create role select_only_role;
（2）为自定义角色select_only_role对项目内所有表（包括未来项目内新建的表）赋予Describe,Select权限
项目下的所有表：
GRANT SELECT ON table * TO Role select_only_role privilegeproperties("policy" = "true");
（3）给用户赋予自定义角色权限(也可以在Dataworks的自定义角色web-ui界面里，添加某个成员到该自定义角色下)
grant role select_only_role to RAM$account@company_name.com:ram_account;
六、DataWorks任务未按时调度运行

被提交发布至生产环境的任务，会按照调度周期来产生实例。通常来讲，实例的状态有：未运行、等待时间、等待资源、运行中、运行失败、运行成功。定时时间到了，但是实例的状态还是「未运行」，此时需要检查上游节点的运行情况。只有上游节点全部运行成功，该节点才会开始调度。
1、如何处理DataWorks任务未按时调度运行，运行日志中显示槽位等待、正在等待在云端的gateway资源等信息的情况？
DataWorks免费为您提供了一定的任务调度能力，但如果达到一定的任务并发量，则需要等待运行中的任务结束后，才可以继续运行等待中的任务。在满足业务诉求的前提下，建议您合理安排任务错峰运行，以便在各个时间段，充分利用已购买的计算资源。 如果需要获得更高任务并发调度能力，可以购买独享资源组。
2、运行诊断
同时运维中心新推出「运行诊断」的功能，针对实例各个环节可能出现的问题，为您提供全链路的诊断和建议。定时时间到了还不运行？任务一直在等资源？运行失败但是日志看不懂？这些问题通通帮您解决。
运行诊断功能的介绍文档链接： https://help.aliyun.com/document_detail/158815.html
七、数据同步任务出现脏数据怎么办？

1、产生脏数据的可能场景
同步任务在任务运行过程中遇到插件的所有异常都会作为脏数据进行统计。
• 数据类型转换（源端表和目的表字段类型不匹配，大概率）
• 源端表数据过长
• 数据源异常
• Reader/Writer插件异常
• 数据中有表情符
2、解决方案
（1）增大脏数据限制条数，扩大阈值，容忍脏数据（源端脏数据仍存在，不同步到目的端，日志会显示脏数据记录，任务不会报错）。
（2）根据运行日志定位源端脏数据。日志中会显示具体是哪个列有问题，同时会有列数据信息，根据日志去修复后再同步。
（3）当同步任务脏数据报错 XXXX command denied to user ‘XXXX’
这类报错是因为没有数据源权限造成的问题，联系对应DBA申请一下update、insert、delete权限。
（4）当我们的数据源有带表情的数据做同步时，需要注意只有utf8mb4编码支持同步表情符。
例如：添加JDBC格式的数据源时，需要修改utf8mb4的设置，如jdbc:mysql://xxx.x.x.x:3306/database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45。
八、如何排查周期任务取不到数据(产出数据为空)的问题？
首先我们需要知道节点依赖和业务逻辑之间是什么关系，其实任务依赖关系（调度关系）和业务逻辑并没有确切性的关联，业务依赖（即抽数/写数表之间的逻辑）并不等于任务依赖之间的关系。
举个栗子：A任务产出A表，B任务产出B表，A、B同级，C任务依赖A、B的表数据产出C表，但是任务依赖关系上C可以不依赖A而只依赖B,这样C任务仍然能够取得符合业务逻辑的数据并对表C进行写入数据。
1、几种容易取不到源表数据的情况
（1）分区&参数的影响：
比如说我有A、B两个小时任务。
A任务业务逻辑样例：
create table if not exists A（id bigint,name string）partitioned by(dt string,hh string);
insert overwrite table A partition(dt='${bidate}',hh='${hh}') select * from S where
dt='${bizdate}'；
其中S表为初始数据表（即底表）;
B表的业务逻辑样例：
create table if not exists B（id bigint,name string）partitioned by(dt string,hh string);
insert overwrite table B partition (dt='${bidate}',hh='${hh}') select * from A where
dt='${bizdate}' and hh='${hh}'；
当A任务的参数中hh这个参数前推了一个小时，实际hh值变成了hh='$[hh24-1],而B任务的hh参数不变，hh='$[hh24]'这种形式，那么一定会找不到A表对应的分区而导致inputs数据为空，从而B表没有写入数据.
（2）没有严格的依赖关系而直接取源表的某一个还没有产出数据的分区导致没有数据：
比如说，A、B两个小时表作为C表的数据来源端，但是C并没有严格依赖A、B两个任务（即C任务没有依赖A、B只在业务上对A、B取数）。当A表任务产出ds='20200421',hh='10'的这个二级分区的时间是 10点30分，而C任务执行并取A表的ds='20200421',hh='10'这个分区的时间是10点10分，那么，就会导致C任务执行时取不到具体的A表对应分区数据而输入为空。
（3）sql逻辑问题导致输入为空
在A、B做join关联后并将数据写入到C表，不符合sql逻辑的条件筛选，没有select出符合条件的数据.
九、数据源连通性测试失败怎么办？
测试数据源连通性失败，是大家在使用数据集成时经常会遇到的问题。排除某些时候粗心大意填错配置信息外，很多时候大家发现都配置对了，但为什么还不通？此时怎么知道问题出在什么地方了呢？
1、测试原理
数据集成由管控服务和执行集群两部分组成，数据源连通性测试由管控服务发起，而同步任务实际运行在执行集群，由于二者部署在不同服务器，所以可能存在数据源连通性测试成功但同步任务执行失败，或者数据源连通性测试失败但同步任务执行成功等情况。
2、可能的原因
对于用户添加的数据源，不能连通具体原因可能有：
• 网络不可达
• 数据源应用层权限控制
• 白名单、应用层acl限制等
至于后两者，是没有办法来推断的，但是判断物理网络通与不通非常关键，如果网络是通的，但是权限受控，就直接找对应的数据源管理员协调就好了。
3、网络通路排查
借助FTP/SFTP数据源辅助验证数据源网络是否可达。操作方法：
（1）添加ftp数据源，设置ip、port为待测试数据源的相关信息
（2）协议Protocol类型选择SFTP
（3）用户名、密码任意填写
（4）点击【测试连通性】

十、员工离职，任务如何去修改
如果有员工离职，运维人员应该在相关人员离职之前修改离职人员创建的任务节点、资源、表的Owner。同时注意检查生产环境MaxCompute访问者身份。
1、修改MaxCompute访问者身份需要注意事项

一般建议生产环境配置MaxCompute访问者身份为主账号。如果生产环境配置MaxCompute访问者身份为子账号那么离职员工离职前需要修改为其他员工账号或者主账号。
开发环境离职员工账号删除RAM账号之后，该账号创建的所有节点在开发环境冒烟测试、开发环境运维中心执行其名下任务会失败。需要在员工离职之前做好任务节点、资源、表的Owner。
（1）主账号需要转交任务，批量转交任务操作如下:
批量修改任务节点责任人
如果人员流动，需要将离职人员的任务批量修改责任人。可以去运维中心周期任务找到该责任人节点。选中节点之后修改责任人即可。

（2）修改表的Owner
MaxCompute SQL支持通过changeowner命令来修改表的拥有人（表Owner），相应的语法格式如下。
alter table table_name changeowner to 'ALIYUN$xxx@aliyun.com';
（3）修改资源权限
该账号可以访问的资源可以通过角色的形式授权给交接人相同的资源访问权限。
十一、Spark访问VPC
Spark on MaxCompute可以访问位于阿里云VPC内的实例（例如ECS、HBase、RDS）,默认MaxCompute底层网络和外网是隔离的，Spark on MaxCompute提供了一种方案通过配置spark.hadoop.odps.cupid.vpc.domain.list来访问阿里云的vpc网络环境的Hbase。Hbase标准版和增强版的配置不同，本文通过访问阿里云的标准版和增强版的Hbase简单的描述需要加的配置。
1、配置步骤如下
（1）需要添加spark.hadoop.odps.cupid.vpc.domain.list配置，该配置描述了需要访问的一个或多个实例的网络情况。配置值为json格式，注意，需要把json压缩成一行。以下给出了示例，把regionId, vpcId, 实例域名，端口等替换成真实值即可。
{"regionId":"cn-beijing", "vpcs":[{"zones":[{"urls":[{ "domain":"spark-oss.oss-cn-beijing-internal.aliyuncs.com", "port":80}] }]}]}
（2）在要访问的服务中添加ip白名单，允许100.104.0.0/16网段的访问
（3）如果region是cn-shanghai或者cn-beijing，需要设置spark.hadoop.odps.cupid.smartnat.enable=true
注意： 只能配置访问本Region下面某一个vpc的服务，不支持同时和多个vpc打通。必须要将配置压缩为一行，并且配置在spark-defaults.conf或dataworks的配置项中，而不能写在代码中！！！
十二、任务执行慢
调度任务执行缓慢首先我们可以找到周期任务执行的节点。然后查看任务运行的日志。
1、如何区分哪些是DataWorks资源延迟哪些是MaxCompute计算延迟呢？
日志中如果看到的是正在等待在云端的gateway资源那么可能是执行的任务达到一定的任务并发量，则需要等待运行中的任务结束后，才可以继续运行等待中的任务。在满足业务诉求的前提下，建议您合理安排任务错峰运行，以便在各个时间段，充分利用已购买的计算资源。同时可以购买独享资源组来保证高峰时间任务的正常运行。
如果看任务的日志是Job Queueing，那基本是等待计算资源了。
对于慢任务而言，如果不能够知道到底是哪一个作业是慢任务，可以采取两种方法：一种是“show p”，可以查看所有示例信息；而“top instance”可以查看当前正在执行的作业，而运行时间最长的作业可能就是阻塞队列导致其他任务排队的任务。对于由于资源抢占所导致的问题，可以做如下的优化：
• 对于后付费用户而言，可以根据作业特性把相对稳定的周期性常规任务放到预付费资源组去执行，可以保证资源不被抢占。
• 对于预付费用户而言，如果并行执行多个作业，最好合理安排作业执行时间，让作业错峰执行，临时任务则建议在后付费资源组执行。
如果按量付费用户需要转包年包月可以提交工单咨询。
2、按量付费转包年包月思路
先通过元数据统计下过去的job消耗情况。https://help.aliyun.com/document_detail/135433.html?spm=a2c4g.11186623.6.944.40527312UEAT6A#title-r2c-tak-zfi
大致思路：
（1）统计最近1个月所有需要转预付的Project每日cost_cpu消耗总和。表 information_schema.tasks_history，cost_cpu原始单位为core.s，需转换成CU.时（cost_cpu/100/3600）。找出正常消费中最高消费的那一天。
（2）对正常消费最高的那一天按小时分别统计所有任务CU时消耗。
（3）按业务划分时间段，取最高时间段进行分析。如业务是0-7点为业务高峰期划分为“ETL夜间高峰段”，其他的使用都很低则为一个时间段。
（4）汇总高峰期时间段CU时总量/时间，得出该时间段内需要的CU量。如：0-7点这8个小时，CU时为800，则需要100CU跑8个小时才能跑完800CU时的计算量。当然这个是最理想的状态，任务不都是很平均，所以需要根据情况设置一定的冗余。另外还有比较极端的情况， 比如有些任务有依赖关系到5点的时候才需要超大量的CU量，但是这个时候用100CU来跑即使跑3个小时也跑不完，所以这种情况就要结合业务需求，如果这个实在不能延迟时间，要么加大CU量，要么这个Project不适合用包年包月资源。
（5）建议不要一次性转所有Project，逐步转，每转一个Project需要通过MaxCompute管家监控资源使用情况，看情况进行扩容/缩容。

欢迎加入“MaxCompute开发者社区2群”,点击链接MaxCompute开发者社区2群申请加入或扫描二维码