1.02亿/月绝对造访人次，用户评论超过3900万，2013年第一季度数据再次让Yelp坐实了美国点评网领域的霸主地位。然而如此多数据的处理确实是笔不菲的开销，这里Yelp分享了他们的省钱秘诀。
在2013年第一季度，Yelp收获了1.02亿/月的绝对造访人次（数据来自Google Analytics），其中包括了平均每月1000万左右使用Yelp应用的绝对移动设备数。Yelp上的用户评论超过3900万，促成Yelp成为时装、器械到餐馆及牙医等全方面的专家。而Yelp收集到数据的多样性更是难以想象：评论、用户文件、业务描述、菜单、签到、视频照片等，并且数据的类型还在逐渐的增多。对于数据的处理有很多途径，而这次我们关注的是离线数据的处理和分析。
在2009年末，Yelp开始着眼Amazon的EMR与内部自建集群之间的选择。而在2010年中期，Yelp已经将所有产品处理转移到EMR，并且关闭了公司的hadoop集群。而当下Yelp每天运行在EMR上的作业超过500个，在此Yelp分享了一些他们的内部实践。
作业流池（Job Flow Pooling）
EMR最大的优势之一就是即时的可扩展性，可以给每个作业流控制所需的实例数量。当然这样的扩展性不是没有代价的：首先开启一个集群需要5至20分钟；其次，你需要按规定付费。这就意味着如果一个耗时2个小时零10分钟的作业，将按3个小时付费。
看起来没什么大不了，但是如果你需要着上千的作业，而每个作业的最后都需要浪费一部分时间（补足最后1小时），那么加起来可能就会浪费数个小时的时间。如果使用mrjob实现的“作业流池”，那么取代在作业结束时关闭一个作业流，mrjob在有另一个作业需求时会让流处于活动状态。这样如果另一个作业有着类似的集群配置需求，那么mrjob将对这个未关闭在作业流重利用。
实现这个功能需要注意以下几点：1. 类似的集群需求的真正意义；2. 避免多个作业之间的竞态条件；3. 集群关闭的条件。
- 类似作业流该达到以下几个标准：
- 相同的AMI（Amazon Machine Image）版本
- 相同的Hadoop版本
- 相同的mrjob版本
- 相同的引导步骤——设置Hadoop或集群选项的引导步骤
- 每个节点（比如说Hadoop主节点或工作节点）需求相同或更大的内存及储存单元
- 合格的作业——作业流最大只可以处理256个步骤
竞态条件可以通过使用锁来避免，通过S3实现锁可以支持区域的一致性，默认情况下是US West。作业的相关信息会通过一个唯一的S3键储存，其中包括了作业名称和集群类型。为了应对故障，需要给锁加设超时情况，这样其它的作业或者是作业终止程序就可以收回作业流。
工作流终止由一个计划作业处理，它会去核对空闲的作业流；会检查空闲的工作流是否将迎来下一个小时的收费，并关闭这些即将扣费的工作流。这将保证了最坏的情况不会超过默认的资费。
为了更进一步的改善作业流，作业可以等待一段时间来获得可以重用的作业流。举个例子，对于一个开发作业，mrjob在开启新作业流之前，会花30秒去尝试寻找一个免费的作业流。在实际操作过程中，没有严格限制截止时间的作业流甚至可以为其设置几个小时的等待时间。
在Yelp中，使用作业流池的情况下可以节约10%左右的开销。从一个开发者的观点，这种成本节约基本上是免费的：通过一些配置设置，不需要开发者的任何努力就可以完成这些转变。事实上，我们还看到了一些附带收益：作业的迭代开发速度得到了显著的提高，因为改进后的MapReduce作业可以对集群进行重用并且省却了集群的启动时间。
预留实例
AWS是按机器的小时计费，它提供了一些其它资费选项用以降低成本。预留实例就是其中一个比较有效的方案：预先付费以获得一个比较便宜的小时算价格。在对比AWS价格与购买服务器之后，Yelp认为应该重视这个选项。
什么情况下购买预留实例会获得总体上的成本几月，Yelp认为这取决于实例每年被使用到的时间。上图显示了运行不同价格预留实例细节：light、medium以及heavy模式。你可以进行按需付费，0.26美元/小时，但是当使用达到3000小时（4个月）左右，选用一个243元的预留实例就比较划算了，因为这样这算下来，使用“light”类型每个小时只花费0.17美元。如果使用多于3000个小时，那么视时间考察是否需要增加使用计划，heary是最大的预留实例类型，也是单小时计算最便宜的计划。
那么你的公司究竟需求多少个预留实例？这取决于具体的使用场景。在这里Yelp对过去的使用数据进行分析并推荐了一个最省钱的使用计划。原理是使用过去的数据去预测未来的使用情况，因为刚开始就做预测，其工作及带来的风险与节约的成本并不成比例。这个被称为EMRio的工具已于去年开源。它将会分析EMR的使用情况并且推荐你应该购买多少个预留实例，同时还会以可视化的方式呈现这些数据。
需要注意的是，预留实例只是一种计费模式，这就是说预留实例并不是你真的购买了一个单独的实例。在月底的时候，Amazon会检查实例使用的小时数，刨去购买预留实例的数量进行收费，当然被刨去的这一部分小时数按预留实例费率进行收费。
学到的知识
在迁移云端之前需衡量得失。对于Yelp来说，使用AWS最主要的收益就是通过减少协调开销及功能延时来增加开发效率。协调开销主要由“产品团队根据系统团队的需求去预估及请求资源”这一过程产生。采购资源，不管是机架还是服务器又或者是网络容量都需要数周的时间，这样将会延迟新功能的发布；而产品的延时发布又会造成多重影响，比如项目间的上下文切换。使用AWS产生的开销可能会比一个充分利用、定制的内部解决方案高，但是其真正的思想是让你获得更多的生产力、更快的效率。
1. 专注全局得失：也许云服务采用的花费会高于自建集群，但是Yelp确实从EMR上获得了最大利益。鉴于离线处理的尖峰（spiky）负载特性，以及通常不需要团队之间的协调，使用云可以有效的提高开发者效率。所以最佳化的使用云，专注解决你最大的瓶颈。
2. 建立在抽象之上：不要让所有人都去关注云服务的细节，就像不要让所有人都去关注数据中心细节一样。记住你最终目标是让开发者更有效率的工作，而不是赶时髦。拥有一个可扩展及自适应的基础设施，并不意味开发者就不可以像使用本地脚本一样简单的进行操控。Yelp比较偏向于mrjob，因为它让Yelp可以使用Pyhon语言来运行MapReduce作业。在本地运行一个作业与在EMR集群上只是修改两个命令行参数这么简单。
3. 先稳定后优化：这里有许多的途径可以削减成本，但是其中的大部分都会给项目带来复杂性，并让项目逐渐失去灵活性。在投入生产之前，确保你使用了一个可用且抽象的解决方案，所以你需要做ROI评估。而Yelp在使用EMR数月后才开发了EMRio，因为在使用之前就视图优化，无异于无的放矢。
4. 评估ROI：通过一些优化，成本评估是很清晰的，比如说在两个月前就使用预留实例节约多少。但是有些成本评估就比较复杂：开发过程中存在什么瓶颈，使用云方案是不是避免这些？不管是简单还是困难，在方案落实之前都需要进行评估，在投入资源削减成本之前必须审视你的用例。
