集中式Hive元存储作为解决方案：我们大部分的工作都选用Hadoop，这是因为SQL接口很简单，业界对SQL接口也很熟悉。随着时间的推移，我们发现使用元存储作为Hadoop工作的数据目录时，Hive还会带来额外的好处。Hive很像其它的SQL工具，它提供了诸如“show tables”，“describe table”和“show partitions”的功能。这个接口比在目录中决定生成文件的清单文件简洁的多，也快的多，一致性也更好，这是因为MySQL数据库支持着这个接口。S3的清单文件很慢，S3不支持移动，还有一致性的问题。因为我们依赖于S3，所以Hive的这些特性显得更重要。 我们用与现有磁盘数据保持Hive元数据一致性的方式排列工作（是Hive，Cascading，Hadoop Steaming还是其它的）。因此，我们可以在多集群和多工作流更新磁盘数据，无需担心用户可能获得部分数据。
多层包/配置：Hadoop应用间差异很大，每个应用都可能有独特的需求和依赖项。我们需要一种灵活的、可以权衡可定制性和快速配置/速度的方法。 我们采用一种三层的方法来管理依赖项，这种方法可以将产生、调用一个千节点集群的时间从45分钟减到5分钟。
1. Baking AMI 对于那些较大的、需要花一段时间安装的依赖项，我们将他们预安装。其中包括我们为了国际化所采用的Hadoop库和NLP库包。我们将这一过程称为“baking an AMI”。不幸的是，很多Hadoop服务供应商尚不支持这种方法。 2. 自动化配置（无管理的Puppet） 我们大部分的定制化服务是使用Puppet管理的。在引导程序阶段，我们的集群在每个节点都安装和配置Puppet，仅需几分钟的时间，Puppet就可以将我们的节点和Puppet配置指定的依赖项匹配。 目前，Puppet主要的局限性如下：当我们在生产系统添加新节点时，这些新节点会自动联系Puppet管理，推翻新配置，这常常会覆盖主节点，进而导致错误。为了避免这种错误，我们允许Puppet客户端从S3获取配置，设置一个负责同步S3配置和Puppet管理的服务，从而将Puppet客户端设置为“无管理”。
3. 运行阶段（在S3上） MapReduce工作间发生的大部分定制化服务都涉及jars，工作配置和自定义代码。开发组需要可以在开发环境中修改这些依赖项，并且在不影响其他工作的前提下使这些依赖项在我们的任意一个Hadoop集群中可用。为了权衡灵活性、速度和隔离性，我们为S3上的每个开发者创建了一个隔离的工作目录。现在，当一个工作执行时，一个工作目录面向一个开发者，工作路径的依赖项直接从S3获得。
|
