在流处理刚被提出来的时候，很多人认为流处理只能进行做近似的结果或者增量的计算，倘若你想保证其安全性，以 Lamda 架构为基础，利用流处理得到最现在的结果。但同时你需要采用 batch processing 等其他方式来保证其全局的安全性以正确性。

在如此多年的研究结果下，在我看来，流处理并不一定是近似的，或者是仅仅以无法保证真确性为代价而提高速度的一种数据处理方式。相反，流处理应该是一个与全局计算、batch processing 稍微有点不同的计算模型。跟批量处理不同之处在于，批量处理将数据引向计算，而流处理将计算引向数据。这句话大概有点模糊，接下来，我举几个大家熟悉的计算模型例子。

第一个计算模型例子—请求应答模型。

请求应答模型是业务生活中最常用的模型例子。首先提交一个请求到服务方，而服务方可能是一个数据库、也可能是别的存储工具；然后进行等待…等待；最后得到一个回答。这便是一次请求、一次计算、一次回答。该模型非常简单、也极易操作，当你需要延展到多个机器上时，只要简单地增加客户端以及处理器即可成功。但是缺点在于，不能达到大的吞吐量，每提交一次请求，都需要等待时间来获得最终应答的结果。

第二种常见的模型就是批量处理如上图所示。如果请求应答模型在谱系的一端，那么 typo 的另一端则认为是批量处理。当我积累数据数量足够多的时候，一次性提交任务到数据仓库，再进行等待，等待时间短则几秒钟、几分钟，长则几小时，最后才得到最终的结果—所有输入对应的所有输出。该批处理模型的好处在于能够提高其吞吐率，一次的请求和应答可以得出较多结果。但它的缺点是具有高延时性，比如某数据产生时间为上午 6 点钟，用户点击某网页，由于批处理模型，每 12 小时才会运行一次，那么它必须等到上午 6 点到下午 6 点的所有数据完整以后才会进行工作，那么运行结果可能是用户点击的 12 个小时之后。高延迟性是批处理自身带有的特性。

那么什么是流处理呢? 在我看来，流处理就是介于请求应答和批处理之间的一种新型计算模型或者编程模型。流处理并不等待数据的完整性，或者说数据本没有完整性这一讲法，数据本身就是一个数据流，当每个数据流每产生一个新数据的时候立刻被计算出、进行返回，因此数据是源源不断地通向计算，并且源源不断有结果被输出。你可以设想，与等待数据完全完成之后发布到计算上相比，流处理就是将计算移到你数据发生地进行实时计算的方式。

为什么很多人之前有这样一种错觉，他们认为流处理可能存在有丢包的情况、或者说只可以得到近似的结果，其实这是早期的一些数据流处理系统所自带的一些限制。因此以 Lamda 架构为基础，在流处理上需要讨论不同维度的取舍。接下里我将举三个例子，延迟、、成本和正确性。正如很多人之前提及的，在进行流处理时候，其大多数情况需要用时间来换取正确性，或者用更多的成本换取时间等等。

第一个例子，说如果你需要做一个实时的 ETL 处理。而关于 ETL 处理不需要太小的延迟，为达到低成本的一种保证，我们可以忍受几分钟或者 1 分钟的延迟；但是，如果你正在进行一个实时的在线监测，存在着几毫秒的延迟，那么这时候可能更愿意选择花大量的金钱，或者采取一些可能不必要的 possibility 来达到一种低延迟的效果；第二个例子，假设你在做一个在线付费协议，它也是一个流处理平台。由于在线付费协议可能关乎到其机构，或者其公司的利益所在，因此你会说，我需要保证百分之百的正确性，我不希望有任何丢包情况；

第三个例子，如果你是做一个实时的日志处理，实时收集所有日志，并将其导入 root，在这种情况下，你可能会说，为了降低成本，我愿意付出一小部分正确性的代价，即使不能达到 100%、达到 99.99%、达到 99.9%，这样的结果都可以接受。这本是用户在定义不同流处理应用或者业务的时候应该可以自己做出的选择。但比较遗憾的是，多数早期的流处理平台其实并没有给予用户该种选择，他们自身的设计理念，那就是为了低延迟直接放弃掉正确性，或者说为了更高的吞吐量直接放弃低延迟。

以上是我想分享的关于流处理的一些误会认知，如果我的分享能够让大家带走两个答案的话，我希望这就是一个。我认为流处理仅仅是一种不一样的计算模型或者编程模型，它将计算带到数据上，而不是将数据引用到计算上，并且在流处理的时候，用户往往需要在正确性、延迟性、成本等不同的维度上做出选择。

为什么当我们说到流处理的时候，很多人都在说 Kafka。大多数人在最早接触 Kafka 时会说，Kafka 就是一个分布式发布订阅的消息系统，但是如果我们去观察 Kafka 的最初一些设计特性可发现以下几点内容。第一点，它可以作为一个写在磁盘上的缓存来使用，或者说，并不是仅基于内存来存储流数据，它可以保证数据包不被及时消费时，依然可用且不被丢失；第二点，由于位移的存在提供了逻辑上的顺序，在同一个话题上，第一个数据比第二个数据最先被发布的时候，也可保证在消费时也是永远第一个数据比第二个数据先被消费；第三点，因为 Kafka 是一个公有的大数据中转站，就是说，所有的数据只要在 Kafka 上，永远可以在 Kafka 周围进行业务的开发或者认知事物的开发。接下来我将花费一些时间详细介绍这三点之间的关系。

