流处理时代（stream processing age)-part 2

流处理时代（stream processing age)-part 2

上接第一部分（part 1）

例子：

以Twitter为例，最常见的写入Twitter数据库的方式是提供一个输入，就是发表一个tweet.一个tweet很简单：它包括一些文字、一个时间戳和一个发表tweet的用户ID.（或者还包括位置、照片或者其他的东西）用户点击发表，这将导致数据库的写入，例如一个event的产生。在输出端，你读取Twitter数据库的方式是查看你的时间轴，这将显示你关注好友写的所有类容。

对于每个tweet，你现在不知有文本，时间戳和userID，还有用户名，简介照片、和其他信息。同时，tweet列表根据你关注的人会不断变化的。

也就是，查找所有$user关注的用户，找到所有这些用户发表的所有tweet，并且按时间排序，并且去最近的100条。在Twitter以前的实现中采用类似的这种方式，导致在用户使用过程中出现问题。当一个用户在查看他的时间轴时，迭代该用户关注的所有用户来获取所有tweet的方式是非常低效。相反，Twitter必须提前计算一个用户的时间轴，然后cache这个时间轴，因此当用户查询时会更快。他们需要一个过程来转换一个写优化的event为读优化的聚合。Twitter有这样一个过程，称之为fanout service.

    从Twitter的例子中，我们能够得到一个模式：输入event，同UI上的按钮一致，非常简单。他们是不变的事实。我们能够简单地存储他们，我能将其认为是真相之源。 你从数据库读出的所有信息，都能够从原event中派生出来。有这么一个过程，该过程从原event中派生出聚合信息，并且当有新的event来到时更新缓存。同时，这个过程是确定的，也就是说如果必要，你可以提供全部的历史信息，该过程派生出的信息同之前的相同。

    现在回到streamprocessing。我们开始描素了怎么样构建一个像Google Analytics的东西，并且比较了存储原始page viewevent和聚合的计数器，并且讨论了你能够通过消费一个event 流来保持这么一个聚合计数器。

后来我们解释了event sourcing，它使用一种相似的方法到数据库中：将数据库的所有写看做是一个event流，并且从该流中构建聚合（view、cache、searchindex）.一旦你有了一个event流，你可以做很多事情。

1.你可以使用所有的原始event，或者将其适当转换，加载到一个大数据仓库中，然和在其中进行分析

2.你可以更新一个全文搜索索引，当他们命中该搜索盒子（searchbox）,他们将得到一个最新的数据版本

3.你可以使一个cache失效或者重新填充一个cache.

4.最后，你可以获取一个event流，以某种方式处理该流（或许融合一些流到一起）生成一个新的输出流。这样，你就可以将一个系统的输出作为另一个系统的输入。

使用append-only流和不变状态event的好处：

松耦合：如果你按照你将要读出数据的schema来写数据的话，你就将应用的数据写入部分（button）和数据读取部分（screen）紧耦合在一起了。我们知道松耦合是一个好的设计原则。通过分开写与读的形式，并且通过显示地转换一个到另一个，你将在你的应用中得到更加松散的耦合部分。

读写性能：过去的范式化（更快的写）和逆范式化之争只存在于读写schema相同的情况下，如果你将其分开，那么可以获得快速的读写性能。

扩展性：由于event流应许你将你的应用程序分解为生产者以及消费者（他们能够独立的运行，能够更好地利用并行硬件）

最后如何将这些idea应用到实践呢。应用层使用eventstream。

一些数据库，例如Event Store 已经面向eventsourcing model提供了解决方案，同时也有一些人在关系型数据库上实现了Event sourcing。这些解决方案在小规模数据上是可用的。

在大规模数据集上使用event流的idea:

接下：kafka原理及实践

samza/storm/spark streaming 比较