帮助企业做好MaxCompute大数据平台成本优化的最佳实践

本文涉及的产品
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 阿里云大数据计算服务MaxCompute通过灵活性、简单性和创新为您企业的业务环境带来了变革,但是您企业是否通过其实现了原本预期的节省成本的目标呢?本文中,我们将为广大读者诸君介绍优化您企业MaxCompute开销的一些关键性的策略。
阿里云大数据计算服务MaxCompute通过灵活性、简单性和创新为您企业的业务环境带来了变革,但是您企业是否通过其实现了原本预期的节省成本的目标呢?本文中,我们将为广大读者诸君介绍优化您企业MaxCompute开销的一些关键性的策略。   
自从MaxCompute于2010年进入市场以来,计算服务MaxCompute就已然永远地改变了整个IT世界了。尽管其价格优势已经领先业界了,但仍然有许多企业客户了解到,迁移到公共云服务并不总是能够帮助他们实现预期的成本节约的目标。
这并不意味着迁移到公共云服务是一个错误。公共云服务在敏捷性、响应性、简化操作和提高创新方面提供了巨大的优势。 这方面的错误在于:假设在不实施管理和自动化的情况下迁移到公共云服务,也能带来成本的节约。为了应对不断上涨的云基础设施成本,我们建议您企业组织不妨参考和借鉴本文中所介绍的这些最佳实践方案,以减低和优化成本,并实现您企业环境的价值最大化。

接下来,我们主要从计算、存储、数据同步、日常账单分析几个点来展开优化实践,帮助企业做到节省预算。

优化控制计算成本

1、通过计费提醒估算计算成本

1.1 使用DataWorks 估算费用

step1 通过DataWorks进入 Project工作区。

step2 进入数据开发。



step3 新建脚本文件。

step4 输入SQL后,点击“成本估计“按钮。


1.2 使用Cost SQL估算费用

step1 启动MaxCompute客户端 ,安装及配置项目参照: https://help.aliyun.com/document_detail/27804.html
step2 输入cost +sql语句计费估算代码:
Cost SQL SELECT * from work_demo.dwd_prouduct_house_basic_info_out_npt;
step3 根据返回的输入数据量*复杂度*0.3元/GB/复杂度估算价格。
Input:44066219424 (Bytes)/1024/1024/1024 x Complexity:1.0 x 0.3(元/GB/复杂度) =12.31元

1.3 使用MaxCompute Stuido估算费用

step1 启动MaxCompute Stuido客户端 ;安装及配置项目参照: https://help.aliyun.com/document_detail/50892.html
step2 输入cost +sql语句计费估算代码获取估算量:

step3根据返回的输入数据量*复杂度*0.3元/GB/复杂度估算价格。Input:919168 (Bytes)/1024/1024/1024 x Complexity:1.0 x 0.3(元/GB/复杂度) =2.57元

1.4 使用产品价格计算器估算费用

目前价格计算器支持预付费估算,
step2 输入所需要的存储数量量(GB、TB或PB)。
step3 输入查询所需要的计算资源CU(最低10CU),输入数据下载量(GB、TB或PB),系统可以为您自动估算费用。

1.5 使用MaxCompute JAVA SDK估算费用

工程示例:

 

其中最核心的API调用如下,SqlCostTask 这个函数就能获取(计算输入数据量 * SQL复杂度 * SQL价格)这三个变量了,文档参考:http://repo.aliyun.com/java-sdk-doc/com/aliyun/odps/task/SQLCostTask.html


 

估算界面:

 

2、通过账单预警控制计算成本

使用阿里云账单中心配置高额预警,当天产品后付费消费大于提醒阀值时,每天早上9点左右短信提醒一次。


第一步,进入账单中心https://usercenter2.aliyun.com,点击按钮开启高额预警;


第二步,选择MaxCompute产品(目前仅支持后付费);


第三步,填写预警阀值,输入按“天”消费上限;


