这篇BLOG是ODPS商业化一系列文章之一，更多请点击这里……

　　ODPS正式商业化以后，微博上议论比较多的是计量计费模型。刚好这件事我全程参与，仔细写写。ODPS的计量计费规则和价格请以阿里云官方网站上的说明和数字为准。这里的内容只反映当前状态，不能保证实时更新。

　　ODPS收费以项目（Project）为单位，对存储、计算和数据下载三个方面分别计费。存储和数据下载的收费形式与其他云产品很类似。而计算这边，目前ODPS仅开放了SQL任务，计费公式为：一次SQL计算费用 = 计算输入数据量 * SQL复杂度 * SQL价格。具体而言：
　　1.计算输入数据量：指一个SQL语句实际扫描的数据量，大部分的SQL语句有分区过滤和列裁剪，所以一般情况下这个值会远小于源表数据大小。
　　2.SQL复杂度：先统计SQL语句中的关键字，再折算为SQL复杂度
　　SQL关键字个数 = Join个数 + Group By个数 + Order By个数 + Distinct个数 + 窗口函数个数 + analyze个数 + max( insert into个数-1, 1)
　　
　　例如，用户输入的SQL语句是：INSERT INTO TABLE out1 SELECT * FROM shop a JOIN sale_detail b ON a.shop_name = b.shop_name;则其SQL关键字个数是2，而SQL复杂度是1。
　　再例如，用户输入的SQL语句是：SELECT DISTINCT total1 FROM (SELECT id1, COUNT(f1) AS total1 FROM in1 GROUP BY id1) ORDER BY total1 DESC LIMIT 100;　则其SQL关键字个数是4，而SQL复杂度是1.5。

　　对于上面这个模型，大家常常提出各种问题：为什么只考虑数据量，而不引入CPU、内存、网络通信等直观的技术指标？进一步，为什么不引入计算时间，使用像“CPU*小时”或“内存*小时”这样的计量单位？为什么引入SQL复杂度这样一个稍微麻烦的概念？模型里包含的关键字和公式里的权重是依据什么标准确定的？从一开始，ODPS策略团队的数据分析师就在这些拷问中不断纠结和探索。

　　由于ODPS在阿里内部已经大规模投入使用，每天生产上跑着几十个BU的上万个作业，吞吐上百P的数据。因此分析师先拿到日志，各种清洗，各种图表，各种统计探查，各种回归和分类，获得了很多好玩的发现。由此产生的结论是源于严谨的数据分析和产品逻辑，并通过各方面很多审核。

　　下面就来说说建模的过程。由于保密原因很多具体细节不能公开分享，但总体思路也许值得大家看一看。

　　首先，要明确什么是好的计量计费模型？计量计费模型是产品特征的重要组成部分，需要遵循的的几个原则：
　　1.基于统计，简单，可解释：不拍脑袋YY，模型的逻辑源于统计事实；在可行范围内尽量简化；公式的输入参数都应该是用户可见的条件；
　　2.可预期，可重复：在跑计算作业之前，用户能根据输入和环境配置算出这次计算底能花多少钱；完全同样的作业重复跑价格不变；
　　3.正引导性：用户采用符合“最佳实践”的操作方式不会受到惩罚，最好受到奖励。
　　关于以上这些计量计费原则，举一些类比的例子。
　　例子一：手机话费的计量，两个人面对面用手机打电话，与一个在城南一个在城北打电话，实际成本肯定不一样，但是如果电信运营商直接按照通信链路经过了几个路由器，几次转发来计费，用户就要晕倒了。所以真实的计费就采用相对粗略的、阶梯的、区域的划分。因为这符合前文提到的3条建模原则。
　　例子二：伊拉克战争中，由于基础设施匮乏，电力局收电费，不是按照电表算，而是到用户家里数灯泡和电器的个数，一个灯泡多少钱，一个空调多少钱。这个计费策略当然很粗略，但是它在这个特定场景下是行之有效的。仔细看看，你会发现它同样符合上面的3条建模原则。

　　接下来，要考虑怎么衡量一个计算作业的成本？
　　很常见的想法是：把一次计算占用的进程、内存，以及中间IO交换的数字都拿出来，分摊对应的硬件成本，也就是CPU、内存、网络设备和磁盘。
　　这个思路是错的，因为实际运行的作业占用各种资源肯定不均衡，总有瓶颈。集群的计算节点是个有机整体，部件不能拆开单用，如果某瓶颈环节100%占满了（例如磁盘和网络IO能力），即使其他硬件空闲（例如CPU），也不可能拿去给其他作业使用了。
　　所以正确做法应该是：先统计到底哪项功能指标是瓶颈，平均闲置率最低，然后以该指标直接换算整个节点全部成本，其他指标都可以忽略。当然，不同的计算作业瓶颈不一样，成本分摊的方式也会不一样，例如Mapreduce类作业一般是IO密集型的，磁盘和网络IO交换是瓶颈；而MPI类的算法一般是CPU密集型，CPU和内存是瓶颈。

　　有了上面两项思考逻辑做为基础，回过头来，我们看看上文用户提到的问题。

