Netflix的云中数据仓库架构和Hadoop PaaS——Genie
Netflix基于Hadoop的数据仓库达到Petabyte量级，而且增长迅速。他们大数据处理架构十分独特，能让他们构建一个可以在云中无限扩容的数据仓库，而且是在数据和计算能力两方面同时做到无限扩容。前不久，他们在自己的技术博客上发布了一篇文章，其中谈到了Netflix基于云的数据仓库，以及它与传统基于数据中心的Hadoop基础设施的不同之处，此外还介绍了如何利用云的弹性构建动态可扩展的系统。文章重点对Genie项目做了说明，该项目是Netflix内部的Hadoop PaaS，为作业执行和资源管理提供REST-ful API。
\u0026#xD;\n在传统的、基于数据中心的Hadoop数据仓库中，数据保存在HDFS中。HDFS可以运行在商用硬件之上，提供对大数据集的容错和高吞吐访问。在云中，最典型的方式就是跟随这个模型，将存在HDFS上的数据放在基于云的Hadoop集群上。但是，Netflix没有这么做，他们的选择是：
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n我们将所有的数据存在Amazon S3上，这是我们架构的核心原则。
\u0026#xD;\n我们使用S3作为基于云的数据仓库的真正数据来源。任何值得存留的数据都放在S3上。这包括每小时产生的几十亿个流事件，它们来自支持Netflix的电视、笔记本电脑、移动设备，被我们的日志数据管道（Ursula）抓取，还有由Cassandra提供的维度数据，来自我们的Aegisthus管道。
\u0026#xD;\n
之所以选择S3，文中给出4个原因：
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nS3保证其中存储的对象在一年期内的耐用性（durability）是99.999999999%，可用性（availability）是99.99%，并可同时承受两个机房的并行数据丢失。
\u0026#xD;\n其次，S3提供存储桶版本控制，我们使用该功能来防止数据出现无意丢失。举个例子，如果开发人员不小心误删除某些数据，我们可以轻易恢复。
\u0026#xD;\n第三，S3具备弹性，而提供事实上“无限”的存储容量。我们不需要事先准备任何存储资源，就让数据仓库做到了有机增长，从几百个T到P级。
\u0026#xD;\n最后，用S3作为数据仓库，我们可以运行多个高度动态化集群，而且能适应失败和负载。
\u0026#xD;\n
当然，也有一些问题：
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nS3的数据读取和写入都比HDFS慢。不过，很多查询和流程都是多步骤的MapReduce作业，因此第一个步骤中的mapper从S3中同时读取输入数据，最后一个步骤中的reducer将数据写回S3。HDFS和本地存储用来完成所有中间的转换和临时数据，这就降低了性能开销。
\u0026#xD;\n
Netflix使用Amazon的Elastic MapReduce（EMR）Hadoop 版本。他们会使用多个Hadoop集群处理不同负载，全都访问同样的数据。一个超过500个节点的“查询”集群，供工程师、数据科学家、分析人员使用，完成随机查询。还有一个与“查询”集群大小相似的“生产”（或称为“SLA”）集群，运行由SLA驱动的ETL（数据抽取、转换、加载）作业。他们还有其他一些“研发”集群，根据需要启动。
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n如果我们使用HDFS作为数据来源，那么就要把数据复制到所有的集群中。使用S3，这就不是问题了，所有的集群可以马上访问同一个完整的数据集。
\u0026#xD;\n
亚马逊通过EMR提供Hadoop IaaS，EMR有API可以准备和运行Hadoop集群。但Netflix实现了自己的Hadoop PaaS，名为“Genie”，提供更高层面的抽象。开发人员可以使用RESTful的API来提交单个Hadoop、Hive或是Pig作业，而不需要准备新的Hadoop集群，或是安装任何Hadoop、Hive或Pig客户端。而且，这让系统管理员可以管理和抽象出云中不同Hadoop后端资源的配置。
\u0026#xD;\n那为什么还要开发Genie呢？
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n我们的ETL过程是松耦合的，组合使用Hadoop和非Hadoop工具，跨越云和我们的数据中心。举个例子：我们需要在基于云的Hadoop数据仓库中使用Pig和Hive执行每日总结，并将结果加载到在数据中心的关系数据仓库中。这是很常用的大数据架构，用小得多的关系数据仓库来对上基于Hadoop的系统。前者提供实时性更强的互动查询和报表，而且与传统的BI工具整合更好。目前，我们使用Teradata作为关系数据仓库。不过，我们也在研究Amazon的Redshift新产品。
\u0026#xD;\n在数据中心中，我们使用企业级调度应用UC4，用其定义数据中心和云之间不同作业的彼此依赖关系，将它们作为“ 流程流（process flow）”运行。因此，我们需要一种机制，在不安装整个Hadoop软件栈的前提下，做到从任何客户端启动Hadoop、Hive和Pig作业。而且，由于我们每小时运行数百个Hadoop作业，需要该系统来水平扩展，主要原因在于：随着将更多ETL和处理工作放在云中的Hadoop上，负载会不断增加。最后，由于云中的集群总有可能发生变化，而且有多个Hadoop集群可以运行Hadoop作业，我们需要从客户端中抽取出后端集群的具体细节。
\u0026#xD;\n
之所以不用一些现有的工具，是因为：
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n开源社区中现在没有合适的工具，能满足我们的需求：要有API可以执行作业、抽象后端集群、有能力提交作业到多个集群、足够的可扩展性（水平或是其他方式）等等。
\u0026#xD;\n
Genie到底是什么呢？
\u0026#xD;\nGenie是一系列REST-ful服务，用来管理Hadoop生态系统中的作业和资源。其中有两个关键服务。
\u0026#xD;\n- 执行服务（Execution Service）：提交和管理Hadoop、Hive和Pig作业。客户端通过执行服务API来与Genie交互，发送带有参数的JSON或是XML消息启动作业。如果一个作业提交成功，Genie会返回一个作业ID，可用它获取作业状态和输出URL。\u0026#xD;\n
- 配置服务（Configuration Service）：保持可用Hadoop资源的资源库，包括需要链接和在这些资源上执行作业的元数据。配置服务跟踪所有目前运行的集群，还有它们支持的调度类型。\u0026#xD;\n
文中还简单介绍了如何使用Genie完成动态资源管理。
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n在Netflix，不同工程师团队在AWS的自动扩展组（auto-scaling groups，简称ASG）内的预留实例上运行自己的服务，它们会根据负载扩展或收缩。很多ETL作业在午夜执行，这个时候，很多ASG都已经变小了。因此，我们使用这些过剩的预留实例来启动“奖励”集群，补充其他生产集群。我们会用配置服务注册这些实例，Genie客户端（ETL作业）会使用执行服务API访问这些新集群。当工程团队需要他们的实例时，“奖励”集群会中止并取消注册，而且无法通过Genie客户端访问。
\u0026#xD;\n不像传统的Hadoop集群，我们不需要做滚动升级。如果需要升级一个生产（SLA）集群，一个方法是使用升级后的软件栈来启动一个新的生产集群，然后停止将流量路由到旧集群上，要实现这个目的，只需要设置其状态为“Out of Servcie”。另一个方法，是将运行中的集群状态设置为“Out of Service”，然后执行升级，并临时将另一个运行中的集群设置为SLA集群。
\u0026#xD;\n
目前，Genie项目还没有开源，让我们期待Netflix将其放在自己Github页面上的那一天！