主流流处理框架比较.docx

分布式流处理是对无边界数据集进行连续不断的处理、聚合和分析。它跟MapReduce一样是一种通用计算，但我们期望延迟在毫秒或者秒级别。这类系统一般采用有向无环图（DAG）。DAG是任务链的图形化表示，我们用它来描述流处理作业的拓扑。如下图，数据从sources流经处理任务链到sinks。单机可以运行DAG，但本篇文章主要聚焦在多台机器上运行DAG的情况。关注点当选择不同的流处理系统时，有以下几点需要注意的：运行时和编程模型：平台框架提供的编程模型决定了许多特色功能，编程模型要足够处理各种应用场景。这是一个相当重要的点，后续会继续。函数式原语：流处理平台应该能提供丰富的功能函数，比如，map或者filter这类易扩展、处理单条信息的函数；处理多条信息的函数aggregation；跨数据流、不易扩展的操作join。状态管理：大部分应用都需要保持状态处理的逻辑。流处理平台应该提供存储、访问和更新状态信息。消息传输保障：消息传输保障一般有三种：at most once，at least once和exactly once。At most once的消息传输机制是每条消息传输零次或者一次，即消息可能会丢失；A t least once意味着每条消息会进行多次传输尝试，至少一次成功，即消息传输可能重复但不会丢失；Exactly once的消息传输机制是每条消息有且只有一次，即消息传输既不会丢失也不会重复。容错：流处理框架中的失败会发生在各个层次，比如，网络部分，磁盘崩溃或者节点宕机等。流处理框架应该具备从所有这种失败中恢复，并从上一个成功的状态（无脏数据）重新消费。性能：延迟时间（Latency），吞吐量（Throughput）和扩展性（Scalability）是流处理应用中极其重要的指标。平台的成熟度和接受度：成熟的流处理框架可以提供潜在的支持，可用的库，甚至开发问答帮助。选择正确的平台会在这方面提供很大的帮助。运行时和编程模型运行时和编程模型是一个系统最重要的特质，因为它们定义了表达方式、可能的操作和将来的局限性。因此，运行时和编程模型决定了系统的能力和适用场景。实现流处理系统有两种完全不同的方式：一种是称作原生流处理，意味着所有输入的记录一旦到达即会一个接着一个进行处理。第二种称为微批处理。把输入的数据按照某种预先定义的时间间隔（典型的是几秒钟）分成短小的批量数据，流经流处理系统。两种方法都有其先天的优势和不足。首先以原生流处理开始，原生流处理的优势在于它的表达方式。数据一旦到达立即处理，这些系统的延迟性远比其它微批处理要好。除了延迟性外，原生流处理的状态操作也容易实现，后续将详细讲解。一般原生流处理系统为了达到低延迟和容错性会花费比较大的成本，因为它需要考虑每条记录。原生流处理的负载均衡也是个问题。比如，我们处理的数据按key分区，如果分区的某个key是资源密集型，那这个分区很容易成为作业的瓶颈。接下来看下微批处理。将流式计算分解成一系列短小的批处理作业，也不可避免的减弱系统的表达力。像状态管理或者join等操作的实现会变的困难，因为微批处理系统必须操作整个批量数据。并且，batch interval会连接两个不易连接的事情：基础属性和业务逻辑。相反地，微批处理系统的容错性和负载均衡实现起来非常简单，因为微批处理系统仅发送每批数据到一个worker节点上，如果一些数据出错那就使用其它副本。微批处理系统很容易建立在原生流处理系统之上。编程模型一般分为组合式和声明式。组合式编程提供基本的构建模块，它们必须紧密结合来创建拓扑。新的组件经常以接口的方式完成。相对应地，声明式API操作是定义的高阶函数。它允许我们用抽象类型和方法来写函数代码，并且系统创建拓扑和优化拓扑。声明式API经常也提供更多高级的操作（比如，窗口函数或者状态管理）。后面很快会给出样例代码。主流流处理系统有一系列各种实现的流处理框架，不能一一列举，这里仅选出主流的流处理解决方案，并且支持Scala API。因此，我们将详细介绍Apache Storm，Trident，Spark Streaming，Samza和Apache Flink。前面选择讲述的虽然都是流处理系统，但它们实现的方法包含了各种不同的挑战。这里暂时不讲商业的系统，比如Google MillWheel或者Amazon Kinesis，也不会涉及很少使用的Intel GearPump或者Apache Apex。Apache Storm最开始是由Nathan Marz和他的团队于2010年在数据分析公司BackType开发的，后来BackType公司被Twitter收购，接着Twitter开源Storm并在2014年成为Apache顶级项目。毋庸置疑，Storm成为大规模流数据处理的先锋，并逐渐成为工业标准。S