![](https://img-blog.csdnimg.cn/20201014180756754.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
流式处理
张包峰
Distributed Computing
展开
-
Storm源码结构 (来源Storm Github Wiki)
本文译自Storm Github Wiki: Structure of the codebase,有助于深入了解Storm的设计和源码学习。本人也是参照这个进行学习的,觉得在理解Storm设计的过程中起到了重要作用,所以也帖一份放在自己博客里。以下的模块分析里没有包括Storm 0.9.0增加的Netty模块,对应的代码包在Storm Github下的storm-netty文件夹内,内容比较简单,关于这块的release note可以参考Storm 0.9.0 Released Netty Transpor翻译 2013-12-30 16:17:33 · 5020 阅读 · 0 评论 -
Spark Streaming原理简析
执行流程数据的接收StreamingContext实例化的时候,需要传入一个SparkContext,然后指定要连接的spark matser url,即连接一个spark engine,用于获得executor。实例化之后,首先,要指定一个接收数据的方式,如val lines = ssc.socketTextStream("localhost", 9999)这样从socket接收文本数据。这个步骤原创 2015-03-19 15:23:05 · 4761 阅读 · 0 评论 -
最近分布式系统开发小结: Slave模块Executors设计
Slave模块三种Executor的设计,主要考虑的是各个Executor挂掉之后,怎样保证数据处理的不重复和不遗漏。我们依赖Zookeeper的可靠性,记录、更新、判断Bundle的状态,做到Input、Cache、Output各司其职,最到最小粒度的容错。Executor本身的失败和重启则由Mesos保障,Mesos作为资源管理系统,由Master监控Slave上各个Executor的执行状况,通过回调,可以在合适的Slave上再次启动挂掉的Executor进程,保证业务Task的顺利进行。原创 2014-01-07 12:14:25 · 3845 阅读 · 0 评论 -
Kafka介绍
传统的消息模型有两种模型,队列模型和发布-订阅模式。1. 队列形式中,一群消费者可能从server那边读消息,而每条消息会流向他们中的一个。2. 发布-订阅模式中,消息会广播到所有它的消费者们那。Kafka是使用consumer group这个概念(下面把它翻译为"消费组"),把两者结合了。。 消费者给自己标志了一个消费组名,每条新发布到topic的消息会被传递给订阅它的消费组里的消费者实例,这些消费者实例可以是不同的进程,存在在不同的机器上。 如果所有的消费者在同一个消费组里,那么这相当于是原创 2014-05-20 17:29:18 · 5619 阅读 · 0 评论 -
淘宝实时数据传输平台: TimeTunnel介绍
作者在工作中遇到了类似流式数据实时接入的业务场景,所以对淘宝的实时数据仓库这一块做了一些调研和了解。本文从业务场景和设计上介绍了淘宝的TimeTunnel工具,文中的图片来自淘宝数据仓库团队交流过程中的sildes,也参考了一些相关文档。业务背景TimeTunnel(简称TT)是一个基于thrift通讯框架搭建的实时数据传输平台,具有高性能、实时性、顺序性、高可靠性、高可用性、可扩展性等特点(基于Hbase)。目前TimeTunnel在阿里巴巴广泛的应用于日志收集、数据监控、广告反馈、量子统计、数据原创 2014-05-19 17:23:04 · 19114 阅读 · 2 评论 -
In-Stream Big Data Processing译文:流式大数据处理
转自:http://blog.csdn.net/idontwantobe/article/details/25938511原文:http://highlyscalable.wordpress.com/2013/08/20/in-stream-big-data-processing/作者:Ilya Katsov相当长一段时间以来,大数据社区已经普遍认识到了批量数据处理的不足。转载 2014-05-18 23:24:19 · 3846 阅读 · 0 评论 -
Storm可靠性及事务性相关设计: Acker及Trident State
上面这件事一般IBasicBolt可以罩住,更多的方法可以使用IRichBolt。一个topology里面的acker数量是可以设置的,然后tuple比较多的话可以多设置几个acker,提高效率。每个tuple有一个64位的id,acker利用这个id来追踪tuple,且会知道这个tuple他的祖宗们,也就是只要继续跟踪新的tuple就可以了,因为祖宗的id会被传递下去。storm用一致性哈希来把spout-tuple-id对应给acker,因为tuple知道自己的祖宗,所以他可以算出通知哪个acker翻译 2013-12-30 20:56:56 · 4964 阅读 · 0 评论 -
分布式日志收集系统Apache Flume的设计介绍
Flume是Cloudera公司的一款高性能、高可能的分布式日志收集系统。现在已经是Apache Top项目。Github地址。同Flume相似的日志收集系统还有Facebook Scribe,Apache Chuwka,Apache Kafka(也是LinkedIn的)。Flume是后起之秀,本文尝试简要分析Flume数据流通过程中提供的组件、可靠性保证来介绍Flume的主要设计,不涉及Flume具体的安装使用,也不涉及代码层面的剖析。写博文来记录这个工具主要是觉得与最近开发的一个流式的数据搬运的工具在设原创 2014-01-12 22:30:32 · 21828 阅读 · 3 评论 -
最近分布式系统开发小结
最近在设计和开发一个分布式系统的流式处理模块,整个系统用于跨集群、跨机房搬运不同数据源内的数据到另一份或多份数据源上,包括HDFS、MySQl、MongoDB、FTP等。功能比较像Hadoop的Sqoop,但是能扩展支持更多的数据源,且本身是个集群部署,不像Sqoop需要依赖Hadoop的MR。我们整个cluster的资源管理借助Mesos来完成,由自己定制的Mesos Scheduler向Mesos Master申请可用的资源,具体把数据搬运的任务分发到Mesos Slave的Executor上,而我主原创 2013-12-27 22:19:12 · 4515 阅读 · 7 评论 -
搬家与流式处理
这两天搬家,身体很劳累,脑子算是没闲着。在把货物搬上楼的过程中,我琢磨了个自认为很高效的方法,本质和流式处理很像。需求与尝试 一车货物,零零散散打了些包,停在楼下,需要搬到五楼去。劳力有三人。一开始的方案是每个人自己拿几样东西,自管自上楼去,再下楼来拿下一趟。搬了几趟后,有以下一些问题: 1. 搬运过程中,累的不是手臂,而是脚。光爬几次五楼,腿已经先受不了了。 2. 过程中为了方便,楼下车不锁原创 2016-01-31 21:17:53 · 2068 阅读 · 0 评论