Beatles小记－分布式数据流分析框架（一）

Author：放翁（文初）

Email：fangweng@taobao.com

Mblog:weibo.com/fangweng

Blog: http://blog.youkuaiyun.com/cenwenchu79/

 

概述

       重要：全文内容都是参照这个源码地址内容所写，因此两边对着看会更清晰明了：https://github.com/cenwenchu/beatles

 

这篇小记主要处于两方面考虑：首先，希望打破一提到海量数据分析，就只有hadoop基础上的一系列工具，更多的时候很多企业需要的是更轻量的设计（办喜酒杀猪杀鸡未必都要用一把刀），因此将开放平台基础分析组件重构版本beatles的设计写出来，给出更多的思考空间。其次，也是希望推广一种思想，所有的系统，框架设计简化（可扩展），小部件精致化，这样才能让很多项目能够整体灵活，细节给力。

 

建议

这篇小记一共分成4部分，概述，整体设计，局部设计，待续。如果你只想了解个背景，那么看完概述即可，如果对于流式分析的大框架设计感兴趣（看看省略了分布式计算集群的什么？核心设计是怎么样的），请仔细看完整体设计。如果还对代码优化有兴趣，那请看局部设计（细到代码功能级别）。最后留下的待续，将会增加后续的一些扩展，及同学看完后提出问题的解答（比较通用的一些问题，例如容灾啊，啥啥啥很多被认为很重要的东西）

 

背景

       07年底开始做开放平台，当时每天访问量在4kw左右，考虑到开放平台的数据透明化需求，开始考虑如何做统计分析，当时需求是一天出一次结果即可，因此自己摸索搭建Hadoop迷你集群，开始了分析之路。09年公司调整加入淘宝开放平台，当时每天服务调用量2亿，数据分析要求比较散，从服务的系统数据统计到业务趋势统计都有涉及，而且统计需求变化较多，因此开始筹备自己写简单的统计抽象模型来规避MapReduce类，提高适应变化的能力，同时出于简化系统设计维护的要求，直接将每日分析数据放置到集中服务器上，每日拉取，切割，分析（统计分析引擎抽象完成）。2010年开放平台基础体系开始建立，对于服务质量，应用行为，用户安全都提到了较高的要求上来，分析结果从原来的统计分析，扩展到了监控告警，每日分析转变为增量分析（频度1小时左右），简化的任务调度模型抽象出来，同时服务调用量增涨到了9亿。2011年平台数据统计分析及时性要求更高，同时开始开放统计数据给外部开发者（系统可用性和效率要求更高），整体框架和局部设计不断优化和改进，截至今年11月，单日最大服务调用量19亿，增量统计实时性要求在2分钟内（包含数据分析和数据产出，低峰期1分钟，高峰期1分半），系统可用性要求高于99.6％，而投入的服务器比起动则几十台甚至上百上千的Hadoop系统来说，就是一个迷你集群（一台Master实体机（16核，16g内存），12台虚拟机（虚后5核，8g内存，实际为4台实体机）），每天负责600