《Designing Data-Intensive Applications》的核心部分都已经翻译完成了。此书是分布式系统架构必读书，出版于2017年，中文版目前还没有面世。我找了其中比较吸引我的那几章，阅读的同时，顺手翻译并记录了下来。这边是其中一章。当然公众号前面也有几篇翻译加整理的文章，比如流量那几篇。

流式处理的一些常用方法：

Complex Event Processing ( CEP) : 更复杂的一些（流式）事件处理

书中提到了这个概念，应用之一是，在流式并发事件中寻求一定 pattern 的一批事件，比如事件相似性的模式。比如同时在成千上万个浏览同一个购物网站的用户中，寻找正在浏览同一个物品的那批顾客。

CEP 处理的方式与数据库式的存储/查询方式不同。数据库将数据持久化起来，而将查询作为一次性应用，即查询执行完之后就丢弃了。CEP 的处理本质是，将查询做持久化存储，而符合查询的事件(Event)才被保留下来。

符合 CEP 机理的产品，有这些：

1. Esper

2. IBM InfoSphere Streams

3. Apama

4. TIBCO StreamBase

5. SQLstream

6. Linkedin Samza

Stream Analytics

对流事件做统计分析，与 CEP 通常有些混淆与模糊的地方

5分钟访问一次微博的客户，这种是 CEP 方法的最终结果；

5 分钟共有 1000W 用户访问了微博，这种是 Stream Analytics 的计算目标。

符合 Stream Analytics 的开源产品：

1 Apache Storm

2. Spark Streaming

3. Flink

4. Concord

5. Samza

6. Kafka Stream

Database Materialized View:

数据库的物化视图，更新也不是及时的。即，物化视图的底层引用表被更新了，物化视图保存的数据是不会更新的，所以需要一次与最新数据的同步，通常放到一个维护窗口期来做。

一个复杂的应用，通常包含了 OLTP 业务性数据库，还有可能有索引数据库（Index Database, 比如 Solr, ElasticSearch 来提供全文检索功能）， 分析数据库（Analytic Database, 比如 TeraData 等数据仓库），缓存数据库（Cache Database, 比如 Redis, 加速前端应用读取数据）等。所以当一笔数据流入 OLTP 业务数据库的时候，这些依靠 OLTP 的下有数据库需要进行一次数据同步，相当于是物化视图的更新。

物化视图的维护，除了各大厂商提供自己的驱动程序外，还可以利用 Samza 和 Kafka 来实现。

Search On Streams

除了 CEP， 我们可能还需要更复杂的查询匹配 stream event 的算法，比如 elasticSearch. 都是在流里面直接找到符合某种条件的 events.

Stream Processor

message-passing & RPC 虽说都是有消息传递的机制，但是严格意义上他们不属于 stream processor, 只能是 actor model. Actor Framework 虽说也能处理 stream, 但是并不能保证在远程节点故障脱机的情况下，将消息安全的送到，即在故障脱机的节点重新恢复后，继续投递原本投递失败的消息。能称得上 stream processor 的有 Apache Storm.

目前涉及到的处理架构有：

1. Message passing, 包含了 message broker 的机制

2. RPC: Remote Procedure Call， 即远程调用程序接口

3. Stream Processing: 流式处理，侧重方向是数据处理，数据模型应用以及数据内部规律的发掘，而前面 2 个架构侧重于数据管理和数据并发。

message passing 和 RPC 的架构采用了 Actor Framework. 这与 Stream Processing 的不同就像伙食采购与烹饪工艺的不同。一个解决有无问题，一个解决口味问题。而 Apache Storm 的厉害之处在于，对于采购和烹饪处理，他家全包了，即 Storm 可以处理消息分发的流程，还可以对消息进行解析。

Reasoning About Time 基于时间维度的分析

对于时间窗口的处理，batch processing 与 stream processing 有些许不同。batch processing 一般都会基于 event timestamp 来抓取符合特定时间窗口的 event ，在 batch 处理的时候，这些 event 已经全部发生，所以不会有漏处理的 event. 而 stream processing 在处理的时候，可能 event 发生的时间与处理时间有较长的时间间隔，导致漏处理。stream processing 利用的是本机时间，当本机时间 与 event 发生时间之间存在间隔很长，这些 event 就有可能被漏掉。取决于 stream processing 的取时间方法，event 处理的结果也就不同了。

