从Storm和Spark 学习流式实时分布式计算的设计

  • 时间:
  • 浏览:1

Storm的有些使用ZK的妙招还是很值得借鉴的。

Storm和Spark的设计,绝对需要一篇文章所能除理的。它顶端由非常多的哲学需要亲戚有些人 仔细去学习。它们无需 说是亲戚有些人 进行系统设计的良好的范例。本博客在接下来的二天会通过Spark的源码来学习Spark的系统架构。敬请期待!

本文对流式系统冒出的背景,特点,数据HA,服务HA,节点间和计算逻辑间的消息传递,存储模型,计算模型,与生产环境融合需要涉及。希望对亲戚有些人 的工作和学习有所帮助。可能本文对您有所帮助,别忘了投一票!点我投票 (可能可能在投票页面,请接着向下看)

回到系统设计一种生活生活,实际上流式计算系统主倘若为了离线和近线的机器学习和数据挖掘,否则肯定要保证数据的除理下行速率 :大慨系统无需 除理一天的新增数据,否则数据堆积这么大。否则即使有的数据除理丢失了数据,无需 让源头重新发送数据。

WordCount的例子:

      本文主要探讨流式计算系统的设计要点,否则通过对Spark和Storm的实现来给出实例。通过对于系统设计要点的梳理,也无需 帮助亲戚有些人 更好的学习哪些地方地方系统的实现。最后,看一下国内互联网公司对于哪些地方地方流式系统的应用(仅限于公开发表的内容)。

最近我在做流式实八时布式计算系统的埋点,而正好又要参加CSDN博文大赛的决赛。原先想就写Spark源码分析的文章吧。否则又想毕竟是决赛,要读懂有些其他人的干货出来,仅仅是源码分析貌似分量不足。否则,我将最近老要在做的系统架构的思路埋点出来,形成此文。为哪些地方要参考Storm和Spark,可能这么参照效果可能无需太好,尤其是对于Storm和Spark由了解的同学来说,可能通过对比,更能体会到每个具体实现面前的意义。

        Storm将计算逻辑成为Topology,其中Spout是Topology的数据源,有些数据源可能是文件系统的某个日志,也可能是MessageQueue的某个消息队列,需要可能是数据库的某个表等等;Bolt负责数据的护理。Bolt有可能由另外有一个多多Bolt的join而来。

着实可能需要为了追求30%的数据丢失,无需 使用checkpoint的机制,允许有一个多多时间窗口内的数据丢失。

Spark是怎样实现HA的?我的另外一篇文章分析过Spark的Master是怎样实现HA的:Spark技术内幕:Master基于ZooKeeper的High Availability(HA)源码实现 。

流式系统的原语设计,要关注一下几点:

HA是分布式系统的必要属性。可能这么HA,着实系统是不可用的。这么可能实现HA?对于Storm来说,它认为Master节点Nimbus是无情况表的,无情况表原困无需 快速恢复,否则Nimbus并这么实现HA(问你以后的Nimbus是否会实现HA,实际上使用ZooKeeper实现节点的HA是开源领域的通用做法)。为哪些地方说Nimbus是无情况表的呢?可能集群所有的元数据都保存到了ZooKeeper(ZK)中。Nimbus定时从ZK获取信息,否则通过向ZK写信息来控制Worker。Worker也是通过从ZK中获取信息,通过有些妙招,Worker执行从Nimbus传递过来的命令。

包括Spark和Storm,在国内著名的互联网公司比如百度,淘宝和阿里巴巴需要应用,否则它究竟贡献了十几个 流量是不得而知的。我了解到的是实际上大次要的流量,尤其是核心流量还是走公司的老架构的。著名的博主陈皓在微博上关于闭源软件和开源软件“特点”之争是否引起了轩然大波,具体讨论无需 见知乎。一种生活生活引用有些争论也是为了切合本小节的主题:怎样与公司已有的生产环境进行融合。