3、通过优化SQL来控制计算成本

做优化前,大家先来了解一下MaxCompute SQL的技术原理,对后续的优化工作会更加容易理解。

3.1 列裁剪

在读数据的时候,只读取查询中需要用到的列,而忽略其他列,避免使用select * 全表扫描引起的错误及资源浪费。例如,对于查询:
SELECT a,b FROM T WHERE e < 10;
其中,T 包含 5 个列 (a,b,c,d,e),列 c,d 将会被忽略,只会读取a, b, e 列

3.2 分区裁剪

分区剪裁是指对分区列指定过滤条件,使得只读取表的部分分区数据,避免全表扫描引起的错误及资源浪费。例如,对于下列查询:
SELECT a,b FROM T WHERE partitiondate='2017-10-01';
partitiondate =“2017-10-01”只扫描2017年10月1日的分区
分区裁剪注意事情:
用户经常觉得已经对分区列做了限制了,但实际还是产生了大量费用。我们看一下如何做好分区裁剪,

3.3 SQL关键字的优化

有一些优化方式官网上已经写出来了,比如避免使用select *,读取分区表时一定要对分区进行过滤。其他的优化方式就需要我们自己去摸索了。
 
计费的SQL关键字包括:Join / Group By / Order By / Distinct /窗口函数/ Insert into
减少full outer join的使用,改为union all;
例如------------------------------------
SELECT COALESCE(t1.id, t2.id) AS id, SUM(t1.col1) AS col1
 , SUM(t2.col2) AS col2
FROM (
 SELECT id, col1
 FROM table1
) t1
FULL OUTER JOIN (
 SELECT id, col2
 FROM table2
) t2
ON t1.id = t2.id
GROUP BY COALESCE(t1.id, t2.id);
可以优化为---------------------------
SELECT t.id, SUM(t.col1) AS col1, SUM(t.col2) AS col2
FROM (
 SELECT id, col1, 0 AS col2
 FROM table1
 UNION ALL
 SELECT id, 0 AS col1, col2
 FROM table2
) t
GROUP BY t.id;

在union all内部尽可能不使用group by,改为在外层统一group by;
例如--------------------------------------
SELECT t.id, SUM(t.val) AS val
FROM (
 SELECT id, SUM(col3) AS val
 FROM table3
 GROUP BY id
 UNION ALL
 SELECT id, SUM(col4) AS val
 FROM table4
 GROUP BY id
) t
GROUP BY t.id;
可以优化为---------------------------
SELECT t.id, SUM(t.val) AS val
FROM (
 SELECT id, col3 AS val
 FROM table3
 UNION ALL
 SELECT id, col4 AS val
 FROM table4
) t
GROUP BY t.id;
临时导出的数据如果需要排序,尽量在导出后使用excel等工具进行排序,避免使用order by;
根据优化原则,尽量避免使用distinct关键字,改为多套一层group by;
例如--------------------------------------
SELECT COUNT(DISTINCT id) AS cnt
FROM table1;
可以优化为---------------------------
SELECT COUNT(1) AS cnt
FROM (
 SELECT id
 FROM table1
 GROUP BY id
) t;
尽量避免使用Insert into方式写入数据,可以考虑增加一个分区字段;
作用:通过降低SQL复杂度,来节省SQL的费用。

3.4 禁止全表扫描

您可以通过设置参数来关闭全表扫描功能,这样也可以避免过度资源浪费。
例如,
session级别控制
set odps.sql.allow.fullscan=false;
select count(*) from work_demo.house_test; 

说明:限制扫描全表。默认情况下true,允许扫描全表;否则为false,如果扫描全表,则抛异常。


Project级别控制

SetProject odps.sql.allow.fullscan

详细参考: https://help.aliyun.com/document_detail/27834.html


3.5 不要运行查询来探索或预览表数据 如果您想预览表数据,可以使用表预览选项查看数据,而不会产生费用。

