共计 16607 个字符，预计需要花费 42 分钟才能阅读完成。
一、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 管家监控资源应用状况，看状况进行扩容 / 缩容。
本文为阿里云原创内容，未经容许不得转载。