分布式流数据处理漫谈

一般，后台的编程模式有三种，服务开发，流处理，批处理。当然，这三者模式可以有相互借鉴，边界也不是分的很清晰。服务开发也有WebFlux的技术，批处理和流处理也没有清楚的界限。不过提到流处理，大家一般都能说出一些主流技术Storm／SparkStream／KafaStream／Flink…
在分布式流式处理中，我们关注的是哪些方面呢？

• 容错，是否支持ExcatlyOnce，事务等等。
• 吞吐量
• 延时
  当然也有一些锦上添花的功能，但是这些不是本文讨论的重点。如动态更改事件订阅，事件格式管理，安全，追踪，监控，测试，等等等等

容错

这个是刚性的功能需求。一个程序运行的再快，如果不能给出正确结果就毫无意义。
Storm采用ACKer跟踪算法来追踪每一个tuple的处理。如果出错就进行重发。这个很容易就保证了At Least Once。配上幂等性的下游系统，可以适用于大部分场景。

架构和部署

部署一般都提供standalone和yarn模式。我们直到，一般大数据批处理的执行是如下的

yarn在及其上创建一个container，然后让container去执行MapTask,ReduceTask等各种任务，或者AppMaster。Appmaster执行完毕后回归还资源一切都会被销毁。但是流式数据处理则有显著不同，表现为App需要长期运行，不能死掉。

下面是一个经典MapReduce的多进程模型。每个Task运行在独立的JVM中。

Spark

和MapReduce不同，Spark是一个如下的多线程模型

Spark在standalone下，有一个中心节点的一个master进程和每台机器上的一个worker进程。集群中woker在接收任务后会创建driver（applcation master）进程(或者在启动clinet的机器上创建)。然后创建若干executor进程，application之间不共享executor。

每个Worker，又会暴露出一个地址来展示该worker的状态。Driver进程也会暴露一个地址来展示这个工作的状态。
在Yarn模式下，master被YARN的RM所替代，woker进程被YARN的NM所替代。NM根据RM的分配启动AM和executor。

Storm

Storm同样有和Spark类似的Master进程和Worker进程和executor进程，只不过分别改名字为nimbus，supervisor，worker。

Flink

Flink的standalone模式是在集群的主节点启动JobManager（相当与spark的master），则集群的其他节点启动TaskManager（相当于Storm的worker）。区别在于每个task都是一个线程执行的，所以需要用到类加载器来进行隔离。不同的工作之间会共享TaskManager。

提交任务有Standalone-client模式和Standalone-cluster模式。区别就在于Driver是在提交作业的进程中启动还是在集群中寻找资源单独启动。生产环境中一般使用后者，不然如果一直用一台机器提交作业,那么所有APP的流量都会压倒这一台机器上。而后者则可以散布在集群中。

生产中使用yarn模式来部署。此时，每提交一个任务都会新建一个flink集群。

KafkaStream

kafkaStream走的就是纯嵌入式架构。最另类的。严格来说，这不能是一种成体系的分布式流处理解决方案。

为什么不需要其他进程支撑的？？因为支撑的就是kafka的进程啊～

架构总结

除了KafkaStream之外，流处理体系，无论如何都需要一个中心协调节点（如Storm的nimbus）。无论如何，每个机器上都需要一个agent进程（如Storm supervisor）。接下来才是区别所在。对于经典的MapReduce，每个task是一个进程。对于Spark和Storm，每个应用有若干个执行进程（executor／worker），每个进程离执行若干个task。对于Flink，每个允许应用共享TaskManager。另外，spark和Flink有app master（Spark的driver，Flink的jobmanager。其实Storm topo也有）的概念，这个app master可以在集群中启动，也可以在客户端上启动。

端到端的ExcatlyOnce

对于任何流处理系统而言，所能保证的ExcatlyOnce，只是端到端的处理而已。因为不能保证外部系统支持回滚。

事务性消息