海清
TA的个人档案
个人介绍
阿里云数加培训讲师， 最擅长MaxCompute、大数据开发套件。
擅长的技术
- Java
- Python
- Linux
- 高分内容
- 最新动态
- 文章
- 问答
-
发表了文章 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年09月
2020年08月
2020年07月
2020年03月
2020年01月
滑动查看更多
-
发表了文章
2021-03-18
MaxCompute作业日常监控与运维实践
-
发表了文章
2021-01-19
MaxCompute消费监控最佳实践
-
发表了文章
2020-09-25
【转载】MaxCompute full outer join改写left anti join实践
-
发表了文章
2020-09-03
持续定义Saas模式云数据仓库+BI
-
发表了文章
2020-08-31
MaxCompute资源管理—— 包年包月资源组隔离
-
发表了文章
2020-07-27
MaxCompute资源管理—— 包年包月资源分时
-
发表了文章
2020-03-09
MaxCompute - ODPS重装上阵 第九弹 - 脚本模式与参数视图
-
发表了文章
2020-02-11
MaxCompute项目子账号做超级管理员
-
发表了文章
2020-01-14
MaxCompute - ODPS重装上阵 第八弹 - 动态类型函数
-
发表了文章
2019-12-31
MaxCompute - ODPS重装上阵 第七弹 - Grouping Set, Cube and Rollup
-
发表了文章
2019-12-13
MaxCompute - ODPS重装上阵 第六弹 - User Defined Type
-
发表了文章
2019-11-25
MaxCompute按量计费计算任务消费监控告警
-
发表了文章
2019-07-03
MaxCompute 项目子账号做权限管理
-
发表了文章
2019-06-26
MaxCompute 费用暴涨之新增SQL分区裁剪失败
-
发表了文章
2019-06-25
MaxCompute 费用暴涨之存储压缩率降低导致SQL输入量变大
-
发表了文章
2019-06-17
MaxCompute预付费套餐(计算资源+存储资源)发布
-
发表了文章
2019-05-24
MaxCompute 预付费标准版VS套餐版
-
发表了文章
2019-05-17
MaxCompute预付费套餐(计算资源+存储资源)发布
-
发表了文章
2019-05-08
MaxCompute Studio使用心得系列7——作业对比
-
发表了文章
2019-04-11
基于MaxCompute的数仓数据质量管理
滑动查看更多
-
回答了问题
2019-07-17
萌新求助，提示MaxCompute project is not怎么解决
需要配置好MaxCompute项目链接，可以参考：https://help.aliyun.com/document_detail/50855.html?spm=5176.doc34614.6.714.TN2kcT
赞0 踩0 评论0
滑动查看更多