执行抽象层 先前，我们使用亚马逊的Elastic MapReduce（EMR）运行我们的Hadoop工作。EMR和S3、Spot实例运行的很好，通常也很稳定。但当我们扩展到几百个节点时，EMR变得没那么稳定，我们遇到了EMR的局限。我们在EMR上搭建了很多应用，以至于我们很难迁移到一个新系统。我们也不知道更换到哪种系统，因为EMR的一些细微差异会导致实际工作逻辑差异。为了试验其它类型的Hadoop，我们实施了一个执行接口，将所有的EMR特定逻辑都迁移到EMR执行接口。 这个接口实施了一系列方法，如“run_raw_hive_query（query_str）” 和 “run_java_job（class_path）”。这使得我们具有在几种Hadoop和Hadoop服务供应商上实验的灵活性，并可以以最小的停机时间逐渐迁移。
最终采用Qubole 最终我们决定将我们的Hadoop工作迁移到Qubole，Quble是Hadoop服务市场的新秀。考虑到目前我们的规模下EMR不再稳定，我们必须快速迁移到一个良好支持AWS（特别是spot实例）和S3的供应商。Qubole支持AWS/S3，并且起步简单。在审核Qubole，并将其性能和几个候选者（包括管理集群）比较后，我们选择了Qubole，原因如下：
总的来说，使用Qubole对我们而言是一个正确的决定，Qubole团队的技术和实施工作深深地打动了我们。从去年开始，Qubole证明了其在拍字节规模的稳定性，相比EMR，为我们提高了30%~60%的吞吐量。非技术用户也很容易上手Qubole。 我们目前的状态 在我们当下的配置下，Hadoop是一项应用在多组织、操作费用低的灵活服务。我们有100多个常规Mapreduce用户，他们每天通过Qubole网络接口、ad-hoc工作和计划工作流运行着2000多个工作。 我们有6个Hadoop集群，他们由3000多个节点组成，开发者可以在几分钟内选择创建自己的Hadoop集群。我们每天生成200亿日志信息，处理大概1拍字节的数据。 我们也在试验者管理Hadoop集群，其中包括Hadoop2，不过目前，使用诸如S3和Qubole的云服务对我们而言是正确的选择，因为它们将我们从Hadoop的操作开销中解放出来，使我们可以专注于大数据应用的工程工作。 原文链接： Powering big data at Pinterest（翻译/仁君 责编/仲浩） |
