关于javascript:MaxComputeDataworks云数仓高可用最佳实践

一、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、按量付费转包年包月思路
大抵思路：
（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管家监控资源应用状况，看状况进行扩容/缩容。

本文为阿里云原创内容，未经容许不得转载。