最近在Sigmod2011年大会上，Yahoo公司publish了一篇文章叫做
Nova:Continuous Pig/Hadoop Workflows
.由于小弟之前一直关注MapReduce工作流的优化，而且毕业开题的方向也和这篇文章的Motivation有些相近，就抽时间研读了一下。
Nova这篇文章是Christopher在Yahoo研究院做的一项工作，Chris长期钻研MapReduce工作流，之前大名鼎鼎的Pig 就是出于此人，还做了很多关于Pig上的优化工作。 他的主页 上publication和相关经历，在学术界(Stanford、CMU、Berkeley)以及工业界Yahoo都有很大的影响力。
Nova是一个数据流管理器，支持有状态的增量数据计算模式。文章的题目是Continuous，在写的Blog的名字的时候，我一直想不到一个非常恰如其分的翻译出来。Continuous在看完整篇文章之后，翻译成流动的可能会更适合一些。
应用需求和背景
在Pig诞生之前，我们要实现一个复杂的逻辑任务，只能一个一个MapReduce去Coding。这种方式对于MapReduce早期来说，是可以容忍的。因为那个时候，大多数使用MapReduce的工作人员都是工科背景出身，写写Mapper和Reducer并非难事。可是随着数据海啸的来临，传统的DB(Oracle、DB2)已经不能满足海量数据处理的需求，MapReduce逐渐成为了数据处理的事实标准，被应用到各行各业中。所以，我们不再期望所有的客户都能快速开发应用相关代码，只能把客户的工作变得简单，就像使用SQL语言，经过简单培训就可以“云”上操作。
Pig就是为了屏蔽MapReduce开发的繁琐细节，为用户提供Pig Latin这样近SQL语言处理能力，让用户可以更方便地处理海量数据。Pig将SQL语句翻译成MR的作业的集合，并通过数据流的方式将其组合起来。然而，在实际的生产系统中，数据是不断追加更新的，如何利用原有计算的结果，按照一定频率执行计算，来处理不间断到来的数据，成为了一个运行系统必须要解决的问题。
正是有了Pig和当前数据处理的需求，Christopher Olston提出了Nova系统，Nova是一个数据量管理器，用来支持有状态的数据的追加操作。论文中介绍了在雅虎公司的三个应用场景：
1）吸收和分析用户的行为日志数据（点击流分析、搜索内容分析等），改进匹配和排名算法，以提高检索和广告业务的质量。
2）构建和更新search index。对于web-crawler抓取了的内容是一个流数据的形式，这包括去冗余、链接分析、内容分类、基于点击次数的受欢迎程度计算(PageRank)、最后建立倒排表。
3）处理半结构化数据订阅（data seeds）服务。包括：deduplcaitin（去冗余），geographic location resolution，以及 named entity recognition.
这些应用可以使用PigLatin来解决，然而在pig之上缺少一个workflow manager链接不同的数据处理过程，使得数据在这些分离的计算过程之上流动起来(continuous)。这相当于在pig之上有架构了一层。这样做的好处为：
1）持续的处理流程。在新增数据之后，上层流程管理器只需跟踪delta 数据集的内容，然后使用合适的顺序执行相关计算即可。
2）独立调度。一个持续执行的作业，它的不同部分的执行频率是不同的，流程管理器可以控制作业的部分内容单独调度。
3）cross-module优化。在pig做MapReduce作业流程组合之上，添加一层流程管理器，它可以识别和利用特定的优化选项。例如，对于读取同一份数据源的MR作业，可以合并成一个loading data的过程，这样避免了在一个流程中单一数据被load两次的带来的开销。
4）可管理特性。使得工作流程的开发、运行和调试都可以被管理。
Nova就是根据上面4个需求，在pig/hadoop的之上，构建的一个与工作流相分离的工作流管理器。流程管理层(Nova)与流程映射层(Pig)分离，可以使得Hadoop/pig的修改，不会影响上层的工作，另外作为一个独立的模块，也便于维护。
核心思想
1）所有的操作都是基于Block(HDFS的中数据分块的概念)的原子性的操作。
2）工作流两类基本组件：操作单元和数容器，必须是数据容器 --》操作单元--》数据容器的过程，以及连接通道。
3）从数据容器到操作单元有两种方式：ALL、New，分别代表数据容器中全部数据、以及管理器监视的更新的数据。从操作单元到数据容器支持B和delta过程。分别代表将所有的数据做一个snapshot传入通道，与输出与existing data 有更新的数据。有一个例子的示意图如下：
4）支持数据操作过程。支持Merge、Chain、diff操作。这里引用其中一段话：
5）以时间或者事件为基准的调度。一个workflow从底向上进行的，首先是task的定义，组装几个task成为workflow片段(workflowette).所有的调度需求都是基于workflowette而言，将调度需求通过三种不同的trigger来描述， a) Data-based trigger，在数据到达某个通道时执行;b)Time-based triggers，周期性地执行;c)cascade triggers，当一个workflowette达到某个状态时执行。
6）Data Compaction与Garbage Collection。从B0 经过 0->1 , 1->2, 2->3过程之后，将最后的结果B3存储，而不需要存储B1、B2中间结果，实现数据压缩。处理过程中，会使用一个指针指示当前数据集所处的处理阶段，例如，如果B0 经过 0->1 , 1->2后，指针位于2，那么B0，0->1, 1->2都可以清除。对于一个海量数据处理系统，存储空间是十分珍贵的，要尽可能得减小中间数据存储的空间。
系统架构
对于一个做系统的人而言，一个系统的成败就在于它的架构上。Nova的系统的架构图：
一个分布式系统的体系架构的设计中，最为重要的要提供如下的性能：
1）多server提供均衡的负载。高负载下，能够通过多个server来分担工作负荷，应该尽量避免单点故障问题。
2）容错性。在当前下，节点失效之后，能够在Client不知情地情况下恢复服务，或者将这种损失降到最低。
3）模块化。这是所有系统都需要保持的优良特性，分布式系统也不例外。
4）良好的用户界面。
Nova的arch是如何保证这些特点呢？
首先，Nova框架支持多个Server Instance，对于clients支持Load balancing，默认使用Round-Robin调度算法。同时，watchdog是zookeeper监测不响应服务的server instance，重启一个新的replacement取代它，重新更新对应的服务器目录路由表。
第二，Nova提供了一个MySql Cluster的Metadata database，用来保存流程管理器获得的clients提交作业的状态信息。这是保证系统容错性的一种做法。通过另外的一个独立的数据库保存MetaData,在多个Server instances下可以更有效地实现同步。
第三，下面将分析各个的模块：
1）User Interface. 用户接口主要为用户提供了注册、解除channel、trigger与workflowette之间的关联，并为上层用户提供查看workflowette执行状态。
2）Process Manager.进程管理者主要按照TriggerManager启动的事件，启动一个workflowette进程，交由Process executor去执行。同时监控所有在该Manager下注册的workflowette执行状况。
3）Data manager:数据管理者负责为Process Manager启动的进程准备数据。它维护了hdfs的block与文件/文件夹的映射关系。（为channel准备输入数据，预留输出数据的位置）
4）process Optimizer：进程优化者主要驻留对于workflowette不同的优化策略。例如，对于不同workflowette读取相同文件，可以合并reading data的过程。这一点，我结合自己的工作，它能实现这一点得意于：数据通道和Data Manager维护的信息。paper中还指出：Other types of optimizations we may consider in the future include:pipelining workflowettes that form a chain," and adjusting the degree of parallelism to trade resource consumption against execution time.其中第一个是管道workflowette，另一个动态调整并行的粒度来换取较高的执行效率。其中，这里提到pipeline，我认为，Chris的这个工作，应该才刚开始，提供类似流水线的处理方式，才是支持Continuous工作流的关键。
5）Process executor进程执行者。将workflowette提交到Oozie上，跟踪执行状况，并反馈给Process Manager。
6）Trigger manager 进程激发器。它作为一个单独的线程存在，主要负责对于workflowette中提到3类的Trigger的维护，在条件满足的情况下，启动Trigger，通知Process Manager.同时Trigger还定期做Data Compaction和Garbage Collection。
评测
测试读写效率。由于使用了数据压缩技术，性能较Map-side merge 和Reduce-side merge要好。
另外的增量数据处理的性能如下：
另外，由于使用了Channel复用技术，这里叫做Scan Sharing，它的优势：
ps:我的思考
读完这篇文章，又花了半天时间写了一个中文分析之后，给了我一些启示：
1）做分布式系统是一个积累的工作，现在做技术的朋友再也不要蔑视Distributed了，它要处理的工作真得很复杂，必须沉下心，多看源码，多总结，多体会，多coding.这是一条不归路.
2)针对这个工作，我个人认为最大的意义是它梳理了我对workflow optimizer或者作业流编译器的框架。
3)在分布式处理领域，有效的往往是general的。记得在前些天看的Eurosys11上的一篇文章Scarlett，为了解决热点数据spot的问题，就是设置滑动窗口累积不同数据的热度，然后将较热的数据拷贝到不同节点上去，增加相关数据的拷贝，实现平衡负载。这些解决办法都很general，因为不general的，你解决不了分布式数据处理的大问题，比方说MapReduce Schema，你还能找到更朴素的思想吗？但是它成功了，不过我想补充一句：Overnight success takes long time.
本篇文章属于原创，其中有不合适的地方，还请大家批评指正。如果要联系本文作者，请发邮件：
jiangbinglover@sina.com
jiangbing@ict.ac.cn
如需要转载，请附上上面的邮箱地址，谢谢，我期望和更多的朋友关于MapReduce、Hadoop、分布式系统展开有价值的讨论。谢谢！
Nova这篇文章是Christopher在Yahoo研究院做的一项工作，Chris长期钻研MapReduce工作流，之前大名鼎鼎的Pig 就是出于此人，还做了很多关于Pig上的优化工作。 他的主页 上publication和相关经历，在学术界(Stanford、CMU、Berkeley)以及工业界Yahoo都有很大的影响力。
Nova是一个数据流管理器，支持有状态的增量数据计算模式。文章的题目是Continuous，在写的Blog的名字的时候，我一直想不到一个非常恰如其分的翻译出来。Continuous在看完整篇文章之后，翻译成流动的可能会更适合一些。
应用需求和背景
在Pig诞生之前，我们要实现一个复杂的逻辑任务，只能一个一个MapReduce去Coding。这种方式对于MapReduce早期来说，是可以容忍的。因为那个时候，大多数使用MapReduce的工作人员都是工科背景出身，写写Mapper和Reducer并非难事。可是随着数据海啸的来临，传统的DB(Oracle、DB2)已经不能满足海量数据处理的需求，MapReduce逐渐成为了数据处理的事实标准，被应用到各行各业中。所以，我们不再期望所有的客户都能快速开发应用相关代码，只能把客户的工作变得简单，就像使用SQL语言，经过简单培训就可以“云”上操作。
Pig就是为了屏蔽MapReduce开发的繁琐细节，为用户提供Pig Latin这样近SQL语言处理能力，让用户可以更方便地处理海量数据。Pig将SQL语句翻译成MR的作业的集合，并通过数据流的方式将其组合起来。然而，在实际的生产系统中，数据是不断追加更新的，如何利用原有计算的结果，按照一定频率执行计算，来处理不间断到来的数据，成为了一个运行系统必须要解决的问题。
正是有了Pig和当前数据处理的需求，Christopher Olston提出了Nova系统，Nova是一个数据量管理器，用来支持有状态的数据的追加操作。论文中介绍了在雅虎公司的三个应用场景：
1）吸收和分析用户的行为日志数据（点击流分析、搜索内容分析等），改进匹配和排名算法，以提高检索和广告业务的质量。
2）构建和更新search index。对于web-crawler抓取了的内容是一个流数据的形式，这包括去冗余、链接分析、内容分类、基于点击次数的受欢迎程度计算(PageRank)、最后建立倒排表。
3）处理半结构化数据订阅（data seeds）服务。包括：deduplcaitin（去冗余），geographic location resolution，以及 named entity recognition.
这些应用可以使用PigLatin来解决，然而在pig之上缺少一个workflow manager链接不同的数据处理过程，使得数据在这些分离的计算过程之上流动起来(continuous)。这相当于在pig之上有架构了一层。这样做的好处为：
1）持续的处理流程。在新增数据之后，上层流程管理器只需跟踪delta 数据集的内容，然后使用合适的顺序执行相关计算即可。
2）独立调度。一个持续执行的作业，它的不同部分的执行频率是不同的，流程管理器可以控制作业的部分内容单独调度。
3）cross-module优化。在pig做MapReduce作业流程组合之上，添加一层流程管理器，它可以识别和利用特定的优化选项。例如，对于读取同一份数据源的MR作业，可以合并成一个loading data的过程，这样避免了在一个流程中单一数据被load两次的带来的开销。
4）可管理特性。使得工作流程的开发、运行和调试都可以被管理。
Nova就是根据上面4个需求，在pig/hadoop的之上，构建的一个与工作流相分离的工作流管理器。流程管理层(Nova)与流程映射层(Pig)分离，可以使得Hadoop/pig的修改，不会影响上层的工作，另外作为一个独立的模块，也便于维护。
核心思想
1）所有的操作都是基于Block(HDFS的中数据分块的概念)的原子性的操作。
2）工作流两类基本组件：操作单元和数容器，必须是数据容器 --》操作单元--》数据容器的过程，以及连接通道。
3）从数据容器到操作单元有两种方式：ALL、New，分别代表数据容器中全部数据、以及管理器监视的更新的数据。从操作单元到数据容器支持B和delta过程。分别代表将所有的数据做一个snapshot传入通道，与输出与existing data 有更新的数据。有一个例子的示意图如下：
4）支持数据操作过程。支持Merge、Chain、diff操作。这里引用其中一段话：
5）以时间或者事件为基准的调度。一个workflow从底向上进行的，首先是task的定义，组装几个task成为workflow片段(workflowette).所有的调度需求都是基于workflowette而言，将调度需求通过三种不同的trigger来描述， a) Data-based trigger，在数据到达某个通道时执行;b)Time-based triggers，周期性地执行;c)cascade triggers，当一个workflowette达到某个状态时执行。
6）Data Compaction与Garbage Collection。从B0 经过 0->1 , 1->2, 2->3过程之后，将最后的结果B3存储，而不需要存储B1、B2中间结果，实现数据压缩。处理过程中，会使用一个指针指示当前数据集所处的处理阶段，例如，如果B0 经过 0->1 , 1->2后，指针位于2，那么B0，0->1, 1->2都可以清除。对于一个海量数据处理系统，存储空间是十分珍贵的，要尽可能得减小中间数据存储的空间。
系统架构
对于一个做系统的人而言，一个系统的成败就在于它的架构上。Nova的系统的架构图：
一个分布式系统的体系架构的设计中，最为重要的要提供如下的性能：
1）多server提供均衡的负载。高负载下，能够通过多个server来分担工作负荷，应该尽量避免单点故障问题。
2）容错性。在当前下，节点失效之后，能够在Client不知情地情况下恢复服务，或者将这种损失降到最低。
3）模块化。这是所有系统都需要保持的优良特性，分布式系统也不例外。
4）良好的用户界面。
Nova的arch是如何保证这些特点呢？
首先，Nova框架支持多个Server Instance，对于clients支持Load balancing，默认使用Round-Robin调度算法。同时，watchdog是zookeeper监测不响应服务的server instance，重启一个新的replacement取代它，重新更新对应的服务器目录路由表。
第二，Nova提供了一个MySql Cluster的Metadata database，用来保存流程管理器获得的clients提交作业的状态信息。这是保证系统容错性的一种做法。通过另外的一个独立的数据库保存MetaData,在多个Server instances下可以更有效地实现同步。
第三，下面将分析各个的模块：
1）User Interface. 用户接口主要为用户提供了注册、解除channel、trigger与workflowette之间的关联，并为上层用户提供查看workflowette执行状态。
2）Process Manager.进程管理者主要按照TriggerManager启动的事件，启动一个workflowette进程，交由Process executor去执行。同时监控所有在该Manager下注册的workflowette执行状况。
3）Data manager:数据管理者负责为Process Manager启动的进程准备数据。它维护了hdfs的block与文件/文件夹的映射关系。（为channel准备输入数据，预留输出数据的位置）
4）process Optimizer：进程优化者主要驻留对于workflowette不同的优化策略。例如，对于不同workflowette读取相同文件，可以合并reading data的过程。这一点，我结合自己的工作，它能实现这一点得意于：数据通道和Data Manager维护的信息。paper中还指出：Other types of optimizations we may consider in the future include:pipelining workflowettes that form a chain," and adjusting the degree of parallelism to trade resource consumption against execution time.其中第一个是管道workflowette，另一个动态调整并行的粒度来换取较高的执行效率。其中，这里提到pipeline，我认为，Chris的这个工作，应该才刚开始，提供类似流水线的处理方式，才是支持Continuous工作流的关键。
5）Process executor进程执行者。将workflowette提交到Oozie上，跟踪执行状况，并反馈给Process Manager。
6）Trigger manager 进程激发器。它作为一个单独的线程存在，主要负责对于workflowette中提到3类的Trigger的维护，在条件满足的情况下，启动Trigger，通知Process Manager.同时Trigger还定期做Data Compaction和Garbage Collection。
评测
测试读写效率。由于使用了数据压缩技术，性能较Map-side merge 和Reduce-side merge要好。
另外的增量数据处理的性能如下：
另外，由于使用了Channel复用技术，这里叫做Scan Sharing，它的优势：
ps:我的思考
读完这篇文章，又花了半天时间写了一个中文分析之后，给了我一些启示：
1）做分布式系统是一个积累的工作，现在做技术的朋友再也不要蔑视Distributed了，它要处理的工作真得很复杂，必须沉下心，多看源码，多总结，多体会，多coding.这是一条不归路.
2)针对这个工作，我个人认为最大的意义是它梳理了我对workflow optimizer或者作业流编译器的框架。
3)在分布式处理领域，有效的往往是general的。记得在前些天看的Eurosys11上的一篇文章Scarlett，为了解决热点数据spot的问题，就是设置滑动窗口累积不同数据的热度，然后将较热的数据拷贝到不同节点上去，增加相关数据的拷贝，实现平衡负载。这些解决办法都很general，因为不general的，你解决不了分布式数据处理的大问题，比方说MapReduce Schema，你还能找到更朴素的思想吗？但是它成功了，不过我想补充一句：Overnight success takes long time.
本篇文章属于原创，其中有不合适的地方，还请大家批评指正。如果要联系本文作者，请发邮件：
jiangbinglover@sina.com
jiangbing@ict.ac.cn
如需要转载，请附上上面的邮箱地址，谢谢，我期望和更多的朋友关于MapReduce、Hadoop、分布式系统展开有价值的讨论。谢谢！
464
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
