核心的实时架构和基于storm的实时架构的设计.
数据流计算来自于一个信念:数据的价值随着时间的流逝而降低,所以事件出现后必须尽快地对它们进行处理,最好数据出现时便立刻对其进行处理,发生一个事件进行一次处理,而不是缓存起来成一批处理。
互联网上海量数据(一般为日志流)的实时计算过程可以被划分为以下三个阶段:数据的产生与收集阶段、传输与分析处理阶段、存储对对外提供服务阶段。
主要是为实时框架提供输入实时的数据流,秒级别的数据并传入实时框架。目前,互联网企业的海量数据采集工具,有Facebook开源的Scribe、LinkedIn开源的Kafka、Cloudera开源的Flume,淘宝开源的TimeTunnel、Hadoop的Chukwa等,均可以满足每秒数百MB的日志数据采集和传输需求。
目前业界诞生了许多系统,它们仿照MapReduce约束编程模型的方式,为了获取更好的执行效率,这些系统包括,微软的DAG任务计算模型Dryad、Google的图批量同步处理系统Pregel和增量式计算框架Percolator,Yahoo!的数据流计算系统S4、NYU的共享内存处理系统Piccolo以及Berkeley的交互式实时处理系统Spark等等。
上图从开发语言、高可用机制、支持精确恢复、主从架构、资源利用率、恢复时间、支持状态持久化及支持去重等几个方面对这三种系统进行了对比。可以看到,为了高效开发,两个系统使用Java,另一种系统使用函数式编程语言Clojure;高可用方案,有两个系统使用Passive Standby方式,系统恢复时间可控,但系统复杂度增加,资源使用率也较低,因为需要一些机器用来当备机;而Storm选择了更简单可行的上游回放方式,资源使用率高,就是恢复时间可能稍长些;Puma和S4都支持状态持久化,但S4目前不支持数据去重,未来可能会实现;三个系统都做不到精确恢复,即恢复后的执行结果和无故障发生时保持一致,因为即使是Passive Standby方式,也只是定期Checkpoint,并没有跟踪每条消息的执行。商用的StreamBase支持精确恢复,这主要应用于金融领域。
全内存: 直接提供数据读取服务,定期dump到磁盘或数据库进行持久化。
半内存: 使用Redis、Memcache、MongoDB、BerkeleyDB等内存数据库提供数据实时查询服务,由这些系统进行持久化操作。
全磁盘: 使用HBase等以分布式文件系统(HDFS)为基础的NoSQL数据库,对于key-value引擎,关键是设计好key的分布*.*
数据输入:采用zeromMQ进行传输,zeroMQ内部做负载均衡
数据处理:采用storm的spout读取zeroMQ传来的数据,bolt进行逻辑的处理
数据结果查询与展现: 最终所有的log都存储在HDFS上,逻辑运行的过程中,处理的时间和处理log的数据被保存到mysql中,
实时的log存储在redis中,供用户查询
实时计算一些基本概念
http://www.cnblogs.com/panfeng412/archive/2011/10/28/2227195.html
Beyond MapReduce:谈2011年风靡的数据流计算系统
http://www.programmer.com.cn/9642/
对互联网海量数据实时计算的理解
http://www.cnblogs.com/panfeng412/archive/2011/10/28/realtime-computing-of-big-data.html
淘宝实时流计算
http://www.cnblogs.com/panfeng412/tag/%E5%AE%9E%E6%97%B6%E6%B5%81%E8%AE%A1%E7%AE%97/
Yahoo! s4和Twitter storm的粗略比较
http://www.blogjava.net/killme2008/archive/2011/11/08/363238.html
Cloudera Announces Game-Changing, Real-Time Query on Hadoop and Leads a New Era of Data Management
http://www.msnbc.msn.com/id/49533097/ns/business-press_releases/t/cloudera-announces-game-changing-real-time-query-hadoop-leads-new-era-data-management/