Event Time versus processing Time

为什么event 发生时间与stream processing 的节点之间，会有那么很长的时间间隔呢？

可能的原因有很多，网络延迟，机器处理速度与传输量增量速度不匹配而导致的处理延迟，网络故障，甚至是event 的发送不及时等。

举个简单的stream processing的例子：如果我们要统计过去每 5秒钟的请求数量，假设系统都运行的很顺畅，那么正常的数量统计显示，一切都是很稳定的，没有特别的量的增长和掉减。一旦 stream proceesor 的节点故障脱机，等到工程师维修完，重新上线的时候，我们再来看5秒流量统计，会发现过去的一段时间有很大的请求量，给我们的分析造成一定的影响，甚至误解。实际上在故障机器重新上线的时候，它只不过是在处理故障之时漏掉处理的那部分请求量而已。假如我们的 stream processor 选择将遗漏的部分舍去，那么故障那段时间的请求量，或许高或许低，那就不清楚了。所以不论是 batch processing , stream processing, 还是故障后从头处理，有选择的处理，都是有缺陷的。

Stream Join :

Stream-Stream Join: 为什么要引入 Join ? 这里有个很重要的概念是 state， 即状态. 假设我们在网易云音乐搜索一类音乐，点击返回结果集中的一个音乐收听，这两个连串的事件，就需要状态来连接。当大量的搜索与点取选择返回给推荐引擎或者其他 stream processor 的时候，需要使用到状态来记录每一次的搜索-点击循环，即两次都是 stream, 并要做关联。

Stream-Table Join: 当用户选择了一个音乐收听时，我们需要记录其收听嗜好。此时前端会发送其 user id 和 music id 的stream 过来，我们需要通过适配 user id 来拿到更多的 user 信息，以方便更好的对某一类用户的嗜好做分析。在存储更详细的用户信息时，就需要stream-table join. 而如果抓取用户的信息需要去远程数据库拉取，中间网络层的通信成本会很高，本地若有 user 信息的副本会极大提高效率，所以这里会采用 CDC 的方式来拿到用户的最新消息的副本，即在本地缓存一份用户基本信息的副本数据，一旦用户信息库数据有更新，通过 CDC 将更新数据同步到stream processor 所在机器的缓存中来。

Table-Table Join: 和 Stream-Stream Join 一样，都需要维护 datasets. 为什么说是 Table-Table Join 而不是 Stream-Stream 呢？ 这种 Join 涉及的主体不再是单一的 stream, 而是并发进行的 stream.

有哪些好用的 stream processing 工具？

除了商业化的数据库，还有 Apache Storm, Apache Spark, Apache Flink, Apache Samza，Kafka Streams.

stream processing 需要和 realtime processing 做一些区别：

1. realtime processing ：我们发出一些查询，等待数秒就得到结果这类交互式查询，可以称之为 realtime processing. 除了数据库，还有 Druid, SAP HANA, VoltDB, MemSQL, Apache Drill .

2. stream processing: 我们发出一个固定的查询请求， 在数据持续不断的流进我们系统的时候，经过我们发出的查询做筛选或者处理，生成新的数据流。例如 Apache Flink, Apache Spark.

根据 srinath Perera 的说法，诸如 real time analytics, streaming analytics, complex event processing, real time streaming analytics, event processing 都可以被叫做 stream processing, 只不过是一些历史叫法而已。

how to do stream processing 如何实现

1. 手工定制：将 event 封装在消息里，传送到 ActiveMQ, RabbitMQ, Kafka 的 message broker topic. 在接收节点端写好解析这些消息的程序， 并将处理完的结果转回给 message broker ,再中转到其他节点上，以供应用处理和存储。

2. 使用产品：Apache Storm, Apache Flink, Apache Samza. 将手工定制部分全部调用 UI 来实现。

3. 2016 年后 StreamSQL 的出现。上述 2）中的所有产品，包括kafka都提供了对 streamSQL 的支持。

—————————–

欢迎关注【有关SQL】，入群讨论技术