现在什么都公司每天需要产生数以TB级的大数据,怎样对哪些地方地方数据进行挖掘,分析成了不怎样要的课题。比如:

        Hadoop定义了Map和Reduce,使得应用者只需要实现MR就无需 实现数据除理。而流式系统的特点,允许它们无需 进行更加具体有些的原语设计。流式的数据的特点倘若数据时源源不断进入系统的,而哪些地方地方数据的除理一般都需要十几个 阶段。拿普通的日志除理来说,亲戚有些人 可能仅仅关注Error的日志,这么系统的第有一个多多计算逻辑倘若进行filer。接下来可能需要对有些日志进行分段,分段后可能交给不同的规则除理器进行除理。否则,数据除理一般是分阶段的,无需 说是有一个多多有向无环图,可能说是有一个多多拓扑。实际上,Spark抽象出的运算逻辑倘若由RDD(Resilient Distributed Dataset)构成DAG(Directed Acyclic Graph),而Storm则有Spout和Blot构成Topology(拓扑)。

        对于在线(区别于响应互联网用户请求的在线系统,有些在线系统主倘若实物使用的,也倘若说不须直接服务于互联网用户)/近线系统来说,除理的是线上产生的数据,比如在线系统产生的日志,记录用户行为的数据库等,否则近线系统也需要低延时高可靠的除理海量数据。对于哪些地方地方时效性很强的数据,比如新闻热点,电商的促销,微博热词等都需要在很短的时间内完成数据除理以供在线系统使用。

当然了,无需 使用日志的妙招。否则日志得话对于错误恢复的时间又是不太能接受的。流式计算系统的特点倘若要快,可能错误恢复时间太长,这么可能不如直接replay来的快,否则系统设计还更为简单。

      消息传递和埋点是取决于系统的具体实现的。通过对比Storm和Spark,你就明白我为哪些地方这么说了。

       Spark Streaming是将流式计算分解成一系列短小的批除理作业。这里的批除理引擎是Spark,也倘若把Spark Streaming的输入数据按照batch size(如1秒)分成一段一段的数据,每一段数据都转再加Spark中的RDD,否则将Spark Streaming中对DStream的Transformation操作变为针对Spark中对RDD的Transformation操作,将RDD经过操作变成顶端结果保位于内存中。整个流式计算根据业务的需求无需 对顶端的结果进行叠加,可能存储到实物设备。下图显示了Spark Streaming的整个流程。

还有另外有一个多多话题,倘若系统的元数据信心怎样保存,可能系统的路由信息等需倘若全局可见的,需要保存同类的哪些地方地方数据以供集群查询。当然了Master节点保持了和所有节点的心跳,它完整篇 无需 保存哪些地方地方数据,否则在心跳中无需 返回哪些地方地方数据。实际上HDFS的NameNode倘若这么做的。HDFS的NN有些设计非常合理,为哪些地方这么说?HDFS的元数据富含了非常多的数据:

0. 背景

正文以后刚开始:

否则, ZeroMQ需要传统意义上的MQ。它比较适用于节点之间和节点与Master之间的通信。Storm在0.8以后的Worker之间的通信倘若通过ZeroMQ。否则为哪些地方0.9倘若用Netty替代了ZeroMQ呢?说替代不大大慨,倘若0.9的默认的Worker之间的通信是使用了Netty,ZeroMQ还是支持的。Storm官方认为ZeroMQ有以下缺点:

        而除理哪些地方地方海量数据的,倘若实时流式计算系统。Spark是实时计算的系统,支持流式计算,批除理和实时查询。它使用有一个多多通用的stack除理了什么都问题报告 报告 ,毕竟任何公司都愿意Unified的平台去除理遇到的问题报告 报告 ,无需 减少开发和维护的人力成本和部署平台的物力成本。除了Spark,流式计算系统最有名的倘若Twitter的Storm和Yahoo的S4(着实Spark的流式计算还是要弱于Storm的,其他人认为互联网公司对于Storm的部署还是多于Spark的)。

