分布式Streaming Data Processing - Samza

现在的主流的互联网应用越来越依赖streaming data来提供用户一些interesting statistics insights。以linkedin为例，最近90天有多少人看过你的linkedin profile。看过你profile的人都是什么job title，他们都在那些公司工作。如下图，你应该如何实现这个功能呢？

相信大家都听说过page view event，就是用户每次打开网站上的某个页面发出来的tracking event，各个大公司一般用这些event来做一些统计分析，business analysis。大家一般会利用一些吞吐量大的分布式消息系统来存储这些event，例如kafka。这是因为对于一些popular的网站，每天可能会有上亿或者10亿的page view event。我们可以利用对这个event的处理来实现我们之前提到的功能。

通常有两种方法可以实现以上的功能，一个是通过hadoop map reduce job，或者更抽象的hive pig query来实现这样的统计功能。但是这个方法有一个明显的劣势，就是处理速度慢，很难做到事实更新。对于我们以上的功能要求或许这个方法没有任何问题，因为我们只关注过去90天的统计信息而且不要求显示当天信息。但是今天我们要探讨另一个实现方法，利用多streaming data processing做到实时统计更新。其实有好多功能是需要事实更新的，例如search index update，twitter或者facebook一些hot topic/trent的发现。

1. Stream Data Repartition

我们可以通过对streaming data的repartition来实现同一个用户的page view events都聚集到了同一个机器上去处理，这样我们可以做到每个用户的统计数据都是准确的。这个功能基本所有主流的streaming data处理框架都支持，例如，kafka + samza，aws kinesis，storm。

1. Streaming Data Join

我们可以看到我们需要根据viewer的职位名称或者公司名称来做统计，但是我们的page view event只有viewer的id，没有职位或者公司这些信息，那我们改怎么实现呢？

一个非常简单的思路就是让我们的streaming processor去call profile的api来拿到职位或者公司名称的信息。这样子做有几个非常明显的劣势。1. 如果streaming processor停止工作半个小时或者更长时间，在重启streaming processor的时候由于积累了大量的未处理的events，streaming processor会flood我们之前说过的profile api。2. Streaming processor每次通过network来call另外一个api会增加额外的latency。3. 很难做到online和offline的isolation，因为这个统计功能还是属于offline或者nearline data processing，我们不希望因为这个功能影响了用户查询或者修改profile信息。比如第一个case发生的时候。

另一个思路就是可以加cache，来cache profile的查询request。但是这样子也有一个劣势，如果TTL设的很大，很难做到cache的数据是事实更新的，如果TTL设的特别短，cahe又基本不起什么作用，而且增加额外的network cost。

这里我们介绍一个samza引进的一个新功能，stream joining。我们可以join page view event和profile edit event，然后解决以上两个方案的劣势。我们的stream processor需要同时听两种events(PageViewEvent and ProfileEditEvent)，然后对这两种event进行同样的partition both by viewer id，对于profile edit events，我们可以在stream processing机器上建立一个小的数据库来存储profile的实时数据，这样子我们可以对viewer进行快速查询来enrish page view event with viewer job title和company information。然后我们再将enriched的page view event重新partition by user id。然后进行统计。这样子我们就做的了profile数据的isolation，也解决了network call的latentcy cost。