Kafka基础-流处理

1. 什么是流处理？

首先，让我们说一下什么是数据流（也称为事件流）？它是无边界数据集的抽象说法，无边界意味着无限且不断增长，因为随着时间的推移，新数据会不断地到来。

除了无边界的特性之外，事件流模型还有其它几个属性：

1.1 事件流是有序的

这在交易事件里是最容易理解的，先在账户里存钱然后消费与先消费再还钱是非常不同的，后者将产生透支费用，而前者不能透支。这是事件流和数据库表之间的不同点之一：表中的记录始终被视为无序的（SQL的“order by”子句不是关系模型的一部分）。

1.2 事件流的数据是不可变的

事件一旦发生，就永远无法修改。例如取消一个交易事务，这个记录本身是不会被删除的，相反，会向流写入一个附加事件，记录之前事务的取消。这是事件流和数据库表之间的另一个不同点：我们可以删除或更新表中的数据。

1.3 事件流是可重放的

对于大多数业务应用程序来说，能够重放几个月前（甚至几年前）发生的原始事件流是至关重要的，这是为了分析修正错误或执行审计所必须的。

2. 流处理的相关概念

流处理和任何类型的数据处理非常相似，都是接收数据，对数据执行某些操作，例如转换、聚合等，然后把结果保存在某处。但是，有一些关键概念是流处理所特有的：

2.1 时间

时间可能是流处理中最重要的概念，因为大多数流式应用程序都在一定的时间内执行操作。例如，计算连续5分钟的股票价格平均值。流处理系统通常参考以下时间概念：

2.1.1 消息创建时间

这是事件被创建的时间。例如，进行测量的时间、出售商品的时间、用户在网站浏览页面的时间等等。在0.10.0及更高版本中，Kafka会在生产者创建消息时自动添加当前的时间。

2.1.2 消息保存时间

这是事件被保存在Kafka broker的时间。在0.10.0及更高版本中，Kafka broker可以配置自动为接收到的消息添加当前的时间。

2.1.3 消息被处理时间

这是流处理应用程序接收事件的时间，这时间可以是事件发生的几毫秒、几小时或者几天之后。

2.2 状态

通常我们是把状态保存在流处理应用程序本地的变量中，例如一个用于保存移动计数的简单哈希表。然而，在流处理应用程序中，这不是一个管理状态的可靠方法，因为当流处理应用程序停止时，状态将丢失。流处理有以下2种类型的状态：

2.2.1 本地或内部状态

只能由流处理应用程序的特定实例访问的状态，该状态通常是使用应用程序内运行的内存数据库来维护和管理。使用本地状态的优点是性能非常快，缺点是受限于可用的内存大小。因此，流处理的许多设计模式都是把数据分到多个子流来处理。

2.2.2 外部状态

使用外部数据存储维护的状态，例如是类似Cassandra的NoSQL数据库。使用外部状态的优点是几乎没有大小的限制，并且可以从应用程序的多个实例或甚至从不同的应用程序访问它；缺点是由于引入了外部组件导致额外的延时和复杂性。

2.3 流-表二元性(Stream-Table Duality)

数据流包含从一开始到现在的完整历史，它表示了过去和当前。它是一系列的事件，其中每个事件都会引起一个变化。而表包含的是某一时刻的状态，是许多变化的结果。从某种意义上可以说流和表是一个硬币的两面，世界总是在变化，有时我们会对引起这些变化的事件感兴趣，而有时我们却对当前的状态感兴趣。我们将这两者之间来回转换的内在关系称为“流-表二元性”。

2.4 时间窗口

大多数流的操作都是在一定的时间内执行 - 移动的平均值、本周最畅销商品等等。例如，当计算移动平均值时，我们需要知道：

• 时间窗口的大小：我们需要计算每5分钟的平均值？还是每15分钟？还是每天？越大的时间窗口数据变化反应会越滞后，例如价格上涨需要更长时间才能注意到。
• 时间窗口移动的频率（间隔）：五分钟的平均值可以每分钟，每秒，或每次有新事件时更新。当间隔等于时间窗口的大小时被称为翻滚窗口（tumbling window）；当时间窗口在每条记录上移动时被称为滑动窗口（sliding window）。
• 时间窗口保持可更新的时间：例如我们五分钟移动平均值是计算00:00-00:05时间窗口的平均值。现在一小时后，我们得到了更多的事件，但它们的事件时间显示为00:02。我们是否应该更新00:00-00:05期间的平均值？还是忽略它们？理想情况下，我们需要定义一个特定的时间段，在此期间接收到的事件将被添加到各自的时间窗口中。

时间窗口可以和时钟对齐，例如每分钟移动的一个5分钟窗口，第一个时间段是00:00-00:05，第二个是00:01-00:06。或者可以简单地从应用程序启动时开始计时，例如03:17-03:22。滑动窗口是永远不会和时钟对齐，因为只要有新记录就会移动。有关这两种时间窗口之间的区别，请参见下图：

3. 流处理设计模式

3.1 单事件处理

流处理的最基本模式是单独处理每个事件，这也称为map/filter模式，因为它通常用于从流中过滤不必要的事件或转换每个事件。术语“map”是基于map/reduce模式而来，在map阶段转换事件，reduce阶段执行聚合。在此模式中，流处理应用程序从流中消费事件、修改每个事件，然后将事件写入到另一个流中。例如，一个应用程序从流中读取日志消息并将ERROR事件写入一个高优先级的流中，其余事件写入到一个低优先级的流中。另一个例子是把读取到的事件格式由JSON转换为Avro。这种模式可以通过一个简单的生产者和一个消费者处理，如下图：

3.2 利用本地状态处理

大多数流处理应用程序都用于聚合操作，特别是时间窗口的聚合。例如，查找出每天股票交易的最低和最高价格并计算其移动的平均值。此类聚合操作需要维护流的状态，例如需要保存当前时刻最低和最高的价格并和流中的每个新价格比较，然后更新它