写在之前：这是用微软输入法打出来的一篇文章。
背景
在Linkedin，大体架构是：ApacheSamza作为流式处理框架，Apache Kafka作为持久化的订阅/发布消息中间件，Databus监控数据库的变化。
数据访问（Data access）的两种模式
为什么数据访问是规模化的挑战？我们处理的数据访问模式主要分两种：
Read/write data：
这里给出一个在Linkedin中使用read-write数据访问模式的场景。Linkedin许多应用需要推送信息给会员，不管通过email还是通知。为了保证更好的用户体验，尽量不多给会员发email。Linkedin开发一个基于Samza的ATC（Air Traffic Control ）应用来控制email和通知送达终端用户。ATC追踪每个会员收到的最后一封邮件的时间，以及所有新的邮件请求的时间。ATC维护着每个会员的状态信息（read/write）。
Read-only data：
同样，给出一个只读数据访问的场景。Linkedin开发一个应用监听会员点击某条广告的事件的时间。这个应用会生成一个AdQuality事件，并高亮点击某些特定广告的会员特征。AdQuality事件会用来训练广告推荐机器学习模型。应用处理AdQuality事件会去查询点击广告的会员的画像。
数据访问的关键特征
除了以上描述的两种访问模式，以下两种数据访问的关键特征也将会极大地影响事件流式处理的架构。
数据访问是否分区？
上面的场景，Kafka的topic是以MemberId分区的。输入事件已经按会员信息（MemberId）分区，那每个事件处理节点仅仅需要访问一个不变的会员数据集。后续我们会看到，如何对已经分区过的数据访问进行缓存优化。
另外一种场景，假设处理每个事件都需要查询Company库获取会员的更多信息，那每个事件处理节点就得查询可能的每个公司。这是访问未分区数据的例子。
数据集的大小
后面会看到，访问一个5M数据集的解决方案跟访问一个5 TB数据集的方案完全不同。比如，你可以把5M数据集完整的存储到每个节点上，然而很显然你不可能对5 TB的数据集做同样的操作。
数据访问的解决方案
下面是展示的是两种常用的数据访问解决方案。
远程存储：这是开发应用的传统的方式。当一个应用处理一个事件，它会远程调用一个隔离的SQL或者No-SQL数据库。这种方法中，写操作总是采用远程调用，但是读数据可以通过本地缓存进行一定程度上的优化。LinkedIn有大量的应用采用这种方法。
另外一种模式，在远程数据库（比如，Oracle）前面前置一个远程缓存（比如，Couchbase）。远程缓存主要用来数据读操作，应用通过Databus之类的工具追踪数据库变化，并替代远程缓存。
本地存储（嵌入式）：这种方法是要求事件处理结果存储的位置和事件处理的地方在同一台机器上。极端的情况是所有数据存储访问都是本地，这样效率最高。
Samza天生就是支持嵌入式本地数据库，它支持把RocksDB嵌入你的事件处理器。它是通过Kafka log compacted topic做备份。
也有其它框架，比如Microsoft ServiceFabric，它本身内建支持本地应用存储。ServiceFabric支持持久化数据到本地磁盘，并把备份持久化到其它处理器实例。ServiceFabric持久化会自动备份到Azure storage。
事件到达点 VS 事件处理点
本地存储和远程存储的讨论是相对于事件处理的位置。在选择使用的框架时，事件到达的位置可能与事件处理的位置不在同一位置。
像GoogleDataflow这类框架支持从未分区的输入源（GooglePub-Sub）读取数据。这种模型中，当事件到达时，处理器会先找出当前事件应该归哪个处理器处理，并转发到对应的实际处理器处理。
而Samza、Spark Streaming和Flink之类的流处理框架《实时流处理框架选型：就应该这样“拉出来遛遛”》天然就支持事件的分区（Kafka，Kinesis等），因此不会再做一步转发处理。
如果你的应用得瓶颈是网络带宽或者计算能力，那处理事件的节点和事件的到达在同一个节点不会出现转发，将会极大的提高性能。
抛开在事件处理之前进行事件转发的情况，本文讨论的在事件处理过程中考虑数据访问这些依然对所有的事件处理框架适用。
在路上
海量流式处理没有一个完美的方案，大家可以根据公司的场景进行平衡取舍。
本文主要讲了两种数据访问的模式，以及数据访问关键特征对架构的影响，并给出了相应的解决方案。最后讨论了事件到达和事件处理位置不同带来的解决方案不同。下期更精彩，敬请关注。
PS：最近更新较少，说声抱歉了。这几周工作较忙，主要涉及到的知识点有：CDH集群、Hue、Zeppelin、Caravel for Hive、elasticsearch on hadoop/Hive、Gobblin、Neo4j等，可以后台留言交流。
参考：
[1] https://engineering.linkedin.com/blog/2016/08/stream-processing-hard-problems-part-ii--data-access
侠天，专注于大数据、机器学习和数学相关的内容，并有个人公众号：bigdata_ny分享相关技术文章。
若发现以上文章有任何不妥，请联系我。