Kafka 不仅仅是一个订阅消息系统，同时也是一个大规模的流数据平台，那么它提供了什么呢？第一，提供订阅和发布消息；第二，提供一个缓存的流数据存储平台；第三，提供流数据的处理平台。今天，我将着重讨论流式计算在 Kafka 上面的应用。

流式计算在 Kafka 上的应用主要有哪些选项呢？第一个选项就是 DIY，Kafka 提供了两个客户端 —— 一个简单的发布者和一个简单的消费者，我们可以使用这两个客户端进行简单的流处理操作。举个简单的例子，利用消息消费者来实时消费数据，每当得到新的消费数据时，可做一些计算的结果，再通过数据发布者发布到 Kafka 上，或者将它存储到第三方存储系统中。DIY 的流处理需要成本。打个比方，考虑数据的延迟性，考虑不同时间上的管理分配，正如很多人提到的 processing time，这将是我后文会重点提及的概念。以上这些都说明，利用 DIY 做流处理任务、或者做流处理业务的应用都不是非常简单的一件事情。

第二个选项是进行开源、闭源的流处理平台。比如，spark。关于流处理平台的一个公有认知的表示是，如果你想进行流处理操作，首先拿出一个集群，且该集群包含所有必需内容，比如，如果你要用 spark，那么必须用 spark 的 runtime。因为他们划定了你作为一个流处理平台使用者需要用到的所有行为，比如，资源管理系统、参数调配系统、容器配置、代码封装、分发等，以上行为都已被该平台所限定。一旦你选择使用甲就必须用甲套餐装备，如果选择使用乙就必须使用乙套餐装备。有人不禁提出疑问，我能不能既选择流处理平台，又使用自己选择的，我能不能这样做呢？

这个应用场景其实很普遍，举个例子，可异步式微服务处理。什么叫异步式微服务处理？假设 Kafka 作为一个缓存数据，在该缓存区含有很多不同的业务。打个比方，一个网店的机构可以有不同的组、不同的员工，有人负责销售、有人负责商品分发，有人负责价格管理、有人负责在线实时的限流监控，不同的组、不同的员工可能会以不同的时间，或者以不同的代码来更新他们的产品，只要拥有一个异步式缓存机制，即 Kafka，便可扩大该微服务，而不需要他们的任何一个组之间进行同步请求应答机制。

在该微服务情况下，每个小组的喜好、特性并不一致，有的组表示我需要做流处理平台，从 Kafka 读数据，处理完再写回 Kafka，并且想要使用 EWS 把我的应用部署在云端大规模集群上；而另外小组表示我不需要那么复杂，我只是小规模数据，不希望起一个集群，只需起三个机器，并且每个机器有 1GB 内存足以，可进行手动控制操作，不需要资源管理器。那么我们能不能同时满足他们不同的需求呢? 答案就是我接下来要说的第三种选项。

第三种选项是使用一个轻量级流处理的库，而不需要使用一个广泛、复杂的框架或者平台来满足他们不同的需求。在 Kafka 0.10 当中已发布轻量级流处理内容平台，我们可以设想，跟其他客户端发布者和消费者一样，它也是一个客户端，不同之处在于它是一个计算者客户端，一个好用的、功能强大的客户端，并且支持 state processing、Windows 延时的、异步的、甚至不同数据的调控。 最重要的是 Kafka 作为一个库，可以采用多种方法来发布流处理平台的使用。比如，你可以构建一个集群；你可以把它作为一个手提电脑来使用；甚至还可以在黑莓上运行 Kafka。以上都是尤其简单的运行库的概念。

因此我们要做的事情与使用 Kafka 其他的客户端类似，比如发布者、消费者，只要在代码里边加入就可以使用各种各样的 API。当你要调配控制 Kafka Stream 应用的时候，选择最基础的 War File 来运行或者采用 Java、C，甚至资源管理器来运行都是可行的。因为 Kafka Stream 是一个轻量级流处理的库，可支持各种各样的运维方式。

在我们看来，简单的就是美的，只有给用户提供最大的兼容性与最大的延展性，用户才能得到最好的用户体验。

如果接触过 Storm、Spark 等流处理平台的同学可以发现，它们与 Kafka Stream 高阶位 DSL 语言其实有相似之处。如上图所示，首先定义一个 Streams 流， Streams 是从 topic1 中的 topic 获取得到，即定义 Streams、处理 Streams、得到新的 Streams。比如，从 topic1 里面得到两个原始数据流，然后数据流进行 countByKey 得到新的数据流叫做 Counts。那么 counts.to(“topic2”) 是什么意思呢？在获取到新的数据流之后写回 Kafka topic2 内，启动 KafkaStreams 进程，与 Kafka producer、Kafka consumer 类似，让它来运行已定义计算。

正如大家所了解的，API 的使用其实很简单。提供一个简单的 API，用户简单地写入运行逻辑即可运行。但是编程应用总是容易的，而它的复杂程度在于，一旦你开始运维该应用，当你想要把业务拓展到更大规模，或者业务出现变化，或者集群不稳定，需要强大的运维时，运维的程度便显得异常重要，最上面的编程可能只是冰山一角。Kafka Stream 的设计理念是最简单的就是最美的，包括 API、运维、debugging，以及各种各样的方式，都是希望给用户带来最简单的体验。它的核心思想就是把难问题直接给 Kafka 集群本身。