MaxCompute是一套阿里自主研发的数据仓库解决方案。产品除了功能、性能、简单等优势外，还能在费用上节省下一大笔前。墨迹天气使用MaxCompute，除了性能和稳定性也有提升外，整体存储和计算的费用比之前节省70%。这是如何做到的呢，这里有一些常用的规则。
在讨论如何做到之前，我们先看下MaxCompute是如何计费的。根据目前的文档，目前的计费方式包含数据的存储、数据的下载以及计算费用。其中计算费用又分I/O后付费和预付费两种收费模式。I/O后付费根据实际的计算来进行收费；而预付费相当于包了几个CU只有购买者可以使用，这几个CU上随便怎么计算都不会产生计算费用。所以如何减少费用，也就是转换成如何减少存储的费用、如何减少下载的费用以及如何减少计算的费用。
存储
数据存储在MaxCompute上是使用列式存储并有压缩的，底层数据存储方式不需要用户自己维护。但是用户可以通过减少存储在MaxCompute上的数据量来减少存储的费用。可以通过及时删除不需要的数据来减少存储费用。这里需要推荐用一个叫生命周期（lifecycle）的功能来定时回收过期的数据。设置了生命周期后，如果是分区表，分区表里的某个分区如果在指定的时间内数据没发生变更，系统会认为这个分区已经不需要了，会自动删除这个分区。如果是非分区表的话，指定的时间内没有数据变化就会删除这整张表。这个功能可以用来配置到一些历史记录表上，比如说如果不想要一年之前的历史记录，可以把表根据写入时间做分区，然后设置生命周期为一年。数据写入的时候，每天数据只写入到当天的那个分区里。一年后，之前的数据因为一整年都没有数据写入，触发生命周期的条件，并后台定时作业删除对应的分区里的数据。
在实际使用中，除了因为没及时删除过期不要的历史记录造成的额外的存储费用外，更多的是因为对数据的管理不到位导致的一些不需要的表一直没删除导致的空间占用。仔细想想，在做查询的时候使用Create table xx as select先存了一些临时表，用好没删除一直放着占用从存储空间，这种事情应该每个人都做过一些。但是如果你真的要去找找哪些数据需要删除，哪些数据是业务数据不能动的时候，对着list tables;出来的几百几千张表也是很无从下手吧。对数据仓库做好分层，做好命名规范，对于每一层根据使用需要配置不同的生命周期回收策略，用一个好的数据管理来保证数据仓库的表的有序存储，不仅能节省一笔存储的钱，也能在实际使用的时候，快速找到需要的表，便于数据的管理和使用。而如果有一些计算过程产生的临时表，后续又确定用不到的，可以在计算结束及时删除。具体可以参考祎休写的基于阿里云数加的企业大数据仓库架构建设思路有比较详细的说明。
下载
下载数据并非全部都会收费的，有一些情况下数据下载也不会产生费用。合理利用这些规则，选择正确的下载方式就能减少下载的费用（而且下载不收费的方式也正好是下载最快的方式）。具体的规则可以参考文档。
另外下载的费用，还和下载的文件的大小有关系。通过合理的表结构设置和数据生成方式，把每次需要下载的数据放到一张表（或一个分区）里，减少下载量也是减少费用的一种策略。比如说需要下载3年级的学生信息的时候，下载全部的学生信息后再执行过滤，肯定比不过先根据年级对学生进行分区，然后只下载3年级的分区来的方法好。
计算
计算里需要注意的相对会多一些。不过我们还是先看看计算的费用和什么有关。先说I/O后付费，现在暂时还只是收取了SQL的费用，所以本文也只讲SQL的部分。看到SQL的费用是根据输入的数据量和SQL的算法复杂度有关的。
计算引擎在计算的时候，合理设置表的分区字段可以减少数据的输入量。关于分区可以参考这里。计算引擎在做执行计划解析的时候，如果发现查询过滤条件是用分区字段做过滤的时候，可以只读计算涉及的分区的数据，从而减少输入的数据量。
除了减少输入的数据量，减少计算复杂度也是一种方法。算法复杂度的优化一般涉及到代码层面的优化，而且有时候需要和业务结合起来。比如前面已经有过一些数据预处理知道本次计算的数据某个字段没有重复，那这次计算的时候就可以少加一次distinct或者group by。通过代码层面结合业务逻辑，一起优化SQL语句减少计算的复杂度，是减少计算费用的一种方法。
另外减少计算的次数也是一种方法。比如某几个计算都需要用到某个实时表的数据，而且都是在某种过滤和汇总之后的再加工，那完全可以把中间可以复用的计算过程保存下来，在数据仓库上做适量的轻度汇总甚至高度汇总。后续的计算可以拿汇总数据再做进一步的计算。这样虽然中间多存了一些数据，但是后续的计算的时候可以少算一些逻辑。这是数据仓库里经常用到的空间换时间的方法。配合之前提到的生命周期，可以用最小的存储费用的代价获得最大的计算费用的减少。当然合理利用这种方法，除了可以减少计算费用外，因为减少重复计算，也可以减少计算的时间提高效率。
除了以上提到的这些，也可以考虑后付费的方式来跑计算，也就是计算费用是包年包月的。一般来说，满足以下条件可以考虑使用后付费
- 任务大部分是周期任务，任务量比较均匀。如果任务以偶发性的临时查询为主可能不合适用后付费
- 任务的提交事件比较分散，如果都集中在某个时间点一起算的，也不太合适
- 经过一段时间的试运行，任务数量已经基本可以估计，不会短期内有比较的明显的增加或者减少
如果不满足这些 条件，者很容易出现在高峰期购买的CU不够用，任务出现排队；低谷的时候资源又利用不起来，造成浪费。
其他
关于费用，其实还有两个非常关键的问题
- 我每天都花了多少钱，如何优化？
可以参考这里，看看每天的账单，通过检查里面的计算、存储和下载分别产生了多少费用。从而从对应的角度去做优化。另外也可以在表格里做金额的排序，看看金额最高的几笔费用是什么费用，看看能否针对性做一些优化。 - 我这个SQL提交后会产生多少费用？
如果产生的费用都不清楚，那提交一个SQL时心里是没底的。在大数据开发套件的数据开发里，跑SQL会跳出消费提醒，从而提前知道提交后会产生的费用。如果发现金额特别高，可以考虑先做一些优化后再提交以免产生不必要的费用。如果是直接在MaxCompute客户端里跑SQL的话，可以用cost sql <SQL Sentence>;估算SQL的费用。