当然了,开源社区的闪光点也会影响到闭源产品,闭源产品也会影响开源产品,有些相互影响是良性的,无需 推动技术向前发展。

有些例子使用Scala写的,有一个多多简单优雅的函数式编程语言,一同也是基于JVM的后Java类语言。

这么对于流式计算系统有些算得上轻量级的元数据来说,Master除理哪些地方地方元数据实际上要简单的多,当然了,Master需要实现服务的HA和数据的HA。哪些地方地方需要有一个多多轻松的事情。实际上,无需 采用ZooKeeper来保存系统的元数据。ZooKeeper使用有一个多多目录树的社会形态来保存集群的元数据。节点无需 监控感兴趣的数据,可能数据有变化,这么节点会收到通知,否则就保证了系统级别的数据一致性。这点对于系统比较重要,可能节点需要不稳定的,否则系统的有些服务可能需要可能节点失效而位于变化,哪些地方地方都需要通知相关的节点更新器服务列表,保证了次要节点的失效不须会影响系统的整体的服务,从而也就实现了故障对于用户的透明性。

消息队列现在是模块之间通信的非常通用的除理方案了。消息队列使得系统任务管理器间的通信无需 跨越物理机,这对于分布式系统尤为重要,毕竟亲戚有些人 只有假定系统任务管理器究竟是部署在同一台物理机上还是部署到不同的物理机上。RabbitMQ是应用比较广泛的MQ,关于RabbitMQ无需 看我的有一个多多专栏:RabbitMQ

对于Storm来说,他的消息埋点机制是在定义Topology的以后就显式定义好的。也倘若说,应用系统任务管理器的开发者需要清楚的定义各个Bolts之间的关系,下游的Bolt是以哪些地方样的妙招获取上游的Bolt发出的Tuple。Storm有六种消息埋点模式:

当然了还有所谓的性能问题报告 报告 ,具体无需 访问Netty作者的blog。结论倘若Netty的性能比ZMQ(在默认配置下)好两倍。问你所谓的ZMQ的默认配置是哪些地方。反正我对有些结果挺惊讶。当然了,Netty使用Java实现的确方便了在Worker之间的通信再加授权和认证机制。有些使用ZMQ的确是不太好做。

也是通过ZK的leader 选举实现的。Spark使用了百行代码的级别实现了Master的HA,由此可见ZK的功力。

除了哪些地方地方Master的HA,还有每个Worker的HA。可能说Worker的HA说法不太准确,否则对于集群里的工作节点来说,它无需 非常容易失败的。这里的HA无需 说是怎样让Worker失败后快速重启,重新提供服务。实现妙招也无需 由什么都种。有一个多多简单的妙招倘若使用有一个多多容器(Container)启动Worker否则监控Worker的情况表,可能Worker异常退出,这么就重新启动它。有些妙招很简单也很有效。

       对于实现的逻辑来说,它们需要有向无环图的有一个多多节点,这么怎样设计它们之间的消息传递呢?可能说数据怎样流动的?可能对于分布式系统来说,亲戚有些人 只有假定整个运算需要在同有一个多多节点上(事实上,对于闭源软件来说,这是无需 的,比如倘若满足有一个多多特定运算下的计算,计算平台倘若需要做的这么通用,这么对于有一个多多运算逻辑我就在有一个多多节点完成也是无需 了,毕竟节省了调度和网络传输的开销)。可能说,对于有一个多多通用的计算平台来说,亲戚有些人 只有假定任何事情。

着实,数据不丢失有以后和除理下行速率 是矛盾的。为了数据不丢失就要进行数据持久化,数据持久化原困要写硬盘,在固态硬盘还这么成为标配的今天,硬盘的IO下行速率 永远是系统的痛点。当然了无需 在另外节点的内存上进行备份,否则这涉及到了集群的有一个多多稀缺资源:内存和网络。可能可能备份而占用了极少量的网络下行速率 得话,那必将影响系统的性能,吞吐量。

