流处理技术的演化
在离线数据批处理场景中，持续的数据生产与数据消耗是分离的，这使得开发系统的工作变得更简单，但也将管理这种分离的复杂性的重担转移到了系统的使用者身上：如应用开发者，运维团队需要使用与管理这些基础设施。
为了管理这种分离，一些使用者尝试着开发他们自己的流处理系统。在开源领域，流处理器的先驱者是Apache Storm 项目，该项目在进入Apache软件基金会之前，由Nathan Marz与一支来自初创公司BackType的团队共同创立（BackType公司后来被Twitter收购）.Storm为流处理器能够达到低延迟带来了可能，但是这种实时处理包含着一种权衡：低延迟下高吞吐很难实现，同时Strom也没有提供控制这种权衡的方法，以匹配不同系统对结果准确性的不同要求。换句话说，它没有做到在维持精确状态的基础上提供恰好一次的保证，即便是Strom所能提供的保证也是在很高的开销下才能够达到的。
Lambda结构概览：优势与限制
为了负担的起大规模的数据，人们开始使用分布式文件系统如HDFS以及批处理计算（MapReduce jobs）。但是这种方法很难达到低延迟。Strom的实时流处理技术的发展解决了这个问题，但是这并不是一个完整的解决方案。就拿一件事情来说：Strom没有提供仅处理一次的状态一致性的保证，并且也不能处理event-time模式。有这些需要的开发者，不得不在他们的应用代码中自己实现这些特性。
一种数据分析中的混合观点融合了方法，提供了一站式解决方案来解决以上挑战。这种混合观点便是：Lambda结构，MapReduce jobs使用该结构提供了延迟的但是准确的结果，Storm使用该结构，它的处理可以提供实时的初步结果。
Lambda结构对于构建大数据应用来时是一个很有用的框架，但这还不够。例如：基于MapReduce与HDFS的一个Lambda系统，有一个小时级别的时间窗口，当遇到故障时，便很显然的发现结果会不准确。Lambda结构也使得相同的业务逻辑在两种不同的编程API中被编写两次：一次为使用批处理的API，一次为使用流处理的API。这导致解决同一业务问题的代码会产生不同的bug。在实践中，这非常难以维护。
为了计算多个流中事件的值，必须要保留事件的数据。这个数据便被称作计算的状态。正确的处理状态在需要保持一致的计算中是必要的。故障或中断发生时，正确更新状态的能力是故障容忍的关键。
维护一个高吞吐，低延迟且具有故障容忍的流处理是一件很困难的事情。但是对保证状态准确性的需要促成了一种巧妙的妥协：如果将一个持续的事件数据流拆分成一系列小的原子化的批处理会怎样？如果这些批处理被切分的非常小 - 称作“微分批处理” - 你的计算就会近似于真实的流计算。延迟可能达不到实时，但是几秒甚至压秒级别的延迟对于简单的应用来说是可以达到的。这就是Apache Spark Streaming 采取的方法，Apche Spark Streaming 运行在 Spark 的批处理引擎上。
更重要的是，有了“微分批处理”，你便可以达到仅处理一次的保证以及状态的一致性。如果某个微分批处理失败了，它也可以重新运行。这比真实地持续进行流处理计算的方法简单多了。一个被称作Storm Trident的Strom扩展，也是采用了“微分批处理”思想，在流处理器上进行计算，提供了仅处理一次的保证，但是为低延迟付出了很大的代价。
然而，通过周期性的批任务来模拟流处理导致程序很脆弱，将DevOps与应用程序开发问题结合在一起。周期性批任务的结束时间与数据的到达时间紧密耦合，任何延迟都会造成不准确（或者说错误）的结果。这种方法的潜在问题在于：对于时间的管理，是由系统中负责创造小任务的部分模块隐式的进行管理。一些框架如Spark Streaming缓和了程序的脆弱性，但是并没有完全解决，相对于批处理而言，这种“微分批处理”的方法对时间的敏感性仍会导致延迟和用户体验的问题：开发者需要在开发应用时，考虑很多代码的性能问题。
在各种想要实现的能力中的权衡，激发了人们对现存处理器进行提升的各种尝试（如，Storm Trident的发展便是为了尝试克服一些Strom中的局限性）。当现有的处理器无法完成时，这个重担就转移到应用的开发者，由开发者来解决所遇到的问题。一个例子便是在使用“微分批处理”框架的场景中，这些框架没有在以会话session来处理数据的场景与以特定时间（恢复时间）来处理数据的场景之间做很好的匹配。灵活性和表现力较差，开发时间漫长且运维人员需要更多的努力来正确的维护应用。
这就把我们带到Apache Flink，这个数据处理器没有那些功能间的权衡，并且整合了许多特色，这些特色能够高效的处理持续事件数据。下图展示了Flink整合的能力。
Apache Flink的一个优势便是把其他项目中需要做权衡的各个能力直接进行整合而无需权衡。相比之下，Apache Storm提供了低延迟，但是目前并没有提供高吞吐，并且不能保证故障发生时能够正确的处理状态。使用“微分批处理”方法的Apache Spark Streaming 实现了高吞吐与故障容忍，但是实现低延迟/实时处理需要非常大的代价，并且无法按照会话session处理数据，同时在API使用的表现力上也有不足
就像Strom以及Spark Streaming一样，其他在流处理领域的新技术提供了一些有用的能力，但是很难找到一个像Flink这样整合了各种特点的框架。如：Apache Samza，是流数据处理领域另一个早期的开源项目，他同样仅仅能保证 at-least-once 至少一次的处理，以及一个 low-level API。同样的，Apache Apex提供了一些Flink的优点，但是并不是全部（例如，他受限于low-level API，并且不支持event-time模式，也不支持批处理计算）。并且没有一个项目的社区能如Flink社区般如此吸引开源社区的注意。
现在，让我们看一看Flink是什么以及这个项目的情况。
网友评论