lambda 架构
对低成本规模化的需求促使人们开始使用分布式文件系统，例如 HDFS 和基于批量数据的计算系统（MapReduce 作业）。但是这种系统很难 到低延迟。 用 Storm 开发的实时流处理技术可以帮助解决延迟性的问 题，但并不完美。其中的一个原因是，Storm 不支持 exactly-once 语义， 因此不能保证状态数据的正确性，另外它也不支持基于事件时间的处理。有以上需求的用户不得不在自己的应用程序代码中加入这些功能。
后来出现了一种混合分析的方法，它将上述两个方案结合起来，既保 证低延迟，又保障正确性。这个方法被称作 Lambda 架构，它通过批 量 MapReduce 作业提供了虽有些延迟但是结果准确的计算，同时通过 Storm 将最新数据的计算结果初步展示出来。Lambda 架构是构建大数据应用程序的一种很有效的框架，但它还不够好。举例来说，基于 MapReduce 和 HDFS 的 Lambda 系统有一个长达 数小时的时间窗口，在这个窗口内，由于实时任务失败而产生的不准 确的结果会一直存在。Lambda 架构需要在两个不同的 API（application programming interface，应用程序编程接口）中对同样的业务逻辑进行 两次编程：一次为批量计算的系统，一次为流式计算的系统。针对同 一个业务问题产生了两个代码库，各有不同的漏洞。这种系统实际上非常难维护。
微批处理
在低延迟和高吞吐的流处理系统中维持良好的容错性是非常困难的，但是 为了得到有保障的准确状态，人们想出了一种替代方法：将连续事件中的 流数据分割成一系列微小的批量作业。如果分割得足够小（即所谓的微批 处理作业），计算就几乎可以实现真正的流处理。因为存在延迟，所以不 可能做到完全实时，但是每个简单的应用程序都可以实现仅有几秒甚至几 亚秒的延迟。这就是在 Spark 批处理引擎上运行的 Apache Spark Streaming 所使用的方法。
通过间歇性的批处理作业来模拟流处理，会导致开发和运维相互交错。完成间歇性的批处理作业所需的时间和数据到达的时间紧密耦合，任 何延迟都可能导致不一致（或者说错误）的结果。
这种技术的潜在问题是， 时间由系统中生成小批量作业的那一部分全权控制。Spark Streaming 等一 些流处理框架在一定程度上弱化了这一弊端，但还是不能完全避免。另外，使用这种方法的计算有着糟糕的用户体验，尤其是那些对延迟比较敏感的 作业，而且人们需要在写业务代码时花费大量精力来提升性能。
Flink
Flink 拥有诸多重要的流式计算功能。其他项目为了实现 这些功能，都不得不付出代价。比如，Storm 实现了低延迟，但是在作者撰写本书 时还做不到高吞吐，也不能在故障发生时准确地处理计算状态；Spark Streaming 通过采用微批处理方法实现了高吞吐和容错性，但是牺牲了低延迟和实时处理能力。
流处理架构
以流为基础的架构设计让数据记录持续地从数据源流向应用程序，并 在各个应用程序间持续流动。没有一个数据库来集中存储全局状态数据， 取而代之的是共享且永不停止的流数据，它是唯一正确的数据源，记录了业务数据的历史。在流处理架构中，每个应用程序都有自己的数据，这些数据采用本地数据库或分布式文件进行存储。
如何有效地实现流处理架构呢？一个常见的做法是设置消息传输层和流处理层。
(1) 消息传输层从各种数据源（生产者）采集连续事件产生的数据，并传输给订阅了这些数据的应用程序和服务（消费者）。消息传输层负责传输连续事件产生的消息，能够提供消息传输的系统包括 Kafka 和 MapR Streams。MapR Streams 是 MapR 融合数据平台的一个主要组成部分，它兼容 Kafka API。
(2) 流处理层有 3 个用途：①持续地将数据在应用程序和系统间移动；②聚合并处理事件；③在本地维持应用程序的状态。
消息传输层的理想功能：
兼具高性能与持久性。具有持久性的好处之一是消息可以重播。这个功能使得像 Flink 这样的处理 器能对事件流中的某一部分进行重播和再计算。
将生产者与消费者解耦。在 Kafka 和 MapR Streams 这样的消息传输工具中，数据的生产者和消费者（Flink 应用程序也是其中的一种消费者）是解耦的。到达的消息既可以立刻被使用， 也可以稍后被使用。消费者从队列中订阅消息，而不是由生产者向所有消费者广播。
PS：下次总结一下时间、状态与检查点。