MaxCompute支持下列数据预览选项:
在DataWorks用户界面中,在数据开发-表查询信息页上,单击表进行数据预览。

在CLT使用read命令并指定预览的行数。
odps@ yinlin_demo>read mc2_ots.demo_dplus_summary 10;
在MaxCompute Studio双击表进行表数据预览。

3.6 在通过MaxCompute计算和通过RDS计算中寻找平衡

由于MaxCompute的查询响应是分钟级,不适合直接用于前端查询。所以计算出的结果数据都会被保存到外部存储中,而对于大部分人来说,关系型数据库是最优先的选择。
 
所以这里就会涉及到一个“度”的问题。要把数据计算到什么程度,才会存放到MYSQL中?
 
(比如现在的用户登陆日志表、用户维度表)
从上边一行的原始表,算出下边一行的几个结果表。
(比如近一周各省份、地市登陆人数、近一周每天登陆人数、近一周每种注册渠道的登陆人数)

 
完全计算
直接出最终结果。前端展示时,不做任何判断、聚合、关联字典表、甚至不带where条件。
(结果表1:省份ID、省份名称、地市ID、地市名称、登陆人数)
(结果表2:日期、登陆人数)
(结果表3:注册渠道ID、注册渠道描述、登陆人数)
理解难度:1⭐
沟通难度:1⭐
MaxCompute费用:4⭐
下行流量:2⭐
离线数据维护成本:2⭐
 
适度计算
后续关联字段表等简单步骤直接在关系型数据库中计算
(结果表1:省份ID、地市ID、登陆人数)
(结果表2:日期、登陆人数)
(结果表3:注册渠道ID、登陆人数)
理解难度:2⭐
沟通难度:2⭐
MaxCompute费用:3⭐
下行流量:1⭐
离线数据维护成本:1⭐
 
轻度计算
后续大量计算任务直接在关系型数据库中计算
(结果表:用户ID、登陆日期、省份ID、地市ID、注册渠道ID)
理解难度:5⭐
沟通难度:5⭐
MaxCompute费用:2⭐
下行流量:5⭐
离线数据维护成本:1⭐

4、MR作业计算控制成本

做优化前,大家先来了解一下MapReduce的技术原理,对后续的优化工作会更加容易理解。 https://help.aliyun.com/document_detail/27875.html?spm=5176.100239.blogcont78108.99.BPYOnj#h1-u5904u7406u6D41u7A0B

4.1 设置合理的参数

split size
map默认的split size是256MB,split size的大小决定了map的个数多少,如果用户的代码逻辑比较耗时,map需要较长时间结束,可以通过JobConf#setSplitSize方法适当调小split size的大小。然而split size也不宜设置太小,否则会占用过多的计算资源。
MapReduce reduce instance
单个 job 默认 reduce instance 个数为 map instance 个数的1/4,用户设置作为最终的 reduce instance 个数,范围 [0, 2000],数量越多,计算时消耗越多,成本越高,应合理设置。

4.2 MR减少中间环节

如果有多个MR作业,之间有关联关系,前一个作业的输出是后一个作业的输入,可以考虑采用Pipeline的模式,将多个串行的MR作业合并为一个,这样可以用更少的作业数量完成同样的任务,一方面减少中间落表造成的的多余磁盘IO,提升性能;另一方面减少作业数量使调度更加简单,增强流程的可维护性。具体使用方法参见 Pipeline示例

4.3 输入表的列裁剪

对于列数特别多的输入表,Map阶段处理只需要其中的某几列, 可以通过在添加输入表时明确指定输入的列,减少输入量; 例如只需要c1,c2俩列,可以这样设置:
InputUtils.addTable(TableInfo.builder().tableName("wc_in").cols(new String[]{"c1","c2"}).build(), job);
设置之后,你在map里的读取到的Record也就只有c1,c2俩列,如果之前是使用列名获取Record数据的,不会有影响,而用下标获取的需要注意这个变化。

4.4 避免资源重复读取