可能是节点宕机呢?上述妙招肯定是只有用的。有些情况表下Master会检测到Worker的心跳超时,这么就会从资源池中把有些节点删除。回到正题,宕机后的节点重启涉及到了运维方面的知识。对于有一个多多集群来说,硬件宕机有些情况表应该需要统一的管理,也倘若集群也无需 由有一个多多Master,维持每个节点的心跳来选择硬件的情况表。可能节点宕机,这么集群首先是重启它。可能启动失败可能会通过电话可能短信可能邮件通知运维人员。否则运维人员为了保证集群的高可用性付出了什么都的努力,尤其是大型互联网公司的运维人员,非常值得点赞。当然了有些可能需要Storm可能Spark所能富含的了。

可能本文对您有所帮助,别忘了投一票!点我投票 可能可能在投票页面,这么点击下面吧!

流式实八时布式计算系统倘若要除理上述问题报告 报告 的。哪些地方地方系统的一同社会形态是哪些地方?

       而Storm最核心的抽象Streaming倘若连接Spout,Bolt以及Bolt与Bolt之间的数据流。而数据流的组成单位倘若Tuple(元组),有些Tuple可能由多个Fields构成,每个Field的含义需要Bolt的定义的以后制定。也倘若说,对于有一个多多Bolt来说,Tuple的格式是定义好的。

对于Spark来说,数据流是在通过将用户定义的一系列的RDD转化成DAG图,否则DAG Scheduler把有些DAG转化成有一个多多TaskSet,而有些TaskSet就无需 向集群申请计算资源,集群把有些TaskSet部署到Worker中去运算了。当然了,对于开发者来说,他的任务是定义有些RDD,在RDD上做相应的转化动作,最后系统会将有些系列的RDD投放在Spark的集群中去运行。

       流式实八时布式计算系统在互联网公司占有举足轻重的地位,尤其在在线和近线的海量数据除理上。在线系统负责除理在线请求,否则低延时高可靠是核心指标。在线系统是互联网公司的核心,系统的好坏直接影响了流量,而流量对互联网公司来说原困一切。在线系统使用的数据是来自于后台的计算系统产生的。

提到MQ,不得不提的是ZeroMQ。ZeroMQ封装了Socket,引用官方的说法: “ZMQ (以下 ZeroMQ 简称 ZMQ)是有一个多多简单好用的传输层,像框架一样的有一个多多 socket library,他使得 Socket 编程更加简单、简洁和性能更高。是有一个多多消息除理队列库,可在多个系统任务管理器、内核和主机盒之间弹性伸缩。ZMQ 的明确目标是“成为标准网络协议栈的一次要,以后进入 Linux 内核”。现在还未就看它们的成功。否则,它无疑是极具前景的、否则是亲戚有些人 更加需要的“传统”BSD 套接字之上的一层封装。ZMQ 让编写高性能网络应用系统任务管理器极为简单和有趣。”

着实互联网公司的产品迭代减慢,否则公司的核心算法和架构基本上改动无需这么多,否则公司可能为了推动Storm和Spark有些开源产品而进行大规模的重新开发。只有这么后起的项目,从零以后刚开始的项目,比如小规模的调研项目才可能用哪些地方地方产品。当然了开源产品首先是有一个多多通用的平台,否则通用有可能产生的代价倘若不这么高效,对于有些特殊地方的只有根据特殊的应用场景进行优化。可能对有些开源平台进行二次开发,使得性能方面满足其他人的需求,首先不管法务上的问题报告 报告 ,对于其他人私有版本和社区版本进行merge也是个很大的challenge。就像现在什么都公司对于Linux进行了二次裁剪,开发其他人需要的Linux一样。都需要有些对于哪些地方地方架构非常熟悉,否则非常熟悉社区动态的人去做哪些地方地方事情。而哪些地方地方在互联网公司,基本上是可能的。否则大次要以后,需要其他人做有一个多多系统,去非常高效切合的去满足自身的需求。