S4实现机理介绍

S4实现机理介绍

2011-03-24 12:53  450人阅读  评论(2)  收藏  举报

         S4是yahoo开源的一套流式数据处理系统，什么是流式处理系统，顾名思义，我们把实时处理模块作为一个黑盒（这个黑盒的具体实现我们在下文中讨论），这个黑盒有很多接入管道，待处理数据可以从这些管道实时接入，并实时从出口产生分析后的结果数据。构建的整套系统可以称为流式数据处理系统。

         该系统主要的应用场景可以在：系统状态实时监控，用户行为实时监控，营销&广告效果实时统计。

         在这里先举个例子：用户行为实时监控：

         用户浏览页面行为的log被实时接入到流式数据处理系统，经过实时分析后，系统可以实时输出到每天到当前时间为止，访问网站各个页面的浏览量和用户数（用户数需要针对用户进行去重）。而当我们遇到的计算任务和分析数据都非常庞大时，分布式解决方案便顺理成章的成为救命稻草。

         接下来我们介绍S4系统的实现：

         S4的主要特点：1.decentralize设计，2.同质化设计

         Decentralize：系统并没有任何master机器，可以近似认为没有任何主控角色，这样的设计使得系统扩展性有非常好的表现，系统可以非常方便的按照处理的数据量压力进行横向扩容。

         同质化设计：系统中所有模块执行的程序都一样，在系统设计时也是一视同仁，并没有任何不同，简单的设计原则，便于实现和验证，而且并不失系统功能性。

 

我们先看一下系统设计架构，非常简单，系统只分为两层网络层和业务逻辑层

 

 

 

接下来我们看系统是如果运作的，其实设计理念非常简单，用户逻辑部分主要是Event和EventProcess以及dispatcher的封装。

不同的数据接入进来被抽象成不同的Event，而每个Event会有对应的EventProcess进行处理，EventProcess处理Event的过程中也会产生很多中间结果的Event类型，而这些Event又被PUSH的网络层，网络层通过配置的dispatcher进行转发。

为了便于理解我们再举一个稍微复杂的一个统计需求的具体例子：

假如我们有银行用户实时取款记录如下：

类型1：用户|地区|取款金额|其他冗余信息

类型2：用户|地区|存款金额|其他冗余信息

银行需要监控资金流动性，需要统计每个自然月到当天为止，每个地区的存款金额总数和每个地区的取款总数。

 

于是乎：数据接入的类型就有两种SaveEvent  和 TakeEvent

 

1.SaveEvent处理

SaveEvent被网络层接收到后，调用用户配置的dispatcher接口的dispatch方法，将该Event发送到某台机器，这台机器反序列化数据后得到该Event为SaveEvent便调用SaveEventProcess进行处理，去除冗余信息生成SaveTakeEvent并调用该Event对用的dispatcher接口，将该Event发送到某台机器。

2. TakeEvent处理

TakeEvent被网络层接收到后，调用用户配置的dispatcher接口的dispatch方法，将该Event发送到某台机器，这台机器反序列化数据后得到该Event为TakeEvent便调用TakeEventProcess进行处理，去除冗余信息也生成SaveTakeEvent并调用该Event对用的dispatcher接口，将该Event发送到某台机器。

3. SaveTakeEvent处理

同一地区的SaveTakeEvent被发送到一起，系统对Event反序列化知道该Event为SaveTakeEvent类型，便调用TakeAndSaveEventProcess进行处理，将Save操作和Take操作的钱数进行对应的累加。

 

这里面有几个关键点：

1.       dispatcher接口，这个接口起到的重要职责有两个：1.负载均衡。2：将关联数据发布到同一台机器。

2.       不同类型的Event有对应的EvenProcess进行处理。

 

如上例，distpatcher接口完全可以按照地区进行散列，既保证同一地区的数据落在一起，又保证不同地区数据分散均匀。

 

上例可以用一个如下一个有向无环图进行表示：

 

接下来我们就看S4的流程控制如何实现，其实很简单，上述过程基本上也已经描述清楚，S4充分利用了java的反射机制结合通过数据序列化和凡序列化实现了上述框架。一个Event类型的数据被disaptch不同机器上，成功反序列化出来以后，可以通过反射机制得到Event类型，然后再通过反射机制生成处理这个Event的EventProcess，然后缓存EventProcess实例，用以不断接受此类Event进行处理，产生的中间结果Event也会通过网络层传送出去，并再次经历上述过程，直到DAG任务的结束。

通过Event和EventProcess的对应可以非常方便的构建出一个DAG

 

还有一个关键就是刚才的dispatcher，这个不再详细赘述了，至于系统通过zookeeper进行名字映射等细节问题，这里也不做过多介绍了。

 

这样的设计可以看到所有的机器上的程序都一样，任何一台机器都需要承载Event和EventProcess，而且毫无二致，dispatcher也通过反射机制得到Event的某些关键属性值，并通过这个属性值进行dispatch。

 

上述只是S4的大致实现思路，详细细节分析以后补充。