资源的读取尽量放置到setup阶段读取,避免资源的多次读取的性能损失,另外系统也有64次读取的限制,资源的读取参见 使用资源示例

4.5 减少对象构造开销

对于Map/Reduce阶段每次都会用到的一些java对象,避免在map/reduce函数里构造,可以放到setup阶段,避免多次构造产生的开销;
{
    ...
    Record word;
    Record one;

    public void setup(TaskContext context) throws IOException {


      // 创建一次就可以,避免在map中每次重复创建
      word = context.createMapOutputKeyRecord();

      one = context.createMapOutputValueRecord();

      one.set(new Object[]{1L});

    }
    ...
}

4.6 合理选择partition column或自定义partitioner

合理选择partition columns,可以使用JobConf#setPartitionColumns这个方法进行设置(默认是key schema定义的column),设置后数据将按照指定的列计算hash值分发到reduce中去, 避免数据倾斜导致作业长尾现象,如有必要也可以选择自定义partitioner,自定义partitioner的使用方法如下:
import com.aliyun.odps.mapred.Partitioner;
 
public static class MyPartitioner extends Partitioner {

@Override
public int getPartition(Record key, Record value, int numPartitions) {
  // numPartitions即对应reducer的个数
  // 通过该函数决定map输出的key value去往哪个reducer
  String k = key.get(0).toString();
  return k.length() % numPartitions;
}
}
在jobconf里进行设置:
jobconf.setPartitionerClass(MyPartitioner.class)
另外需要在jobconf里明确指定reducer的个数:
jobconf.setNumReduceTasks(num)

4.7 合理使用combiner

如果map的输出结果中有很多重复的key,可以合并后输出,combine后可以减少网络带宽传输和一定shuffle的开销,如果map输出本来就没有多少重复的,就不要用combiner,用了反而可能会有一些额外的开销。combiner实现的是和reducer相同的接口,例如一个WordCount程序的combiner可以定义如下:
/**
   * A combiner class that combines map output by sum them.
   */
  public static class SumCombiner extends ReducerBase {

    private Record count;

    @Override
    public void setup(TaskContext context) throws IOException {
      count = context.createMapOutputValueRecord();
    }

    @Override
    public void reduce(Record key, Iterator values, TaskContext context)
        throws IOException {
      long c = 0;
      while (values.hasNext()) {
        Record val = values.next();
        c += (Long) val.get(0);
      }
      count.set(0, c);
      context.write(key, count);
    }
  }

3.8 合理使用JVM内存参数
部分客户过于追求调优,把MR任务内存设置过大,标准配置是1 Core 4G ,odps.stage.reducer.jvm.mem=4006,当CPU与内存比超过1:4时,对应的费用也会大幅升高。

5、计费模式转换

5.1 后付费转预付费

当后付费产生的账单超出您的企业预算时,您可以转换为预付费,将CU计算资源包月。
注意事项:请合理评估计算作业性能与时间关系,很多企业转为预付费后,由于购买的CU数量少,作业计算周期长,达不到预期,又转回后付费。
合理预估预付费CU资源方法参照(仅供参考):
SQL估算资源建议:show p后,通过logview查看历史作业平均消耗的worker数量,一个worker 近似1CU;
MR估算资源建议:show p后,通过logview查看历史作业平均消耗的cost * min计算时,cost数量近似CU。
命令行如下:
show p;--查看所有instance_id,例如20171106100629865g4iplf9
wait 20171106100629865g4iplf9;--查看每个instance_id的logview
show/wait 实例的参考文档, 点击这里

5.2 预付费+后付费混合模式

混合模式一,预付费做生产业务(小时级ETL)+后付费非周期任务或即席查询Adhoc。将非周期性的大规模数据处理作业放到后付费模式上。将周期性高密度计算作业放到预付费模式。数据可以存储在预付费模式下,后付费模式不用存储数据,通过跨表计算省去一份存储成本。注意:不同账号下跨表计算需要通过Grant授权来实现,参考:


案例分析:这个案例是后付费月账单1万元的3个月计算消耗明细,Max最大200CU,平时用到30CU;
此方案的结构可以优化为:
最经济型:月4500元(30CU,不预留水位)+1800 元(1000GB*1.5复杂度*0.3(元/GB/复杂度 *4次),节省:3700元/月,虽然节省较多,但数据业务的增长会遇到水位线瓶颈,需要定期扩展CU。
次经济性:月7500元(50CU,预留30%水位)+1800 元(1000GB*1.5复杂度*0.3 元/GB/复杂度 *4次), 节省:节省800元/月,虽然节省少,但资源还比原来更充裕了。

混合模式二,预付费做非周期任务或即席查询Adhoc+后付费生产业务(天级ETL)。企业为了控制日常数据探索带来的SQL健康度下降及费用不可控,可以把数据探索和非周期任务放在固定资源组,通过CU管家为开发组和BI组配置不同的二级资源,生产作业如果只是每天处理一次,可以通过弹性的方式跑在后付费资源组。

优化控制存储成本

1、设置合理的表生命周期

MaxCompute中存储资源是非常宝贵的。可以根据数据本身的使用情况,对表设置生命周期,MaxCompute会及时删除超过生命周期的数据,达到节省存储空间的目的。比如:
create table test3 (key boolean) partitioned by (pt string, ds string) lifecycle 100;
创建一张生命周期为100的表。如果这张表或者分区的最后修改时间超过了100天将会被删掉。需要注意的是生命周期是以分区为最小单位的,所以一个分区表,如果部分分区达到了生命周期的阀值,那么这些分区会被直接删掉,未达到生命周期阀值的分区不受影响。
另外可以通过命令
alter table table_name set lifecycle days;
修改已经创建好的表的生命周期。

2、合理设置数据分区

MaxCompute将分区列的每个值作为一个分区(目录)。用户可以指定多级分区,即将表的多个字段作为表的分区,分区之间正如多级目录的关系。在使用数据时如果指定了需要访问的分区名称,则只会读取相应的分区,避免全表扫描,提高处理效率,降低费用。
假如最小统计周期为天,宜采用日期作为分区字段。每天将数据覆盖迁移到指定分区,再读取指定分区的数据进行下游统计。
假如最小统计周期为小时,宜采用日期+小时作为分区字段。每小时将数据覆盖迁移到指定分区,再读取指定分区的数据进行下游统计。若小时调度的统计任务也按天分区,数据每小时追加,则每小时将多读取大量的无用数据,增加的流入数据量,增加了不必要的费用。
 
分区字段不一定非得是时间,根据实际需要,也可以使用其他的枚举值个数相对固定的字段,比如渠道、比如国家省份地市。或者使用时间和其他字段共同作为分区字段。
 

优化控制数据同步成本

1、尽可能使用经典网络和VPC网络

通过使用内部网络(经典网络、VPC)实现零成本数据导入、导出。

2、合理利用ECS的公共下载资源

很多企业客户ECS带宽是包月的,可以使用Tunnel等数据同步工具,将MaxCompute数据同步到ECS上,然后下载到本地。下载方法参考:

3、Tunnl文件上传优化

当文件量小的时候,会消耗更多计算资源参与计算,建议文件量积累较大时一次性上传,比如,用户在调用tunnel sdk时当buffer达到64M时提交一次。

4、合理预估VPC专线

当数据在IDC机房,需要通过专线同步到MaxCompute的时候,我们需要做好带宽预估,平衡数据同步与带宽之间的成本。

举个例子,企业有50T数据上云,如果我们需要1天同步完成,我们需要多少带宽, 50T*1024(GB)* 8(小b)*/24小时*3600秒=4.7Gb/s,大约需要5G带宽;

分析账单与明细

1、账单及时查看

养成定期查看账单的好习惯,及时优化使用成本。通过阿里云控制台-消费-消费记录-消费明细,查看MaxCompute/odps每日计费清单及账单(计算、存储、下载)明细。

2、案例分析

场景1,查看昨天的收费情况
出账后,通过控制台消费明细来查看。
出账时间:
预付费出账单时间次日12点
后付费出账单时间是次日9点
step1 进入阿里云控制台-消费, https://expense.console.aliyun.com/#/
step2 打开消费总览,看到当月账单。

step3点击左侧消费明细,根据产品分类Maxcompute及时间来筛选昨天的消费金额, https://expense.console.aliyun.com/#/consumption/list/flow/afterpay

step4 点击详情,展开每个项目的消费情况,查看有无“贵”收费
如发现“贵“的项目,可根据存储、计算、下载几个场景对应到下面的解决方法。

场景2,分析某一天计算收费“贵“原因
通过导出使用记录,分析消费多的作业instance具体情况。

step1 打开消费明细后,看到账单异常后,请到左侧消费记录下载导出使用记录。

step2下载记录后,打开excel表,定位异常数据的instanceid。
比如,计量信息编号20171106100629865g4iplf9这个SQL任务,产生的费用是SQL读取量7352600872 (Bytes) /1024/1024/1024* SQL复杂度 1 * 0.3(元/GB/复杂度)=2元 ,计算公式参考官网: https://help.aliyun.com/document_detail/27989.html?spm=5176.product27797.6.559.QL7dYV#h2-u6309u91CFu540Eu4ED8u8D39

step3 查看这个“贵”instanceID 的logview
wait 20171106100629865g4iplf9

step4 通过Logview我们发现产生了全表扫描、长尾计算等问题,及时优化我们的SQL/MR作业。
长尾优化参考:

场景3,分析存储收取1分钱的原因
通过导出使用记录,分析消费多的存储Storeage明细。
step1 下载记录后,打开excel表。

step2 查看数据分类中的Storage,会发现在yinlin_test_huabei2_io Project下存储了384字节数据。
按照官网存储定价规则,存储384 (Bytes) /1024/1024/1024*0.0192(元/GB)不到1分钱,但官网提到小于等于512M数据最低收取1分钱。计算公式参考官网: https://help.aliyun.com/document_detail/27989.html?spm=5176.product27797.6.559.QL7dYV#h1-u5B58u50A8u8BA1u8D39

step3 如果这份数据是用来测试的,你可以通过IDE删除Project下的表数据。
场景4,分析数据上传和下载是否产生了费用
部分用户总担心数据同步会产生费用,我们可以通过分析账单来解决。

step1 点击消费明细详情,查看上行、下载有无收费。
我们可以看到收费明细里面并没有上行计费项,所以用户不必担心数据上传产生了费用。
同时,我们看到了下载产生了0.12元。

step2 通过导出使用记录,分析消费多的下载消耗明细。

step3 可以看到公网下行流量产生了一条约0.153GB(164223524 byte)的下行流量,根据官网收费标准, 164223524(byte)/1024/1024/1024*0.8 (元/GB)=0.12元。计费公式参考: https://help.aliyun.com/document_detail/27989.html?spm=5176.product27797.6.559.QL7dYV#h1-u4E0Bu8F7Du8BA1u8D39

step4 下行优化
a 查看你的tunnel设置的service,是否设置成了公共网络。参考: https://help.aliyun.com/document_detail/34951.html
b 如果你本地在苏州,Region在华东2上海,那么你可以先通过华东2的ECS把数据下载到虚机,然后利用ECS包月下载资源。

MaxCompute计费命令详解

客户非常关心收费细节,经常会问哪些命令是收费的。比如删除命令收不收费,更新数据收不收费。整理了一个表格,方便大家查阅MaxCompute 计算收费的命令;


语法表达式

用途

是否收费

样例

Tunnel Download

下载数据(经典网络)

tunnel download Table_name e:/Table_name.txt;配置经典网络endpoint:http://dt.cn-shanghai.maxcompute.aliyun-inc.com

Tunnel Download

下载数据(公网)

收费

tunnel download Table_name e:/Table_name.txt;配置外网网络endpoint:http://dt.cn-shanghai.maxcompute.aliyun.com

Tunnel Upload

上传数据

Tunnel upload  e:/Table_name.txt Table_name;

Cost SQL

费用预估

Cost SQL SELECT * from Table_name;

Read Table

数据预览

read Table_name 10;

Insert Overwrite …Select

数据更新

收费

insert overwrite table Table_name partition (sale_date='20180122') select shop_name, customer_id, total_price from sale_detail;

Desc Table

查看表信息

desc Table_name;

Drop Table

删除非分区表及数据

drop table if exists Table_name;

Create Table

创建分区表

create table if not exists Table_name (key string ,value bigint) partitioned by (p string);

Create Table …Select 

创建分区表

收费

create table if not exists Table_name as select * from A_Tab;

Insert Into Table

指定列插入数据

insert into table Table_name partition (p)(key,p) values ('d','20170101'),('e','20170101'),('f','20170101');

Insert Into Table...Select

插入数据

收费

insert into table Table_name select shop_name, customer_id, total_price from sale_detail;

Select UDF [not Count or All] from Table

查询表数据

收费

Select sum(a) from Table_name;

Set Flag

会话设置

set odps.sql.allow.fullscan=true;

Jar MR

运行MapReduce作业

收费

jar -l com.aliyun.odps.mapred.example.WordCount wc_in wc_out

Add Jar/file/archive/table 

注册资源

add jar data\resources\mapreduce-examples.jar -f;

Drop Jar/file/archive/table 

删除资源

DROP RESOURCE sale.res

List Resources

查看资源列表

list resources;

Get  Resources

下载资源

get resource odps-udf-examples.jar d:\;

Create Functions

注册函数

CREATE FUNCTION test_lower

Drop Functions

删除函数

DROP FUNCTION test_lower;

List Functions

查看函数列表

list functions;        

Alter Table

删除分区表

Alter table user drop if exists partition(region='hangzhou',dt='20150923');

TRUNCATE TABLE

删除非分区表

TRUNCATE TABLE table_name;

CREATE EXTERNAL TABLE 

创建外表

否(公测)

CREATE EXTERNAL TABLE IF NOT EXISTS ambulance_data_csv_external…LOCATION 'oss://oss-cn-shanghai-internal.aliyuncs.com/oss-odps-test/Demo/'

Select  [EXTERNAL] TABLE

读取外表

否(公测)

select recordId, patientId, direction from ambulance_data_csv_external where patientId > 25;

Show Tables

列出当前项目空间下所有的表

SHOW TABLES;

Show Partitions Tables

列出一张表中的所有分区

SHOW PARTITIONS

Show Instances/Show P

返回由当前用户创建的实例信息

Show Instances/Show P

Wait Instance

返回指定实例Logview

Wait 20131225123302267gk3u6k4y2

Status Instance

返回指定实例的状态

Status 20131225123302267gk3u6k4y2

Kill Instance

停止您指定的实例

Kill 20131225123302267gk3u6k4y2



结论
重要的是要记住,这些最佳实践方法并不意味着是一次性的活动,而是持续性的过程。由于大数据的动态性和不断变化的性质,企业用户成本优化的活动应该持续不断的进行。

现在的企业数据资产繁杂众多,成本也会相应的提升,特别是建设大数据平台的企业,数据的类型、分布、实现技术、所属部门等都很繁杂,通过数据资产治理降低企业数据使用的成本,提高以数据指导管理决策的效率,已然成为大数据时代中企业竞争力的重要来源。


如果你有更好的省钱方法,欢迎补充, https://yq.aliyun.com/ask/61311/


新的一年开始了,欢迎您加入MaxCompute开发者社区,在新征程里与更多大数据开发者一起学习交流大数据技术。
搜索钉钉群号:11782920,或扫码加入
image 阿里巴巴大数据-玩家社区  https://yq.aliyun.com/teams/6/

---阿里大数据博文,问答,社群,实践,有朋自远方来,不亦说乎……



相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps&nbsp;
目录
相关文章
|
1月前
|
存储 分布式计算 大数据
大数据 优化数据读取
【11月更文挑战第4天】
48 2
|
5天前
|
存储 分布式计算 安全
MaxCompute Bloomfilter index 在蚂蚁安全溯源场景大规模点查询的最佳实践
MaxCompute 在11月最新版本中全新上线了 Bloomfilter index 能力,针对大规模数据点查场景,支持更细粒度的数据裁剪,减少查询过程中不必要的数据扫描,从而提高整体的查询效率和性能。
|
4天前
|
分布式计算 DataWorks 搜索推荐
DataWorks产品评测:大数据开发治理平台的最佳实践与体验
DataWorks是阿里云推出的一款大数据开发治理平台,集成了多种大数据引擎,支持数据集成、开发、分析和任务调度。本文通过用户画像分析的最佳实践,评测了DataWorks的功能和使用体验,并提出了优化建议。通过实践,DataWorks在数据整合、清洗及可视化方面表现出色,适合企业高效管理和分析数据。
44 0
|
1月前
|
存储 算法 固态存储
大数据分区优化存储成本
大数据分区优化存储成本
32 4
|
1月前
|
存储 大数据 Serverless
大数据增加分区优化资源使用
大数据增加分区优化资源使用
29 1
|
1月前
|
消息中间件 分布式计算 大数据
数据为王:大数据处理与分析技术在企业决策中的力量
【10月更文挑战第29天】在信息爆炸的时代,大数据处理与分析技术为企业提供了前所未有的洞察力和决策支持。本文探讨了大数据技术在企业决策中的重要性和实际应用,包括数据的力量、实时分析、数据驱动的决策以及数据安全与隐私保护。通过这些技术,企业能够从海量数据中提取有价值的信息,预测市场趋势,优化业务流程,从而在竞争中占据优势。
114 2
|
1月前
|
存储 NoSQL 大数据
大数据 数据存储优化
【10月更文挑战第25天】
80 2
|
1月前
|
数据采集 分布式计算 OLAP
最佳实践:AnalyticDB在企业级大数据分析中的应用案例
【10月更文挑战第22天】在数字化转型的大潮中,企业对数据的依赖程度越来越高。如何高效地处理和分析海量数据,从中提取有价值的洞察,成为企业竞争力的关键。作为阿里云推出的一款实时OLAP数据库服务,AnalyticDB(ADB)凭借其强大的数据处理能力和亚秒级的查询响应时间,已经在多个行业和业务场景中得到了广泛应用。本文将从个人的角度出发,分享多个成功案例,展示AnalyticDB如何助力企业在广告投放效果分析、用户行为追踪、财务报表生成等领域实现高效的数据处理与洞察发现。
58 0
|
2月前
|
Oracle 大数据 数据挖掘
企业内训|大数据产品运营实战培训-某电信运营商大数据产品研发中心
本课程是TsingtaoAI专为某电信运营商的大数据产品研发中心的产品支撑组设计,旨在深入探讨大数据在电信运营商领域的应用与运营策略。通过密集的培训,从数据的本质与价值出发,系统解析大数据工具和技术的最新进展,深入剖析行业内外的实践案例。课程涵盖如何理解和评估数据、如何有效运用大数据技术、以及如何在不同业务场景中实现数据的价值转化。
61 0
|
2月前
|
存储 机器学习/深度学习 分布式计算
大数据技术——解锁数据的力量,引领未来趋势
【10月更文挑战第5天】大数据技术——解锁数据的力量,引领未来趋势

相关产品

  • 云原生大数据计算服务 MaxCompute