　　SQL计算的计量模型为什么引入输入数据量作为参数？
　　很明显，因为SQL以及它背后的Mapreduce计算是典型的IO密集型运算。而且“输入数据量”符合上文计量计费原则1和原则2，用户可以自己查看、控制和预估。
　　这样还有个好处，就是让用户时刻注意语句的写法。因为这里的“输入数据量”是指实际扫描的数据量，如果SQL语句有分区过滤和列裁剪，费用就会远小于源表数据大小：
　　a) 列裁剪：例如用户SQL是select f1,f2,f3 from t1; 只计算t1表中f1，f2，f3三列的数据量，其他列不会参与计费。
　　b) 分区过滤：例如SQL语句中含有where ds>”20130101”，ds是分区列，则计费的数据量只会包括实际读取的分区，不会包括其他分区的数据。
　　有了这个游戏规则，精明的用户一定会尽量用select f1, f2, f3 from…替代select * from…，能用分区裁剪就尽量避免全局扫描。而这正符合数据仓库开发的最佳实践。很多成熟的数仓团队已经把它作为生产纪律强制执行。比如“不准使用select * from …”这一条，如果上游表追加了新的一列（这在数仓生产中很常见），使用select *的SQL作业往往运行失败。因此，我们的模型又符合了前文建模原则3，鼓励最佳实践，平台和用户都会因此获得好处。
　　一个有趣的现象是，当我们用这个计量计费模型试算阿里内部不同团队的作业时，也发现了分化：有一些BU，例如阿里金融，拥有很多资深的数仓专家（这些家伙甚至能用SQL实现一个跳棋程序），这种团队的计算花费汇总下来，往往接近甚至低于平台的成本曲线，说明其主力生产SQL经过了精心优化；然而也有一些BU的团队，显然刚开始接触大数据分析业务，把ODPS当MYSQL用，于是产生的计算费用远远高于平台耗费的成本。我们可以推测，对外的场景下也会有类似的事发生，而且随着时间推移，用户行为会整体向更经济的方向移动。这也是平台团队想要看到的，因为我们可以腾出更多资源给新用户和新业务。

　　为什么不引入CPU、内存、网络通信等更直观的技术指标？为什么不引入计算时间，使用像“CPU*小时”或“内存*小时”这样的计量单位？
　　的确传统的超算中心是这么计费的。我们认为做错了。因为这样做违反了上文计量计费建模原则1和原则2。
　　运行一个SQL作业占用多少CPU、内存、网络通信，完全是由平台方的具体技术实现决定的。这些参数其实和用户无关，用户也无法控制，无法预测。平台定义某条SQL很贵，用户也没办法跑来看代码，挑战说ODPS不应该用这么多内存。
　　另外，参考前面说的，其实不需要那么好多个指标，只需要关注一两个关键的瓶颈指标。
　　进一步，对于ODPS这样的离线计算场景而言，不可能保证每次运算的时间精确一致，更无法预测。如果以运行时间为依据收费，有可能第一次运算用了10分钟，第二次由于调度原因或者发生了failover，用了12分钟。如果完全相同的计算，今天收1块，明天收1.2块，用户就疯掉了。
　　反过来说，采用这种计量计费模型，也会让平台技术团队丧失持续优化系统的动力。

　　为什么引入SQL复杂度？模型包括的关键字和公式里的权重是依据什么标准确定的？
　　由于ODPS支持强大的SQL语法。实际运行中除了显式输入输出，中间阶段还会进行多次临时文件磁盘交换（专业术语一般称为Shuffle）。例如：可以在一条语句里，join十几个表，套上七八个子查询，再加上各种全局分组和排序……这些操作都会导致IO的明显增多。问题是直接采用中间IO量或者Shuffle次数计费，又违反了上文的计量计费原则1，于是我们必须寻找替代方案。
　　幸好能造成Shuffle的SQL关键词操作只有7个：Insert Into、Join、Group By、Order By、Distinct、 窗口函数和analyze。因此我们尝试用关键字个数来拟合中间IO，获得了不错的效果。公式里的权重值都是依据阿里内部实际生产的日志回归出来的，是科学和严谨的。

　　说到这里。用户可以看看Google BigQuery是怎么收费的。他们甚至在官网上贴了一篇文字，描述其计量计费模型的“设计哲学”。Google BigQuery与ODPS商业化的进程一先一后，大家彼此完全独立思考，得出的方法论和最终模型却殊途同归，这实在是一件很好玩的事。至于Google BigQuery公式里不包括SQL复杂度，原因也很简单：他们的SQL功能比ODPS SQL弱很多，例如根本就不支持两个大表的Join。由于这个原因，所以其SQL基本就对应于ODPS SQL中，复杂度为1的那个子集。

　　和ODPS类似的公有云产品还有AWS EMR。不过EMR本质上是租用虚拟机然后在上面搭hadoop，不是多租户的，也就是多个用户无法分享单节点上的计算和存储。因此大家的收费模型思路不同，针对不同的场景各有优劣。我很想看看接下来市场的反馈。

　　当然ODPS还有很多需要做的，例如接下来会推出计费计算器：输入SQL，返回需要花多少钱。再例如会提供更多打包计费的方式，例如包年包月,以简化用户的智力负担。ODPS还支持SQL以外的更多功能，例如mapreduce编程模型、xlib机器学习算法，它们如何计量计费还在摸索中。

　　总结一下。如果您是ODPS用户，希望这篇文章展示了ODPS计量计费模型的逻辑，能帮你优化作业节省成本，也希望您能体会到其中的诚意。如果您是同行，云计算领域的产品经理，期望这篇文章对你规划自己产品的收费策略有借鉴意义。我们在创新，要获得问题的答案，甚至定义问题本身，都需要洞察和思考。

　　最后感谢ODPS策略团队，尤其是数据分析师@班马明，上面这些逻辑都是他被几百张图表痛苦折磨几个月之后逐步梳理出来的。事实不止一次证明，数据分析师要有一颗产品经理的心，反之亦然。顺便提一下，面对ODPS系统的海量日志数据，@班马明同学“吃自己的狗粮”，利用ODPS本身完成了数据的抽取、探查、挖掘和验证。

　　这篇是ODPS商业化一系列文章之一，更多请点击这里……