Hadoop(2.x)云计算生态系统

MUPD8

开发者通常想看到是否有其他类似的系统可以做一个对比。我们会竭尽所能,拿其他系统的特征与samza的相关特性做一个对比。但我们不是这些系统的专家。我们的理解有可能完全失之偏颇。如果的确有的话,请让我们知道,我们会改正的。

持久性

MUPD8 没有实现持久性与消息传输的完整性(可能会有消息丢失)。在MUPD8内,流处理器接收消息的任务最多一次。samza使用kafka的消息系统,保证消息的持久化与消息传输的完整性。

顺序性

相对于持久性而言,开发者观念上更重视消息的处理是否能够按照他们写入时候的顺序进行处理。

我们并没有完整查看MUPD8对于顺序性的保障机制,看起来像是所有的消息进入队列后,按照入队的先后顺序处理消息,这点跟kafka的机制有些类似的。

消息的缓存

当我们设计一个流处理系统的时候,面临的一个关键问题就是,当我们的下游处理系统变慢的时候,我们的流处理系统将会承受越来越大的压力。

mupd8在两任务之间传递消息的时候,会缓冲消息在本地的内存队列中。当队列满时,开发者可以选择丢掉消息或者记录到本地磁盘上面。所有这些选择都不是最理想的。丢失消息将导致不正确的结果。记录到本地磁盘上面看似是最合理的选择,但当故障发生时,这些消息会由于没有副本机制,将导致无法实现故障故障转移,从而丢失消息。

samza是数据源采用kafka的作为远端缓冲,解决上面所有这些问题。kafka从架构上面解决了消息的副本与本地消息高效存储。[笔者add:samza的流处理系统是基于消息队列的分布式流处理系统]

数据状态管理

就如前面的介绍说的那样,流处理程序需要考虑在处理过程中保存数据处理的状态信息。不同的软件架构有不同的保存状态的方式和出现异常后的不同处理模式。 mupd8将状态维护到内存里面,并周期性的同步到Cassandra数据库中。

samza维护task的状态是在本地。这样能够维护的数据可以比内存更大。状态数据被持久化到了输出数据流中,这样当task失败的时候可以恢复。我们通过日志的变化来捕获状态的变化,从而能够将状态恢复到失败之前的时间点的一致性状态中,我们相信这样的设计将能够较好的支持服务的容错性。

部署与执行

MUPD8是有自己的执行框架,对以此框架的特点与特性我们并不清楚。

Samza 利用 YARN 来部署我们的代码,并在一个分布式的环境中执行相关代码。

容错机制

当我们的服务器down机之后,我们的流处理系统该做一些什么呢? MUPD8使用类似Yarn的容管理错机制。当流处理器不能给下游流处理器发送消息的时候,它将通知MUPD8的控制器并且其他所有流处理器将会获得到通知,根据key的散列值与一台新的服务器建立通信,此时此message与对应的状态信息将会丢失。

Samza使用YARN管理容错。当node或者samza的task节点失败的时候,yorn会发现并通知Samza ApplicationMaster. 因此,具体如何来做就有samza来决定。通常来说,会在其他机器上面重启samza的task任务,因为消息数据是存储在远端的kafka服务器上面而不是本地的内存中,一次不用考虑数据的流失问题(除非是samza使用的是kafka的异步提交模式,为了提高发送的性能,但不得不承担数据丢失的风险)。

工作流

有时候为了完成一件事情,可能涉及的job不止一个.我们可能需要考虑将数据流进行重分区从而分成多个job进行并行执行,最后将执行的结果汇总到统一的一个job中进行汇总处理。

MUPD8 可以在流处理系统沙面设置来定义如何同时执行多个任务,以及如何从一个数据流到另一个数据流。

Samza是按照单个作业执行的粒度级别进行设计。通过再job中命名输入和输出流的名字进行数据交互。这隐含定义了所有正在运行的作业之间的数据流之间的关系。我们选择这个模式,可以使数据流图在不同团队的工程师在以及不同的代码库的基础上进行合作,无需任何将任何资源与技术统一到一个大的框架下面。

内存模式

MUPD8执行它的所有map/reduce的处理器统一在一个单一JVM内,使用线程机制。内存级别的数据共享效率比较高。

Samza使用为每个数据流处理器容器单独的JVM。与在单个JVM上运行多个数据流处理线程相比,将使用更多的内存,这个是缺点。然而,其优点是任务可以使更可靠的进行隔离,不同的任务之间不会受到影响。

资源隔离

MUPD8提供流处理器没有提供资源隔离的功能。流处理器可以使用节点上所有资源。

Samza使用Yarn进行资源隔离处理。每个进程的内存我们可以执行严格的限制。此外,Samza也支持CPU限制。Yarn未来将的进一步发展,也应该成为可能支持磁盘和网络进行相关限制。