海清_个人页_阿里云开发者社区

发表了文章 2021-03-18

MaxCompute作业日常监控与运维实践

监控项目作业超时运行案例一专用于业务团队取数的project_A ，基本都是手动跑SQL查询，每个作业执行基本不会很长时间，由于目前使用的是包年包月计算资源，为了防止单个作业长期占用资源，需要对作业进行超时监控。假设对于project_A的SQL作业，只要某个作业运行时长（等待时间+真正运行时间）超过15分钟，则视为异常用时作业，需介入检查。监控配置 1. 登录[云监控控制台](https://cloudmonitor.console.aliyun.com/)。 2. 在左侧导航栏，单击报警服务 > 报警规则。 3. 在报警规则页面的阈值报警页签，单击创建报警规则。 4. 单击创建报警规则。 5. 在创建报警规则页面，基于场景配置报警规则相关信息，详细参数配置请参见[创建阈值报警规则](https://help.aliyun.com/document_detail/103072.html)。配置报警联系人详情请参见[创建报警联系人或报警联系组](https://help.aliyun.com/document_detail/104004.html)。资源范围：选择项目名称，并在下方"项目名称"中指定需要监控的项目project_A 。规则描述：即选择监控指标，如此案例我们针对项目下所有作业监控，则选择作业运行时长类型。最大值大于等于15*60=900秒，即配置作业运行时长超过15分钟则触发告警，注意单位为'秒'。通知方式：可以选择短信+邮件+钉钉机器人 (Warning)，以便快速从各个通道获取告警，另外告警接收人要注意一定要配置好具体人员，避免接收的人员不是负责此业务的人员。告警处理收到单个job的超时告警，考虑是否单个作业本身问题，可以通过[MaxCompute管家的作业运维管理](https://help.aliyun.com/document_detail/198711.html?spm=a2c4g.11186623.6.1026.25656a2coeGp9Z)-高级查询单独搜索这个instance id: 在结果列表里，可以看到作业的基本信息，可以点击'Logview'查看详情，如是否是长尾、是否是作业查询量本身就非常大等，经过判断后，可以考虑是否让job继续运行，若不能继续运行则kill掉。若一直是等待资源状态，那么可以到“作业快照”中查看当前时刻，对应资源组的作业负载情况，是否是有其他项目作业占满长期占满资源等。收到多个job超时告警，或者持续单个不同的job超时告警，可以考虑是否是资源不足，大量作业在等待资源，可以在MaxCompute管家作业快照里查看对应资源组此刻正在运行作业负载情况，人工介入，该kill作业的kull作业，该扩容的扩容等。案例二生产项目project_B ，有跑MaxCompute的SQL、spark等类型任务，所有生产任务都比较重要，正常情况下再大的任务执行时间（等待时间+真正运行时间）不会超过1个小时，考虑到spark有流式作业存在，一个job拉起会很长时间也是正常现象，因此对于本生产项目，可以对SQL类型作业进行监控超时情况，以便尽快介入检查。监控配置 1. 登录[云监控控制台](https://cloudmonitor.console.aliyun.com/)。 2. 在左侧导航栏，单击报警服务 > 报警规则。 3. 在报警规则页面的阈值报警页签，单击创建报警规则。 4. 单击创建报警规则。 5. 在创建报警规则页面，基于场景配置报警规则相关信息，详细参数配置请参见[创建阈值报警规则](https://help.aliyun.com/document_detail/103072.html)。配置报警联系人详情请参见[创建报警联系人或报警联系组](https://help.aliyun.com/document_detail/104004.html)。资源范围：选择项目名称，并在下方"项目名称"中指定需要监控的项目project_B 。规则描述：即选择监控指标，如此案例我们针对项目下所有作业监控，则选择作业运行时长类型。最大值大于等于60*60=3600秒，即配置作业运行时长超过1个小时则触发告警，注意单位为'秒'。通知方式：可以选择短信+邮件+钉钉机器人 (Warning)，以便快速从各个通道获取告警，另外告警接收人要注意一定要配置好具体人员，避免接收的人员不是负责此业务的人员。告警处理收到告警后，您可以通过[MaxCompute管家的作业运维管理](https://help.aliyun.com/document_detail/198711.html?spm=a2c4g.11186623.6.1026.25656a2coeGp9Z)-高级查询单独搜索对应的job，在结果列表中可先判断是否还是等待资源状态，若是，则可以通过作业快照查看此刻对应资源组作业运行情况是否资源紧张；若不是，可以点击Logview查看详细信息，是否长尾等。判断作业的合理性，决定是否继续运行或者kill掉。若您是通过DataWorks使用MaxCompute，也可以通过DataWorks的[智能监控](https://help.aliyun.com/document_detail/138162.html?spm=a2c4g.11186623.6.1074.f4352d21zjMF73)配置自定义监控规则进行作业超时监控。DataWorks上还可以针对具体调度节点进行监控，监控的指标也更加丰富。需要注意的是，如果作业一直为运行状态，触发告警的job如果一直处在running状态，那么只要满足告警周期规则，会持续发出告警，直到job运行完成（成功或失败）。如果遇到需要放行继续运行的job，告警周期又短，可能会频繁收到告警，因此在配置规则时告警周期需要合理配置。查看某时段发起的作业执行情况日常数据开发过程中，需要对自己负责的作业进行运维管理，如查看当天发起的作业执行情况，有哪些作业失败要查看失败原因等。通过[MaxCompute管家的作业运维管理](https://help.aliyun.com/document_detail/198711.html?spm=a2c4g.11186623.6.1026.25656a2coeGp9Z)，可以查看，如下图：选择需要查看具体发起作业的时间段，选择状态，cancelled即为失败状态，点开高级查询，输入提交人（目前只支持精准匹配，需要带上`ALIYUN$`或`RAM$`前缀），进行搜索。在结果列表里可以快速获取一些基础信息，但是要查看具体失败原因，还需要点击Logview，通过Logview日志查看详情，包括查看对应跑的什么脚本、返回的失败信息等。需要注意的是，如果是通过DataWorks发起的作业，且项目的“MaxCompute访问者身份”选择的是阿里云主账号的话，那么项目的所有提交人都会是主账号，因此就不适合通过“提交人”进行过滤，只能按其他粒度进行过滤。查看某时刻包年包月资源组作业负载作业资源运维人员，管理计算资源的分配，如收到开发人员反馈当前大量作业等待资源，通过MaxCompute管家概览页的“CU资源使用趋势”查看对应资源组的负载线图，点击具体时间点查看对应时刻作业快照：如果对应资源组是完全独享型（所有自定义配额组预留CU都是最大值=最小值），选择具体的资源组进行查看，这样更有针对性。点击曲线图上对应时刻，进入此刻的作业快照列表，查看当前运行的作业资源占用情况。在结果列表中，再对CUP使用占比进行从高到低排序，看是否是某个或某几个作业长时间占用大量资源，针对性对这些作业进行处理。如果资源组是共享型（自定义配额组预留CU最大值>最小值）,那么可以直接默认查看所有资源组的CU资源使用趋势，这样进入快照列表中看所有资源的作业列表，对CUP使用占比进行从高到低排序，可以看到具体哪些作业在哪个资源组抢占了大量资源，进而针对性的处理作业，或者调整资源组，比如业务优先级低的项目所在资源组最大值可以分配小一些，以免抢占高优先级项目所属资源组的资源。针对资源组的分配，可以参考[包年包月资源隔离](https://help.aliyun.com/document_detail/197810.html?spm=a2c4g.11186623.6.1153.11fe32c0myBda4)、[包年包月资源分时配额](https://help.aliyun.com/document_detail/194065.html?spm=a2c4g.11186623.6.1152.542b274biJDwSm)。查看某作业执行相关信息在做费用审计、资源审计等,获取到了某个job的instance id，需要找到提交人或者查看具体是执行了什么脚本等。案例：如使用按量计费资源，对SQL进行费用审计，发现有某个或某几个作业费用异常，需要知道是谁执行的，执行的sql是什么。1. 通过[MaxCompute管家的作业运维管理](https://help.aliyun.com/document_detail/198711.html?spm=a2c4g.11186623.6.1026.25656a2coeGp9Z)-高级查询单独搜索对应的job,因为是SQL消费审计，作业一定是成功状态，所以选择terminated状态。2. 在结果列表中，查看信息：若提交人为子账号，则可直接找对应子账号负责人进行自检。若提交人为主账号且有DataWorks节点ID非空，则大概可以判断是通过DataWorks调度发起的生产节点，可以到DataWorks 运维中心[查看周期任务](https://help.aliyun.com/document_detail/137787.html?spm=a2c4g.11174283.6.1064.1be52b65CcPWWn)搜索节点，找到对应“责任人”，让责任人自检。若提交人为主账号，且DataWorks节点ID为空，此类比较难以判断责任人，可以通过点击查看Logview，获取具体的query，线下寻找跑过此query的提交人。需要注意的是，Logview一般保留时长为7天，超过7天，可以尝试通过[information schema->TASKS_HISTORY](https://help.aliyun.com/document_detail/135433.html?spm=a2c4g.11186623.6.1032.7ea65856ZU3E4x#title-r2c-tak-zfi)获取作业信息。若作业是最近7天运行的，作业责任人自检时，也可以直接在结果列表里访问Logview进行查看。

发表了文章 2021-01-19

MaxCompute消费监控最佳实践

MaxCompute计费方式有按量计费和包年包月，其中按量计费若使用不当，比较容易出现预料之外的高额消费产生，本文将结合阿里云提供的相关消费监控以及MaxCompute本身的消费监控/限制功能，介绍如何更好的进行MaxCompute按量计费消费监控和限制，更大程度的避免出现不必要的消费。 MaxCompute计费方式 MaxCompute主要对存储、计算和下载操作进行计费，每种资源计费方式如下图：对于包年包月，只有计算资源，可通过MaxCompute管家进行日常资源/作业负载监控，同时通过云监控对配额组使用占比进行监控以便及时发现资源满负载的情况。而对于按量计费，可根据不同消费异常的场景结合不同的方式进行监控预警或者限制消费。常见消费突增场景 SQL费用突增，主要两种情况：突发某个或某几个作业单作业高额消费，一般是SQL扫描量非常大，常见原因：业务分析人员临时查询没有写好分区条件扫描全表或者大量分区；使用UDF表达分区条件但没开启支持分区裁剪的功能使得分区裁剪失效即全表扫描；源头数据量因为各种原因暴涨等。 SQL作业量突增，如平是日平均SQL量几百，某天突然上涨到几万，场景的原因：通过SDK发起作业，误操作高频发起大量的作业；正常业务如补历史数据、业务上量而产生大量的计算作业属于正常使用。下载费用突增，常见主要是因为Tunnel SDK导出数据时endpoint和Tunnel endpoint配置为公网导致走公网下载。消费预警和控制方式针对上述的常见消费突增场景，MaxCompute产品本身针对SQL和下载都分别支持了一些监控预警或消费限制功能，而对于其他的如spark按量计费任务，也会出现消费突增的情况，我们依然可以结合阿里云提供的成本管家、高额消费预警功能进行监控。可以结合业务使用情况，选择相应的方式进行监控。实时消费监控告警您可以通过云监控平台进行配置实时消费监控告警，针对未出账的标准SQL和MapReduce计算任务进行实时消费监控及告警。系统以项目（Project）为单位，按量统计日或月的累计消费，当累计消费超出设定的阈值时，系统会通过电话、短信、邮件或钉钉等方式通知您。这种监控方式非常适合SQL突增，特别是突增大量SQL导致费用上涨的场景，可以及时获知并止损。 POC阶段，若使用的是按量计费，由于对MC计算还不是非常熟知的情况下，为了避免POC超预算，建议分别设置日累计实时消费监控和月累计实时消费监控。如设定每日计算消费超过1000元则预警，月累计消费超过50000则预警，通过此监控，一方面若超出消费预期则能及时获知快速进行人工介入排查，另一方面，也能获知测试的业务量对应消费量为多少。业务稳定阶段，建议也对业务比较稳定的项目进行消费监控，以便突发消费情况能今早发现。如projecta的业务已经比较稳定，日平均消费为5000元，若超过6000则可视为异常，那么可配置监控如单SQL消费限制 MaxCompute支持在执行SQL语句前预估SQL语句的消费。单SQL消费限制功能支持在预估消费超出设定的阈值时，限制SQL语句执行，系统返回失败状态并给出失败信息。您可以通过此功能预防单个SQL语句产生高额费用。单SQL消费限制支持如下两种设置方式：项目级别设置。Project Owner或者拥有Super_Administrator角色的用户才能执行该命令。setproject odps.sql.metering.value.max=<m_value>; Session级别设置。该命令需要和SQL语句一起执行。只对本次执行有效。set odps.sql.metering.value.max=<m_value>; 结合单SQL消费突增常见场景，可以预先配置SQL消费限制：业务分析人员取数专用的project，由于这个场景使用人员比较多，对MaxCompute的SQL了解程度也有限，最容易出现“烂SQL”，也是最容易跑出高消费的SQL，因此建议针对此类项目都配置SQL消费限制，如果预估project下每条SQL消费不超过50元，换算成计算消耗量（即SQL读取量（GB）×SQL复杂度）=50/0.3=166.67，则可针对project设置project级别的sql消费限制setproject odps.sql.metering.value.max=166.67; POC阶段，同样由于对业务和消耗量不是非常熟悉，也可以针对project级别设置单SQL消耗量，若真测试都某个计算量超过设定的值，可以针对该计算SQL设置Session级别的value相对更大的限制。如一开始限制每条SQL不能超过10元（value=10/0.3）则project级别设置setproject odps.sql.metering.value.max=33.33;，遇到需要30元的SQL则可针对该SQL设置set odps.sql.metering.value.max=100;。业务稳定阶段，业务相对稳定的生产项目，建议配置实时日累计消费监控后，不大建议设置单SQL消费限制，因为限制是直接限制SQL执行，会可能影响业务产出，当然您若有强需求如坚决不能有消费超过xxx的sql，则也可以配置。历史高额账单预警您可以通过阿里云用户中心进行设置高额消费预警，针对已经出账的账单金额进行监控及告警。MaxCompute按量计费的账单为天账单，即当天消费第二天出账，该方式只能监控历史消费金额。如果当天的账单金额超出设定的阈值，系统会在第二天09:00左右通过短信方式通知您。此种方式主要主要是事后，账单出账后才能告警，有一定的延迟性，但是因为是针对整个账单，所以MaxCompute产品本身没有支持监控的其他各类计费项，都可以通过此功能进行统一监控，尽可能快的发现异常，更早人工介入避免异常持续发生。成本管家监控阿里云日志服务推出的成本管家功能，可一键开通后自动导入账单，并提供可视化的账单分析报表，帮助您提高账单分析的效率。您可以通过成本管家自动导入MaxCompute账单，并选择邮件或者WebHook-钉钉机器人的方式发送订阅的报告。以此每日快速阅览账单。自定义监控如果上述各种方式都不能满足，您可以考虑通过MaxCompute提供的information schema数据，自定义对按量计费项目任务进行监控告警，您可以参考《统计MaxCompute TOPN费用账号及耗时作业》。更多相关MaxCompute成本优化相关的介绍、实践等可参考如下：MaxCompute消费预警与控制-视频讲解MaxCompute成本优化系列

发表了文章 2020-09-25

【转载】MaxCompute full outer join改写left anti join实践

背景 ods层数据同步时经常会遇到增全量合并的模型，即T-1天增量表 + T-2全量表 = T-1全量表。可以通过full outer join脚本来完成合并，但是数据量很大时非常消耗资源。 insert overwrite table tb_test partition(ds='${bizdate}') select case when a.id is not null then a.id esle b.id end as id ,if(a.name is not null, a.name, b.name) as name ,coalesce(a.age, b.age) as age --这3种写法一样，都是优先取delta表的字段 from ( select * from tb_test_delta where ds='${bizdate}' ) a full outer join ( select * from tb_test where ds='${bizdate-1}' ) b on a.id =b.id; 这种写法可实现新增和更新操作：新增是指增量表中新出现的数据，而全量表中没有；更新是指增量表和全量表中都有的数据，但优先取增量表的数据，覆盖历史表的数据。如下图所示，R2_1是增量表当天去重后增量数据，M3是全量表前一天的数据，而J4_2_3则是full outer join的执行图。将J4_2_3展开会发现里面将增量和全量进行了merge join，当数据量很大（1288亿条）时会产生很大的shuffle开销。此时优化方案就是将full outer join改成 union all，从而避免join shuffle。优化模型结论：full outer join改成hash cluster + left join +union all可以有效地降低计算成本，且有两种应用场景。先将模型进行抽象，假设有a和b两个表，a是增量表，b是全量表： with a as ( select * from values (1,'111') ,(2,'two') ,(7,'777') as (id,name) ) --增量 ,b as ( select * from values (1,'') ,(2,'222') ,(3,'333') ,(4,'444') as (id,name) ) --全量场景1:只合并新增数据到全量表 left anti join相当于not in，增量not in全量,过滤后只剩下完全新增的id，对全量中已有的id不修改： --查询完全新增的id select * from a left anti join b on a.id=b.id ; --结果如下 +------------+------+ | id | name | +------------+------+ | 7 | 777 | +------------+------+ --完全新增的合并全量表 select * from a --增量表 left anti join b on a.id=b.id union all select * from b --全量表 --结果如下 +------------+------+ | id | name | +------------+------+ | 1 | | | 2 | 222 | | 3 | 333 | | 4 | 444 | | 7 | 777 | +------------+------+ 场景2:合并新增数据到全量表，且更新历史数据全量not in增量,过滤后只剩下历史的id，然后union all增量，既新增也修改 --查询历史全量数据 select * from b left anti join a on a.id=b.id; --结果如下 +------------+------+ | id | name | +------------+------+ | 3 | 333 | | 4 | 444 | +------------+------+ --合并新增数据到全量表，且更新历史数据 select * from b --全量表 left anti join a on a.id=b.id union all select * from a ; --增量表 --结果如下 +------------+------+ | id | name | +------------+------+ | 1 | 111 | | 2 | two | | 7 | 777 | | 3 | 333 | | 4 | 444 | +------------+------+ 优化实践步骤1：表属性修改表、作业属性修改,对原来的表、作业进行属性优化，可以提升优化效果。 set odps.sql.reducer.instances=3072; --可选。默认最大1111个reducer,1111哈希桶。 alter table table_name clustered by(contact_id) sorted by(contact_id) into 3072 buckets;--必选步骤2：按照上述模型的场景1 或者场景2进行代码改造。这里先给出代码改造后的资源消耗对比：原来的full outer jion left anti join初始化原来的full outer jion left anti join第二天以后时间消耗 8h30min38s 1h4min48s 7h32min30s 32min30s cpu消耗 29666.02 Core * Min 65705.30 Core * Min 31126.86 Core * Min 30589.29 Core * Min mem消耗 109640.80 GB * Min 133922.25 GB * Min 114764.80 GB * Min 65509.28 GB * Min 可以发现hash cluster分桶操作在初始化有额外的开销，主要是按主键进行散列和排序，但是这是值得的，可一劳永逸，后续的读取速度非常快。以前每天跑需要8小时，现在除了分桶初始化需要1小时，以后每天实际只需要30分钟。初始化执行图图1： M2是读全量表。 M4是读取增量表,在场景2的模型中增量表被读取了两次，其中： R5_4是对主键去重（row_number）后用于后面的union all，里面包含了所有的增量数据； R1_4是对主键去重（row_number）后用于left anti join，里面只包含了主键。 J3_1_2是left anti join,将它展开后看到这里还是有mergJoin，但是这只是初始化的操作，后面每天就不会有了。展开后如图2。 R6_3_5是将增量和全量进行union all，展开后如图3。 R7_6则是将索引信息写入元数据，如图3的MetaCollector1会在R7_6中sink。因此：图1中除了R5_4和R1_4是去重必须的，有shuffle。还有J3_1_2和R6_3_5这两个地方有shuffle。图2：图3：第二天以后的执行图图1：同上，图1中的R3_2和R1_2是对增量去重必要对操作，有shuffle，这里忽略。初始化执行图的J3_1_2和R6_3_5已经被合并到了M4_1_3，将其展开后如图2。即left anti join 和 union all这两步操作在一个阶段完成了，且这个阶段是Map 任务（M4_1_3），而不是Join任务或Reduce任务。而且全量表不在单独占用一个Map任务，也被合并到了M4_1_3，因此整个过程下来没有shuffle操作，速度提升非常明显。也就是说只需要一个M4_1_3就能完成所有到操作，直接sink到表。 R5_4则是将索引信息写入元数据，如图2的MetaCollector1会在R5_4中sink。图2：原创：阿里菜鸟-数据鹤方

发表了文章 2020-09-03

持续定义Saas模式云数据仓库+BI

云数据仓库概述今天和大家一起探讨一下我们Saas模式下云数据仓库加上商业智能BI能有什么新的东西出来。我们先来看一下云数据仓库的一些概述。预测到2025年，全球数据增长至175ZB，中国数据量增长至48.6ZB。数据量暴涨这个前提下，我们看一下BI市场规模的增长。预测到2023年，我们中国BI软件市场年复合增长率为32%。云计算也同样在增速发展，2019年第四季中国云数据市场的增长率已经达到66.9%。云数据仓库可以让企业几分钟内创建并开始使用数据仓库服务，在更低的成本下，专注业务，通过对大规模数据进行多样化的处理、挖掘、分析，快速获得业务洞察。它有四大特点：大规模数据分析，高性能，灵活扩容，低成本。 BI使用场景与趋势商业智能（BI，Business Intelligence）是一种以提供决策分析性的运营数据为目的而建立的信息系统。随着我们社会发展以及数据量的爆发，在这么大量的数据支持之下，企业希望能快速从这些数据里边挖掘出更科学的一些数据，然后对我们的企业有一个科学化和数据化决策的帮助力。同时，BI也会助力企业用到一个精细化运营，客户关系维护，还有成本控制等。我们看一下商业智能建立一个信息系统它主要的一个流程。首先是数据接入，将分散于我们企业内外各种数据集成和进行整合。然后再进入一个数据准备阶段，就是一个ETL的阶段。然后再到一个数据分析的阶段，最后将这些成果交给决策层，决策层就可以通过这数据进行一些决策。不管是精细化运营，还是客户维护关系，还是成本控制，都可以从这些数据里边得到一些助力。随着数据量的暴涨，我们的业务快速的增长，产生了各种分析需求。不仅仅是分析多样，而且还想要实时的，比如说秒级的即时查询。同时在这么大量的数据基础上，数据的安全合规也越来越受到重视。所以需要快速的整合多系统数据和实现信息透明，以及构建一个统一的简单易用的可视化分析平台，提高制表效率。这已经成为BI系统的新的趋势。基于MaxCompute云数仓+BI的特性 MaxCompute（原ODPS）是一项大数据计算服务，它能提供灵活快速、完全托管、高性能、低成本、安全的PB级数据仓库解决方案，使您可以经济并高效的分析处理海量数据。基于MaxCompute云数据仓库的基本架构如下图所示。底层的集群是MaxCompute本身搭建好的，用户无需感知。再往上，有多种的计算引擎。引擎之上提供各种的API，还有深度的集成了一个一站式大数据智能云研发平台DataWorks。在云数据仓库的这么一个体系下，可以做数据准备，进行各种清洗、加工、分析之后，就可以进入一个数据消费的阶段。总结一下MaxCompute云数仓的特性。第一，是一个开箱即用的在线服务。免平台运维，总体拥有成本低。第二，极致弹性能力。弹性扩展，无需容量规划即可应对业务规模的快速变化。第三，简单易用，多功能计算服务。多种计算模型，多种数据通道，外部数据源联邦计算。第四，企业级安全能力。多租户安全保障机制，细粒度授权，数据加密、脱敏，备份恢复。第五，生态融合。支持多样数据源、生态工具和标准。基于MaxCompute云数据仓库，我们和BI工具是如何对接的呢。MaxCompute主要是一个存储和计算服务，加上一个数据开发平台DataWorks，组成了一个离线的云数据仓库。在这之上，深度的集成了一个阿里云的Quick BI。它是一个分析报表工具，直接连接一MaxCompute的数据表即可以自己对这个表进行分析。还有第三方的一些工具，帆软，Tableau。同时我们在生态这一方面，JDBC同样也是支持。还有一些企业、一些客户对于商业智能这一块有更加多样化的一个需求或者个性的需求，现有对接的这些工具有可能不支持，那么它也可以通过SDK的方式来连接，从而实现基于MaxCompute云数据仓库对接的一个商业智能的信息平台。我们看一下MaxCompute离线数仓是怎么实现一个高性能低延迟的分析查询。它可以直接读取离线数仓，支持多样化的查询分析，包括一些简单的查询、复杂的查询、点查询、联邦查询等等。它底层也可以有丰富的数据源，通过MaxCompute + Hologres组成一个交互式分析。这么一个大数据生态下，它都可以无缝的对接。比如说Quick BI，Tableau，帆软。所以它可以做到很快的上手，通过这么一个组合我们可以很快速的实现一个企业的信息平台。实践案例接下来我们看一下几个实践案例。新零售的一个行业案例，需求背景：基于Hadoop开源生态打造，软硬件维护成本高昂，稳定性问题不断，严重影响业务经营分析；线上业务爆发，需求积压严重，期望有整体解决方案，能够快速灵活支持业务发展所需的技术扩展。通过这么一个大数据解决方案，直接用了阿里云的Quick BI这个产品，实现了快速数智化转型，拥抱新零售，降低TCO的同时，更好的依托云上生态，实现数据资产业务化闭环。最终新零售这个案例，基于我们的MaxCompute + DataWorks，提高了他的数据业务的开发效率。我们再看一个新金融的案例。需求背景：金融业务数据，对安全管控有极强要求，需要一个完整的安全管理体系，同时还要满足个性化安全需求；业务快速发展，需要能快速搭建、成本低、秒级扩展的数据中台体系。我们给客户创造的价值：基于MaxCompute开箱即用的应用满足其在安全审计过程中的数据安全需求，缩短了需求响应时间并满足其在数据安全上的个性化需求。

发表了文章 2020-08-31

MaxCompute资源管理—— 包年包月资源组隔离

概述使用基于MaxCompute云数据仓库的企业，由于业务的差异，会创建多project进行数据隔离。同时也因为业务的差异，每个project需要跑的任务量、业务紧急程度等也有差异，因此不同project对计算资源的需求也不一致。本文我们一起探讨如何通过MaxCompute管家实现MaxCompute包年包月的资源隔离。背景信息默认预付费Quota：购买包年包月计算资源后，默认创建的配额组，该配额组不支持修改；升级或降配时，对应的CU量都在这个配额组中进行增减。管家中支持创建配额组（自定义配额组），自定义的配额组里预留CU的最小值和非预留CU的值将从默认配额组对应的值里进行扣减。所有配额组预留CU的最小值相加等于购买的预留CU量；所有配额组的非预留CU值相加等于购买的非预留CU量。配额组中，预留CU的最小和最大值分别代表：最小值：保障值。最大值：可使用的最大值（最大可设置为购买的预留CU量）。当有多个配额组且配置了最小值<最大值是，一旦有配额组资源为空闲的时候，则可以占用。 >当有配额组最小值<最大值时，说明配额组是有可能会抢占其他配额组空闲资源，因此会导致所有配额组都是共享（当前账号当前region范围）资源组。使用案例需求背景公司使用到MaxComput进行大数据开发、分析、挖掘的业务大致为：数仓开发和生产、运营分析需求、算法挖掘。因而也创建了不同的project进行数据业务划分，project业务特点如下：数仓project，分开发和生产，且按数仓模型分层划分project。运营分析project，主要提供给业务部分进行日常数据分析取数，根据业务部分需求建不同部门专用project。算法挖掘，分开发和生产，根据作业周期特点划分project。根据前期业务评估当前购买的计算资源为预留CU量1000CU，非预留CU量600CU。现在需要将这些计算资源合理的进行隔离分配，以便能最大化提升资源使用率。资源划分资源划分可参考几个注意点：高保障project主要配预留CU，非预留CU可作为加持资源。预留CU最小值要根据实际配置避免滥用。对于非高保障，优先级也不高但是会有可能请求大量资源的项目，对应配额组的最大值建议控制范围，影响以免其他资源组资源。平均占用资源时间较长的考虑隔离独立配额组，同时最大值建议控制范围。对时效性要求不高，资源占用频率高可以考虑非预留CU。可根据实际情况结合资源分时功能。因为默认配额组不可修改包括CU最大值，若不想让某些项目发起的任务可能会占用所有的CU量，那么可以考虑默认配额组不关联项目。由于默认配额组预留CU最小值不能为0，则可以留1CU，然后其他配额组里配置预留CU最小值<最大值，则其他配额组也依然能占用这1CU。配额组设计如下：综上所述，因为考虑到业务特点，配额组的预留CU最大值都进行了限制，避免严重影响其他配额组的最低保障值。在MaxCompute管家上进行配额组设计管理时，按上述表格，默认配额组不能关联项目，但预留CU最小值又必须大于0，可以选择保留1CU，可以选择上述数仓开发项目最小CU值减1。具体配置步骤如下：先进行分时设置，把配额分为00:00:00-09:00:00、09:00:00-23:59:59 两个时段。再分别新增配额组，设置数仓生产、数仓开发、运营、算法相关配额组。最后分别将项目关联对应的配额组，默认配额组不关联项目。总结随着业务变化，配额组的划分也会可能需要随之变化，所以有必要随时监控配额组的使用情况，以便及时对配额组进行调整。关于配额组监控，您可以通过云监控的"MaxCompute-包年包月Quota组资源"指标进行监控，详情请参考文档j监控告警。另外，您还可以结合MaxCompute更多的资源管理功能如包年包月项目任务使用按量付费资源、包年包月项目任务优先级进行更精细的资源管理。

发表了文章 2020-07-27

MaxCompute资源管理—— 包年包月资源分时

背景概述在数据开发过程中，普遍有这样的场景：不同项目（开发、生产）对资源使用的时段不同，如数仓团队有离线生产project在夜间是计算高峰期，开发project和业务分析团队的project计算高峰在白天。即不同project在不同的时段对CU的消耗需求不同，日常峰谷时间段比较固定。 MaxCompute管家之前提供的自定义配额组，只能对配额进行二级切分，但无法进行时段切分，2020年7月23日开始，MaxCompute 管家陆续对各个区域进行升级新版本，新版本支持的功能之一——分时配额，将支持对预留计算资源（预留CU）进行按时段切分，满足时段的差异化资源需求，满足对资源隔离（生产/开发/自助分析）不同工作负载的能力，避免相互干扰，同时更大化提高资源使用率。本文将介绍如何进行分时配额，协助您更快上手使用分时配额功能，提高资源使用率。注意事项基本原则：只有包年包月的预留计算资源（预留CU）支持分时配置，非预留计算资源不支持分时。开启分时配置，是对当前region下所有配额组都开启，但默认quota组不支持编辑。配额组开启分时后，默认是一个时段（00:00:00—23:59:59），最多支持3个时间段，所有quota组分时都支持一个分时规则，即所有quota组都有一样的时间段。只支持整点分时，如0:00点—07:00,最后一个时段截止时刻必须为23:59:59。开启分时后配额组设置注意事项：开启分时后，如果某个配额组不需要分时，那么每个时间段设置的最小/最大CU量都一样既可。同一个时间段，所有配额组预留CU最小值总和等于购买量。关闭分时：如果发现当前的分时时段不合理或者根据业务需求需要调整，则再点击设置分时，进入设置分时页面，点击“关闭分时”，此时分时功能关闭，各个配额组的预留CU量设置为当前时间点对应关闭前的时间段设置的CU量。修改分时：目前不支持直接在原来的分时上修改分时时段，需要先“关闭分时”再“开启分时”进行新的分时配置，然后对应修改各个自定义配额则中预留CU每个时段的CU量。使用案例需求背景：北京region购买了包年包月预留计算资源100CU，数仓团队有生产、开发项目，业务团队有自助分析项目。分析：生产项目计算高峰时间段0点-8点，CU使用量较高，其余时间会有小部分小时任务且时间上要求不是很高；开发项目计算高峰期在9点到23点，计算频次较高；自助分析项目计算高峰期子9点到23点，计算比较分散，但也有些固定周期调度任务需要保障。时间段分布比较固定，因此可以将配额切分2个时段‘00:00:00—08:00:00’、‘08:00:00—23:59:59’。生产、开发、自助分析项目对计算资源的需求量也各有差异，因此可以自定义2个配额组+默认配额组共3个配额组进行分配。配额组设计：时段1：代表时段‘00:00:00—08:00:00’时段2：代表时段‘08:00:00—23:59:59’ 配额组名称时段1预留CU Min值时段1预留CU Max值时段2预留CU Min值时段2预留CU Max值备注默认配额 80 100 20 100 做为生产配额开发配额 10 10 30 50 时间段1预留一些CU防止需要临时开发测试，若空闲，默认配额请求超过80也可使用自助分析配额 10 10 50 100 时间段1预留一些CU防止临时取数，若空闲，默认配额请求超过80也可使用操作步骤：进入MaxCompute管家页面。登录DataWorks控制台；在左侧导航栏，单击计算引擎列表 > MaxCompute；在计算引擎列表—MaxCompute页面上方选择您所在的区域；单击包年包月区域的CU管理，进入MaxCompute管家页面。管家页面左侧导航点击配额，进入配额页面，点击“设置分时”，弹框中进行分时设置，输入好分时后点击“开启分时”。新建或者修改原有配额组，对每个配额组预留CU不同时段的Min和Max值进行设置，如“自助分析配额”组的设置。设置完成后，列表上显示的各配额组预留CU的Min和Max值对应当前时段的值。配额组设置好后，在项目列表中对应项目的“修改”操作，分别给生产、开发、自助分析项目关联对应的配额组。总结 MaxCompute 管家支持的分时配额，可以友好的支持时段的差异化资源需求，满足对资源隔离（生产/开发/自助分析）不同工作负载的能力，避免相互干扰，同时更大化提高资源使用率。您可以根据自己业务需求进行合理的设置，更多MaxCompute 管家使用请参考文档

发表了文章 2020-03-09

MaxCompute - ODPS重装上阵第九弹 - 脚本模式与参数视图

MaxCompute（原ODPS）是阿里云自主研发的具有业界领先水平的分布式大数据处理平台, 尤其在集团内部得到广泛应用，支撑了多个BU的核心业务。 MaxCompute除了持续优化性能外，也致力于提升SQL语言的用户体验和表达能力，提高广大ODPS开发者的生产力。 MaxCompute基于ODPS2.0新一代的SQL引擎，显著提升了SQL语言编译过程的易用性与语言的表达能力。我们在此推出MaxCompute(ODPS2.0)重装上阵系列文章第一弹 - 善用MaxCompute编译器的错误和警告第二弹 - 新的基本数据类型与内建函数第三弹 - 复杂类型第四弹 - CTE，VALUES，SEMIJOIN第五弹 - SELECT TRANSFORM第六弹 - User Defined Type第七弹 - Grouping Set, Cube and Rollup第八弹 - 动态类型函数第八弹中提到了参数化视图，本篇就向您介绍MaxCompute 脚本模式和参数化视图。场景1 项目有个业务处理逻辑很复杂，需要读多个表，某些表之间需要join，得出结果后再join，且要从不同的运算阶段输出多个表，即使用CTE也无法表达，只好将此业务逻辑拆分为多个作业，按顺序提交，如此一来使得作业又复杂性能也不好。场景2 当前Project有个数据表需要分享给多个团队使用，考虑安全性做成了视图，视图是通过一个算法模式实现。其他团队发现此算法挺好也想用，但是底层访问的数据表不一样，一些模式识别的参数也不一样，没办法只好再做一个新的视图提供。若后续发现原来的视图有bug，那么只能一个个的修复。 MaxCompute 提供的脚本模式与参数化视图，基本解决了上述场景中的问题。脚本模式此文中采用MaxCompute Studio作展示，首先，安装MaxCompute Studio，导入测试MaxCompute项目，创建工程，建立一个新的MaxCompute脚本文件,　如下注意，要选取MaxCompute Studio的脚本模式。这样编译器就会将整个文件作为一个整体编译，而不是一个一个语句的编译，提交的时候，也是整体提交。观察此脚本，可以看到其从多个表src, src1, src2读取数据，中间可以做任意的filter, union, join等操作，最后输出到多个表，dest和dest1中。多个语句以@开始的表变量连接。编译后提交脚本运行，可以通过MaxCompute Studio的作业试图察看执行计划，如下：右键点击图中任意task，弹出菜单点击“expand all”，可以在一个视图中看到执行计划所有operator及其相互关系，如下：可以看到虽然有多个语句，但是执行计划是互相连通的一个DAG。这样的执行计划，用传统的SQL语句，不管是CTE还是multi INSERT，都无法生成。一个执行计划可以保证一次排队，一次执行，充分利用了MaxCompute的资源。且书写起来也更自然，只需要按照业务逻辑，用类似于普通编程语言的方式书写，不用分心考虑如何组织语句，比如使用CTE和MULTI INSERT等，来优化性能。同时，MaxCompute的优化器，比起多个语句分别执行，在脚本模式下能够看到更完整的执行计划，也就可以有更多的优化机会，生成全局最优的物理执行计划，提高性能。脚本模式也支持SET语句和部分DDL语句。例如：一个脚本的完整形式是先SET语句，然后DDL语句，最后DML语句。每个部分都可以有0到多个语句，但是不同类型的语句不能交错。需要注意的是，在脚本模式下，如果一个表先被写，又被读，会报告错误，避免混淆。例如以下语句会报错 insert overwrite table src2 select * from src where key > 0; @a := select * from src2; select * from @a; 建议您在书写的时候，避免先写后读，例如以上脚本可以修改为： @a := select * from src where key > 0; insert overwrite table src2 select * from @a; select * from @a; 这样就可以打印出会写入src2中的内容了。脚本模式下目前还有一些限制一个脚本，目前最多支持一个屏显语句，否则会报告错误。不建议在脚本中执行屏幕显示的SELECT语句。一个脚本，目前最多支持一个CREATE TABLE AS语句并且必须是最后一句。我们推荐您将建表语句与INSERT语句分开写，如上面提到的DDL和DML混合的脚本。通过MaxCompute CMD使用脚本模式脚本模式是一种新的模式，如果使用MaxCompute CMD来提交脚本，需要使用0.27以上的版本。建议您下载安装最新版本。安装后，请使用新的 -s 参数来提交。如编辑脚本模式的源码myscript.sql文件，调用odpscmd命令执行如下。 odpscmd -s myscript.mysql; 说明 -s 为odpscmd的命令行选项，类似于-f、-e，而非交互环境中的命令。odpscmd的交互环境中暂不支持脚本模式与表变量。如果希望传递一些setting，但是又不想写在脚本里面，可以按照如下的方，使用-e参数来单独传递setting odpscmd -e 'set odps.sql.setting1=a;odps.sql.setting2=b='-s myscript.sql 通过DataWorks使用脚本模式在DataWorks中可以建立脚本模式的节点ODPS Script，如下图所示。在此节点中进行脚本模式编辑，编辑完成后单击工具栏的运行按钮，提交脚本到MaxCompute执行。从输出信息的Logview URL中可以查看执行计划图和结果。什么时候不应将多个小SQL语句组合为一个大模式脚本SQL 脚本模式能够支持复杂的逻辑，一个脚本可以有很多行，编译为一个执行计划，这样很容易将原来在多个SQL节点中的语句通过table variable衔接起来，拼装为一个大的脚本模式SQL。但是，并不是所有场景都适合。例如，如果上游数据来源于两个每日更新的表，一个凌晨1点数据准备好，一个凌晨7点准备好，原来一个SQL节点1点的时候处理第一个数据，结果存为一个中间表。另一个SQL节点在7点的时候将此中间表和第二个数据源作进一步运算得到结果数据。这种场景就不适合将两个节点中的SQL组合为一个大脚本。因为一个SQL节点本来可以更早的做好数据预处理，如果合成一个大脚本，就只能在7点所有数据都到达后生成一个作业，本来可以预处理的也要在大作业中完成，反而造成全链路E2E时间更长，出错的概率也更高。脚本模式更适合用来改写本来要用层层嵌套子查询的单个语句，或者因为脚本复杂性而不得不拆成多个语句的脚本。参数化的视图 (VIEW) MaxCompute传统的VIEW，可以封装一段SQL脚本，底层的逻辑可以很复杂，比如访问多个表，做复杂的运算，但是调用者可以像读普通表一样调用VIEW，不关心底层实现。这样的VIEW实现了一定的封装与重用，使用非常广泛。但是传统的VIEW也有一个限制，就是不能接受任何调用者传递的参数。例如某个VIEW读取一个底层表，希望调用者可以提供一个表对底层数据进行过滤，或者传递任何其他参数，这些需求传统VIEW都不支持。如此便限制了传统VIEW在代码重用方面的能力，而开发中仍经常需要多次复制类似的代码。 MaxCompute支持带参数的VIEW，可以传入任意表或者其他变量，定制VIEW的行为。首先在MaxCompute建立一个新的MaxCompute脚本文件,　如下: 可以看到，pv有两个参数，一个是表参数，一个是string参数，参数可以是任意的表或者基本类型。创建另一个脚本调用此VIEW，如下：可以看到pv1可以用不同的参数调用，表参数可以是个物理表，view，表变量或者CTE中的表别名，普通参数可以是变量或者常量。点击此脚本的graph页 (上图中最下边的红框)，可以看到此脚本对应的执行计划：可以看到，不管调用多少次，用什么样的参数，MaxCompute编译器都会将整个脚本编译为一个执行计划。实际上，参数化VIEW不一定是一个SQL语句，也可以像脚本一样，包含多个语句。例如：其中BEGIN到END;之间的语句，就是这个VIEW的脚本。注意其中最后一句，@pv2 := ...，这个语句相当于是其他语言中的RETURN语句，方式为向一个与VIEW同名的隐含的表变量赋值。在VIEW参数匹配的时候，实参和形参匹配的规则和普通语言一样。如果可以隐式转换，就可以匹配，例如bigint的值可以匹配类型为double的参数。表变量相对复杂一些，但是规则也很简单，如果一个表的Schema，能够用来插入到另一个表中，那也可以用来匹配同样表Schema的表类型参数。对于返回的类型，有的时候希望明确声明，例如为了可读性。可以明确地声明返回类型，例如：其中的RETURNS @ret TABLE (x string, y string), 定义了：返回类型为TABLE (x string, y string)。也就是返回给调用者的类型，注意可以在此定制表的Schema 返回参数为@ret，在VIEW的脚本中对其赋值，就相当于返回。实际上，对于没有BEGIN/END和没有返回变量的VIEW，都可以认为是这种形式的简化形式。在参数化VIEW的时候，对于脚本有一些其他限制。脚本中只能由DML语句，并且不能有INSERT与CREATE TABLE AS语句。脚本中不能有屏幕显示语句。最后，MaxCompute提供了新的脚本模式与参数化视图，可以明显提高开发者的编程效率，提高代码的可重用性，与此同时，也提高了性能！我们推荐您尽量使用脚本模式和参数化视图。

发表了文章 2020-02-11

MaxCompute项目子账号做超级管理员

场景主账号不是大数据团队管理，使用MaxCompute员工都只持有子账号，而project的owner只能为主账号，但是很多MaxCompute的权限管理还需要owner才可以操作（如项目级别的flag设置，package跨项目资源共享配置等），因此非常需要一个子账号拥有超级管理员权限。之前有写过一篇文章《MaxCompute 项目子账号做权限管理》,是通过MaxCompute的admin role来解决问题，本文主要介绍super_administrator role，以及作为超级管理员日常管理工作中的一些建议。关于super_administrator role Super_Administrator role：MaxCompute新增内置的管理角色，拥有操作项目内所有类型资源的权限和管理类权限，具体权限请参考文档管理角色。该角色可由project owner指派给子账号，子账号获得该角色后，即可代替owner对该project在进行数据开发过程中所需的各种管理操作，包括常用的项目级别的flag设置以及所有权限管理操作。指派子账号为超级管理员前提建议：可以将有权限创建project的子账号指派为super_administrator role，这样该账号既可以很好的管理DataWorks项目的同时管理对应的Max Compute 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授权：登录DataWorks，进入工作空间配置页面。添加子账号为项目空间成员(已经添加过可忽略)。为子账号授权Super_Administrator角色。子账号查看自身的权限：cmd中执行 show grants;,如果有Super_Administrator 这个role，说明已经赋权成功。成员、权限管理拥有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服务提供的相关视图进行权限审计。资源使用以及成本管理作为MaxComopute主要负责人，不应该仅仅关注成员和权限，还有资源使用、成本都需要关注。关于成本，避不开账单，可以参考文档《查看账单详情》，对于子账号，需要主账号在RAM访问控制-角色管理给子账号所在角色赋相关权限：（AliyunBSSFullAccess—管理费用中心（BSS）的权限；或，AliyunBSSReadOnlyAccess—只读访问费用中心（BSS）的权限；或，AliyunBSSOrderAccess—费用中心（BSS）查看订单、支付订单及取消订单的权限） > 注意，费用中心相关权限与MaxCompute project的super_administrator role无关联。关于资源使用管理，如果您使用MaxCompute包年包月的计算资源，则可以通过MaxCompute 管家进行计算资源的使用查看及管理。如果您使用的是MaxCompute后付费模式，可通过MaxCompute的元数据服务Information_Schema服务提供的相关视图，如TASKS_HISTORY 可详细审计作业执行情况包括时间、job内容、资源消耗等。 >注意元数据服务提供的视图只有最近15天的数据，你若有需求，可自行将数据读取保存。

发表了文章 2020-01-14

MaxCompute - ODPS重装上阵　第八弹 - 动态类型函数

MaxCompute（原ODPS）是阿里云自主研发的具有业界领先水平的分布式大数据处理平台, 尤其在集团内部得到广泛应用，支撑了多个BU的核心业务。 MaxCompute除了持续优化性能外，也致力于提升SQL语言的用户体验和表达能力，提高广大ODPS开发者的生产力。 MaxCompute基于ODPS2.0新一代的SQL引擎，显著提升了SQL语言编译过程的易用性与语言的表达能力。我们在此推出MaxCompute(ODPS2.0)重装上阵系列文章第一弹 - 善用MaxCompute编译器的错误和警告第二弹 - 新的基本数据类型与内建函数第三弹 - 复杂类型第四弹 - CTE，VALUES，SEMIJOIN 第五弹 - SELECT TRANSFORM 第六弹 - User Defined Type 第七弹 - Grouping Set, Cube and Rollup 第八弹 - 动态类型函数 MaxCompute自定义函数的参数和返回值不够灵活，是数据开发过程中时常被提及的问题。Hive 提供给了 GenericUDF 的方式，通过调用一段用户代码，让用户来根据参数类型决定返回值类型。MaxCompute 出于性能、安全性等考虑，没有支持这种方式。但是MaxCompute也提供了许多方式，让您能够灵活地自定义函数。场景1 需要实现一个UDF，可以接受任意类型的输入，但是MaxCompute的UDF不支持泛型，要做一个接受任何类型的函数，就必须为每种类型都写一个evaluate函数。场景2 MaxCompute的UDAF和UDTF使用@Resolve的注解来指定输入输出类型，无法重载。要做一个接受多种类型的自定义功能，就需要定义多个不同的函数。场景3 MaxCompute支持了参数化视图，能够把一些公共的SQL提出来。参数化视图的表值参数要求输入表的列数和类型与视图定义时完全一致，如果想要写一个能够接受具有相似特征的不同的表的视图，还无法定义出来。本文带大家一起看看MaxCompute对这些大家关心的问题都做了哪些改进。参数化视图问题参数化视图是MaxCompute自己设计的一种视图。允许用户定义参数，从而能够大大视图代码的复用率。很多用户都利用这一功能，将一些公共SQL提取到视图中，形成公共SQL代码池。参数化视图在声明过程中具有局限性：参数类型，长度都是固定的。尤其是参数化视图允许传入表值参数，表值参数要求形参与实参在列的个数和类型上都一致。这一点限制了许多使用场景，如下面的例子： CREATE VIEW paramed_view (@a TABLE(key bigint)) AS SELECT @a.* FROM @a JOIN dim on a.key = dim.key; 这个例子封装了一段使用dim表来过滤输入表的逻辑，本来这个是个通用的逻辑，任何包含key这一列的表，都可以用来做输入表。但是由于定义视图时只能确定输入中包含key列，因此声明的参数类型只包含这一列。导致了视图的调用者传递的表参数必须只能有一列，而返回的数据集也只包含一列，这显然与这个视图的设计初衷不合。改进最新的MaxCompute版本对参数化视图做了一些改进，可以大大提升参数化视图定义的灵活性。首先，参数化视图的参数可以使用ANY关键字，表示任意类型。如 CREATE VIEW paramed_view (@a ANY) AS SELECT * FROM src WHERE case when @a is null then key1 else key2 end = key3; 这里定义的视图，第一个参数可以接受任意类型。注意ANY类型不能参与如 '+', 'AND' 之类的需要明确类型才能做的运算。ANY类型更多是在TABLE参数中做passthrough列，如 CREATE VIEW paramed_view (@a TABLE(name STRING, id ANY, age BIGINT)) AS SELECT * FROM @a WHRER name = 'foo' and age < 25; -- 调用示例 SELECT * FROM param_view((SELECT name, id, age from students)); 上面的视图接受一个表值参数，但是并不关心这个表的第二列，那么这个列可以直接定义为ANY类型。参数化视图在调用时，每次都会根据输入参数的实际类型重新推算返回值类型。比如上面的视图，当输入的表是 TABLE(c1 STRING, c2 DOUBLE, c3 BIGINT)，那么输出的数据集的第二列也会自动变成DOUBLE类型，让视图的调用者可以使用任何可用于DOUBLE类型的操作来操作这一列。需要注意的一点是，我们用CREATE VIEW创建了视图后，可以用DESC来获取视图的描述，这个描述中会包含视图的返回类型信息。但是由于视图的返回类型是在调用的时候重新推算的，重新推算出来的类型可能与创建视图时推导出来的不一致。一个例子就是上面的ANY类型。在ANY之外，参数化视图中的表值参数还支持了*，表示任意多个列。这个 * 可以带类型，也可以使用ANY类型。如 CREATE VIEW paramed_view (@a TABLE(key STRING, * ANY), @b TABLE(key STRING, * STRING)) AS SELECT a.* FROM @a JOIN @b ON a.key = b.key; -- 调用示例 SELECT name, address FROM param_view((SELECT school, name, age, address FROM student), school) WHERE age < 20; 上面这个视图接受两个表值参数，第一个表值参数第一列是string类型，后面可以是任意多个任意类型的列，而第二个表值参数的第一列是string，后面可以是任意多个STRING类型的列。这其中有几点需要注意: 变长部分必须要写在表值参数定义的最后面，即在 * 的后面不允许再有其他列。这也间接导致了一个表值参数中最多只有一个变长列列表。由于变长部分必须在最后，有的时候输入表的列不一定是按照这种顺序排列的，这时候需要对输入表的列做一定重排，可以以subquery作为参数（参考上面的例子），注意subquery外面要加一层括号。由于表值参数中变长部分没有名字，因此在视图定义过程中没办法获得对这部分数据的引用，也就没有办法对这些数据做运算。这个限制是特意设置的，如果需要对变长部分的数据做运算，需要把要运算的列声明在定长部分，而编译器会对调用时传入的参数进行检查。虽然不能对变长部分做运算，但是 SELECT * 这种通配符的使用依旧可以将变长部分的列传递出去，如上面的例子在paramed_view中将 @a 的所有列返回，虽然创建视图的时候，a中只有key这一列，但是调用视图的时候，编译器推算出@a中还包含了name, age, address，因此视图返回的数据集中也包含这三列，而视图的调用者也可以对着三列进行操作（如 WHERE age < 20）。表值参数的列与视图声明时指定的定长列部分不一定完全一致。如果名字不一样，编译器会自动做重命名，如果类型不一样，编译器会做隐式转换（不能隐式转换则会报错）。上面提到的第4点非常有用，一方面保证了调用视图是输入参数的灵活性，另一方面又不降低数据的信息量。好好利用能够很大程度上增加公共代码的复用率。下面是一个调用示例。该例子使用的视图是： CREATE VIEW paramed_view (@a TABLE(key STRING, * ANY), @b TABLE(key STRING, * STRING)) AS SELECT a.* FROM @a JOIN @b ON a.key = b.key; 在MaxCompute Studio中调用，可以享受语法高亮和错误提示等功能。执行的调用代码如下：执行的状态图如下：放大执行过程仔细观察，图中可以发现几点有意思的地方：上述执行输出的结果如下： +------+---------+ | name | address | +------+---------+ | 小明 | 杭州 | +------+---------+ 其他用法经常有用户误用参数化视图，将参数化视图的参数当做是宏替换参数来使用。这里说明一下。参数化视图实际上是函数调用，而不是宏替换。如下面的例子： CREATE VIEW paramed_view(@a TABLE(key STRING, value STRING), @b STRING) AS SELECT * FROM @a ORDER BY @b; -- 调用示例 select * from paramed_view(src, 'key'); 上面的例子中，用户的期望是 ORDER BY @b 被宏替换为 ORDER BY key，即根据输入参数，决定了按照key列做排序。然而，实际上参数@b是作为一个值来传递的，ORDER BY @b 相当于 ORDER BY 'key'，即 ORDER BY一个字符串常量('key')而不是一列。要想实现"让调用者决定排序列"这一功能，可以考虑下述做法。 CREATE VIEW orderByFirstCol(@a TABLE(columnForOrder ANY, * ANY)) AS SELECT `(columnForOrder)?+.+` FROM (SELECT * FROM @a ORDER BY columnForOrder) t; -- 调用示例 select * from orderByFirstCol((select key, * from src)); 上面的例子，要求调用者将要排序的列放在第一列，于是在调用的时候使用子查询将src的需要排序的列抽取到最前面。视图返回的 (columnForOrder)?+.+ 是一个正则通配符，匹配columnForOrder之外的所有列，列表达式使用正则表达式可参考SELECT语法介绍>列表达式关于正则表达式的说明。 UDF：函数重载方式问题 MaxCompute 的 UDF 使用重载 evalaute 方法的方式来重载函数，如下面的UDF定义了两个重载，当输入是 String 类型时，输出String类型，输入是BIGINT类型时，输出DOUBLE类型。 public UDFClass extends UDF { public String evaluate(String input) { return input + "123"; } public Double evaluate(Long input) { return input + 123.0; } } 这种方式固然能解决一些问题，但有一定的局限性。比如不支持泛型，要做一个接受任何类型的函数，就必须为每种类型都写一个evaluate函数。有的时候重载甚至是不能实现的，比如ARRAY 和 ARRAY 的重载是做不到的。 public UDFClass extends UDF { public String evaluate(List<Long> input) { return input.size(); } // 这里会报错，因为在java类型擦除后，这个函数和 String evaluate(List<Long> input) 的参数是一样的 public Double evaluate(List<Double> input) { input.size(); } // UDF 不支持下面这种定义方式 public String evaluate(List<Object> input) { return input.size(); } } PYTHON UDF 或 UDTF 在不提供 Resolve 注解（annotation）的时候，会根据参数个数决定输入参数，也支持变长，因此非常灵活。但也因为过于灵活，编译器无法静态找到某些错误。比如 class Substr(object): def evaluate(self, a, b): return a[b:]; 上面的函数接受两个参数，从实现上看，第一个参数需要是STRING类型，第二个参数应该是整形。而这个限制需要用户在调用时自己去把握。即使用户传错了参数，编译器也没有办法报错。同时，这种方式定义的UDF返回值类型只能是STRING，不够灵活。改进要解决上面的问题。可以考虑使用UDT。 UDT经常被简单在调用JDK中的方法的时候使用，比如 java.util.Objects.toString(x) 将任何对象 x 转成STRING类型。但是在自定义函数方面同样也有很好的用途。 UDT支持泛型，支持类继承，支持变长等功能，让定义函数更方便。如下面的例子： public class UDTClass { // 这个函数接受一个数值类型（可以是 TINYINT, SMALLINT, INT, BIGINT, FLOAT, DOUBLE 以及任何以Number为基类的UDT)，返回DOUBLE public static Double doubleValue(Number input) { return input.doubleValue(); } // 这个方法，接受一个数值类型参数和一个任意类型的参数，返回值类型与第二个参数的类型相同 public static <T extends Number, R> R nullOrValue(T a, R b) { return a.doubleValue() > 0 ? b : null; } // 这个方法接受一个任意元素类型的array或List，返回BIGINT public static Long length(java.util.List<? extends Object> input) { return input.size(); } // 注意这个在不做强制转换的情况下参数只能接受 UDT 的 java.util.Map<Object, Object> 对象。如果需要传入任何map对象，比如 map<bigint,bigint> 可以考虑: // 1. 定义函数时使用java.util.Map<? extends Object, ? extends Object> // 2. 调用时强转，比如 UDTClass.mapSize(cast(mapObj as java.util.Map<Object, Object>)) public static Long mapSize(java.util.Map<Object, Object> input) { return input.size(); } } UDT 能够提供灵活的函数定义方式。但是有的时候UDF 需要通过 com.aliyun.odps.udf.ExecutionContext（在setup方法中传入）来获取一些上下文。现在UDT也可以通过 com.aliyun.odps.udt.UDTExecutionContext.get() 方法来或者这样的一个 ExecutionContext 对象。 Aggregator 与 UDTF：Annotation方式问题 MaxCompute 的 UDAF 和 UDTF 使用Resolve注解来决定函数Signature。比如下面的方式定义了一个UDTF，该UDTF接受一个BIGINT参数，返回DOUBLE类型。 @com.aliyun.odps.udf.annotation.Resolve("BIGINT->DOUBLE") public class UDTFClass extends UDTF { ... } 这种方式的局限性很明显，输入参数和输出参数都是固定的，没办法重载。改进 MaxCompute对Resolve注解的语法做了许多扩展，现在能够支持一定的灵活性。参数列表中可以使用星号（'*')，表示接受任意长度的，任意类型的输入参数。比如 @Resolve('double,*->String')，接受第一个是double，后接任意类型，任意个数的参数列表。这里需要UDF的作者在代码里面自己去判断输入的个数和类型，然后做出相应的动作（可以对比 C 语言里面的 printf 函数来理解）。注意星号用在返回值列表中时，表示的是不同的含义，在后续第三点中说明。参数列表中可以使用 ANY 关键字，表示任意类型的参数。比如 @Resolve('double,any->string')，接受第一个是double，第二个任意类型的参数列表。注意，ANY在返回值列表中不能使用，也不能在复杂类型的子类型中使用(如不能写ARRAY)。 UDTF的返回值可以使用星号，表示返回任意多个string类型。这里需要注意，返回值的个数并非真的是任意多个，而是与调用函数时给出的alias个数有关。比如@Resolve("ANY,ANY->DOUBLE,*")，调用方式是 UDTF(x, y) as (a, b, c)，这里as后面给出了三个alias (a, b, c)，编译器会认定a为double类型（annotation中返回值第一列的类型是给定的），b，c为string类型，而因为这里给出了三个返回值，所以UDTF在forward的时候，也一定要forward长度为3的数组，否则会出现运行时错误。注意这个错误是无法在编译时给出的，因此通常需要UDTF的作者与调用者互相沟通好，调用者在SQL中给出alias个数的时候，一定要按照UDTF的需要来写。由于Aggregator返回值个数固定是1，所以这个功能对UDAF无意义。用一个例子来说明。如下UDTF： import com.aliyun.odps.udf.UDFException; import com.aliyun.odps.udf.UDTF; import com.aliyun.odps.udf.annotation.Resolve; import org.json.JSONException; import org.json.JSONObject; @Resolve("STRING,*->STRING,*") public class JsonTuple extends UDTF { private Object[] result = null; @Override public void process(Object[] input) throws UDFException { if (result == null) { result = new Object[input.length]; } try { JSONObject obj = new JSONObject((String)input[0]); for (int i = 1; i < input.length; i++) { // 返回值要求变长部分都是STRING result[i] = String.valueOf(obj.get((String)(input[i]))); } result[0] = null; } catch (JSONException ex) { for (int i = 1; i < result.length; i++) { result[i] = null; } result[0] = ex.getMessage(); } forward(result); } } 这个UDTF的返回值个数会根据输入参数的个数来决定。输出参数的第一个是一个JSON文本，后面是需要从JSON中解析的key。返回值第一个是解析JSON过程中的出错信息，如果没有出错，则后续根据输入的key依次输出从json中解析出来的内容。使用示例如下。 -- 根据输入参数的个数定制输出alias个数 SELECT my_json_tuple(json, ’a‘, 'b') as exceptions, a, b FROM jsons; -- 变长部分可以一列都没有 SELECT my_json_tuple(json) as exceptions, a, b FROM jsons; -- 下面这个SQL会出现运行时错误，因为alias个数与实际输出个数不符 -- 注意编译时无法发现这个错误 SELECT my_json_tuple(json, 'a', 'b') as exceptions, a, b, c FROM jsons; 上面虽然做出了许多扩展，但是这些扩展并不一定能满足所有的需求。这时候依然可以考虑使用UDT。UDT也是可以用来实现Aggregator和UDTF的功能的。详细可以参考UDT示例文档，“聚合操作的实现示例” 及 “表值函数的实现示例” 的内容。总结 MaxCompute自定义函数的函数原型不够灵活，在数据开发过程中带来诸多不便利，本文列举了各种函数定义方式存在的问题与解决方案，希望对大家有帮助，同时也告诉大家MaxCompute一直在努力为大家提供更好的服务。

发表了文章 2019-12-31

MaxCompute - ODPS重装上阵　第七弹 - Grouping Set, Cube and Rollup

MaxCompute（原ODPS）是阿里云自主研发的具有业界领先水平的分布式大数据处理平台, 尤其在集团内部得到广泛应用，支撑了多个BU的核心业务。 MaxCompute除了持续优化性能外，也致力于提升SQL语言的用户体验和表达能力，提高广大ODPS开发者的生产力。 MaxCompute基于ODPS2.0新一代的SQL引擎，显著提升了SQL语言编译过程的易用性与语言的表达能力。我们在此推出MaxCompute(ODPS2.0)重装上阵系列文章第一弹 - 善用MaxCompute编译器的错误和警告第二弹 - 新的基本数据类型与内建函数第三弹 - 复杂类型第四弹 - CTE，VALUES，SEMIJOIN 第五弹 - SELECT TRANSFORM 第六弹 - User Defined Type 第七弹 - Grouping Set, Cube and Rollup 第六弹向您介绍了User Defined Type，本篇将向您介绍MaxCompute对GROUPING SETS的支持。场景由于业务需求，需要经常对数据进行多维度的聚合分析，如既需要对a列做聚合也要对b列做聚合，同时也要按照a、b两列同时做聚合，所以，不得不写很多很多的UNION ALL，因此造成了很多重复代码，维护起来不方便。该场景的问题，可以通过使用Grouping Sets能够非常好地解决。本文中很多例子采用MaxCompute Studio作展示，没有安装MaxCompute Studio的用户，可以参照wiki安装MaxCompute Studio，导入测试MaxCompute项目，创建工程。功能简介 MaxCompute中的GROUPING SETS功能是SELECT语句中GROUP BY子句的扩展。允许采用多种方式对结果分组，而不必使用多个SELECT语句来实现这一目的。这样能够使MaxCompute的引擎给出更有的执行计划，从而提高执行性能。如下例子：准备数据。数据源requests表记录了某系统收到的请求。 create table requests LIFECYCLE 20 as select * from values (1, 'windows', 'PC', 'Beijing'), (2, 'windows', 'PC', 'Shijiazhuang'), (3, 'linux', 'Phone', 'Beijing'), (4, 'windows', 'PC', 'Beijing'), (5, 'ios', 'Phone', 'Shijiazhuang'), (6, 'linux', 'PC', 'Beijing'), (7, 'windows', 'Phone', 'Shijiazhuang') as t(id, os, device, city); 需求：在city维度和os、device维度计算请求数量，同时计算总的请求数。之前解法，必须使用多个 SELECT 语句计算多个分组，并且用UNION ALL把它们连接起来： SELECT NULL, NULL, NULL, COUNT(*) FROM requests UNION ALL SELECT os, device, NULL, COUNT(*) FROM requests GROUP BY os, device UNION ALL SELECT NULL, NULL, city, COUNT(*) FROM requests GROUP BY city; 通过MaxCompute Studio的执行图，我们可以看出，物理执行计划是做了3次聚合，然后再UNION起来。 GROUPING SETS语法可以做到相同的逻辑，同时，使用更少的代码，消耗更少的集群资源： SELECT os,device, city ,COUNT(*) FROM requests GROUP BY os, device, city GROUPING SETS((os, device), (city), ()); GROUPING SETS语法和普通GROUP BY类似，但需要额外执行所需的多个GROUP BY组合。例如以上SQL的((os, device), (city), ())，请注意这是一个2层的括号，每个内层括号执行一个GROUP BY组合；空括号表示GROUP BY列表为空，即COUNT所有列。观察MaxCompute Studio的执行图，我们发现，物理执行计划只包含一个Reduce阶段，无需进行UNION操作。两种方法均产生相同的结果，如下所示：请注意: 若分组集里不使用表达式，系统会使用NULL充当占位符，使得这些结果集可以做UNION操作。例如，结果第 1-5 行的city列。相比于UNION多个group by的实现，GROUPINGSETS方式在总的资源消耗上面占优的。但使用GROUPINGSETS会使Reducer的阶段变少，如上例，从3个（R2_1, R3_1, R4_1）变为1个(R2_1), 从而导致总的Reducer instance数变少，可能会使任务端到端时间变长。这种情况建议使用 odps.sql.reducer.instances手动调大reducer的instance数目。例如上面的示例，可以 set odps.sql.reducer.instances=3; 来保持和原来instance数不变。 CUBE and ROLLUP CUBE和ROLLUP可以认为是特殊的GROUPING SETS。 CUBE会枚举指定列的所有可能组合作为GROUPING SETS。而ROLLUP会以按层级聚合的方式产生GROUPING SETS。例如： GROUP BY CUBE(a, b, c) 等价于 GROUPING SETS( (a,b,c), (a,b), (a,c), (b,c), (a) ,(b), (c), () )。 GROUP BY ROLLUP(a,b,c) 等价于 GROUPING SETS( (a,b,c), (a,b), (a), () )。 CUBE会把GROUP BY列进行全量组合，即N个列会产生 2^N中组合，故不建议N的数目超过5。 GROUPING() and GROUPING_ID() 前面提到，系统在GROUPING SETS结果中用 NULL 用作占位符，当出现此情况后，将无法区分占位符 NULL 与数据中真正的 NULL，针对这个问题，MaxCompute提供了GROUPING 函数。 GROUPING 函数接受一个列名作为参数，如果结果对应行使用了参数列做聚合，返回0，此时意味着NULL来自输入数据。否则返回1，此时意味着NULL是GROUPING SETS的占位符。此外，MaxCompute还提供了GROUPING_ID函数，此函数接受1个或多个列名作为参数。结果是将参数列的GROUPING结果按照BitMap的方式组成整数。如： SELECT a,b,c ,COUNT(*), GROUPING(a) ga, GROUPING(b) gb, GROUPING(c) gc, GROUPING_ID(a,b,c) groupingid FROM VALUES (1,2,3) as t(a,b,c) GROUP BY CUBE(a,b,c); 结果：默认情况，GROUP BY列表中不被使用的列，会被填充为NULL。我们可以通过GROUPING函数输出更有实际意义的值。如： SELECT IF(GROUPING(os) == 0, os, 'ALL') as os, IF(GROUPING(device) == 0, device, 'ALL') as device, IF(GROUPING(city) == 0, city, 'ALL') as city , COUNT(*) as count FROM requests GROUP BY os, device, city GROUPING SETS((os, device), (city), ()); 输出结果：注意事项 CUBE会把GROUP BY列进行全量组合，即N个列会产生 2^N中组合，目前我们设置了GROUP BY列上限为13个。小节 GROUPING SETS扩充了GROUP BY的聚合功能，在易用性，兼容性和性能方面，可以更好的满足您的需求。对于SQL比较熟悉的专家会发现，上述功能大部分是标准的SQL支持的功能。MaxCompute会持续提升与标准SQL和业界常用产品的兼容性。

发表了文章 2019-12-13

MaxCompute - ODPS重装上阵　第六弹 - User Defined Type

MaxCompute（原ODPS）是阿里云自主研发的具有业界领先水平的分布式大数据处理平台, 尤其在集团内部得到广泛应用，支撑了多个BU的核心业务。 MaxCompute除了持续优化性能外，也致力于提升SQL语言的用户体验和表达能力，提高广大ODPS开发者的生产力。 MaxCompute基于ODPS2.0新一代的SQL引擎，显著提升了SQL语言编译过程的易用性与语言的表达能力。我们在此推出MaxCompute(ODPS2.0)重装上阵系列文章第一弹 - 善用MaxCompute编译器的错误和警告第二弹 - 新的基本数据类型与内建函数第三弹 - 复杂类型第四弹 - CTE，VALUES，SEMIJOIN 第五弹 - SELECT TRANSFORM 第六弹 - User Defined Type 第七弹 - Grouping Set, Cube and Rollup 第五弹向您介绍了MaxCompute如何嵌入其他语言的脚本。SELECT TRANSFORM的优势在于可以不创建function甚至不上传资源的情况下执行其他语言的脚本，而即使需要编写资源也没有任何由MaxCompute规定的格式要求和依赖。本文将介绍另一种将这一优势提升到更高层次的新功能：User Defined Type，简称UDT。场景1 某个功能通过其他语言既可非常简单的实现，如用java预计只需要一次内置类的方法调用就可以实现，但MaxCompute没有合适的内置函数实现这一功能。为如此简单的功能写一个UDF非常繁琐，体验很差。场景2 SELECT TRANSFORM能够让我直接把脚本写到sql语句中，大大提升了代码的可读性（UDF为黑盒，而直接写在sql里面的脚本，功能一目了然）和维护性（不需要commit多个代码文件，特别是sql和其他的脚本文件存放的repository还不一样）。但是某些语言无法这么用，比如java源代码必须经过编译才能执行，那么有没有办法能够让这些语言享受相同的优势？场景3 sql中需要调用第三方库来实现相关功能。希望能够在SQL里面直接调用，而不需要再wrap一层UDF。上述场景的问题，通过UDT能够非常好地解决，接下来将具体介绍UDT使用。本文中很多例子采用MaxCompute Studio作展示，没有安装MaxCompute Studio的用户，可以参照文档安装MaxCompute Studio)，导入测试MaxCompute项目，创建工程。功能简介 MaxCompute中的UDT（User Defined Type）功能支持在SQL中直接引用第三方语言的类或者对象，获取其数据内容或者调用其方法。在其他的SQL引擎中也有UDT的概念，但是和MaxCompute的概念有许多差异。很多SQL引擎中的概念比较像MaxCompute的struct复杂类型。而某些语言提供了调用第三方库的功能，如Oracle 的 CREATE TYPE。相比之下，MaxCompute的UDT更像这种CREATE TYPE的概念，Type中不仅仅包含数据域，还包含方法。而且MaxCompute做的更彻底：开发者不需要用特殊的DDL语法来定义类型的映射，而是在SQL中直接使用。一个简单的例子如下: set odps.sql.type.system.odps2=true; -- 打开新类型，因为下面的操作会用到 Integer，即 int类型 SELECT java.lang.Integer.MAX_VALUE; 上面的例子输出： +-----------+ | max_value | +-----------+ | 2147483647 | +-----------+ 和java语言一样，java.lang这个package是可以省略的。所以上面例子更可以简写为: set odps.sql.type.system.odps2=true; SELECT Integer.MAX_VALUE; 可以看到，上面的例子在select列表中直接写上了类似于java表达式的表达式，而这个表达式的确就按照java的语义来执行了。这个例子表现出来的能力就是MaxCompute的UDT。 UDT所提供的所有扩展能力，实际上用UDF都可以实现。譬如上面的例子，如果使用UDF实现，需要做下列操作。首先，定义一个UDF的类： package com.aliyun.odps.test; public class IntegerMaxValue extends com.aliyun.odps.udf.UDF { public Integer evaluate() { return Integer.MAX_VALUE; } } 然后，将上面的UDF编译，并打成jar包。然后再上传jar包，并创建function add jar odps-test.jar; create function integer_max_value as 'com.aliyun.odps.test.IntegerMaxValue' using 'odps-test.jar'; 最后才可以在sql中使用 select integer_max_value(); UDT相当于简化了上述一系列的过程，让开发者能够轻松简单地用其他语言扩展SQL的功能。上述例子表现的是java静态域访问的能力，而UDT的能力远不限于此。譬如下面的例子： -- 示例数据 @table1 := select * from values ('100000000000000000000') as t(x); @table2 := select * from values (100L) as t(y); -- 代码逻辑 @a := select new java.math.BigInteger(x) x from @table1; -- new创建对象 @b := select java.math.BigInteger.valueOf(y) y from @table2; -- 静态方法调用 select /*+mapjoin(b)*/ x.add(y).toString() from @a a join @b b; -- 实例方法调用上述例子输出结果 100000000000000000100。这个例子还表现了一种用UDF比较不好实现的功能：子查询的结果允许UDT类型的列。例如上面变量a的x列是java.math.BigInteger类型，而不是内置类型。UDT类型的数据可以被带到下一个operator中再调用其他方法，甚至能参与数据shuffle。比如上面的例子，在MaxCompute studio中的执行图如下：可以看出图中共有三个STAGE: M1, R2 和 J3。熟悉MapReduce原理的用户会知道，由于join的存在需要做数据reshuffle，所以会出现多个stage。一般情况下，不同stage不仅是在不同进程，甚至是在不同物理机器上运行的。双击代表M1的方块，显示如下：可以看到，M1仅仅执行了 new java.math.BigInteger(x) 这个操作。而同样点开代表J3的方块，可以看到 J3 在不同的阶段执行了 java.math.BigInteger.valueOf(y) 的操作，和 x.add(y).toString() 的操作：这几个操作不仅仅是分阶段执行的，甚至是在不同进程，不同物理机器上执行的。但是UDT把这个过程封装起来，让用户看起来和在同一个JVM中执行的效果几乎一样。 UDT同样允许用户上传自己的jar包，并且直接引用。如上面UDF的jar包。用UDT来使用: set odps.sql.type.system.odps2=true; set odps.sql.session.resources=odps-test.jar; --指定要引用的jar，这些jar一定要事先上传到project，并且需要是jar类型的资源 select new com.aliyun.odps.test.IntegerMaxValue().evaluate(); 如果觉得写 package全路径麻烦，还可以像java的import一样，用flag来指定默认的package。 set odps.sql.type.system.odps2=true; set odps.sql.session.resources=odps-test.jar; set odps.sql.session.java.imports=com.aliyun.odps.test.*; -- 指定默认的package select new IntegerMaxValue().evaluate(); 详细说明目前UDT 只支持java语言。提供一些提升使用效率的flag： odps.sql.session.resources :指定引用的资源，可以指定多个，用英文逗号隔开：set odps.sql.session.resources=foo.sh,bar.txt; 注意这个flag和SELECT TRANSFORM中指定资源的flag相同，所以这个flag会同时影响SELECT TRANSFORM和UDT两个功能。 odps.sql.session.java.imports ：指定默认的package，可以指定多个，用逗号隔开。和java的import语句类似，可以提供完整类路径，如 java.math.BigInteger，也可以使用 *。暂不支持static import。 UDT支持的操作包括：实例化对象的new操作。实例化数组的new操作，包括使用初始化列表创建数组，如 new Integer[] { 1, 2, 3 }。方法调用，包括静态方法调用（因此能用工厂方法构建对象）. 域访问，包括静态域。注意: 只支持公有方法和共有域的访问。 UDT中的标识符是大小写敏感的，包括package，类名，方法名，域(field)名。 UDT支持类型转换，但限于SQL形式，如 cast(1 as java.lang.Object)。不支持java形式的类型转换，如（Object)1。暂不支持匿名类和lambda表达式（后续版本可能会支持）。暂不支持无返回值的函数调用（这个是因为UDT都是出现在expression中，没有返回值的函数调用无法嵌入到expression中，这个问题在后续的版本中可能会有解决方案）。 Java SDK 的类都是默认可用的。但是需要注意目前runtime使用的JDK版本是JDK1.8，比该版本更新的JDK功能可能不支持。需要特别注意的是，所有的运算符都是MaxCompute SQL的语义，不是UDT的语义。如 String.valueOf(1) + String.valueOf(2) 的结果是 3 (string隐式转换为double，并且double相加），而不是'12' (java中string相加是concatenate的语义）。除了string的相加操作比较容易混淆外，另一个比较容易混淆的是 = 操作。SQL中的 = 不是赋值而是判断相等。而对于java对象来说，判断相等应该用equals方法，通过等号判断的相等无法保证其行为（在UDT场景下，同一对象的概念是不能保证的，具体原因参考下述第8点）。内置类型与特定java类型有一一映射关系，见UDF类型映射。这个映射在UDT也有效：内置类型的数据能够直接调用其映射到的Java类型的方法，如 '123'.length() , 1L.hashCode()。 UDT类型能够直接参与内置函数或者UDF的运算，如 chr(Long.valueOf('100'))，其中 Long.valueOf 返回的是 java.lang.Long 类型的数据，而内置函数chr接受的数据类型是内置类型BIGINT。 Java的primitive类型可以自动转化为其boxing类型，并应用上面两条规则注意：某些内置类型是需要 set odps.sql.type.system.odps2=true; 才能使用的。否则会报错。 UDT对泛型有比较完整的支持，如 java.util.Arrays.asList(new java.math.BigInteger('1'))，编译器能够根据参数类型知道该方法的返回值是 java.util.List<java.math.BigInteger> 类型注意构造函数需要指定类型参数，否则使用java.lang.Object，这一点和java保持一致: new java.util.ArrayList(java.util.Arrays.asList('1', '2')) 的结果是 java.util.ArrayList<Object> 类型; 而 new java.util.ArrayList<String>(java.util.Arrays.asList('1', '2')) 的结果是 java.util.ArrayList<String> 类型。 UDT对 "同一对象" 的概念是模糊的。这是由数据的reshuffle导致的。从上面第一部分的join的示例可以看出，对象有可能会在不同进程，不同物理机器之间传输，在传输过程中同一个对象的两个引用后面可能分别引用了不同的对象（比如对象先被shuffle到两台机器，然后下次又shuffle回一起）。在使用UDT的时候，应该避免使用 = operator来判断相等，而是使用 equals 方法。某行某列的对象，其内部包含的各个数据对象的相关性是可以保证的。不能保证的是不同行或者不同列的对象的数据相关性。目前UDT不能用作shuffle key：包括join，group by，distribute by，sort by, order by, cluster by 等结构的key并不是说UDT不能用在这些结构里面，UDT可以在expression中间的任意阶段使用，只是不能作为最终输出。比如虽然不能 group by new java.math.BigInteger('123')，但是可以 group by new java.math.BigInteger('123').hashCode()。因为hashCode的返回值是int.class类型可以当做内置类型int来使用(应上述“内置类型与特定java类型映射”的规则)。注意：这个限制未来的版本会计划去掉。 UDT扩展了类型转换规则： UDT对象能够被隐式类型转换为其基类对象。 UDT对象能够被强制类型转换为其基类或子类对象。没有继承关系的两个对象之间遵守原来的类型转换规则，注意这时候可能会导致内容变化，比如java.lang.Long类型的数据是可以强制转换为java.lang.Integer的，应用的是内置类型的bigint强制转换为int的过程，而这个过程会真的导致数据内容的变化，甚至可能会有精度损失。目前UDT对象不能落盘。这意味着不能将UDT对象insert到表中（实际上DDL不支持UDT，创建不出来这样的表），当然，隐式类型转换变成了内置类型的除外。同时，屏显的最终结果也不能是UDT类型，对于屏显的场景，由于所有的java类都有toString()方法，而java.lang.String类型是合法的。所以debug的时候，可以用这种方法来观察UDT的内容。可以设置 set odps.sql.udt.display.tostring=true; 这样MaxCompute会自动把所有的以UDT为最终输出的列wrap上 java.util.Objects.toString(...)，从而方便调试。这个flag只对屏显语句生效，对insert语句不生效，所以专门用在调试中。内置类型支持binary或者string类型，因此可自定义实现serialize的过程，将byte[]的数据落盘。下次读出来的时候再还原回来。见后面的例子某些类可能自带序列化和反序列化的方法，如protobuffer。目前UDT依旧支持落盘，还是需要自行调用序列化反序列化方法，变成binary数据类型来落盘。 UDT不仅能够实现scalar函数的功能，配合着内置函数collect_list和explode（doc），完全能够实现 aggregator和table function的功能。更多示例使用Java数组 set odps.sql.type.system.odps2=true; set odps.sql.udt.display.tostring=true; select new Integer[10], -- 创建一个10个元素的数组 new Integer[] {c1, c2, c3}, -- 通过初始化列表创建一个长度为3的数组 new Integer[][] { new Integer[] {c1, c2}, new Integer[] {c3, c4} }, -- 创建多维数组 new Integer[] {c1, c2, c3} [2], -- 通过下标操作访问数组元素 java.util.Arrays.asList(c1, c2, c3); -- 这个创建了一个 List<Integer>，这个也能当做array<int>来用，所以这是另一个创建内置array数据的方法 from values (1,2,3,4) as t(c1, c2, c3, c4); JSON用户的福音 UDT的runtime自带一个gson的依赖(2.2.4)。因此用户可以直接使用gson set odps.sql.type.system.odps2=true; set odps.sql.session.java.imports=java.util.*,java,com.google.gson.*; -- 同时import多个package，用逗号隔开 @a := select new Gson() gson; -- 构建gson对象 select gson.toJson(new ArrayList<Integer>(Arrays.asList(1, 2, 3))), -- 将任意对象转成 json 字符串 cast(gson.fromJson('["a","b","c"]', List.class) as array<string>) -- 反序列化json字符串, 注意gson的接口，直接反序列化出来是List<Object>类型，所以这里强转成了 List<String>，方便后续使用 from @a; 相比于get_json_object，上述用法不仅仅是使用方便了，在需要对json字符串多个部分做内容提取时，先将gson字符串反序列成格式化数据，其效率要高得多。除了GSON, MaxCompute runtime自带的依赖还包括： commons-logging（1.1.1）， commons-lang（2.5）， commons-io（2.4），protobuf-java（2.4.1）。复杂类型操作内置类型array和map 与 java.util.List 和 java.util.Map 存在映射关系。结果就是: Java中实现了java.util.List 或者 java.util.Map 接口的类的对象，都可以参与MaxComputeSQL的复杂类型操作。 MaxCompute 中 array, map的数据，能够直接调用 List 或者 Map 的接口。 set odps.sql.type.system.odps2=true; set odps.sql.session.java.imports=java.util.*; select size(new ArrayList<Integer>()), -- 对 ArrayList数据调用内置函数size array(1,2,3).size(), -- 对内置类型array调用 List的方法 sort_array(new ArrayList<Integer>()), -- 对 ArrayList 的数据进行排序 al[1], -- 虽然java的List不支持下标操作，但是别忘了array是支持的 Objects.toString(a)), -- 过去不支持将array类型cast成string，现在有绕过方法了 array(1,2,3).subList(1, 2) -- 求subList from (select new ArrayList<Integer>(array(1,2,3)) as al, array(1,2,3) as a) t; 还可以实现一些特殊的功能，比如 array的distinct select cast (new java.util.ArrayList<Long>(new java.util.HashSet<Long>(array(1L, 2L, 2L))) as array<bigint>); -- 输出 [1, 2] 聚合操作的实现 UDT实现聚合的原理是，先用COLLECT_SET 或 COLLECT_LIST 函数将数据转变成 List, 之后对该List应用UDT的标量方法求得这一组数据的聚合值。如用下面的示例实现对BigInteger求中位数（由于数据是 java.math.BigInteger类型的，所以不能直接用内置的median函数） set odps.sql.session.java.imports=java.math.*; @test_data := select * from values (1),(2),(3),(5) as t(value); @a := select collect_list(new BigInteger(value)) values from @test_data; -- 先把数据聚合成list @b := select sort_array(values) as values, values.size() cnt from @a; -- 求中位数的逻辑，先将数据排序 @c := select if(cnt % 2 == 1, new BigDecimal(values[cnt div 2]), new BigDecimal(values[cnt div 2 - 1].add(values[cnt div 2])).divide(new BigDecimal(2))) med from @b; -- 最终结果 select med.toString() from @c; 由于collect_list会先把所有数据都收集到一块，是没有办法实现partial aggregate的，所以这个做法的效率会比内置的aggregator或者udaf低，所以在内置aggregator能实现的情况下，应尽量使用内置的aggregator 。同时把一个group的所有数据都收集到一起的做法，会增加数据倾斜的风险。但是另一方面，如果UDAF本身的逻辑就是要将所有数据收集到一块（比如类似wm_concat的功能），此时使用上述方法，反而可能比UDAF（注意不是内置aggregator）高。表值函数的实现表值函数允许输入多行多列数据，输出多行多列数据。可以按照下述原理实现：对于输入多行多列数据，可以参考聚合函数实现的示例。要实现多行的输出，可以让UDT方法输出一个Collection类型的数据（List 或者 Map)，然后调用explode函数，将Collections展开成多行。 UDT本身就可以包含多个数据域，通过调用不同的getter方法来获取各个域的内容即可展开成多列。下述示例实现将一个json字符串的内容展开出来的功能 @a := select '[{"a":"1","b":"2"},{"a":"1","b":"2"}]' str; -- 示例数据 @b := select new com.google.gson.Gson().fromJson(str, java.util.List.class) l from @a; -- 反序列化json @c := select cast(e as java.util.Map<Object,Object>) m from @b lateral view explode(l) t as e; -- 用explode打成多行 @d := select m.get('a') as a, m.get('b') as b from @c; -- 展开成多列 select a.toString() a, b.toString() b from @d; -- 最终结果输出(注意变量d的输出中a, b两列是Object类型）读取资源文件我们知道在UDF中可以通过ExecutionContext对象来读取资源文件。现在UDT也可以通过 com.aliyun.odps.udt.UDTExecutionContext.get() 方法来或者这样的一个 ExecutionContext 对象。下述示例将资源文件 1.txt 读取到一个string对象中，并输出： set odps.sql.session.resources=1.txt; select new String(com.aliyun.odps.udt.UDTExecutionContext.get().readResourceFile('1.txt')) text; UDT对象持久化 UDT对象默认是不支持落盘的。但是有方法能够把UDT的对象持久化。基本的思想是将数据序列化成为binary或者string来做持久化，或者将udt对象展开，持久化里面的能转成内置类型的关键数据。如下UDT定义： public class Shape { public List<Point> points; public Shape(List<Point> points) { this.points = points; } } public class Point { public int x; public int y; public Point(int x, int y) { this.x = x; this.y = y; } } 将对象展开成内置类型: @data := select key, shape from ...; @exploded := select key, point from @data lateral view explode(shape.points) t as point; @expanded := select key, point.x, point.y from @exploded; insert into table points select * from @expanded; 需要用时再重新构造: select key, new Shape(collect_list(new Point(x, y))) as shape from points group by key; 或者将对象serialize成binary。平展开的最大问题是，序列化和反序列化的麻烦。当然可以直接转成binary。如改造Shape类: -- 改造 Shape 类 public com.aliyun.odps.data.Binary serialize() { ByteBuffer buffer = ByteBuffer.allocate(points.size() * 8 + 4); buffer.putInt(points.size()); for (Point point : points) { buffer.putInt(point.x); buffer.putInt(point.y); } return new com.aliyun.odps.data.Binary(buffer.array()); } public static Shape deserialize(com.aliyun.odps.data.Binary bytes) { ByteBuffer buffer = ByteBuffer.wrap(bytes.data()); int size = buffer.getInt(); List<Point> points = new ArrayList<>(size); for (int i = 0; i < size; i++) { points.add(new Point(buffer.getInt(), buffer.getInt())); } return new Shape(points); } -- 需要持久化的时候，调用serialize() select key, shape.serialize() data from ... -- 需要读取的时候，调用deserialize方法 select key, Shape.deserialize(data) as Shape from ... 如果直接利用已有的框架，也许会更方便。如 Shape 是用 ProtoBuffer 定义的 -- shape 的定义 message Point { required int32 x = 1; required int32 y = 2; } message Shape { repeated Point points = 1; } SQL中直接调用pb的方法 select key, new com.aliyun.odps.data.Binary(shape.toByteArray()) from ... MaxCompute Studio的支持本功能和 MaxCompute Studio 搭配着使用，才能发挥其最大的价值。 MaxCompute Studio 智能提示能够大大提升编码效率。 MaxCompute Studio 的类型推导过程，能让您知道某个表达式是什么类型。 MaxCompute Studio 的实时语法检查，能快速定位问题语法问题。功能，性能与安全性功能方面，UDT的优势是显而易见的：使用简单，不需要定义任何function。支持JDK的所有功能，从而扩展了SQL的能力。代码直接和SQL放在一块，便于管理。其它类库拿来即用，代码重用率高。可以使用面向对象的思想设计某些功能。在性能方面，UDT执行过程和UDF非常接近，其性能与UDF几乎是一致的，而且产品针对UDT做了很多优化，在某些场景下UDT的性能甚至略高一筹：对象在一个进程内实际上是不需要做列化反序列化的，只有跨进程的时候才需要。简单地说，就是在没有join或者aggregator等需要做数据reshuffle的情况下，UDT并没有序列化反序列化的开销。 UDT的Runtime实现是基于codegen，而不是反射，所以不会存在反射带来的性能损失连续的多个UDT的操作，实际上会合并在一起，在一个FunctionCall里一起执行，如上述例子中values[x].add(values[y]).divide(java.math.BigInteger.valueOf(2)) 这个看似存在多次UDT方法调用的操作，实际上只有一次调用。所以虽然UDT操作的单元都比较小，但是并不会因此造成多次函数调用的接口上的额外开销。在安全控制方面，UDT和UDF完全一样。即都会受到沙箱policy的限制。所以如果要使用受限的操作，需要打开沙箱隔离，或者申请沙箱白名单。总结本文从使用的角度介绍了UDT的功能。UDT能够在SQL中直接写java的表达式，并可以引用jdk中的类。这一功能极大地方便扩展SQL的功能。当然，UDT的功能还有许多功能还有待完善。文中也提到了几点有待完善的功能：支持无返回值的函数调用（或者有返回值，但是忽略返回值，直接取操作数本身，如调用List的add方法，结束后返回执行完add操作的List）。支持匿名类和lambda表达式。支持用作shuffle key。支持JAVA外的其他语言，如python。

发表了文章 2019-11-25

MaxCompute按量计费计算任务消费监控告警

MaxCompute 按量计费资源为弹性伸缩资源，对于计算任务，按任务需求提供所需资源，对资源使用无限制，同时MaxCompute按量计费的账单为天账单，即当天消费需要第二天才出账，因此，有必要对计算任务的消费进行监控以免超预期消费而不可知。本文将介绍如何通过云监控配置MaxCompute按量计费计算任务消费监控告警。背景知识：云监控统计计算消费主要为标准SQL和MapReduce计算任务消费（纯资源使用消费）：单SQL费用统计公式：扫描量(GB)️ ️* 复杂度️ * 单价单MapReduce费用统计公式：计算时️ ️* 单价计算消费按Project为单位，统计日、月累计消费。更多监控指标说明请参考文档管理->监控报警监控需求：MaxCompute按量计费每个Project SQL、MR日消费达到0.01￥(为了演示效果配置很低的阈值)，则通过短信、钉钉、邮件发送告警通知。配置步骤：云监控中配置"报警联系人"：进入云监控控制台->报警服务->报警联系人进行报警联系人新增、编辑。需要短信、邮件、钉钉通知配置如：配置报警联系组云监控中配置"报警规则"：进入云监控->报警服务->报警规则,新增阈值报警规则：接收到钉钉机器人和邮件告警如下：

发表了文章 2019-07-03

MaxCompute 项目子账号做权限管理

场景：一个企业使用多款阿里云产品，MaxCompute是其中一个产品，用的是同个主账号，主账号不是由使用MaxCompute的大数据同学管理，大数据同学使用的是子账号。大数据同学日常需要给MaxCompute项目操作新增子账号（add user），新的子账号授权（grant xx on project/table）等操作，即日常权限管理。背景知识： MaxCompute项目权限管理默认只有owner可以操作，而MaxCompute项目的owner只能是主账号。子账号开通MaxCompute并创建项目，项目的owner依然是对应的主账号。 DataWorks中，子账号拥有项目空间的“项目管理员”或“安全管理员”角色，都只是拥有对应DataWorks的操作权限，并不能操作MaxCompute 项目的权限管理。具体可参考《DataWorks角色权限和MaxCompute 角色权限关系》。解决方案：指定一个子账号作为大数据MaxCompute的权限管理账号，让主账号给该子账号授admin role --如主账号是bob@aliyun.com，作为日常权限管理的子账号是Allen grant admin TO ram$bob@aliyun.com:Allen; 注意admin可以满足常用的一些日常权限管理，但并不能代替owner做所有管理，此时还是必须要owner才能进行操作。

发表了文章 2019-06-26

MaxCompute 费用暴涨之新增SQL分区裁剪失败

现象：因业务需求新增了SQL任务，这SQL扫描的表为分区表，且SQL条件里表只指定了一个分区，按指定的分区来看数据量并不大，但是SQL的费用非常高。费用比预想的结果相差几倍甚至10倍以上。若只知道总体费用暴涨，但是没明确是什么任务暴涨，可以可以参考查看账单详情-使用记录文档，找出费用异常的记录。分析：我们先明确MaxCompute SQL后付费的计费公式：一条SQL执行的费用=扫描输入量 ️ SQL复杂度 ️ 0.3(￥/GB)。变量主要是输入量和复杂度，但实际上复杂度最高也就为4，由复杂度引起的费用暴涨是比较罕见，我们不妨先把排查重点放在输入量上。排查：查看Logview的inputs信息如上图会发现input的分区量是14个，这个与预想的（SQL条件中只指定一个分区）不一致。问题就出在这里，此时基本可以判断这个SQL的分区并没有裁剪好，也就是说最终输入量不是一个分区而是多个或者全表。输入的分区量和预计的不一致，排除SQL中确实没有对分区设置条件这因素，那么就是分区裁剪失效了。已知的分区裁剪失效场景主要有：分区条件用了自定义函数进行裁剪；在 Join 关联时的 Where 条件中也有可能会失效。执行explain sql语句;看执行结果，读取的分区都有哪些，如执行explain select seller_id from xxxxx_trd_slr_ord_1d where ds=rand(); 结果如下：看上图中红框的内容，表示读取了表 xxxxx_trd_slr_ord_1d 的 1344 个分区，即该表的所有分区，如果直接执行这个sql，最终会因为全表扫描导致输入量增加从而费用增加。关于分区裁剪失败场景(使用函数或者跟join关联有关的场景)分析可以参考文档《分区剪裁合理性评估》。大家在执行sql前如果对分区的裁剪有疑虑，不妨执行一次explain sql语句;再执行SQL语句。关于分区条件用自定义函数导致分区裁剪失效的解决方案，有两种方式：在编写UDF的时候，UDF类上加入Annotation。@com.aliyun.odps.udf.annotation.UdfProperty(isDeterministic=true) >注意： com.aliyun.odps.udf.annotation.UdfProperty定义在odps-sdk-udf.jar文件中。您需要把引用的odps-sdk-udf版本提高到0.30.x或以上。在SQL语句前设置Flag：set odps.sql.udf.ppr.deterministic = true;，此时SQL中所有的UDF均被视为deterministic。该操作执行的原理是做执行结果回填，但是结果回填存在限制，即最多回填1000个Partition。因此，如果UDF类加入Annotation，则可能会导致出现超过1000个回填结果的报错。此时您如果需要忽视此错误，可以通过设置Flag：`set odps.sql.udf.ppr.to.subquery = false;`全局关闭此功能。关闭后，UDF分区裁剪也会失效。

发表了文章 2019-06-25

MaxCompute 费用暴涨之存储压缩率降低导致SQL输入量变大

现象：同样的SQL，每天处理的数据行数差不多，但是费用突然暴涨甚至会翻数倍。分析：我们先明确MaxCompute SQL后付费的计费公式：一条SQL执行的费用=扫描输入量 ️ SQL复杂度 ️ 0.3(￥/GB)。变量主要是输入量和复杂度，如果SQL没有变更的情况下复杂度度也没有变化，那么费用上涨主要原因就是输入量增加，因此我们侧重从输入量去排查是什么环节导致来了输入量的增加。排查：挑两个job的Logview查看输入量，推荐用MaxCompute Studio的作业对比功能查看，作业对比功能使用方式可以参考《MaxCompute Studio使用心得系列7——作业对比》。输入量如下：如上图，数据行数差别没有翻倍，但是大小(bytes)翻倍，基本可以排除是因为数据量暴增导致。那么数据行数增量不大，但是数据大小翻倍，无疑翻倍的这些数据肯定是有了变化，比如某些列的值长度变大那么size就变大，这个可以从这些数据的上游链路去查是否有可能某些列的值长度变的很大，如果这个也能排除，那么就可以考虑存储压缩率了。存储在MaxCompute里的数据是经过压缩后存放的，而MaxCompute的存储计费和SQL计费涉及到的数据量都是按这些数据存在MaxCompute里压缩后的量统计。 MaxCompute数据存储压缩没有固定比例，跟表数据有关，如平均字段长度、唯一值个数、数据相似度等，一般说来，每个表中都有存在1个或几个对存储空间影响比较的字段，这些字段就是影响压缩效果的关键（可以参考相关的存储介绍文章）。知道这个知识点，我们再去排查费用变化的这一天，输入的这些数据产出的方式变化情况。数据产出方式变化我们遇到的两个例子：数据中的时间字段计算方式变化。原来存储时会处理成" yyyy-mm-dd 00:00:00"格式，此时针对这个字段yyyy-mm-dd这段重复度高，对压缩算法比较友好，最终数据的压缩率高。之后对这个字段就不进行任何处理直接是按实际时间"yyyy-mm-dd hh:mi:ss",重复率底，存储压缩率就降低，从而数据的size就更大，最终SQL扫描这部分数据时输入量也就变大所以费用就上涨。数据中的敏感字段计算方式变化。原来存储时不经过任何处理，这个字段的数据相对比较有序，压缩率也比较高。之后这个字段经过自定义函数进行加密，加密后的数据变成随机无序，压缩率就底，数据的size也就更大，最终SQL扫描这部分数据时输入量也随之更大费用就上涨。可能还有其他的情况目前还没遇到，大家如果出现这类问题，不妨自己做一下分析。

发表了文章 2019-06-17

MaxCompute预付费套餐(计算资源+存储资源)发布

信息摘要： MaxCompute的预付费新增套餐规格类型，购买套餐即包含计算资源和存储资源。适用客户：适用于使用MaxCompute包年包月资源，同时存储量比较大的企业大数据开发用户，通过套餐使用可以更大降低成本，如：原来每日存储量达150TB，计算资源用量150CU，按每天平均存储150TB算一个月30天，存储和计算资源的费用大概50000￥。购买套餐可选存储密集型160套餐，含计算资源160CU足够使用，同时还有每日150TB的免费存储量，该套餐一个月费用35000￥。两者相比成本节约大概30%。版本/规格功能：目前MaxCompute推出套餐有：存储密集型160套餐（含计算资源160CU+存储资源150TB）、存储密集型320套餐（含计算资源320CU+存储资源300TB）、存储密集型600套餐（含计算资源600CU+存储资源500TB），购买套餐后，存储超出套餐资源会按量收费，价格比标准版更优惠。产品文档： https://help.aliyun.com/document_detail/117922.html

发表了文章 2019-05-24

MaxCompute 预付费标准版VS套餐版

MaxCompute 于5月7日正式售卖预付费（包年包月）套餐资源，主打存储密集型套餐，一共三个套餐：存储密集型160套餐存储密集型320套餐存储密集型600套餐本文主要给大家介绍预付标准版和套餐版的资源、售价以及两者对比的情况，以供大家选购时进行参考。资源标准版购买后只包含计算资源，具体如下规格类型计算资源（CU）存储资源上传/下载资源标准版按需购买，10CU起步无限制，按量付费无限制，按量付费套餐包含计算资源和存储资源，如下表所示。规格类型计算资源（CU）存储资源上传/下载资源存储密集型160套餐 160 150TB，超出部分按量付费无限制，按量付费存储密集型320套餐 320 300TB，超出部分按量付费无限制，按量付费存储密集型600套餐 600 500TB，超出部分按量付费无限制，按量付费售价标准版售价规格类型月单价（元/月）存储单价公网下载单价（元/GB）优惠标准版按需购买，1500起步阶梯价格（按量后付费） 0.8（按量后付费）一次性购满1年或以上有折扣套餐售价规格类型月单价（元/月）存储超出单价（元/GB）公网下载单价（元/GB）存储密集型160套餐 35000 0.019 （按量后付费） 0.8（按量后付费）存储密集型320套餐 70000 0.019 （按量后付费） 0.8（按量后付费）存储密集型600套餐 125000 0.019 （按量后付费） 0.8（按量后付费）套餐折扣购买时长套餐折扣 1个月无 3个月 9折 6个月 8.5折 1年 7.8折 2年 6.5折 3年 5.6折标准版 VS 套餐版从资源和售价介绍中我们可以很清楚的知道标准版和套餐最大的区别就是套餐除了计算资源还包含存储资源，在售价方面数据下载都是一样的计费方式。因此本小节我们以购买时长为1个月对比两个版本的计算和存储的花费。 1个月按30天计算. 需求资源选购规格 CU数每日平均存储量(TB) 购买金额(￥) 月存储费用(￥) 月总花费金额(￥) 同需求月总花费与标准版相比 100CU+150TB 标准版 100 150 15000 31768.704 46768.704 - 100CU+150TB 存储密集型160套餐 160 150 35000 0 35000 少约11768￥ 160CU+150TB 标准版 160 150 24000 31768.704 55768.704 - 160CU+150TB 存储密集型160套餐 160 150 35000 0 35000 少约20768￥ 200CU+200TB 标准版 200 200TB 30000 40984.704 70984.704 - 200CU+200TB 存储密集型160套餐 160 200 35000 29184 64184 少约6800￥ 200CU+200TB 存储密集型320套餐 320 200 70000 0 70000 少约984￥ 320CU+300TB 标准版 320 300 48000 59416.704 107416.704 - 320CU+300TB 存储密集型320套餐 320 300 70000 0 70000 少约37416￥ 300CU+400TB 标准版 300 400 45000 77848.704 122848.704 - 300CU+400TB 存储密集型320套餐 320 400 70000 58368 128368 多约5519￥ 300CU+400TB 存储密集型600套餐 600 400 125000 0 125000 多约2151￥ 400CU+400TB 标准版 400 400 60000 77848.704 137848.704 - 400CU+400TB 存储密集型320套餐 320 400 70000 58368 128368 少约9480￥ 400CU+400TB 存储密集型600套餐 600 400 125000 0 125000 少约12848￥ 500CU+500TB 标准版 500 500 75000 96280.704 171280.704 - 500CU+500TB 存储密集型600套餐 600 500 125000 0 125000 少约46280￥ 600CU+500TB 标准版 600 500 90000 96280.704 186280.704 - 600CU+500TB 存储密集型600套餐 600 500 125000 0 125000 少约61280￥ 500CU+600TB 标准版 500 500 75000 114712.704 189712.704 - 500CU+600TB 存储密集型600套餐 600 600 125000 58368 183368 少约6344￥通过上表的对比，如果需求量和套餐的资源量都很接近，建议可以考虑套餐版，如果比较集中使用计算，存储量极少可以考虑标准版，大家可以针对自己的业务需求进行参考。

发表了文章 2019-05-17

MaxCompute预付费套餐(计算资源+存储资源)发布

信息摘要： MaxCompute的预付费新增套餐规格类型，购买套餐即包含计算资源和存储资源。适用客户：适用于使用MaxCompute包年包月资源，同时存储量比较大的企业大数据开发用户，通过套餐使用可以更大降低成本，如：原来每日存储量达150TB，计算资源用量150CU，按每天平均存储150TB算一个月30天，存储和计算资源的费用大概50000￥。购买套餐可选存储密集型160套餐，含计算资源160CU足够使用，同时还有每日150TB的免费存储量，该套餐一个月费用35000￥。两者相比成本节约大概30%。版本/规格功能：目前MaxCompute推出套餐有：存储密集型160套餐（含计算资源160CU+存储资源150TB）、存储密集型320套餐（含计算资源320CU+存储资源300TB）、存储密集型600套餐（含计算资源600CU+存储资源500TB），购买套餐后，存储超出套餐资源会按量收费，价格比标准版更优惠。产品文档： https://help.aliyun.com/document_detail/116774.html

发表了文章 2019-05-08

MaxCompute Studio使用心得系列7——作业对比

在数据开发过程中，我们通常需要将两个作业进行对比从而定位作业运行性能或者结果有差异的问题，但是对比作业时需要同时打开两个studio 的tab页，或者两个Logview页，不停切换进行对比，使用起来非常的不方便。MaxCompute Studio从3.1.0版本开始支持作业对比，可以在一个页面同时比较两个作业，并且能自动标注出作业的差异点。本文我以查找同个作业执行两次用时差别很大的原因为例，通过MaxCompute Studio的对比功能对两次执行的job进行对比，找出执行时间差别大的原因。作业对比入口 MaxCompute Studio的Maxcompute 工具菜单中进入作业对比。输入两个需要对比的job的logview url 地址，点击“OK”按钮就可以开始对比：对比基本信息作业一运行了01:11:08 ，作业二运行了00:45:59，想知道是什么导致了相差近半个小时。先看基本信息对比：通过基本信息可以看到studio 标注出作业一的耗时明显上升，其他项目，如IO Bytes 等相差不多，输入输出表完全相同。基本可以断定是同一作业，为了确保是同一个作业还可以对比执行计划和脚本。对比执行图打开执行图 Tab ，可以一目了然看到两个作业的执行计划，执行图无法进行标注，可以通过查看text diff查看。点击text diff 后可以对比fuxi task 的执行时间，输入输出等详细信息。可以比较绝对值，可以按比例比较，不一致的地方都会进行有效标注。这里可以发现执行计划是完全一致的。对比脚本点击脚本对比Tab 后，可以对比settings 和script ，settings 非常关键，不同的参数可能会导致完全不同的结果。这里需要使用text diff 功能比较sql 脚本。可以看到脚本对比功能很方便使用，即便是很复杂的sql 脚本都可以快速发现区别，这里发现只有分区日期不同，其他完全一致。进一步分析执行计划通过前面几个对比，确定两个作业完全一致，再回到执行图中，通过回放可以发现运行瓶颈在J4，查看text diff 发现作业一的J4 用时52分，作业二28分，由此判断作业一主要是J4用时长导致整体运行变慢。接下来重点分析J4 ，打开J4的 Operation Graph， Studio 在Operation 层新添加了Metric 信息，可以看到每个operation 的执行时间，inner_time_ms, 这个时间指Operation 执行完所有行的平均时间（每个fuxi instance 都会用这个operation执行，当这个operation 处理完所有分配给他的数据后就得出一个时间，这里的inner_time_ms 指的是这些fuxi instance 对应的Operation 执行的平均时间），通过这个时间可以发现某个Operation 执行时间是否过长，例如自定义udf 是否有性能问题。对比J4 的实际运行时间相差不多，并且执行的都比较快，由此可以考虑J4 是否存在等待资源情况，导致fuxi instance 并没有及时开始运行。对比分析Tab 打开作业分析tab的时序图子页面，可以明显发现作业一的J4_2_3 task 运行时间大于作业二的，与前面看到的执行计划图一致。鼠标放到J4上点击展开作业后，可以看出fuxi instance 开始执行时间非常晚，这进一步验证了资源不足导致作业等待情况。小结通过Studio 的作业对比功能，调查了资源等待导致的作业运行变慢情况，并且排查的效率更高。作业对比还有很多其他功能，各位可以自行尝试。使用MaxCompute和Studio有疑惑可以工单咨询，更多探讨可以加入对应钉钉群一起畅聊： MaxCompute开发者社区钉钉群号：11782920 MaxCompute Studio用户群钉钉群号：21791804

发表了文章 2019-04-11

基于MaxCompute的数仓数据质量管理

声明本文中介绍的非功能性规范均为建议性规范，产品功能无强制，仅供指导。参考文献《大数据之路——阿里巴巴大数据实践》——阿里巴巴数据技术及产品部著。背景及目的数据对一个企业来说已经是一项重要的资产，既然是资产，肯定需要管理。随着业务的增加，数据的应用越来越多，企业在创建的数仓过程中对数据的管理也提出了更高的要求，而数据质量也是数仓建设过程不容忽视的环节。本文针对MaxCompute数仓建设过程中如何做数据质量给出规范建议，为实际数据治理提供依据及指导。数据质量保障原则评估数据质量的好坏不同行业甚至不同企业有不同标准，在此我们主要从四个方面进行评估，即完整性、准确性、一致性和及时性。完整性。完整性是指数据的记录和信息是否完整，是否存在缺失情况。数据缺失主要包括记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果不准确，可以说，完整性是数据质量最基础的保障。如某个相对稳定的业务数据量每天的都有100万条记录，某天突然下降1万条，那么可能就是记录缺失。而对于记录中某个字段信息缺失，如某科高考成绩表中一个考卷分数要对应一个准考证号，这个字段的空值数就该为0，一旦大于0，说明该信息缺失了。准确性。准确性是指数据中记录的信息和数据是否准确，是否存在异常或者错误的信息。比如成绩单中分数出现负数，比如订单没有买家信息等，这些都是有问题的。确保记录的准确性也是抱着数据质量必不可少的一个原则。一致性。一致性一般体现在跨度很大的数据仓库体现中。比如公司中有很多业务数仓分支，对于同一份数据必须保证一致性。例如用户ID，从在线业务库加工到数据仓库，再到各个数据应用节点，必须都是同一种类型、长度保持一致。因此在《MaxCompute数仓建设规范指南》中有了“公共层”的加工，确保数据的一致性。及时性。保障数据的及时产出，体现数据的价值。如决策的分析师一般都希望当天可以看到前一天的数据而不是要等三五天才能看到某一个数据分析结果，否则就失去了数据及时性的价值，使得数据分析工作变得毫无意义。数据质量管理流程要做数据质量管理，制定满足以上数据质量原则集基础上的质量管理规范，需要考虑几方面：什么数据需要做质量管理。什么环节进行数据质量管理。数据质量管理具体怎么做。数据质量定义定义哪些数据需要做质量管理一般可以通过数据资产等级划分和元数据的应用链路分析得出。根据应用的影响程度，确定数据资产等级；根据数据链路血缘，将数据资产等级上推至各数据生产加工的各个环节，确定链路上所涉及的数据的资产等级和在各个加工环节上根据资产等级的不同所采取的不同处理方式。数据资产等级定义对于数据的资产等级，在质量管理方向，可以从数据质量“不满足四个原则”情况下对业务的影响性质，比如可以划分为5个等级的性质，即毁灭性质、全局性质、局部性质、一般性质、未知性质，不同性质的重要性一次降低，具体定义如下: 毁灭性质，即数据一旦出错，将会引起重大资产损失，面临重大收益损失等。全局性质，即数据直接或间接用于企业级业务和效果评估、重要决策等。局部性质，即数据直接或间接用于某些业务线的运营、报告等，若出现问题会给业务线造成影响或者造成工作效率损失。一般性质，即数据主要用于日常数据分析，出现问题带来的影响极小。未知性质，即无法明确数据的应用场景。如table的label等级，资产等级可以用Asset进行标记：毁灭性质-A1，全局性质-A2，局部性质-A3，一般性质-A4，未知性质-Ax。重要程度为：A1>A2>A3>A4>Ax。若一份数据出现在多个应用场景汇总则遵循就高原则。数据资产等级落地方法定义划分好数据资产等级后，接下来就考虑怎么落地，对数仓中庞大的数据量进行资产等级打标。可以从数据流转链路着手。 MaxCompute进行数据加工基本基本流程：数据从业务系统上产生，通过同步工具（DataWorks的数据集成或阿里云DTS）进入数据数仓系统（MaxCompute）,数据在数仓中进行清洗、加工、整合、算法、模型等一系列运算后，再通过同步工具输出到数据产品中进行消费。整个流程数据都是以存放在表的形式体现，流转链路大致如下图：从数据流转链路上，整理哪些表是被哪些应用业务产品消费，通过给这些应用业务产品划分数据资产等级，再结合数据的上下游血缘，将整个链路打上某一类资产等级的标签。如，一个A2等级的的数据应用产品，对应导入这个数据产品的table即数仓（MaxCompute）的导出表Table1、Table2、Table3，几个表都打上A2-xxx数据产品标记，根据血缘往上追溯，将这几个表的上有都打上A2的标记，一直标记到源数据业务系统。通过如上方式完成数据资产等级的确认，给不同的数据定义不同的重要程度。知道了数据的重要等级针对不同的等级，采取不同的保障措施，接下来我们介绍在基于MaxCompute的数据仓库中针对不同等级的数据的保障方法。数据加工过程卡点校验在线系统卡点校验在线系统数据加工过程卡点校验，主要是指在业务系统的数据生成过程中进行的卡点校验。在线业务系统产生的数据也是数据仓库的数据来源，然而在线业务系统普遍都是复杂多变，且每次变更不可避免会带来数据的变化，数仓需要适应多变的业务发展，及时做到数据的准确性。因此，在线业务的变更如何高效的通知到基于MaxCompute的离线数据仓库，也是需要考虑的问题。这里我们介绍两个方法拱参考：工具和人员双管齐下。纪要在工具上自动捕捉每一次业务的变化，同时也要求开发人员在意识上自动进行业务变更通知。工具——发布平台。在业务进行重大变更时，订阅这个发布过程，通知到离线开发人员，使其知晓此次变更内容。当业务系统足够繁杂，日常发布变更频繁的情况下，若每次变更都通知离线业务，势必会造成不必要的浪费，同时也影响业务迭代效率。此时，可以通过数据资产等级的标识，对业务进行打标后，针对高等级的数据资产，整理出什么变更会影响数据的加工，如相关财务报表，如果业务系统的改造影响到财务报表的计算，使得约定好的计算口径被业务系统发布变更修改了，这种情况必须要告知离线业务，而离线开发人员也必须主动关注这类发布变更通知。注意：这里指的发布平台非阿里云提供发布平台，只是一种统称，指各个企业自己在线业务的相关发布平台。工具——数据库的变化感知。随着业务的发展，业务数据库（MaxCompute数仓的数据源）不可避免会出现数据库扩容或者DDL变更，这些变更都要主动通知到离线开发人员。基于MaxCompute的数据仓库在进行离线数据抽取时，通过DataWorks的数据集成工具，可能会限制某个业务数据库表，如果该数据库表发生扩容或者迁移等，数据集成工具感知不到，会可能导致数据抽取错漏，而一旦错漏，会影响下游一系列依赖该表的应用，因此建议业务数据库也需要有库表变更通知。工具只是一种辅助手段，操作工具的人员才是核心。数据资产等级的上下游打通，同样也将这个过程给到在线开发人员，使其知晓哪些是重要的核心数据资产，提高在线开发人员的数据风险意识。通过培训等方式将离线数据的诉求、离线数据的加工过程、数据产品的应用方式告诉在线业务开发人员，让其了解数据的重要性，了解数据的价值，同时也告知出错后果。让在线开发人员在完成业务目标时，也要考虑数据的目标，做到业务端和数据端一致。离线系统卡点校验首先我们再次认识MaxCompute进行数据加工的基本流程：数据从业务系统上产生，通过同步工具（DataWorks的数据集成或阿里云DTS）进入数仓系统（MaxCompute）,数据在数仓中进行清洗、加工、整合、算法、模型等一系列运算后，再通过同步工具输出到数据产品中进行消费。整个流程中，有了数据加工，才有了数据仓库模型和数据仓库代码的建设，如何保障数据加工过程中的质量是离线数据仓库保障数据质量的一个重要环节。 MaxCompute进行数据加工，可以通过DataWorks、也可以通过MaxCompute studio、或者直接通过MaxCompute SDK提交各种任务进行加工。无论用什么工具，都会经历代码开发->测试、发布->运维、变更的过程，可以对这个过程每个环节进行卡点校验。代码提交的卡点校验。即在sql提交前进行相关规则校验。这个校验目前公共云没有直接可用的工具辅助，有能力的用户可以自己开发相关的工具。规则分类如：代码规范类规则，如表命名规范、生命周期设置、表注释等。代码质量类规则，如分母为0提醒、NULL值参与计算影响结果提醒、插入字段顺序错误等。代码性能类规则，如分区裁剪失效、扫描大表提醒、重复计算检测等。任务发布上线时的卡点校验。为了保障线上数据的准确性，每一次变更都需要测试后再发布到线上生产环境，且生产环境测试通过后才算发布成功。任务变更或者数据重跑，在离线数据加工过程中不可避免都会出现的操作。针对这个操作，在进行更新前，需要通知下游，将变更原因、变更逻辑、变更时间等信息表明，下游对此次变更没有异议后再按照约定时间执行发布变更，将变更对下游的影响降到最低。数据风险点监控前一章节主要介绍通过数据加工过程的卡点校验保障在线数据和离线数据的一致性问题，本章节主要通过对数据风险点的监控来介绍如何保障数据的准确性。在线数据风险点监控在线业务系统的数据生成过程需要保证数据质量，主要根据业务规则对数据进行监控。MaxCompute本身没有配套的工具，需用户自己实现，在此只能给出一些建议拱参考。如针对数据库表的记录进行规则校验，制定一些监控规则，在业务系统中，每个业务过程进行数据落库时对数据进行校验。监控规则如交易系统中，订单拍下时间、订单完结时间、订单支付金额、订单状态流转都配置校验规则，订单拍下时间不会大于当天时间，也不会小于业务系统上线时间，一旦出现异常校验就不通过。当业务繁杂且规则繁多，规则配置等运行成本高时，同样根据数据资产等级进行监控。离线数据风险点监控本小节将介绍基于MaxCompute的数据仓库建设过程中离线数据的风险点监控，主要报对数据准确性和数据产出及时性的监控。数据准确性数据准确性是数据质量的关键，因此数据准确成为数据直连的重中之重，是所有离线系统加工时的第一保障要素，在此我们主要介绍通过DataWorks的数据质量工具——DQC来保障MaxCompute离线数据的准确性。注意，要用DQC，必须是使用DataWorks进行任务调度执行。我们先来认识DQC工具架构：DQC以数据集（DataSet）为监控对象，当离线MaxCompute数据发生变化时，DQC会对数据进行校验，并阻塞生产链路，以避免问题数据污染扩散。同时，DQC提供了历史校验结果的管理，以便对数据质量分析和定级。由上图我们看出DQC主要是通过配置数据质量校验规则，自动在数据处理过程中进行数据质量监控。DQC能监控数据质量并报警，本身不对数据产出进行处理，需要报警接收人判断并决定如何处理。 DQC数据监控规则有强规则和弱规则之分。强规则，一旦触发报警就会阻断任务的执行（将任务置为失败状态，使下游任务不会被触发执行）；弱规则，只告警不会阻断任务的执行。DQC根据阿里内部的经验，提供了一些常用的规则模板，包括：表行数较N天前波动率、表空间大小较N天前波动率、字段最大/最小/平均值相比N天前波动率、字段空值/唯一个数等等，更多请参考DataWorks用户手册中数据质量模块介绍。 DQC的工作流程如下图所示：由此看出DQC的检查其实也是运行SQL任务，只是这个任务是嵌套在主任务中，若检查的太多也会影响整体的任务执行性能，因此哪些数据需要配置DQC规则，应该配置什么规则，也要根据数据资产等级来确定。如A1、A2类数据监控率要达到90%以上，规则类需要3种以上，而不重要的数据资产不做强要求。类似的规则都是有离线开发人员进行配置来确保数据准确性，当然不同的业务会有业务规则的约束，这些规则来源于数据产品或者消费的业务需求，有消费节点进行配置，然后上推到离线系统的起点进行监控，做到规则影响最小化。数据的及时性在确保数据准确性的前提下，需要进一步让数据能够及时的提供服务，否则数据的价值将大幅降低，甚至无价值，所以确保数据及时性也是保障数据质量重中之重的一环。基于MaxCompute的离线任务，如常见的以天作为时间间隔，对于天任务，一些重要的业务会对数据产出有时间要求，比如一些决策报表要求9:00或更早必须产出。为确保数据完整性，天任务一般都是0点开始执行，计算刚过去的一天的数据，这些任务大多在夜里运行，要确保数据按时产出，需要考虑任务的优先执行（当Project里任务很多而资源有限的时候不得不考虑）和任务执行失败或时长过长时的告警问题。这里说的重要业务的“重要性”同样是前面所说的数据资产等级的划分，等级越高保障优先级越高。任务优先级。MaxCompute平台上任务优先级都是一样，无法配置。因此要对MaxCompute的任务实现“优先级”功能，只能从调度平台入手，优先调度下发重要的任务。DataWorks平台的调度任务，当对应的Project是使用预付费资源（预购固定的计算资源仅供当前项目使用）时，可以通过“智能监控”工具进行优先级设置。DataWorks的调度是一个树形结构，当配置了叶子节点的优先级，这个优先级会传递到所有的上游节点，而叶子节点往往就是服务业务的消费节点。因此在优先级的设置上，先确定业务的资产等级，等级越高的业务对应的消费节点优先级配置越高，优先调度从而优先占用计算资源，确保高等级业务准时产出。当DataWorks的节点任务所属的Project使用的是MaxCompute的后付费资源（计算按量付费，无固定资源使用），智能监控配置的优先级无效，因此，需要评估是否要购买预付费资源，同时对任务进行优化，减少不必要的资源浪费，力争在有限的资源下更高效的完成计算。任务报警。任务报警和优先级类似，通过DataWorks的“智能监控”工具进行配置，只需要配置叶子节点即可向上游传递。任务执行过程中出错或者可能出现延迟都是不可避免的，为了保障最重要数据（资产等级高）产出，我们需要“出错”立即处理、“可能”延迟必须知晓并介入。 DataWorks—智能监控。MaxCompute的离线任务，通过DataWorks进行离线任务调度时，DataWorks提供智能监控工具，对调度任务进行监控告警。智能监控是DataWorks任务运行的监控及分析系统。根据监控规则和任务运行情况，智能监控决策是否报警、何时报警、如何报警以及给谁报警。智能监控会自动选择最合理的报警时间，报警方式以及报警对象。智能监控旨在：降低您的配置成本。杜绝无效报警。自动覆盖所有重要任务（数量已经多到您自己无法梳理）。数据质量衡量前面章节给出了保障基于MaxCompute的数据仓库数据质量的方案，但是这些方案是否真的合适，或者哪些点需要改进，这些需制定一套指标进行度量。比如：频繁的接到DataWorks的智能监控发出的告警；每一个数据质量事件发生，必须分析有原因、处理过程、后续同类事件预防方案；严重的数据质量事件升级为故障，并对故障进行定义、等级划分、处理、review。相关工具链接 DataWorks-数据质量管理工具，文档，工具界面。 DataWorks—智能监控工具，文档，工具界面。

发表了文章 2019-04-08

MaxCompute SQL 使用正则表达式选列

编辑MaxCompute SQL 时，经常会需要在某个表N个列中指定一些列。若需要指定的列比较少，编写SQL时一个个输入既可。当遇到列多的时候，一个个输入就会非常费劲。本文将介绍如何在编写MaxCompute SQL时通过正则表达式表达列（column），从而提升编码效率。首先用一个简单的示例介绍正则表达式的使用方法： SELECT `abc.*` FROM t;--查询 t 表中所有名字以 'abc' 开头的列。如上示例，使用了正则表达式"abc.*"，在MaxCompute SQL中，正则表达式需要使用 ` 符号括起来，这个符号是键盘上 1 键左边的那个键，称做反单引号（注意需英文模式输入）。正则表达选列的一个非常重要的用法是，使用反选的方式来选列。如： SELECT `(ds)?+.+` FROM t;--选t表中列名字不叫‘ds’的所有列。类似的用法还有: (ds|pt)?+.+ 排除两列. (d.*)?+.+ 排除名字以d打头的所有列. 注意：在排除多个列的时候，如果col2是col1的前缀，则一定要把col1写到col2的前面（长的写前面）。比如一个表有2个分区你不想select，一个叫ds，另一个叫dshh，那么要写成 (dshh|ds)?+.+ ，而不能写成 (ds|dshh)?+.+ 。

发表了文章 2019-01-14

MaxCompute安全管理指南-案例篇

通过《MaxCompute安全管理-基础篇》了解到MaxCompute和DataWorks的相关安全模型、两个产品安全方面的关联，以及各种安全操作后，本篇主要给出一些安全管理案例，给安全管理的成员作为参考。项目创建案例前面了解了MaxCompute和DataWorks的安全模型以及两个产品之间的权限联系，本章节我们以常见2个基础业务需求来介绍项目创建和管理。基本ETL开发业务项目场景描述：多人协同开发，成员责任划分明确，需走正常的开发、调试、发布流程，生产数据查看须严格控制。分析：多人协同开发，DataWorks项目本身就满足这一点。成员责任划分明确，DataWorks的基础成员角色（项目管理、开发、运维、部署、访客）基本可以满足需求。走正常开发、调试、发布流程，生成数据需严格控制，这些通过DataWorks创建的“开发”“生成”项目可以进行控制。实操：创建项目。主要配置如图：项目模式选“择标准模式（开发跟生产隔离）”。这个模式创建的结果是一个DataWorks项目空间绑定关联两个MaxCompute project（分开发和生产project）。开发环境上进行开发调试，生产环境任务由开发环境走发布流程发布过来进行稳定运行。开发环境“MaxCompute访问身份”为个人账号。项目成员在开发环境做任务开发调试时用个人账号进行操作，这样做的目的在于，每个成员根据业务需求在开发调试过程中需要用到的MaxCompute各种生产资源（table、Resource、function）不同，为了防止权限过大，每个成员自己申请自己所需的权限（主要是生产表权限），同时还可以更好的做后续的安全审计。生产环境“MaxCompute访问身份”为项目负责人账号即project的owner。生产环境要保障稳定和安全生产，正常情况下：不允许成员可以随意提交job，不允许个人账号拥有生产表的删除、修改权限以免通过命令行工具进行操作无法受到更好的控制，个人账号需要读生产表权限必须走申请以便更好的管理数据安全。添加项目成员。DataWorks上添加RAM子账号为项目成员，按需分配角色，同时，对应开发project会将对应的role授权给子账号（各个role拥有的权限请看前面《基础篇之MaxCompute和DataWorks权限关系》章节）：项目管理员：除拥有开发角色和运维角色全部权限外，还可以进行添加/移出项目成员并授予角色创建自定义资源组等项目级别的操作。同时拥有MaxCompute 开发project的role_project_admin这个role。开发：负责数据开发页面设计和维护工作流。同时拥有MaxCompute开发project的role_project_dev这个role。运维：负责在运维中心页面管理全部任务的运行情况并做相应处理。同时拥有MaxCompute开发project的role_project_pe这个role。部署：仅在多项目模式时审核任务代码并决定是否提交运维。同时拥有MaxCompute开发project的role_project_deploy这个role。访客：仅有只读权限，可查看数据开发页面的工作流设计和代码内容。同时拥有MaxCompute开发project的role_project_guest这个role。安全管理员：仅有数据保护伞模块的操作权限，无其他模块权限。同时拥有MaxCompute开发project的role_project_security这个role。任务开发调试。开发角色成员在DataWorks的“数据开发”模块（对应MaxCompute开发project）进行任务开发调试，，其间用到的生产project表，可以到DataWorks的“数据管理”模块进行申请。任务发布到生产环境。开发角色成员调试好任务后，进行打包。运维角色成员可以进行代码review（开发角色到运维角色这个流程需要线下通知）后执行发布包将任务发布到生产环境。这个过程保障任务不能随意发布到生产环境执行。开发成员生产任务测试。任务发布到生产环境后，建议开发成员还是需要到运维中心对生产环境任务测试执行一次，以确保生产任务的可正常执行。若任务执行返回成功状态，还是需要先查看日志判断执行是否正常，进一步验证就需要查询结果表是否有正常的产出，此时一般是在开发界面进行表查询，而个人对生产环境产出的表默认无权限，可以到DataWorks的“数据管理”模块进行申请。这一整套配置和操作流程走完后，需要注意几点： DataWorks-数据开发模块是多人协同开发，所有本项目的成员都可以查看任务代码，且有编辑权限的成员都可以进行修改编辑，所以对于一些核心的敏感度高的代码将无法很好的进行保密，因此有类似高保密性的任务及数据，目前可以通过单独项目固定成员进行开发。生产环境由于都是通过project的owner访问MaxCompute，因此创建的table、function、Resource的owner都是project owner的账号，会出现“我的任务创建的表owner不是我”、“我的任务创建的表我自己没权限查看”这样的情况。由于开发和生产项目owner都是同一个账号，因为谨防通过发布任务到生产项目将生产项目表读写到开发项目，再通过开发项目获取生产数据。单项目且每个成员只能操作自己创建的表场景描述：业务单一，成员角色基本一致，后续业务也不会扩展。如专供取数即不做数据开发，只需要查询下载业务数据（比如运营角色需要获取一些数据进行分析）。分析：本项目不做数据开发，那么需要分析的数据必定是在其他项目中，同时为了避免不同主账号资源隔离，本项目的owner（主账号）必须与数据开发生产项目的owner同一账号。本项目主要是做数据查询下载，所以需要每个成员用自己的权限进行数据查询下载。因此这个项目的MaxCompute设置中“MaxCompute访问身份”属性为“个人账号”。当项目“MaxCompute访问身份”属性为“个人账号”后，DataWorks中每个项目成员将会被授予对应MaxCompute的role权限，但是需求是每个成员只能操作自己创建的表，因此需要处理好这个默认的role权限。实操：创建项目。注意主账号必须是需要分析的数据所在的项目主账号。项目配置如下：创建MaxCompute自定义role并授权。主账号通过console进行操作： create role custom_dev;--创建自定义role grant List, CreateInstance,CreateTable,CreateFunction,CreateResource on project prj_name to role custom_dev;--给自定义role赋权 MaxCompute的project设置“允许对象创建者默认拥有访问权限”。主账号通过console操作： set ObjectCreatorHasAccessPermission=true; --实际上这个flag默认已经为true，可以通过如下命令查看 show SecurityConfiguration; 也可以在DataWorks的‘项目管理——MaxCompute设置’中进行配置。添加项目成员。DataWorks上添加子账号为新成员，如添加成员时角色为“开发”，添加成功后，在对应MaxCompute的project里该成员对应的role是role_project_dev，主账号通过consle命令行查看如： show grants for ram$主账号:子账号; 修改新成员的MaxCompute权限。主账号通过consle操作： revoke role_project_dev from ram$主账号:子账号;--将新成员从默认授予的role中移除。注意，如果后期又通过DataWorks成员管理页面在操作授予成员角色，那么也会重新授予该MaxCompute role。 grant custom_dev to ram$主账号:子账号;--给新成员授予自定义角色。至此，该特殊需求权限管理的项目已经配置好。还需要注意以下几点：该项目的成员若重新操作添加如上描述中的“开发”角色，那么成员又会重新被授予role_project_dev 这个role。该项目如此配置后只能做到每个成员可以查看自己创建的表（对象），但是做不到每个成员只能看到自己创建的任务。该项目成员需要查询的表的权限需要自己走正常的权限申请流程（可在DataWorks的数据管理中申请），或者通过package授权方式，把其他生产项目的表加到package中，再将package安装到该项目并授权给成员，具体可以参考《基础篇之package授权管理》章节。其他案例 package赋权案例场景：业务分析人员需要查生产表，但是不允许查看生产任务代码，需要将多个生产项目的部分表开放给业务分析人员。场景分析：需要查生产表但是又不能查看生产任务，那么需要单独给创建一个项目。可以通过在多个生产项目创建package把需要开放的表加到package中，在分析项目中安装package并授权给分析人员，如此可以减少成员管理成本无需在所有生产项目中add 分析人员，同时保证这些分析人员只能在分析项目中查看package中的表。操作步骤： 1) 生产项目中创建Package： CREATE PACKAGE PACKAGE_NAME; 如： CREATE PACKAGE prj_prod2bi; 2) 生产项目中向Package中添加需要分享的资源: ADD table TO PACKAGE [包名称]; 如： ADD table adl_test_table TO PACKAGE prj_prod2bi; 3) 生产项目许可分析项目空间使用Package ALLOW PROJECT [允许安装的 project] TO INSTALL PACKAGE [包名称]; 如: ALLOW PRJ_BI TO INSTALL PACKAGE prj_prod2bi; 4) 分析项目安装 package： INSTALL PACKAGE [应用名].[包名称]; 如: INSTALL PACKAGE prj_prod.prj_prod2bi; 5) package赋权给使用者: 赋权给user： GRANT read on package prj_prod2bi TO USER [云账号]; 赋权给role： GRANT read on package prj_prod2bi TO ROLE [rolename]; 数据安全自查案例场景：项目初期为了加快进度，一些用户和权限管理就相对宽松，当项目工作进入了一个相对稳定发展阶段后，数据安全将成为管理方面越来越重要的点。此时需要对数据安全进行自查分析，生成一个方案并落地。本案例主要通过介绍某客户进行数据安全自查后重点调整的方向给出数据安全调整思路。自查思路账号数量统计。统计DataWorks项目的成员和MaxCompute project user，确认每个成员拥有且只拥有一个工作账号，便于责任追责和管理。存量账号数量及权限统计。废弃账号及权限统计：对于已在MaxCompute或DateWorks项目中拥有角色的RAM子账号，请在删除子账号之前解除子账号在项目的角色并在项目空间中删除子账号。否则子账号会在项目空间中残留，显示为“ p4_xxxxxxxxxxxxxxxxxxxx”且无法在项目空间中移除（不影响项目空间正常功能使用）。但若是因职位发生变化的账号及遗留权限，需要回收。建议有些不是长期使用的成员账户，有些申请了但是长期不用的账户，可以在通过通知、调研，把这部分账户清理。做到有的放矢，权限在用的时候再申请，用完后，可以再收回。个人账号调查分析（可以工单申请推送元仓数据进行分析统计）。通过调查个人账号最近3个月在开发阶段提交的查询（提交的数据检索、计算任务，主要是以SQL任务为主。），统计topN用户，并选取代表性账号分析其日常任务。如，账号对应成员主要工作的项目空间为算法开发项目，日常工作主要执行的任务是SQL任务，执行的SQL任务主要是开发环境的查询和写表操作。算法任务、MR任务相对SQL任务数量较少，但是都有分布。这也符合数据开发的实际情况，能用SQL处理，一般优先使用SQL处理数据。又如，有个账号提交的任务非常多，经了解其将自己的ak通过adk方式配置了一个查询软件，并提供多人进行查询，这种多人共用一个账号需要整改。数据下载统计（可以工单申请推送元仓数据进行分析统计）。统计各个项目的数据下载请求任务，分析规划可下载项目。调整要点账号以及全新合理分配。调整原则：每个工作成员都使用自己的个人账户。针对不同人员所在的的不同业务开发小组和角色给出不同的数据访问权限，禁止相互借用他人的账户使用。避免因为用户权限过大导致的数据安全风险。如，按数据开发过程的业务分组进行账号分配。分组如管理组、数据集成组、数据模型组、算法组、分析组、运维组、安全组等。业务小组账户数管理组 N …… …… -- -- -- -- 管理组 project1 powner@aliyun.com:user1 管理员管理组 project2 powner@aliyun.com:user1 管理员 …… …… …… …… 数据流动控制。限制部分项目的数据导出，控制部分人员的权限。数据随意在各个项目之间流动，不但会导致云平台数据架构混乱，同样也会导致数据泄露的风险。所以，针对大部分项目做出了数据流动的限制。如通过MaxCompute层面限制数据只能流动到指定的项目或者指定的位置，从而规避未知数据流动带来的风险。数据导出限制。数据一旦从MaxCompute落地为文件，就意味着数据不可控。所以，必须要尽可能的减少数据落地带来的风险。通过用户角色的详细划分，限制只有一些业务组可以有数据导出的权限。且也不影响日常开发工作。更多MaxCompute的相关问题讨论可以加入钉钉群与众多开发者一起讨论：

发表了文章 2019-01-14

MaxCompute安全管理指南-基础篇

背景及目的方便和辅助MaxCompute的project owner或安全管理员进行project的日常安全运维，保障数据安全。 MaxCompute有安全模型，DataWorks也有安全模型，当通过DataWorks使用MaxCompute，而DataWorks的安全模型不满足业务安全需求时，合理的将两个安全模型结合使用就尤其重要。安全模型 MaxCompute安全模型安全体系 MaxCompute 多租户的数据安全体系，主要包括如下内容：用户认证。支持云账号和 RAM 账号两种账号体系，对于RAM账号，仅识别账号体系不识别RAM权限体系，即可将主账号自身的任意 RAM 子账号加入 MaxCompute 的某一个项目中，但 MaxCompute 在对该 RAM 子账号做权限验证时，并不会考虑 RAM 中的权限定义。用户与授权管理。在MaxCompute Project中对用户添加（add）、移除（remove）、授权（grant）管理。还可以通过角色（role）管理授权，MaxCompute project默认有admin role。而授权方式包含ACL和Policy方式，本文只讲ACL方式，Policy方式待后续升级篇中介绍。ACL即似于 SQL92 定义的 GRANT/REVOKE 语法，它通过简单的授权语句来完成对已存在的项目空间对象的授权或撤销授权。授权语法如下： grant actions on object to subject revoke actions on object from subject 标签安全策略基于标签的安全(LabelSecurity)是项目空间级别的一种强制访问控制策略(Mandatory Access Control, MAC)，它的引入是为了让项目空间管理员能更加灵活地控制用户对列级别敏感数据的访问。跨项目空间的资源分享。Package是一种跨项目空间共享数据及资源的机制，主要用于解决跨项目空间的用户授权问题。即可以分享table、Resource、function等资源给其他项目，但是无需对其他项目的用户进行管理。项目空间的数据保护。主要解决“不允许用户将数据转移到项目空间之外”的需求。对象操作赋权、Role 和 label 关系介绍上个小节中介绍了MaxCompute体系包含多种策略，而各种策略赋权是权限递增关系。以需要获取一个L4等级表的权限来展开说明这个递增关系，主要进行以下步骤操作：第一步: 如果用户未有过授权记录，且非本项目用户，首先需要添加一个 USER(用户)，这个过程，用户还没有任何实际权限。第二步: 赋权 USER(用户)对象的操作权限，有以下方式赋权。 1) 可以是单独的操作权限; 2) 通过 policy 方式赋权给用户; 3) 将 ACL 和 policy 赋权给 role 再赋权给用户。如果资源是没有设置 Label 的，则此时用户已经拥有的该资源的权限。第三步: 对于拥有 Label 的资源，例如:数据表、打包了数据表的 package，则还需要赋权 Label 权限。有以下四钟 Label 赋权: 1) 针对某个数据表的字段; 2) 针对某个数据表; 3) 针对某个 package; 4) 给某个 USER(用户)一个批量的 Label 权限，不支持 ROLE。各权限赋权过程及关系图如下：数据流程保护机制和 Package 关系介绍 ProjectProtection(数据流出保护机制)是 MaxCompute 防止项目内的数据批量流出的安全功能。开启数据流程保护后，如果相互之间没有建立“TrustedProject Group” ，与其它 project 的数据赋权就必须通过 Package 方式进行，Package 赋权后，对方 package 可以自主赋权 Package 内的资源给组内用户。部分资源(例如某些常用表、UDF 等)，如想放权给其 Package 管理，也可以通过 Package 的方式，将资源打包后赋权给其他 Project。 ProjectProtection(数据流出保护机制)支持做例外处理，部分特殊的业务场景，可以针对应用的 IP 地址、产品云账号做 Exception 策略，以满足特殊的数据流出需求。 DataWorks安全模型 DataWorks提供多人协同数据开发工作的平台，其安全模型需要考虑几方面：企业之间数据的安全隔离。数据开发即ETL过程中的安全问题，如生产任务如何保障不可随意变更；如哪个成员可以进行代码编辑调试，哪个成员可以进行发布生产任务等。由于底层MaxCompute有自己的安全模型，项目成员做ETL过程肯定会需要MaxCompute的各种资源（table、Resource、function、instance）的相关权限。针对第一点，DataWorks的用户认证，DataWorks对接RAM，云账号可作为主账号进行开通并创建DataWorks项目，而项目成员必须为该主账号的RAM子账号不能是其他云账号。另外，同个主账号创建的项目作为一个组织，项目与项目之间的任务可以进行依赖配置；不同主账号创建的项目之间数据（各种任务）隔离。针对第二点，DataWorks通过业务划分“开发项目”、“生产项目”进行任务开发调试和稳定生产的隔离；通过成员角色控制哪个成员可以进行任务开发调试，哪个成员可以运维生产任务等。针对第三点，DataWorks在MaxCompute Project创建成功的同时，在MaxCompute Project里对应DataWorks的角色创建role，并给不同role赋权。 MaxCompute和DataWorks权限关系从前面介绍的MaxCompute和DataWorks两个小节可以知道，通过MaxCompute的安全模型进行权限控制，并不会影响成员在DataWorks任何界面操作。通过DataWorks的用户角色分配，是有可能影响成员的MaxCompute资源权限。下面我们详细介绍这两个产品之间权限如何交叉关联。项目关系通过MaxCompute或DataWorks官网产品页进入的控制台创建的项目， DataWorks 两种选择：简单模式的项目实际上是创建了关联绑定好的一个MaxCompute project和一个DataWorks项目空间，同时在MaxCompute 的project里创建对应的几个role，具体role权限后续小节会介绍。标准模式的项目实际上是创建了关联绑定好的一个开发（dev）MaxCompute project、一个生产（prod）MaxCompute project对应一个DataWorks项目空间。同时在MaxCompute 的project里创建对应的几个role，具体role权限后续小节会介绍。账号认证云账号在DataWorks项目中只能是主账号即项目owner，在MaxCompute既可以为owner也可以为普通user。当通过DataWorks项目成员管理添加成员时只能是添加当前项目主账号对应的RAM子账号。而MaxCompute可以通过命令行add user xxx;命令添加其他云账号。成员角色权限关系如前面小节（DataWorks安全模型）说的DataWorks为了解决项目成员在ETL过程中需要的MaxCompute相关资源权限，绑定了一些MaxCompute role。具体是指DataWorks项目固定有几个成员角色，同时在对应MaxCompute project上创建了对应几个role。另外MaxCompute project本身除了project owner，也还有一个admin role。具体权限对应如下表： MaxCompute角色 MaxCompute数据权限 DataWorks成员角色平台权限特征 project owner MaxCompute project的owner，拥有所有project的权限。无无 admin 每一个project在创建时，会自动创建一个 admin 的role，并且为该role授予了确定的权限：可以访问project的所有对象、对user或role进行管理、对user或role进行授权。与project Owner 相比，admin 角色不能将 admin 权限指派给用户，不能设定项目空间的安全配置，不能修改项目空间的鉴权模型，admin 角色所对应的权限不能被修改。project owner可以将这admin role赋权给一个user，让该user代理安全管理。无无 role_project_admin project/table/fuction/resource/instance/job/package 的所有权限项目管理员指项目空间的管理者，可对该项目空间的基本属性、数据源、当前项目空间计算引擎配置和项目成员等进行管理，并为项目成员赋予项目管理员、开发、运维、部署、访客角色。 role_project_dev project/fuction/resource/instance/job/package/table 的所有权限开发开发角色的用户能够创建工作流、脚本文件、资源和 UDF，新建/删除表，同时可以创建发布包，但不能执行发布操作。 role_project_pe project/fuction/resource/instance/job 的所有权限，拥有package 的 read 权限和table 的 read/describe 权限。运维运维角色的用户由项目管理员分配运维权限；拥有发布及线上运维的操作权限，没有数据开发的操作权限。 role_project_deploy 默认无权限部署部署角色与运维角色相似，但是它没有线上运维的操作权限。 role_project_guest 默认无权限访客访客角色的用户只具备查看权限，没有权限进行编辑工作流和代码等操作。 role_project_security 默认无权限安全管理员安全管理员仅在数据保护伞中用到，用于敏感规则配置，数据风险审计等由上表可知，DataWorks角色对应的MaxCompute权限是固定的，一旦某个user通过DataWorks角色获取MaxCompute相关role权限后，又通过命令行方式获得MaxCompute的其他权限，会使该user在MaxCompute的权限与在DataWorks上看到的不一致。用户和权限关系图一个DataWorks项目空间绑定一个MaxCompute project，此时根据DataWorks的项目管理——MaxCompute设置中的“MaxCompute访问身份”这个属性设置决定DataWorks其他项目成员是否拥有MaxCompute project的权限。标准模式，一个DataWorks项目空间绑定两个MaxCompute project，此时固定MaxCompute的project一个是开发项目一个是生产项目，DataWorks其他项目成员根据成员角色拥有MaxCompute 开发project对应的role权限，但没有MaxCompute生产project的权限，MaxCompute 任务需要走发布流程发布到生产project后以owner账号提交到MaxCompute执行。用户与权限管理用户管理操作类型 DataWorks用户管理 MaxCompute用户管理操作描述准确添加和管理用户，应删除或锁定，无属主、闲置以及离职人员的账号权限，严控管理员、运维权限。应删除或锁定，无属主、闲置以及离职人员的账号权限。通过DataWorks新增的用户，注意会可能授权于默认的 role。操作角色项目管理员 owner或admin role 现状查看 DataWorks项目管理页模块的——项目成员管理查看现有成员及角色，并确认各个成员权限的合理性。查看项目下的用户：list users;;查看指定用户拥有的权限：show grants for <username>; 赋权操作 DataWorks项目管理页模块的——项目成员管理添加成员和分配角色。注意：1.只能添加该项目负责人账号下的RAM子账号为项目成员；2.添加一个成员，并分配角色，可能会在MaxCompute 赋予默认的 role 权限。具体可参看前面《MaxCompute & DataWorks用户和权限关系图》小节成员仅加入 MaxCompute project，不在DataWorks 项目成员中体现，且无任何权限。需要结合“对象操作”、“Role 权限”、“label 权限”才能使用，所以应关注成员是否拥有“对象操作”和“label 权限”，并对相应授权进行清理。另外，可以添加云账号和RAM子账号。在项目空间中添加用户:add user <username>; 回退操作清理成员或对应角色权限，删除后，会自动清除对应 MaxCompute 内的 user 和默认 role。在项目空间中移除用户：remove user <username>; 角色管理操作类型 MaxCompute role管理 DataWorks角色管理操作描述准确的创建role并配置role权限，及时清理离职或转岗人员的账号，清理role中不必要开放的资源和权限。MaxCompute project创建成功后除了默认有admin role外，DataWorks还给创建几个role具体可参考前面《成员角色权限关系》小节。准确的分配角色，成员工作性质发生改变需及时改变角色，严格控制项目管理员和运维角色的分配。操作角色 project owner或admin 项目管理员现状查看查看当前project所有role：list roles;查看role中的权限：describe role <role_name>;查看某用户在什么role中：show grants for <username>；查看某个role都指派给哪些user：目前暂不支持！ DataWorks项目管理->成员管理页面，可以点击每个角色查看该角色下的成员。赋权操作 MaxCompute除了默认的role，还可以自定义role，通过命令自定义role权限并将role授权给user。创建role：Create role <role_name>;给角色授权：grant actions on object to <role_name>;添加用户到角色:GRANT <roleName> TO <full_username> ;此外，DataWorks的项目管理->MaxCompute高级配置->自定义用户角色页面，可以通过界面方式创建MaxCompute自定义role、对role进行授权、将role授权给成员，但是注意通过命令行创建的role不会在这个界面显示。 DataWorks角色是固定的不能自定义，成员添加到DataWorks项目时勾选角色分配给成员，该成员既可拥有对应角色的权限。回退操作删除角色中的用户：REVOKE <roleName> FROM <full_username>;撤销对角色的授权：revoke <privList> on <objType> <objName> from role <rolename>;删除角色：DROP ROLE <roleName>;如果是通过DataWorks的项目管理->MaxCompute高级配置->自定义用户角色页面创建的role，也通过这个页面进行回退操作。 DataWorks的角色不能删除，只能将某个成员的角色去掉。 ACL（对象操作）的授权管理操作类型说明操作描述回收非必须必要的对象操作授权，操作权限涉及多种操作对象和类型，应逐一确认。操作角色 project owner或admin role 现状查看查看指定用户的权限：show grants for <username>;查看当前用户的权限:show grants;查看指定对象的授权列表:show acl for <objectName> [on type <objectType>];查看某 package 赋权情况案例:show acl for alipaydw.alipaydw_for_alisec_app on type package; 赋权操作进行某对象的操作赋权：grant actions on object to subject;操作、主体、客体类型表达式：actions 类型： action_item1, action_item2, ...object 类型：project project_name,table schema_name ,instance inst_name ,function func_name ,resource res_namesubject 类型：user full_username ,role role_name操作、主体、客体类型，详细说明请看官方文档。回退操作回收某对象的操作权限：revoke actions on object from subject; Role授权管理操作类型说明操作描述角色(Role)可以打包多个 ACL 权限。当需要对一组用户赋予相同的权限，或者多ACL 权限时，可以使用角色(Role)来授权。操作角色 project owner或admin role 现状查看查看指定角色的赋权内容，以及拥有该权限用户：describe role <rolename>;查看指定用户拥有哪些 role 及 ACL:show grants for <username>;查看当前用户的 role 及 ACL:show grants; 赋权操作 1. 创建角色:create role <rolename>;2. 给用户指派某种角色:grant <rolename> to <username>;3. 给角色打包 ACL，有两种方式：方法一：逐一执行 ACL 授权命令。:grant actions on object to role <rolename>;操作、主体、客体类型表达式：actions 类型： action_item1, action_item2, ...object 类型：project project_name , table schema_name ,instance inst_name , function func_name , resource res_name操作、主体类型，详细说明见官方文档。方法二：新建 policy 文件，将 policy 映射给 role。Put policy <policy 文件所在本地位置> on role <rolename>;案例：PUT POLICY D:\sx_default.txt ON ROLE sx_default; 将存放在 D 盘根目录下的 policy 文件 sx_default.txt，映射给 sx_default 角色；Policy 配置详见《policy 的授权》小节回退操作 1. 删除角色：drop role <rolename>;2. 撤销角色指派:revoke <rolename> from <username>;3. 更改角色打包的 ACL，两种方式：方法一：逐一执行 ACL 更改授权命令。revoke actions on object from role <rolename>;方法二：更改 policy 文件，将新的 policy 映射给 role。Put policy <policy 文件所在本地位置> on role <rolename>; package授权管理操作类型说明操作描述开启 ProjectProtection 的项目，如果没有在同一个互信项目组（TrustedProject Group），则必须使用 package 方式赋权，package 赋权有两种方式。确保package 合理打包和赋权，无闲置 package 赋权。操作角色 project owner 现状查看 1. 了解本项目 Package 创建及赋权情况：查看已创建和已安装的 Package 列表:show packages;查看 Package 详细信息:describe package <pkgname>;2. 本项目安装的 Package ，对用户的授权情况:show acl for <project_name.package_name> on type package; 赋权操作 Package创建者:1. 创建 Package:create package <pkgname>;2. 将分享的资源添加到 Package:add project_object to package package_name [with privileges privileges];project_object 表达式：table table_name ,instance inst_name ,function func_name ,resource res_name3. 许可其他项目空间使用 Package:allow project <prjname> to install package <pkgname> [using label<number>];Package使用者: 1. 安装 Package:install package <pkgname>;2. 将 package 赋权给用户、角色，package赋权给具体用户时，不能指定 label。(project owner 或admin 都可操作)grant actions on package <pkgName> to user <username>;grant actions on package <pkgName> to role <role_name>;actions 类型：参考官方文档，一般将Package的 read权限赋给对象既可满足对象访问package里的资源。回退操作 1. 撤销其他项目空间使用 Package 的许可:disallow project <prjname> to install package <pkgname>;2. 删除 Package:delete package <pkgname>;3. 将分享的资源移出 Package:remove project_object from package package_name;project_object 表达式：table table_name ,instance inst_name ,function func_name ,resource res_name4. 撤销 package 的用户、角色的权限。revoke actions on package <pkgName> from user <username>;revoke actions on package <pkgName> from role <role_name>; Label授权管理操作类型说明操作描述 Maxcompute的字段、表、package 分为 1~4 个等级，应根据用户实际需要，赋予对应的 label 权限。操作角色 project owner 现状查看 1. 查看一个用户能访问哪些敏感数据集:SHOW LABEL [<level>] GRANTS [FOR USER <username>];--省略 [FOR USER <username>]时，查看当前用户所能访问的敏感数据集.--省略<level>时，将显示所有 label 等级的授权；--若指定<level>，则只显示指定等级的授权.2. 查看一个敏感数据表能被哪些用户访问:SHOW LABEL [<level>] GRANTS ON TABLE <tablename>;--显示指定 table 上的 Label 授权3. 查看一个用户对一个数据表的所有列级别的 Label 权限:SHOW LABEL [<level>] GRANTS ON TABLE <tablename> FOR USER <username>;--显示指定用户对指定 table 上列级别的 Label 授权赋权操作 1. 给用户单个表或字段的安全许可标签。GRANT LABEL <number> ON TABLE <tablename>[(column_list)] TO USER <username> [WITH EXP <days>]; --默认过期时间是 180 天举例：GRANT LABEL 2 ON TABLE t1 TO USER alice WITH EXP 1; --显式授权alice 访问 t1 表中敏感度不超过 2 级的数据，授权有效期为 1 天GRANT LABEL 3 ON TABLE t1(col1, col2) TO USER alice WITH EXP 1; --显式授权 alice 访问 t1(col1, col2)中敏感度不超过3 级的数据，授权有效期为 1 天2. 给用户授权整个项目的安全许可标签。SET LABEL <number> TO USER <username>;3. 控制 package 安装者对 package 中敏感资源的许可访问级别ALLOW PROJECT <prjName> TO INSTALL PACKAGE <pkgName> [USING LABEL <number>];--由 package 创建者授权，授予 package 安装者对 package 中敏感资源的许可访问级别4. 将 package 赋权给用户、角色，package 赋权给具体用户时，不能指定 label。grant actions on package <pkgName> to user <username>;grant actions on package <pkgName> to role <role_name>; 回退操作 1. 撤销用户单个表或字段的安全许可标签。【撤销授权】：REVOKE LABEL ON TABLE <tablename>[(column_list)] FROM USER <username>;【清理过期的授权】：CLEAR EXPIRED GRANTS;举例:REVOKE LABEL ON TABLE t1 FROM USER alice;--撤销 alice对 t1 表的敏感数据访问2. 更改用户授权整个项目的安全许可标签，默认等级为 0。SET LABEL <number> TO USER <username>;3. 更改 package 安装者对 package 中敏感资源的许可访问级别，调整为其他级别，默认为 0。ALLOW PROJECT <prjName> TO INSTALL PACKAGE <pkgName> [USING LABEL <number>];4. 撤销 package 的用户、角色的权限。revoke actions on package <pkgName> from user <username>;revoke actions on package <pkgName> from role <role_name>; 安全功能启用设置 ProjectProtection（数据流出保护机制）项目空间的数据保护主要解决“不允许用户将数据转移到项目空间之外”的需求。操作类型说明操作描述设置 ProjectProtection 避免项目批量数据下载到本地电脑，出现批量数据泄露风险。操作角色 project owner 查看现状执行命令：show SecurityConfiguration;查是否 ProjectProtection=true 操作设置设置 ProjectProtection 机制，默认为 false；两个方法设置：DataWorks界面上设置：进入DataWorks项目管理->MaxCompute设置->基本设置页面，把“项目空间数据保护”属性打开。命令行方式执行MaxCompute命令：SET ProjectProtection=true [WITH EXCEPTION <policyFile>];开启后由于部分公共账号，个人用户因种种原因需要数据流出权限，根据需要附带 exception 例外策略（白名单），exception policy具体看升级篇介绍。以下情形建议配置 Exception 策略：1) 需要数据流出权限的应用系统云账号或 IP 地址。2) 个人账号开通白名单，应指定允许下载的表。添加项目互信：对于数据可互通的 project 可以通过项目互信的方式确保数据顺利流转。查看当前project 中的所有 TrustedProjects: list trustedprojects;在当前 project 中添加一个 TrustedProjectadd trustedproject <projectname>;在当前 project 中移除一个 TrustedProject:remove trustedproject <projectname>; 未添加TrustedProject 的项目，申请本项目数据，需要以 package 方式授权。回退操作关闭 ProjectProtection 机制:SET ProjectProtection=false;移除 TrustedProject:remove trustedproject <projectname> ; 开启 Label Security（列及安全控制）基于标签的安全(LabelSecurity)是项目空间级别的一种强制访问控制策略(Mandatory Access Control, MAC)，它的引入是为了让项目空间管理员能更加灵活地控制用户对列级别敏感数据的访问。操作类型说明操作描述打开 LabelSecurity 确保字段级别安全控制生效，项目空间中的 LabelSecurity 安全机制默认是关闭的。操作角色 project owner 查看现状 show SecurityConfiguration;查是否 LabelSecurity=true 操作设置开启 LabelSecurity 机制，默认为 false。Set LabelSecurity=true; 回退操作关闭 LabelSecurity 机制:Set LabelSecurity=false; 操作前，需要确认外部 project 数据的依赖情况，是否赋于了表的 label 权限。合理设置字段的 Label 操作类型说明操作描述 MaxCompute数据的敏感性可以分为 0~4 级。所有数据表，可以设置安全等级，避免数据表出现不合理授权访问情形。查看现状查看 MaxCompute表字段的等级，两个方式:方式一，执行命令：DESCRIBE <tablename>;方式二：在DataWorks的数据管理查看表详情中的字段信息。操作设置给表字段设置安全级别可以通过两种方式：方式一【推荐此方式】：DataWorks的数据管理里，新建表或者编辑已有表的字段信息，均可以设置字段安全级别。（注意，只有Project的LabelSecurity=true，数据管理页面才可见字段安全级别属性。）方式二，执行命令：SET LABEL <number> TO TABLE tablename[(column_list)]; -- number 取值范围:[0, 4]。举例:SET LABEL 1 TO TABLE t1; --设置表 t1 的 label 为 1 级SET LABEL 2 TO TABLE t1(mobile, addr); --将 t1 的 mobile,addr 两列的 label 设置为 2 级SET LABEL 3 TO TABLE t1; --设置表 t1 的 label 为 3 级. 注意此时 mobile,addr 两列的 label 仍为 2 级注意：通过命令行设置自动安全级别后，在DataWorks的数据管理界面，对应表字段安全等级不同步，因此，建议通过DataWorks对表的字段进行安全级别设置回退操作将安全等级调整回原来等级。注意：字段安全等级的上调，会导致原有的授权失效（涉及 package 授权、生产账号和个人账号），调整前必须通知到受影响用户，以减少影响。设置访问Project的IP白名单操作类型说明操作描述设置IP白名单，指定白名单列表中的IP（console或者SDK所在的出口IP）能够访问这个Project。注：1.当前project的所有user（包括主账号）都会受限。 2.DataWorks的机器默认在白名单内，因此通过DataWorks提交MaxCompute任务不会受此限制。操作角色 project owner 查看现状通过console执行命令：setproject;查看对应的‘odps.security.ip.whitelist= ’若等号后面为空则未设置白名单列表操作设置设置前请特别注意：在白名单list加上自己当前机器IP，以免把自己屏蔽。通过console执行命令：setproject odps.security.ip.whitelist=xxx.xxx.xxx.xxx,xxx.xxx.x.x/xx,xxx.xxx.xxx.xxx-xxx.xxx.xxx.xxx; 白名单中IP列表的表示格式有三种。单纯IP：例如101.132.236.134。子网掩码：100.116.0.0/16。网段：101.132.236.134-101.132.236.144。设置IP白名单后，您需要等待五分钟后才会生效。若需更精细化管理，也可以通过policy授权，可参考后面的案例《project Policy 案例》。回退操作 IP白名单清空后，MaxCompute就认为Project关闭了白名单功能。setproject odps.security.ip.whitelist=; 设置禁止DataWorks的select结果下载到本地操作类型说明描述开发者通过DataWorks进行数据分析，通常会屏显在IDE上并且可以下载结果。project设置ProjectProtection为true后，在本project中只要有表的读取权限，依然可以通过DataWorks的开发界面select后进行结果下载。操作角色 DataWorks管理员查看现状进入DataWorks的项目管理->项目设置页面，查看“在本项目中能下载select结果”属性是否打开。操作设置进入DataWorks的项目管理->项目设置页面，关闭“在本项目中能下载select结果”开关。回退操作进入DataWorks的项目管理->项目设置页面，打开“在本项目中能下载select结果”开关。如何通过其它云服务提高安全管理使用MaxCompute过程中，会关联使用到其他的云服务，因此也需要考虑通过其他云服务提高MaxCompute的安全管理。本章节主要介绍通过DataWorks使用MaxCompute时，添加项目成员必须会用到RAM子账号，那么如何在RAM子账号服务上提高安全管理。前面《MaxCompute安全模型》章节中提到MaxCompute的用户认证“支持云账号和 RAM 账号两种账号体系，对于RAM账号，仅识别账号体系不识别RAM权限体系，即可将主账号自身的任意 RAM 子账号加入 MaxCompute 的某一个项目中，但 MaxCompute 在对该 RAM 子账号做权限验证时，并不会考虑 RAM 中的权限定义。” 因此，我们只需要从RAM子账号登录验证入手进行安全控制。子账号密码强度设置如果您允许子用户更改登录密码，那么应该要求他们创建强密码并且定期轮换。您可以通过 RAM 控制台设置密码策略，如最短长度、是否需要非字母字符、必须进行轮换的频率等等。子账号登录掩码设置通过设置网络掩码决定哪些IP地址会受到登录控制台的影响，子用户必须只能从指定的IP地址进行登录。及时撤销用户不再需要的权限当一个子账号对应员工由于工作职责变更而不再使用权限时，应该及时将对应子账号的权限撤销。案例具体请看《MaxCompute安全管理指南-案例篇》。更多MaxCompute的相关问题讨论可以加入钉钉群与众多开发者一起讨论：

发表了文章 2017-12-21

MaxCompute Studio使用心得系列6——一个工具完成整个Python UDF开发

2017/12/20 北京云栖大会上阿里云MaxCompute发布了最新的功能Python UDF，万众期待的功能终于支持啦，我怎么能不一试为快，今天就分享如何通过Studio进行Python udf开发。前置条件了解到，虽然功能发布，不过还在公测阶段，如果想要使用，还得申请开通：https://page.aliyun.com/form/odps_py/pc/index.htm。这里我就不介绍申请开通具体流程了。环境准备 MaxCompute Studio支持Python UDF开发，前提需要安装python, pyodps和idea的python插件。安装Python：可以Google或者百度搜索下如何安装。安装pyodps：可以参考python sdk文档的安装步骤。即，在 Python 2.6 以上（包括 Python 3），系统安装 pip 后，只需运行下 pip install pyodps，PyODPS 的相关依赖便会自动安装。 Intellij IDEA中安装Python插件。搜索Python Community Edition插件并安装配置studio module对python的依赖。 File -> Project structure，添加python sdk: File -> Project structure，添加python facets: File -> Project structure，配置module依赖python facets: 开发Python UDF 环境都准备好后，既可在对应依赖的module里创建进行python udf开发。新建python脚本。右键 new | MaxCompute Python，弹框里输入脚本名称，选择类型为python udf：生成的模板已自动填充框架代码，只需要编写UDF的入参出参，以及函数逻辑：本地调试代码开发好后，可以在Studio中进行本地调试。Studio支持下载表的部分sample数据到本地运行，进行debug，步骤如下: 右键python udf类，点击”运行”菜单，弹出run configuration对话框。UDF|UDAF|UDTF一般作用于select子句中表的某些列，此处需配置MaxCompute project，table和column（元数据来源于project explorer窗口和warehouse下的example项目）: 点击OK后，通过tunnel自动下载指定表的sample数据到本地warehouse目录（若之前已下载过，则不会再次重复下载，否则利用tunnel服务下载数据。默认下载100条，如需更多数据测试，可自行使用console的tunnel命令或者studio的表下载功能）。下载完成后，可以在warehouse目录看到下载的sample数据。这里用户也可以使用warehouse里的数据进行调试，具体可参考java udf开发中的关于本地运行的warehouse目录”部分）。然后本地运行框架会根据指定的列，获取data文件里指定列的数据，调用UDF本地运行。注册发布Python UDF 代码调试好后，将python脚本添加为MaxCompute的Resource：注意此处选择的MaxCompute project必须是已经申请开通python udf的project。注册python 函数：在sql脚本中编辑MaxCompute sql试用python udf: 好了，一个简单完整的python UDF通过Studio开发实践分享完成。更多python UDF可以参考其他文章: 北京云栖大会MaxCompute又出大招，Python UDF抢先体验! Python on MaxCompute之UDF操作命令行 Python实现MaxCompute UDF/UDAF/UDTF 使用MaxCompute的pyodps和Studio有疑惑可以工单咨询，更多探讨可以加入对应钉钉群一起畅聊：

发表了文章 2017-12-12

MaxCompute Studio 2.8.2 新版本发布啦！

新特性概览新功能可视化建表；历史job日志保存，查看本地job日志文件。查看历史通过studio提交运行的sql。重点优化项优化Editor性能，解决大脚本文件实时编译卡顿问题。可编辑代码模板。 Builtln Functions更新2.0扩展的函数。新功能介绍可视化建表提供可视化建表，更全面的对MaxCompute数据表进行管理。在project explorer右击项目，选择“Create a new table”，在弹框里填写好tablename、comment、column，点击“Generate CreateTable Statement”生成建表语句后，点击“Excute”执行建表语句。历史job日志保存、查看 MaxCompute的日志logview默认保留7天，若需要查看7天前的job日志，目前只能查看job基本信息，很多详细日志已经无法查看。Studio2.8.2版本开始支持用户自定义将logview日志文件保存到本地，并随时可以通过Studio进行可视化查看。保存日志文件到本地 job explorer打开的或者脚本执行过程打开的logview，可以点击工具栏上的“Save”按钮：文件将会自动保存到本地，可以配置默认保存目录。进入Settings/MaxCompute Studio 页面（Windows Ctrl-Alt-S, Mac ⌘,）：查看本地日志文件菜单栏MaxCompute -> 打开LogView，选择“使用导出后的日志文件”：历史执行的SQL Studio上开发的SQL脚本默认是离线开发，保存在本地，没有版本管理，2.8.2版本开始，通过Studio执行的sql内容将会被记录并随时查看。打开任意sql脚本文件，单击工具栏上“SQL History”：可以通过筛选查看该sql脚本执行过的历史sql列表。更多变更请在更新插件时查看插件说明，有任何问题欢迎查阅文档或提工单或加入钉钉群交流。

发表了文章 2017-12-06

MaxCompute Studio使用心得系列5——一个工具完成整个JAVA UDF开发

MaxCompute提供了丰富的内置函数，但是依然还是无法满足所有业务，所以自定义函数在所难免。 MaxCompute目前支持的UDF主要是JAVA UDF，但是原来的客户端console和大数据开发套件都不支持JAVA编辑，只能先在自己机器的java环境中编辑测试好，然后输出jar包，再通过console或大数据开发套件将jar包添加成resource，最后再注册成function。整个过程需要跨工具平台，且JAVA环境还需配置好MaxCompute提供的Eclipse插件，流程长耗时多。本文分享通过MaxCompute Studio 进行UDF开发，从环境准备到JAVA代码开发、调试、打jar包/添加MaxCompute resource/注册函数整个过程一气呵成。操作步骤步骤一：MaxCompute Studio安装再此不赘述。步骤二：创建 MaxCompute Java Module。依次点击 File | new | module module类型为'MaxCompute Java'，配置Java JDK。点击next，输入module名，点击finish。 studio会帮用户自动创建一个maven module，并引入MaxCompute相关依赖（具体请查看pom文件），相关module结构说明详见文档。步骤三：开发java udf代码。在已创建的 MaxCompute Java Module 目录，导航至 src ->main ->java -> new: 若想先创建package可以选择package，创建好后再在这个package下创建MaxCompute java，name直接输入文件名称。也可以直接选择MaxCompute java然后name里输入‘package名称.文件名’，如下图。Kind都选择UDF。创建文件后，既可进行java代码编辑。如快速入门 > UDF代码示例：步骤四：本地调试，代码调试可以进行单元测试和本地运行，具体请看UDF调试文档，在此不赘述。步骤五：注册MaxCompute UDF。调试好后右击UDF的java文件，选择‘Deploy to server’，弹框里选择注册到那个MaxCompute project，输入function name，Resource name也可以修改。点击ok，操作成功的话，会同时生成jar包、将jar包提交为Resource、创建对应的function。可以在project元数据中查看到步骤六：试用UDF。打开sql脚本，执行代码如select Lower_test('ABC');结果如下图：好了，整个UDF开发过程只通过MaxCompute Studio就可以完成了。以上操作步骤给的例子是一个UDF只需引用一个jar包资源的情况。如果还需引用其他的资源，那么jar包需要先导出，然后再添加成Resource，其他的资源也添加成Resource，最后再添加UDF，大致步骤如下：修改pom.xml打包相关配置，导出jar包。File -> Project Structure->Artifacts新增JAR包，导出jar包到本地。添加资源。选择资源文件（本地的jar包，或者其他资源文件）创建UDF。需要多个资源时，在using resources列表可以选择多个资源。欢迎加入Studio钉钉用户群一起交流经验！

发表了文章 2017-11-14

MaxCompute Studio使用心得系列4——可视化查看所有job并分析运行情况

在使用MaxCompute的时候，很多同学会关注当前项目有多少任务在执行，哪些任务耗时长，哪些任务已经完成，并且能通过任务的logview来分析任务耗时长的原因。 ofo的同学选择自己搭建任务管理平台通过sdk函数获取MaxCompute 相关job信息进行管理。如《MaxCompute的任务状态和多任务执行》所分享。其他的没有精力自己搭建平台，可以通过show p -all;命令查看所有job，再通过wait instanceid;查看这个job的logview，最后通过logview再查看具体的执行日志。如《如何在客户端上追踪一个任务信息》所介绍。今天我要分享的是通过MaxCompute Studio可以可视化查看项目想的所有job并分析运行情况。具体操作如下：查看某个项目下，过去24小时的所有job列表，并查看那些job耗时最长。进入Studio的job explorer选项卡，选择需要查看的项目（该项目链接必须已经配置好，可以参考《项目空间连接管理》）；状态选择’全部作业‘；提交者选择’任何人‘（项目owner肯定有权限，其他同学有project的list权限也可以否则只能看自己提交的job）：在查询结果列表中，点击“总时长”进行高到低排序既可得出上图列表。注意，界面最多显示满足条件的前1000条记录。假如只想看正在活动的作业，可以过滤状态：假如还想看更长久的作业，可以过滤日期：查看耗时最长的job的具体运行情况。可以直接双击查询列表中总时长按高到低排列后时长最高的job，既可打开该作业的详情显示区。注意，如果job已经超过7天，详情中只能查看基本的一些基本信息包括脚本信息。在作业详情显示区，如果该job没超过7天，那么可以查看详细的执行过程日志，具体分析操作参考可以上一篇的分享《MaxCompute Studio使用心得系列3——可视化分析作业运行》。假如你查看的是running状态的job详情，还可以进行kill操作非常方便。如果从其他途径知道了某个logview地址，也可以通过Studio直接打开这个logview进行分析：好了，想可视化查看所有job以及job的具体运行信息，就分享到这。若能通过instance id搜索想看的job，以及通过脚本内容关键字搜索哪些job执行过这些内容就更好了！

发表了文章 2017-11-09

MaxCompute Studio使用心得系列3——可视化分析作业运行

上一篇写分享了通过MaxCompute Studio 编写sql脚本时“编译”功能带来的便捷，这次分享脚本编译好提交运行后，自助查看作业的执行情况。我们很熟悉的是通过logview，去分析作业的执行情况，logview上有很详细的执行日志，而Studio不仅仅提供可视化的信息，还会明确给出一些分析结论如job是有否长尾或数据倾斜情况。比如我写完一个sql脚本，编译成功接着执行脚本，Studio自动打开当前job的执行详细信息页面，包括job基本信息列表、详情展示和分析区（执行计划图、时序图、分析等）如上图，job执行失败：界面底部RUN日志中打出具体的错误信息。详情展示区默认显示执行计划图，可以看到子任务的依赖关系，双击每一个子任务节点图，可以展开更详细的信息。即使是失败的job，也可以切换到分析tab查看具体结论，如本次执行，job有长尾。可以点击具体的长尾节点查看该节点的长尾图进一步分析，相关长尾调优可以参考文档计算长尾调优。修改好sql脚本，再执行，执行成功如下图：成功的任务我们依然可以分析很多信息，比如查看那个任务task耗时热点：点击下面的进度条可以回放整个job执行的过程可以查看耗时最长的前10个节点可以查看每个子任务执行过程所有fuxi instance各种I/O信息：同样的可以看到分析信息，看是否还有可优化的点。怎么样，这样看日志是不是感觉更容易理解了呢！对了，MaxCompute Studio也有用户钉钉支持群：

发表了文章 2017-10-30

MaxCompute Studio使用心得系列2——编译SQL脚本

开发人员写好代码，对代码进行语法编译是很常见的操作，但是目前常用的MaxCompute sql开发工具（大数据开发套件和console客户端），都没有该功能，必须把sql脚本提交运行后若有语法问题才会通过返回错误日志中获取相关信息。 MaxCompute每次提交job都要少则几秒多则数分钟不等的排队过程，等返回失败信息，也需要等待一定的时间，不仅仅影响开发效率，还浪费计算资源。本次分享通过MaxCompute Studio 进行SQL脚本开发过程中“编译”功能带来的便利。前提条件：Project Explorer窗口中必须添加好项目，即添加项目元数据。语法检查与错误提示 Studio脚本编辑功能与 MaxCompute 编译器高度整合，能够在脚本编辑过程中实时进行语法检查，并通过特殊高亮及 tips 文本给出错误提醒。便于开发人员快速排错，提前对位问题。如上图所示，select * from abc;这个简单的语句，abc是表名，但在该脚本所属的MaxCompute project中，表是不存在的，因此该表名字体变成红色高亮，鼠标移至上方会显示 table hntest.abc cannot be resolved。不仅仅能检查到表是否存在，列是否存在也可以检查到，如下图所示：潜在风险提示由于 MaxCompute 语法及数据类型转换的灵活性。很多情况下，书写的脚本没有语法错误，但也没有得到想要的结果。针对这个痛点，Studio 结合脚本的编译结果，给出相应的 WARNING 提示，将脚本中潜在的风险在开发和调试阶段给出提醒，防患于未然。 Studio 对相关风险部分给予语法高亮或添加背景色展示并给出详细说明，如：本地编译与错误定位 Studio 提供本地编译脚本功能，在提交到服务器上运行之前在本地进行必要的语法检查、类型检查等，编译过程信息通过 Messages MaxCompute View 展现: 双击编译结果窗口中的 Log Item，可以快速定位到脚本的对应行列位置，直接进行修复。假如我一直忽视了编译功能给我的各种语法错误检查结果，也没有操作本地编译，直接在MaxCompute Studio上运行有语法错误的脚本，MaxCompute Studio依然尽职尽责的先把我提交的脚本进行本地编译，然后给我提示：好了，先分享到这，MaxCompute Studio编译功能还会给我们带来多少惊喜，需要多实践才能多发现！

发表了文章 2017-10-26

MaxCompute Studio使用心得系列1——本地数据上传下载

MaxCompute Studio已经发布好久，一直没能好好体验，近期MaxCompute Studio 陆续推出很多好用的功能，今天开始给大家分享使用心得。用过大数据开发套件的同学，对于本地数据上传下载，都会遇到这样的问题： ‘导入本地数据’功能，限制本地数据文件大小最大为10MB；查询结果导出本地时，由于select语句返回结果最大为10000行的限制，最多只能导出1W数据；数据导出本地文件的功能只有‘查询结果导出本地’。要解决以上问题，通常都是需要自己安装console客户端，通过tunnel命令进行导入导出。现在来分享使用MaxCompute Studio工具界面，可以更轻松完成tunnel命令能完成的本地数据导入导出工作。 MaxCompute Studio工具安装请参考文档安装 IntelliJ IDEA、安装MaxCompute Studio. 本地数据导入前提条件：表、分区已经存在，操作人有权限对表进行数据写入。进入MaxCompute Studio的Project Explorer窗口，展开Data Preview，鼠标对需要导入数据的表右键，选择 Import data into table 弹出的框里选择上传的本地数据文件路径、分区（非分区表无需填）、分隔符、行数限制、大小限制等：注意：大小限制（Size Limit）不限于10MB。点击OK后可以看右下角进度条，最终成功与否会在Event Log里可查看相关日志。导入成功日志中会给出写入成功的行数和写入失败的行数。如：上午10:35 Success: Import to table tablename from file /Users/.../Documents/.../t_data.txt finished, success [ 220977 ], failed [ 0 ]. 数据导出本地前提条件：操作人有权限对表进行数据导出。进入MaxCompute Studio的Project Explorer窗口，展开Data Preview，鼠标对需要导入数据的表右键，选择 Export data from table 弹出框输入导出文件地址包括文件名文件类型（CSV或TXT）、选择需要下载的分区（非分区表直接下载整张表）、导出行数限制、大小限制等。注意：行数不限于10000行，大小不限于10MB，可以下载整张非分区表或分区表的整个分区。点击OK后可以看右下角进度条，最终成功与否会在Event Log里可查看相关日志。导出成功日志中会给出导出成功的行数和导出失败的行数。如：上午10:47 Success: Export from table tablename to file /Users/..../Desktop/... finished, success [ 220977 ], failed [ 0 ]. 结束语：MaxCompute Studio中上述的本地数据导入导出功能实际上就是采用 MaxCompute Tunnel 服务，功能与Tunnel命令一样。

发表了文章 2017-09-01

阿里云大数据计算服务MaxCompute（原ODPS）华南1（深圳）Region即将开服！

2017年9月7日，阿里云数加·MaxCompute（原ODPS）华南1（深圳）数据中心正式开服售卖，这是数加·MaxCompute在国内开服的第二个区域。届时MaxCompute将会针对新服开展促销活动，具体活动规则敬请期待！关于售价华南1区域价格与华东2一致，主要收费分3部分：存储、计算、下载，其中计算（指SQL和MR计算任务）分预付费、按量后付费两种模式，存储和下载都是按量后付费。做预算的具体的售价信息请看官网定价页或《计量计费文档》。关于开通确保云账号是实名认证的账号，在开通购买页面区域选择时，注意选择华南1。那么什么场景适合选择区域是华南1呢？选择地域时，您需要考虑的最主要因素是MaxCompute与其他阿里云产品之间的关系，如： ECS在华南1区域。ECS访问、下载华南1的MaxCompute数据都可以通过内网，快速又避免跨region走公网下载产生费用。数据在华南1区域。如RDS、OSS、TableStore等在华南1区，那么在和华南1的MaxCompute进行数据传输时可以走内网，避免跨Region配置阿里云内网或VPC网络时不保证连通性的情况。对开通购买华南1Region有疑惑，欢迎提交工单或者加入“数加·MaxCompute购买咨询”钉钉群（群号： 11782920）进行咨询，群二维码如下：关于不同区域数据是否互通仅针对MaxCompute而言，假如您即购买华东2又购买华南1的服务，那么MaxCompute之间的数据不互通。当您云服务器ECS不在华南1，要访问连接华南1的MaxCompute，跨region访问各种服务连接请参考《访问域名和数据中心》。关于数据跨Region迁移若您原来已经开通购买华东2区域，目前想使用华南1区域，但由于两个区域数据不能互通，所以希望将华东2的所有数据迁移到华南1。迁移方式建议：通过配置数据集成任务进行数据同步，如在华南1区创建好的项目中配置数据集成任务读华东2区表写华南1区的表，如遇到问题请提工单咨询。

发表了文章 2017-07-05

MaxCompute分区表和非分区表使用对比

本文我们将通过对有同样数据量、表结构除分区列其他都一模一样的表,从查询计算、写入、删除数据几个简单操作进行对比，了解MaxCompute分区表和非分区表在使用上有什么差异。在介绍之前，需要大家先了解MaxCompute分区的概念。数据准备分区表：取公共数据集中的表dwd_prouduct_house_basic_info_out（二手房产数据集）；非分区表：执行建表语句： create table dwd_prouduct_house_basic_info_out_npt as select * from public_data.dwd_prouduct_house_basic_info_out; 创建表的同时将源表的所有数据都复制到新表dwd_prouduct_house_basic_info_out_npt中。由于create table … as select … 语句创建的表不会复制分区属性，只会把源表的分区列作为目标表的一般列处理，所以新表dwd_prouduct_house_basic_info_out_npt为非分区表。可以分别执行select count(*) from public_data.dwd_prouduct_house_basic_info_out; 和 select count(*) from dwd_prouduct_house_basic_info_out_npt;查看这两个表的记录数会是一样。本次操作表的记录数为1147676063条。计算对比我们执行一个简单的查询某个分区数据的job： Select * from public_data.dwd_prouduct_house_basic_info_out where ds= '20170113';--分区表查询 Select * from dwd_prouduct_house_basic_info_out_npt where ds= '20170113';--非分区表查询计算时长对比计算资源充足的情况下进行操作。分区表里查询使用时间1秒，： ![image](https://yqfile.alicdn.com/f0b14b6c41c665568e53cff9ce2bf01fd29ae212.png) 直接在对应分区中取出该分区所有数据。非分区里表查询：加上job等待时间共1分15秒 ![image](https://yqfile.alicdn.com/470444f8b68cf80ce9d4e11e48f59a5b5f17c549.png) 真正执行时长53秒 ![image](https://yqfile.alicdn.com/cf8dfc1ef56a50b6be4eeda8055491cea96f9530.png) 需要在整个表1147676063条记录中取出满足条件的数据。 ![image](https://yqfile.alicdn.com/157dad8d5793761cbaa95e30d8cc340f23e0bccc.png) 计算费用对比我们可以直接通过大数据开发套件->“数据开发”工作区中的“成本估计”对两条查询语句进行费用预估，该预估功能采用的计费公式可参考“[计量计费->I/O后付费](https://help.aliyun.com/document_detail/27989.html)”。若采用计算预付费模式，可不用在意该计算费用。下图是通过成本估计功能预估的费用，结果显示在非分区表中查询一样条件的数据会花费更多，当然最终花费还得看最后的账单。 table size对比由于MaxCompute存储压缩比不一定完全一致，两个表数据在MaxCompute的size也会有一定的差异。 desc public_data.dwd_prouduct_house_basic_info_out; 分区表执行结果如下图： desc dwd_prouduct_house_basic_info_out_npt; 非分区表执行结果如下图：写入对比创建三个表，表结构除了分区列，其他都一致：非分区表， create table house_test_npt(house_id string , house_total_price string , house_unit_price string , house_type string , house_floor string , house_direction string , house_deckoration string , house_area string , house_community_name string , house_region string , house_city string, ds string) 以时间为分区的分区表 create table house_test_pt_1(house_id string , house_total_price string , house_unit_price string , house_type string , house_floor string , house_direction string , house_deckoration string , house_area string , house_community_name string , house_region string , house_city string ) partitioned by ( ds string) 以时间为一级分区，城市为二级分区的分区表 create table house_test_pt(house_id string , house_total_price string , house_unit_price string , house_type string , house_floor string , house_direction string , house_deckoration string , house_area string , house_community_name string , house_region string ) partitioned by (ds string , house_city string) 分别执行3个insert语句，源表取一模一样的数据，即select分句一模一样： insert overwrite table house_test_npt select house_id,house_total_price,house_unit_price,house_type,house_floor,house_direction,house_deckoration,house_area,house_community_name,house_region,house_city,ds from public_data.dwd_prouduct_house_basic_info_out where ds ='20170114';--写入非分区表 insert overwrite table house_test_pt_1 partition (ds='20170114') select house_id,house_total_price,house_unit_price,house_type,house_floor,house_direction,house_deckoration,house_area,house_community_name,house_region,house_city from public_data.dwd_prouduct_house_basic_info_out where ds ='20170114';--写入一级分区表 insert overwrite table house_test_pt partition (ds='20170114',house_city) select house_id,house_total_price,house_unit_price,house_type,house_floor,house_direction,house_deckoration,house_area,house_community_name,house_region,house_city from public_data.dwd_prouduct_house_basic_info_out where ds ='20170114';--使用动态分区方式写入二级分区表对比执行过程：非分区表，一个task，耗时41s： ![image](https://yqfile.alicdn.com/d1ac9fe2ebcfc6c664a872a20490d937ffb2391a.png) 一级分区表，一个task，耗时41s： ![image](https://yqfile.alicdn.com/6e3ef3aa8672220c78f7d5ca708a4784b9458011.png) 二级分区表，第二级分区值为动态输入，2个task，最长task耗时1分31秒： ![image](https://yqfile.alicdn.com/359afdc276eb8b2d3552e79649204048a9309b2c.png) 数据删除操作对比假设要删除表某一天的数据，由于MaxCompute不支持delete语法，我们需要通过别的方式进行数据删除。分区表只需要通过alter语句drop对应分区即可，如下删除分区为20170112的数据： ALTER TABLE public_data.ods_enterprise_share_basic DROP IF EXISTS PARTITION (ds='20170112'); 非分区表，需要将不需要删除的数据查询出来并覆盖写入方式写回表中，增加了计算量。 INSERT OVERWRITE TABLE dwd_prouduct_house_basic_info_out_npt SELECT * FROM dwd_prouduct_house_basic_info_out_npt WHERE ds<>'20170112';

发表了文章 2017-06-15

【大数据开发套件调度配置实践】——调度任务各种周期配置和调度形态

数加·大数据开发套件目前支持任务调度周期有五种：天、周、月、分钟、小时。本文将介绍这五种周期的配置和调度形态。调度规则——调度任务是否能运行起来要满足的条件：上游任务实例是否都运行成功。若所有上游任务实例都运行成功则触发任务进入等待时间状态。任务实例定时时间是否已经到。任务实例进入等待时间状态后会check本身定时时间是否到，如果时间到了则进入等待资源状态；当前调度资源是否充足。任务实例进入等待资源状态后，check当前本项目调度资源是否充足，若充足则可以运行起来。天调度任务天调度任务，即每天自动调度运行一次，运行时遵循调度规则。新建调度任务时，调度周期默认就是天调度。具体时间默认是00:00:00，可自行指定，当然指定具体时间后依然需要遵循调度规则进行起调，不一定就能在指定的时间马上运行起来。场景：3个任务——导入、统计加工、导出，都是天任务，具体时间如上图13点；统计加工任务依赖导入任务，导出任务依赖统计加工任务，依赖配置如下图（‘统计加工任务’的依赖属性配置上游任务为‘导入任务’）：这样的配置自动调度形态如下：周调度任务周调度任务，即每周周N那天会自动调度运行一次，运行时遵循调度规则；没指定的每天也都会生成自动调度实例但是是空跑实例，即调度到的时候直接返回成功状态不会真正执行任何逻辑，也不会占用资源。如上图中，每周一、周五两天生成的实例会正常的调度执行，而周二、三、四、六以及周日5天都是生成空跑实例。注意：这个任务提交后，想进行调度测试，选择业务日期的时候，只有选择“周日”或“周四”的日期，生成的测试实例可以真正运行的实例，选择其他业务日期生成的实例都是空跑实例。任务的自动调度形态如下：月调度任务周调度任务，即每月指定的日期那天会自动调度运行一次，运行时遵循调度规则；没指定的日期每天也都会生成自动调度实例但是是空跑实例，即调度到的时候直接返回成功状态不会真正执行任何逻辑，也不会占用资源。如上图中，每月1日生成的实例会正常的调度执行，其他日期每天都是生成空跑实例。注意：这个任务提交后，想进行调度测试，选择业务日期的时候，只有选择每个月最后一天的日期生成的测试实例才能真正运行，其他业务日期生成的实例都是空跑实例。目前系统不支持配置“每月最后一天”，调度周期—选择时间若选“每月31日”那么只有那个有31日的月份会有一天真正调度，其他都是空跑。若是需要统计汇总每个月的数据，正常情况就是配置每月一日调度，代码逻辑里写定义处理上个月的数据。上图的配置，任务自动调度形态如下：分钟调度任务分钟调度任务，即每天指定的时间段内，每隔N（5的倍数）分钟自动调度运行一次，运行时遵循调度规则。如上图，表示每天00点整到23点59分这个时间段内，每隔30分钟会自动调度一次。开始时间、结束时间的“时”可以调整，比如可以调整为每天08点——20点59分，每隔30分钟执行一次。上图的配置，调度形态如下：小时调度任务小时调度任务，即每天指定的时间段内，每隔N（1的倍数）分钟自动调度运行一次，运行时遵循调度规则。如上图，表示每天00点整到23点59分这个时间段内，每隔6小时会自动调度一次。开始时间、结束时间的“时”可以调整，比如可以调整为每天08点——20点59分，每隔1小时执行一次。上图的配置，调度形态如下：

发表了文章 2017-06-14

【大数据开发套件调度配置实践】——不同周期任务依赖配置

大数据开发过程中常遇到不同运行周期的任务进行依赖，常见天任务依赖小时任务、小时任务依赖分钟任务。那么如何通过大数据开发套件开发这两种场景呢？本文将从这两个场景出发，结合调度依赖/参数/调度执行等，介绍不同周期调度依赖的最佳操作实践。再此之前，我们先明确几个概念：业务日期：业务数据产生的日期，这里指完整一天的业务数据。在大数据开发套件里任务每天能处理的最近的完整一天业务数据是昨天的数据，所以业务日期=日常调度日期-1天。依赖关系：依赖关系是描述两个或多个节点/工作流之间的语义连接关系，其中上游节点/工作流的运行状态可以影响下游节点/工作流的运行状态，反之则不成立。调度实例：大数据开发套件的调度系统对周期任务进行调度执行时，会先根据任务的配置进行实例化，每个实例带上具体的定时时间、状态、上下游依赖等属性。注意：目前数加大数据开发套件每天自动调度的实例都是在昨天晚上23:30生成。调度规则：调度任务是否能运行起来要满足的条件：上游任务实例是否都运行成功。若所有上游任务实例都运行成功则触发任务进入等待时间状态。任务实例定时时间是否已经到。任务实例进入等待时间状态后会check本身定时时间是否到，如果时间到了则进入等待资源状态；当前调度资源是否充足。任务实例进入等待资源状态后，check当前本项目调度资源是否充足，若充足则可以运行起来。天任务依赖小时任务业务场景系统需求统计截止到每小时的业务数据增量，然后在最后一个小时的数据汇总完成后需要一个任务进行一整天的汇总。需求分析 1）每个小时的增量，即每整点起任务统计上个小时时间段的数据量。需要配置一个每天每整点调度一次的任务，每天最后一个小时的数据是在第二天第一个实例进行统计。 2）最后的汇总任务为每天执行一次，且必须是在每天最后一个小时的数据统计完成之后才能执行，那么需要配置一个天任务，依赖小时任务的第一个实例。分析得出的调度形态如下图：但是，真正如上图调度任务定义那样配置调度依赖后，调度任务实例并没有得到上图的效果，而是如下图：上图中，天任务必须等小时任务当天其他所有实例也执行完成才能执行，而需求是天任务只需依赖小时任务第一个实例，此效果明显不能满足需求。要达到该场景需求，此时就需要结合任务“跨周期依赖”进行配置，可以将小时任务“跨周期依赖”属性配置成“自依赖”，然后天任务配置定时时间为零点整，且依赖属性配置依赖小时任务。分析得出的最终方案调度形态如下图：此时，小时任务的实例为串行执行，第一个实例能执行成功，可保证它前面（昨天）的实例都已经执行成功，因此天任务可以只需要依赖第一个实例。配置实践小时任务的调度配置如下图：天任务的调度配置如下图：参数配置：小时任务每整点实例处理前一小时的数据，如可以用$[yyyy-mm-dd-hh24-1/24]，天任务若时间格式为yyyymmdd，用${bdp.system.bizdate}；若时间格式为yyyy-mm-dd，用自定义参数$[yyyy-mm-dd-1]，具体视详细设计而定。参数配置如下图所示：测试/补数据/自动调度测试和补数据：都是手动生成的调度实例，选择的是业务日期。如选择业务日期为 2017-01-10：天任务实例的定时时间是 2017-01-11 00:00:00；小时实例的定时时间是 2017-01-11 00:00:00 至 2017-01-11 23:00:00； ${bdp.system.bizdate} 赋值结果为 20170110（实例定时间年月日减1天）； $[yyyy-mm-dd-hh24-1/24] 赋值结果为 2017-01-10-23 至 2017-01-11-22（实例定时间年月日时减1小时）。自动调度：调度系统自动生成的实例，每天的实例定时时间都是当天，如“需求分析”中的最终方案效果图。小时任务依赖分钟任务业务场景已经有任务每 30 分钟进行一次同步，将前 30 分钟的系统数据增量导入到 MaxCompute，任务定时为每天的每个整点和整点 30 分运行。现在需要配置一个小时任务，每 6 个小时进行一次统计，即每天分别统计 0 点到 6 点之间、6 点到 12 点之间、12 点到 18 点之间、18 点到明天 0 点整之间的数据。需求分析 1）分钟任务： 00:00 实例同步的是昨天最后 30 分钟的数据，产出的表分区如“昨天日期年-月-日-23:30”； 00:30 实例同步的是今天 00:00-00:30 之间的数据，产出的分区如“今天日期年-月-日-00:00”； 01:00 实例同步到是今天 00:30-01:00 之间的数据，产出的分区如“今天日期年-月-日-00:30”；以此类推， 23:30 实例同步的是今天 23:00-23:30 之间的数据，产出的分区如：“今天日期年-月-日-23:00” 2）小时任务：每 6 个小时进行一次统计，则一天调度 4 次；统计 0 点到 6 点之间的数据，则依赖分钟任务当天的 00:30—6:00 共 12 个实例；统计 6 点到 12 点之间的数据，则依赖分钟任务当天的 6:30—12:00 共 12 个实例；统计 12 点到 18 点之间的数据，则依赖分钟任务当天的 12:30—18:00 共 12 个实例；统计 18 点到第二天 0 点之间的数据，则依赖分钟任务当天的 18:30—23:30 以及第二天 00:00 共 12 个实例。分析得出的调度形态如下图：但是，真正如上图调度任务定义那样配置调度依赖后，调度任务实例并没有得到上图的效果，而是如下图：如上图，10 日 18 点到 11 日 0 点之间的数据，11 日小时任务 0 点整点实例只依赖了分钟任务 11 日 0 点整实例，不能确保分钟任务 10 日 18:30 至 23:30 的实例是否执行成功。要达到该场景需求，此时就需要结合任务“跨周期依赖”进行配置，可以将分钟任务“跨周期依赖”属性配置成“自依赖”，然后小时任务依赖属性配置依赖小时任务。分析得出的最终方案调度形态如下图：此时，分钟任务的实例为串行，每个实例能执行成功，可保证它前面（或昨天）的实例都已经执行成功，因此小时任务每个实例可以只需要依赖分钟任务定时时间离它最近（小于等于）的一个实例。配置实践分钟任务的调度配置如下图：小时任务调度配置如下图：参数配置：分钟任务每个实例处理前面30分钟数据产出的分区可以用参数如 $[yyyy-mm-dd-hh24:mi-30/24/60] , 具体视详细设计而定。配置类似下图：测试/补数据/自动调度测试和补数据：都是手动生成的调度实例，选择的是业务日期。如选择业务日期为 2017-01-10：分钟任务实例的定时时间是 2017-01-11 00:00:00 至 2017-01-11 23:30:00，共 48 个实例；小时实例的定时时间是 2017-01-11 00:00:00、06:00:00、12:00:00、18:00:00 共 4 个实例； $[yyyy-mm-dd-hh24:mi-30/24/60] 赋值结果为 2017-01-10-23:30 至 2017-01-11-23:00（实例定时间年月日时分减 30 分钟）。自动调度：调度系统自动生成的实例，每天都实例定时时间都是当天，如“需求分析”中的最终方案效果图。总结长周期任务依赖短周期任务时，如果短周期有自依赖：当天的调度实例中，长周期任务的每个实例只依赖短周期实例中定时时间与它最近（且小于）的一个实例。长周期任务（小时）依赖短周期任务（分钟）时，如果短周期无自依赖：当天的调度实例中，长周期任务的每个实例会依赖定时时间小于等于且没被本任务其他实例依赖的短周期实例；天/周/月依赖小时/分钟任务例外，因为天任务实例会依赖所有小时/分钟任务。调度周期和调度时间参数配合使用，最终调度参数替换的值取决于每次调度的实例定时时间，而调度上看到的业务日期=实例定时时间年月日减1天。

发表了文章 2017-06-09

数据库工程师快速上手MaxCompute进行ETL

案例说明本案例主要是介绍如何通过数加MaxCompute+大数据开发套件两个产品实现简单的网站数据统计分析。适用人群 MaxCompute初学者，特别是无大数据开发基础但有数据库使用基础。案例侧重数据库工程师快速上手MaxCompute进行大数据开发，简单了解在MaxCompute做大数据ETL过程，同时了解一些MaxCompute SQL和常用数据库SQL的基本区别。示例介绍房产网上经常会看到一些排行榜，如最近30日签约的楼盘排行、签约金额的楼盘排行等，本示例我们简单介绍通过对二手房产数据信息表（house_basic_info）统计分析出每个城市二手房均价top 5的楼盘并且给出该楼盘所在城区，最后需要让这些数据在房产网上呈现。数据说明二手房网产品数据信息表house_basic_info存储于RDS-MySQL（区域：阿里云华南1可用区A；网络：专有网络），表数据每天全量更新。 “二手房网产品数据信息表”在数加平台公开数据集-二手房产数据集上有，可以直接使用,不过数据量会与本案例呈现的可能不完全一致。具体表信息如下：字段字段类型字段说明 house_id varchar 房产 ID house_city varchar 房产所在城市 house_total_price Double 房产总价 house_unit_price Double 房产均价 house_type varchar 房产类型 house_floor varchar 房产楼层 house_direction varchar 房产方向 house_deckoration varchar 房产装修 house_area Double 房产面积 house_community_name varchar 房产所在小区 house_region varchar 房产所在地区 proj_name varchar 楼盘名称 proj_addr varchar 项目地址 period int 产权年限 property varchar 物业公司 greening_rate varchar 绿化率 property_costs varchar 物业费用 datetime varchar 数据日期数据样例（英文逗号分隔）： 000404705c6add1dc08e54ba10720698,beijing,8000000,72717,3室1厅,低楼层/共24层,南,平层/精装,137,玺萌丽苑,丰台草桥三至四环,null,null,null,null,null,null,20170605 RDS-MySQL上house_basic_info表的建表语句，如： CREATE TABLE `house_basic_info` ( `house_id` varchar(1024) NOT NULL COMMENT '房产 ID', `house_city` varchar(1024) NULL COMMENT '房产所在城市', `house_total_price` double NULL COMMENT '房产总价', `house_unit_price` double NULL COMMENT '房产均价', `house_type` varchar(1024) NULL COMMENT '房产类型', `house_floor` varchar(1024) NULL COMMENT '房产楼层', `house_direction` varchar(1024) NULL COMMENT '房产方向', `house_deckoration` varchar(512) NULL COMMENT '房产装修', `house_area` double NULL COMMENT '房产面积', `house_community_name` varchar(1024) NULL COMMENT '房产所在小区', `house_region` varchar(1024) NULL COMMENT '房产所在地区', `proj_name` varchar(1024) NULL, `proj_addr` varchar(1024) NULL, `period` int(11) NULL, `property` varchar(1024) NULL, `greening_rate` varchar(1024) NULL, `property_costs` varchar(1024) NULL, `datetime` varchar(512) NULL COMMENT '数据日期' ) ENGINE=InnoDB DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci COMMENT='二手房网产品数据信息表'; 需求分析核心目标：统计分析出每个城市二手房均价top 5的楼盘并且给出该楼盘所在城区，即[城市,楼盘、均价、排名、所在城区]。数据现状：信息表中，每个楼盘可能有多条记录，多个均价信息，本案例为简单起见我们只针对整个楼盘的均价求平均；信息表中，house_region中包含城区、街道地址信息，需要拆分出城区信息。每天都数据都有变化，每个数据日期的数据都是全量数据。所需操作：数据从RDS导入MaxCompute； MaxCompute上对数据进行统计分析，并得出结果表；将结果表回流到网站业务系统，以便网站直接调用数据进行前端显示。需求实现前置说明大数据开发套件是架构在MaxCompute上的一站式大数据开发管理工具，大数据开发套件是免费使用；MaxComput主要提供计算和存储能力，关于MaxCompute入门通常需要了解的信息可参考该文章。前提条件开通MaxCompute，创建MaxCompute项目（如项目名：house_web)，具体操可参考通过大数据开发套件创建MaxCompute的介绍。 RDS数据导入MaxCompute 步骤一配置RDS数据源前置条件：因RDS数据安全限制，大数据开发套件的数据同步任务要与RDS数据库进行联通，必须将执行数据同步任务的机器ip添加到RDS的白名单中，具体的ip请点击此文档查看，或者在配置数据源界面有ip查看入口。具体操作：进入大数据开发套件-数据集成大数据开发套件-数据集成-数据源，点击新增数据源，弹框里配置数据源信息，测试连通性正常后，确定添加即可。所需RDS-MySQL实例ID即下图中的实例名称：注意：本示例RDS实例所在区域为华南1，网络类型为专有网络，通过大数据开发套件进行数据同步时，属于跨region走专有网络方式导数据。大数据开发套件的数据集成针对RDS通过反向代理自动检测使得网络能够互通，无需其他特殊处理即可保证数据同步正常联通。步骤二配置数据同步任务进入大数据开发套件-数据集成大数据开发套件-数据集成-数据同步，工作台上点击“向导模式”新建一个同步任务。选择来源：表每天全量更新，每次统计的数据时只需统计数据日期为昨天完整一天数据即可，因此数据过滤时，每天自动调度取datatime为昨天日期，可以使用系统参数${bdp.system.bizdate}代替，使得任务每天调度执行自动替换字段值，系统参数说明请看系统调度参数文档说明。选择目标：本案例是将数据导入到本项目，所以目标选择默认的数据源odps_first(odps)，这时发现一个问题，目标表没创建，所以我们需要先创建目标表，点击快速建表（更多建表方式可参考文档创建表）。弹框里显示系统自动根据源表结构生成对应的MaxCompute建表语句： CREATE TABLE IF NOT EXISTS your_table_name ( house_id STRING COMMENT '*', house_city STRING COMMENT '*', house_total_price DOUBLE COMMENT '*', house_unit_price DOUBLE COMMENT '*', house_type STRING COMMENT '*', house_floor STRING COMMENT '*', house_direction STRING COMMENT '*', house_deckoration STRING COMMENT '*', house_area DOUBLE COMMENT '*', house_community_name STRING COMMENT '*', house_region STRING COMMENT '*', proj_name STRING COMMENT '*', proj_addr STRING COMMENT '*', period BIGINT COMMENT '*', property STRING COMMENT '*', greening_rate STRING COMMENT '*', property_costs STRING COMMENT '*', datetime STRING COMMENT '*' ) COMMENT '*' PARTITIONED BY (pt STRING); 注意：自动生成的代码里，表名需要修改成真正的目标表表名，可以与源表表名一致house_basic_info；自动生成的代码里，源表中varchar类型会对应string类型，int类型会对应bigint类型。MaxCompute目前只支持6种数据类型，与常用数据库数据类型有所差异。自动生成的代码里，字段不能指定默认值、不能指定是否非空默认都是可空、不能指定长度默认每个字段长度上限为8M。自动生成的代码会是创建分区表，且分区名称为pt。MySQL数据库中没有分区概念，MaxCompute的分区概念与hadoop分区概念类似，具体可以参考分区介绍。本案例中目标表可以保留分区设置，以时间作为分区。既然已经有时间分区，那么源表的datetime字段可以不需要同步到目标表，表也可以不需要创建该字段。常用数据库sql与MaxCompute sql更多差异请看文档——与主流SQL差异。综上所述，修改后的建表语句,并点击提交： CREATE TABLE IF NOT EXISTS house_basic_info ( house_id STRING COMMENT '*', house_city STRING COMMENT '*', house_total_price DOUBLE COMMENT '*', house_unit_price DOUBLE COMMENT '*', house_type STRING COMMENT '*', house_floor STRING COMMENT '*', house_direction STRING COMMENT '*', house_deckoration STRING COMMENT '*', house_area DOUBLE COMMENT '*', house_community_name STRING COMMENT '*', house_region STRING COMMENT '*', proj_name STRING COMMENT '*', proj_addr STRING COMMENT '*', period BIGINT COMMENT '*', property STRING COMMENT '*', greening_rate STRING COMMENT '*', property_costs STRING COMMENT '*' ) COMMENT '*' PARTITIONED BY (pt STRING); 配置目标如下：分区值保留默认的${bdp.system.bizdate}，与来源表的过滤条件取的datetime数据日期对应，表示该分区存放的数据为源表中datetime=${bdp.system.bizdate}的数据。清理规则保留默认选项，写入前清理已有数据（分区表时只清理（若有）当前分区数据）。字段映射直接保留默认即可。源表和目标表字段名都一致会自动对应好，源表datetime字段无对应目标字段且不用同步因而无需任何处理。通道控制本案例中都保留默认即可，具体通道控制各项配置说明请看文档——数据同步通道控制参数设置。保存、提交保存任务时可以创建专门的目录存放，本案例我们接用目标表名称作为任务名称；提交任务主要是将任务提交到调度系统，使得任务可以按照调度配置进行自动运行。本案例调度配置保留默认配置，调度周期为“天”调度。步骤三执行数据导入任务在大数据开发套件中，切换到“运维中心-任务管理”找到任务house_basic_info，在任务视图上右键-测试节点：等待任务执行成功后，可以到“大数据开发套件——数据开发”的"脚本开发"中创建一个sql脚本文件，执行select语句查看表house_basic_info数据是否真的同步成功：数据统计分析数据导入到MaxCompute后，我们将通过MaxCompute SQL、MR等对数据进行加工处理。创建目标表前面“需求分析”的目标分析（统计分析出每个城市二手房均价top 5的楼盘并且给出该楼盘所在城区，即[城市,楼盘、均价、排名、所在城区])得出表5个字段。进入“大数据开发套件——数据开发”，工作区的工具栏上点击“新建”选择新建表，输入建表语句并提交。 CREATE TABLE IF NOT EXISTS house_unit_price_top5 ( house_city STRING, house_community_name STRING, house_unit_price_all DOUBLE, area STRING, tops BIGINT ) PARTITIONED BY ( pt STRING ); 创建任务进行数据统计分析进入“大数据开发套件——数据开发”的"任务开发"中创建一个sql任务编辑SQL代码 --产出每个城市每个楼盘的均价临时表 --分区值是对应数据导入任务配置的分区值，保证每天运行都是取当天导入的最新分区。 DROP TABLE IF EXISTS t_house_unit_price_info; CREATE TABLE IF NOT EXISTS t_house_unit_price_info AS SELECT house_city , house_community_name , AVG(house_unit_price) AS house_unit_price_all FROM house_basic_info WHERE pt = '${bdp.system.bizdate}' GROUP BY house_city, house_community_name; --拆分house_region字段只取城区名称输出字段为area，并存储到一个临时表。 --分区值是对应数据导入任务配置的分区值，保证每天运行都是取当天导入的最新分区。 DROP TABLE IF EXISTS t_house_area; CREATE TABLE IF NOT EXISTS t_house_area AS SELECT distinct house_city ,house_community_name ,split_part(house_region, ' ', 1) AS area FROM house_basic_info WHERE pt = '${bdp.system.bizdate}'; --产出最终目标表：每天每个城市二手房均价top 5的楼盘并且给出该楼盘所在城区。 --分区值是对应数据导入任务配置的分区值，保证每天运行产出的日期分区值与源表数据日期一致。 INSERT OVERWRITE TABLE house_unit_price_top5 PARTITION (pt='${bdp.system.bizdate}') SELECT a.house_city , a.house_community_name , a.house_unit_price_all , b.area , a.tops FROM ( SELECT house_city , house_community_name , house_unit_price_all , ROW_NUMBER() OVER (PARTITION BY house_city ORDER BY house_unit_price_all DESC) AS tops FROM t_house_unit_price_info ) a JOIN t_house_area b ON a.house_city = b.house_city AND a.house_community_name = b.house_community_name AND a.tops < 6; 注意 MaxCompoute SQL语法采用类似于常用SQL语法，可以看作是标准SQL的子集，但MaxCompute在很多方面并不具备常用数据库的特征，如事务、主键约束、索引等都不支持，因而SQL也有一定的差异。前面介绍数据导入创建目标表时已经简单的介绍了一些DDL语法的差异，针对这里DML语句，我们也做简单介绍： "产出每个城市每个楼盘的均价临时表"语句,整个语句只需要修改where条件中pt条件，即可直接在mysql上执行。 “拆分house_region字段”的语句中“split_part()")”函数是MaxCompute内置的字符串函数，可以直接在SQL中使用，对应MySQL上substring_index()或其他。产出目标表语句中，ROW_NUMBER()")是MaxCompute内置的窗口函数，在本案例中主要作用于计算排行,可在SQL中直接使用，MySQL上没有可直接对应的函数。产出目标表语句中，insert overwrite（或insert into）后要加 table 关键字，MySQL或Oracle不需要table关键字。 MaxCompute SQL和常用SQl更多差异请看文档——与主流SQL差异。调度配置和参数配置代码编辑好后，可以点击工具栏执行按钮执行sql语句，对sql进行探查。确定无误后进行调度配置主要包括调度属性和依赖属性：调度属性：由于每天调度一次，直接保留默认配置即可。依赖属性：由于本任务处理的数据来源是数据导入任务"house_basic_info"产出大数据，为了保证本任务执行时，数据导入已经完成，我们需要将导入任务设置为本任务的上游任务（即父任务）。至于“参数配置”由于本任务中只用到系统参数${bdp.system.bizdate},这个参数在系统调度任务时会自动替换，所以无需再进行其他配置。（详情请看系统参数说明）保存提交所有配置项都配置完成后点击工具栏上的“保存”、“提交”按钮，将任务提交到调度系统。点击工作区右上角“前往运维”按钮可以到运维中心查看工作流形态: 执行任务与前面数据导入任务执行操作类似。执行成功后可以在“数据开发”模块sql脚本中查看目标表数据：到目前为止，我们的目标表已经正常产出了，但是MaxCompute SQL在执行时会有一定的等待调度时间，适合做大数据批处理，网站前端读取数据就不适合直接读MaxCompute的数据，所以接下来我们需要把目标表回流到网站业务库。数据回流与数据导入一样，需要配置数据同步任务，不一样的是回流任务来源是MaxCompute的表，目标库是业务库，如还是用本示例中的RDS-MySQL的house_web_master 数据库中。操作步骤： RDS-MySQL中创建好对应的表,若需要保留每天都数据，可以加一个字段保存日期信息；在导数据开发套件的数据集成里配置新数据源，参考前面数据导入时配置数据源的方式；创建并配置数据同步任务，假设命名为 house_unit_price_top5_2_mysql，主要用MaxCompute读插件和RDS-MySQL写插件，大致配置如下：字段配置如果想直接把源表的分区字段同步到MySQL的日期信息字段依赖属性中，为了保证每次回流都是最新的数据，将数据加工任务house_unit_price_top5设置为父任务保存提交任务后在运维管理可以看到工作流形态：执行回流任务，参考前面的任务执行方式。执行成功后，可以到RDS-MySQL上查看表数据是否正常导入。总结到此，我们整个需求目标都完成了，本案例在MaxCompute只是实现一个非常简单的统计分析，更多的高级功能组件（MapReduce、Graph等）没有用到。通过本案例我们可以了解到：大数据开发套件是架构在MaxCompute的web工具，提供界面操作以及数据集成和任务调度功能，而MaxCompute提供计算和存储服务。 MaxCompute SQL作业提交后会有几十秒到数分钟不等的排队调度，所以适合处理跑批作业，一次作业批量处理海量数据，不适合直接对接需要每秒处理几千至数万笔事务的前台业务系统。 MaxCompute SQL采用的是类似于SQL的语法，可以看作是标准SQL的子集，但不能因此简单的把MaxCompute 等价成一个数据库，它在很多方面并不具备数据库的特征，如事务、主键约束、索引等（更多差异请点击进入查看）。大数据开发套件里的数据同步可以实现跨region的RDS与MaxCompute的数据互传，无需特殊处理。

海清_个人页

个人介绍

擅长的技术

MaxCompute作业日常监控与运维实践

MaxCompute消费监控最佳实践

【转载】MaxCompute full outer join改写left anti join实践

持续定义Saas模式云数据仓库+BI

MaxCompute资源管理—— 包年包月资源组隔离

MaxCompute资源管理—— 包年包月资源分时

MaxCompute - ODPS重装上阵 第九弹 - 脚本模式与参数视图

MaxCompute项目子账号做超级管理员

MaxCompute - ODPS重装上阵 第八弹 - 动态类型函数

MaxCompute - ODPS重装上阵 第七弹 - Grouping Set, Cube and Rollup

MaxCompute - ODPS重装上阵 第六弹 - User Defined Type

MaxCompute按量计费计算任务消费监控告警

MaxCompute 项目子账号做权限管理

MaxCompute 费用暴涨之新增SQL分区裁剪失败

MaxCompute 费用暴涨之存储压缩率降低导致SQL输入量变大

MaxCompute预付费套餐(计算资源+存储资源)发布

MaxCompute 预付费标准版VS套餐版

MaxCompute预付费套餐(计算资源+存储资源)发布

MaxCompute Studio使用心得系列7——作业对比

基于MaxCompute的数仓数据质量管理

MaxCompute SQL 使用正则表达式选列

MaxCompute安全管理指南-案例篇

MaxCompute安全管理指南-基础篇

MaxCompute Studio使用心得系列6——一个工具完成整个Python UDF开发

MaxCompute Studio 2.8.2 新版本发布啦！

MaxCompute Studio使用心得系列5——一个工具完成整个JAVA UDF开发

MaxCompute Studio使用心得系列4——可视化查看所有job并分析运行情况

MaxCompute Studio使用心得系列3——可视化分析作业运行

MaxCompute Studio使用心得系列2——编译SQL脚本

MaxCompute Studio使用心得系列1——本地数据上传下载

阿里云大数据计算服务MaxCompute（原ODPS）华南1（深圳）Region即将开服！

MaxCompute分区表和非分区表使用对比

【大数据开发套件调度配置实践】——调度任务各种周期配置和调度形态

【大数据开发套件调度配置实践】——不同周期任务依赖配置

数据库工程师快速上手MaxCompute进行ETL

MaxCompute作业日常监控与运维实践

MaxCompute消费监控最佳实践

【转载】MaxCompute full outer join改写left anti join实践

持续定义Saas模式云数据仓库+BI

MaxCompute资源管理—— 包年包月资源组隔离

MaxCompute资源管理—— 包年包月资源分时

MaxCompute - ODPS重装上阵 第九弹 - 脚本模式与参数视图

MaxCompute项目子账号做超级管理员

MaxCompute - ODPS重装上阵 第八弹 - 动态类型函数

MaxCompute - ODPS重装上阵 第七弹 - Grouping Set, Cube and Rollup

MaxCompute - ODPS重装上阵 第六弹 - User Defined Type

MaxCompute按量计费计算任务消费监控告警

MaxCompute 项目子账号做权限管理

MaxCompute 费用暴涨之新增SQL分区裁剪失败

MaxCompute 费用暴涨之存储压缩率降低导致SQL输入量变大

MaxCompute预付费套餐(计算资源+存储资源)发布

MaxCompute 预付费标准版VS套餐版

MaxCompute预付费套餐(计算资源+存储资源)发布

MaxCompute Studio使用心得系列7——作业对比

基于MaxCompute的数仓数据质量管理

萌新求助，提示MaxCompute project is not怎么解决

MaxCompute - ODPS重装上阵第九弹 - 脚本模式与参数视图

MaxCompute - ODPS重装上阵　第八弹 - 动态类型函数

MaxCompute - ODPS重装上阵　第七弹 - Grouping Set, Cube and Rollup

MaxCompute - ODPS重装上阵　第六弹 - User Defined Type

MaxCompute - ODPS重装上阵第九弹 - 脚本模式与参数视图

MaxCompute - ODPS重装上阵　第八弹 - 动态类型函数

MaxCompute - ODPS重装上阵　第七弹 - Grouping Set, Cube and Rollup

MaxCompute - ODPS重装上阵　第六弹 - User Defined Type