Hadoop应用设计的思考

 

最近的事确实很多，但大部分精力都放在了项目的设计方面，最近几天才完成了一些初步的编码的工作。在这个阶段，我发现，需要对数据的录入和Job执行的管理做细致的规划，否则在后期的扩展性上将有很大的局限。我设计的框架大体如下：



在这个结构里面，可以明显的看到我采用了2种Client，一个是数据录入层，一个是Job管理层。这里我说明一下为什么需要这2种Client。

1、数据录入主要接收数据，数据有多种形式传输，有流模式也有文件模式，为了不影响TaskTracker的性能，我采用Client单独的录入数据。

2、对于Job管理，因为Job任务有先后的顺序管理，而且对于失败的Job需要做重新的尝试，同时还要做到对Job的监控以及执行Job的增删。所以我单独采用一个Client对Job进行管理。实现Job执行的流程控制、状态反馈处理以及Job的热拔插。后面会详细说明。

到这里，可以看到，集群的应用我分成了3个部分。数据录入端、集群以及Job管理端。接下来我说下数据录入和Job管理的内容。

一、数据录入端

在这个部分主要就是对数据进行接收，然后将数据进行简单的时间区分，然后根据指定的时间和条件录入到集群中指定的目录下。例如，时间目录、数据来源目录以及地域目录等等。在这个部分实际上没有什么特别的描述，主要就是接收数据的形式方面，采用了流模式，提升传输的速度。对于一些延迟或是传输失败的数据采用文件搬运的模式。数据接收到本地之后采用Hadoop的API将数据录入到集群中。

二、Job管理端

对于这个部分，主要有以下功能点:

1、Job顺序控制。由于一个业务不可能是一个Job完成，可能需要多个Job来执行，先后存在一些依赖关系，所以通过对Job顺序的控制来完成一组业务。这个通过读取JobList的配置文件来确定先后顺序。

2、Job任务监控。同样，在这个部分主要是采用JobClient来实现。这里就不做细致的代码说明，查看Hadoop的API有详细的说明。如果确实需要代码可以发邮件给我。

3、实现Job的热拔插。由于业务分析的多变，所以需要对Job随时进行一些增删。例如一些Job可能需要新增加，而又有一些Job需要删除不执行。所以这个时候通过配置JobList清单就可以控制Job执行的顺序以及哪些Job执行哪些Job不执行。这样的操作不需要重启任何程序。

4、调度模式。每个业务可能需要多个Job,但是业务之间基本不存在依赖的关系，所以，这个时候，一个业务内的Job就需要实现FIFO模式，也就是顺序执行。但是对于业务之间，我们则需要考虑并发模式，也就是公平调度（公平调度模式需要配置，Hadoop默认是FIFO模式）。在集群支持公平调度模式的情况下，在Job管理端可以实现不同业务下Job的并发执行。

如上图：

1、所有的Business是可以并发的。但是同一个Business下的Job必须是顺序执行，因为存在依赖关系。

2、Job A、Job B、Job C是必须FIFO模式执行。而不同业务下的Job又是可以并发执行。

三、总结

1、分离出来的2种client有利于提升性能，同时具有良好的维护性。

2、Job的管理更加灵活。数据录入相对稳定。集群的计算影响减小。

3、当然，这里还没有提到如何将数据录入到RDBMS中，实际上，一个业务执行完成之后就会将结果数据录入到对应的RDBMS表中。

4、一些代码的编写基本上采用了Java，主要是考虑能更好的调用Hadoop的API。当然中间有些流程也采用了Shell脚本。

5、大体上设计内容如上，如果大家有疑问或是觉得我写的不对的地方欢迎大家发邮件交流。[e-mail]