首页 文章 精选 留言 我的

精选列表

搜索[hadoop],共8437篇文章
优秀的个人博客,低调大师

云上大数据系列1:手把手教你何如在ECS上搭建Hadoop开发测试环境(CDH版)

本篇是云上大数据系列第一篇文章,主要介绍开发测试环境的搭建。在后续的文章中,我们还将会分享更多关于云上大数据系统的性能分析和调优经验,敬请期待。 大数据系统是典型的复杂分布式系统,搭建一套大数据系统不但需要大量的资源,还需要对大数据系统本省有一定的了解。云计算的普及使得大数据系统的快速部署,甚至一键部署成为可能。笔者在阿里云上尝试搭建了一套大数据系统,将部署的过程和大家分享一下。 资源环境:ecs.d1.6xlarge × 5 软件系统:CDH 5.14.2 操作系统:CentOS 7.3 以下教程基于Cloudera官方教程,结合笔者实际部署过程中遇到的问题编写而成。读者在实践的过程中可以将本文和官方教程结合来参考。官方教程点这里查看。 教程特点(做好心理准备):需要下载 cloudera-manager-daemons 包(744M),cloudera-manager-agent 包(788M),下载过程比较慢,且中途容易出错,需要多次重试。如果对上述部署方式不满意,还可以尝试官方的第三种方式(预下载安装包并手动安装):https://www.cloudera.com/documentation/enterprise/5-13-x/topics/cm_ig_install_path_c.html#cmig_topic_6_7 第一步:购买ECS资源: 在阿里云官方网站上购买5台规格为ecs.d1.6xlarge的机器。注意两点: 修改机器名称以区分不同的角色:1台 master,4台 worker,例如cdh-m1, cdh-w1, cdh-w2, cdh-w3, cdh-w4; 点击下单前选择密码登录,并记住登录密码。 第二步:简单配置集群 为所有结点设置免密登录(百度搜索“ssh免密登录”) 修改所有结点 hostname : hostname cdh-m1 并同步修改 /etc/hostname 文件 (optional) 为所有结点配置pdsh,方便批量操作。pdsh的基本命令: pdsh -w cdh-w[1-4] cmd (可以放在第四步的间隙来做)配置本地数据盘(格式化,挂载,开启自动挂载) 点击这里下载 format.sh脚本。 for i in {1..4}; do scp format.sh root@cdh-w$i:/root; done pdsh -w cdh-w[1-4] bash /root/format.sh 检查一下是否配置成功(输出为所有 worker 结点本地盘数量总和,4结点是48): pdsh -w cdh-w[1-4] df -h | grep "5.1T" | wc -l 其中“5.1T”为数据盘大小,可以根据本地数据盘做修改。 第三步:安装基础服务 登录到 master 结点,安装 MySQL :详细教程点击这里。对照教程,完成: 配置 my.cnf(只需要照着它的推荐配置配就可以了); 备份 ib_logfile; 修改 root 用户登录密码; 添加到开机自启动; 下载 jdbc; 创建一些数据库:在 MySQL 中执行脚本:create_databases.sql。点击这里下载脚本。 配置Cloudera源:下载(点击下载)并将 cloudera-manager.repo 文件拷贝到 /etc/yum.repos.d/ 安装jdk-1.7:(下载速度较慢,15min) sudo yum install oracle-j2sdk1.7 第四步:安装CDH 安装 Cloudera Manager Server Packages:(下载速度较慢,中途可能失败,需要反复重试,利用这个时间空隙,可以完成第二步第4小步) sudo yum install cloudera-manager-daemons cloudera-manager-server 为 Cloudera Manager 配置本地数据库: 在 MySQL中创建一个服务于 cloudera manager 的数据库,起名叫 cloudera_manager (小写): create database cloudera_manager DEFAULT CHARACTER SET utf8; 连接到该数据库: /usr/share/cmf/schema/scm_prepare_database.sh mysql cloudera_manager root password 启动 Cloudera Manager Server: sudo service cloudera-scm-server start 在浏览器中打开 http://cdh-m1:7180,此时无响应,需要做端口映射:详细教程可以点击这里了解更多。 我的做法:开两个命令窗口,分别跑两个进程: ssh -i id_rsa -ND 7180 root@cdh-m1 其中“7180”是准备映射的端口。 /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --proxy-server="socks5://localhost:7180" --host-resolver-rules="MAP * 0.0.0.0 , EXCLUDE localhost" --user-data-dir=/tmp/ 刷新刚才的页面:http://cdh-m1:7180,用户名和密码都是admin。按照提示开始安装过程。由于每台机器都需要安装 jdk 和 cloudera-manager-agent,这两个包的下载速度非常慢,过程可能长达数小时。需要提前做好心里准备(其他准备也做不了)。安装过程中需要注意几个问题: 在主机检查阶段,确保所有项目都checked,如果没有,按照提示逐一修复; 在服务选择阶段,可以自定义服务,根据需要选择相应的服务,而无需选择所有服务。也可以直接选择所有服务,安装完成后手动停掉不需要的服务,我选择了所有服务(后来我又把不需要的服务都手工删掉了,衰); 在数据库连接阶段,打开 create_databases.sql 文件,并对照填写相应的内容;如果在上一步中选择了 Hue 和 Oozie 服务,那么这里需要为这两个服务配置相应的数据库,详细教程见这里: Hue:https://www.cloudera.com/documentation/enterprise/5-13-x/topics/hue_dbs_mysql.html#hue_dbs_mysqlOozie:https://www.cloudera.com/documentation/enterprise/5-13-x/topics/install_oozie_ext_db.html#admin_oozie_ext_db 如果配置 Oozie 的时候需要JDBC,那么建立软链: ln -s /usr/share/java/mysql-connector-java.jar /opt/cloudera/parcels/CDH/lib/oozie/lib/mysql-connector-java.jar 停止或者删除不需要的服务,并根据 Cloudera Manager 的建议,修复一些其他问题。 第五步:验证安装是否成功: 登录到 master 结点,以 hive 用户连接到 HiveServer2 : beeline -u "jdbc:hive2://localhost:10000/default" -n hive 创建一张叫 table_name 的 ORC 事务表: CREATE TABLE table_name (id int, name string) CLUSTERED BY (id) INTO 2 BUCKETS STORED AS ORC TBLPROPERTIES ("transactional"="true", "compactor.mapreduce.map.memory.mb"="2048", "compactorthreshold.hive.compactor.delta.num.threshold"="4", "compactorthreshold.hive.compactor.delta.pct.threshold"="0.5" ); 插入一条记录并读取: insert into table_name(id, name) values('1', 'Alex'); select * from table_name; 验证 Hive-on-Spark 是否正常: set hive.execution.engine=spark; select count(*) from table_name; 如果输出的结果为1, 那么表明安装正常。 到此为止,我们已经成功在ECS上搭建起了一套大数据系统。

优秀的个人博客,低调大师

Hadoop MapReduce概念学习系列之map并发任务数和reduce并发任务数的原理和代码实现(十八)

首先,来说的是,reduce并发任务数,默认是1。 即,在jps后,出现一个yarnchild。之后又消失。 这里,我控制reduce并发任务数6。 有多少个reduce的并发任务数可以在程序里控制,但有多少个map的并发任务数还没。 其实啊,有多少个map的并发任务数还没(是在分片中控制的)。 1、现在,我们控制为map的并发任务数为4。(即是在分片中控制) 2、 jps -> 生成个Runjar -> 3、jps -> 生成个Runjar -> 生成个MRAppMaster(运行map任务) soga 4、 jps -> 生成个Runjar -> 生成个MRAppMaster(运行map任务) -> 查看map并发任务数 -> 5、jps -> 生成个Runjar -> 生成个MRAppMaster(运行map任务) -> 查看map并发任务数 -> Map的Task进程被回收 ->查看reduce并发任务数 -> Reduce的Task进程被回收 –> jps 以上是单独控制了Mapreduce的map并发任务数和reduce并发任务数。 总结 前者Mapreduce的map并发任务数默认是1,控制reduce并发任务数为6。 后者控制map并发任务数为4,Mapreduce的reduce并发任务数默认是1。 综合即控制map,又控制reduce,不再赘述。 本文转自大数据躺过的坑博客园博客,原文链接:http://www.cnblogs.com/zlslch/p/5713652.html,如需转载请自行联系原作者

优秀的个人博客,低调大师

大数据框架对比:Hadoop、Storm、Samza、Spark和Flink--容错机制(ACK,RDD,基于log和状态快照),消息处理a...

分布式流处理是对无边界数据集进行连续不断的处理、聚合和分析。它跟MapReduce一样是一种通用计算,但我们期望延迟在毫秒或者秒级别。这类系统一般采用有向无环图(DAG)。 DAG是任务链的图形化表示,我们用它来描述流处理作业的拓扑。如下图,数据从sources流经处理任务链到sinks。单机可以运行DAG,但本篇文章主要聚焦在多台机器上运行DAG的情况。 关注点 当选择不同的流处理系统时,有以下几点需要注意的: 运行时和编程模型:平台框架提供的编程模型决定了许多特色功能,编程模型要足够处理各种应用场景。这是一个相当重要的点,后续会继续。 函数式原语:流处理平台应该能提供丰富的功能函数,比如,map或者filter这类易扩展、处理单条信息的函数;处理多条信息的函数aggregation;跨数据流、不易扩展的操作join。 状态管理:大部分应用都需要保持状态处理的逻辑。流处理平台应该提供存储、访问和更新状态信息。 消息传输保障:消息传输保障一般有三种:at most once,at least once和exactly once。At most once的消息传输机制是每条消息传输零次或者一次,即消息可能会丢失;A t least once意味着每条消息会进行多次传输尝试,至少一次成功,即消息传输可能重复但不会丢失;Exactly once的消息传输机制是每条消息有且只有一次,即消息传输既不会丢失也不会重复。 容错:流处理框架中的失败会发生在各个层次,比如,网络部分,磁盘崩溃或者节点宕机等。流处理框架应该具备从所有这种失败中恢复,并从上一个成功的状态(无脏数据)重新消费。 性能:延迟时间(Latency),吞吐量(Throughput)和扩展性(Scalability)是流处理应用中极其重要的指标。 平台的成熟度和接受度:成熟的流处理框架可以提供潜在的支持,可用的库,甚至开发问答帮助。选择正确的平台会在这方面提供很大的帮助。 运行时和编程模型 运行时和编程模型是一个系统最重要的特质,因为它们定义了表达方式、可能的操作和将来的局限性。因此,运行时和编程模型决定了系统的能力和适用场景。 实现流处理系统有两种完全不同的方式:一种是称作原生流处理,意味着所有输入的记录一旦到达即会一个接着一个进行处理。 第二种称为微批处理。把输入的数据按照某种预先定义的时间间隔(典型的是几秒钟)分成短小的批量数据,流经流处理系统。 两种方法都有其先天的优势和不足。首先以原生流处理开始,原生流处理的优势在于它的表达方式。数据一旦到达立即处理,这些系统的延迟性远比其它微批处理要好。除了延迟性外,原生流处理的状态操作也容易实现,后续将详细讲解。 一般原生流处理系统为了达到低延迟和容错性会花费比较大的成本,因为它需要考虑每条记录。原生流处理的负载均衡也是个问题。比如,我们处理的数据按key分区,如果分区的某个key是资源密集型,那这个分区很容易成为作业的瓶颈。 接下来看下微批处理。将流式计算分解成一系列短小的批处理作业,也不可避免的减弱系统的表达力。像状态管理或者join等操作的实现会变的困难,因为微批处理系统必须操作整个批量数据。并且,batch interval会连接两个不易连接的事情:基础属性和业务逻辑。 相反地,微批处理系统的容错性和负载均衡实现起来非常简单,因为微批处理系统仅发送每批数据到一个worker节点上,如果一些数据出错那就使用其它副本。微批处理系统很容易建立在原生流处理系统之上。 编程模型一般分为组合式和声明式。组合式编程提供基本的构建模块,它们必须紧密结合来创建拓扑。新的组件经常以接口的方式完成。相对应地,声明式API操作是定义的高阶函数。它允许我们用抽象类型和方法来写函数代码,并且系统创建拓扑和优化拓扑。声明式API经常也提供更多高级的操作(比如,窗口函数或者状态管理)。后面很快会给出样例代码。 主流流处理系统 有一系列各种实现的流处理框架,不能一一列举,这里仅选出主流的流处理解决方案,并且支持Scala API。因此,我们将详细介绍Apache Storm,Trident,Spark Streaming,Samza和Apache Flink。前面选择讲述的虽然都是流处理系统,但它们实现的方法包含了各种不同的挑战。这里暂时不讲商业的系统,比如Google MillWheel或者Amazon Kinesis,也不会涉及很少使用的Intel GearPump或者Apache Apex。 Apache Storm最开始是由Nathan Marz和他的团队于2010年在数据分析公司BackType开发的,后来BackType公司被Twitter收购,接着Twitter开源Storm并在2014年成为Apache顶级项目。毋庸置疑,Storm成为大规模流数据处理的先锋,并逐渐成为工业标准。Storm是原生的流处理系统,提供low-level的API。Storm使用Thrift来定义topology和支持多语言协议,使得我们可以使用大部分编程语言开发,Scala自然包括在内。 Trident是对Storm的一个更高层次的抽象,Trident最大的特点以batch的形式进行流处理。Trident简化topology构建过程,增加了窗口操作、聚合操作或者状态管理等高级操作,这些在Storm中并不支持。相对应于Storm的At most once流传输机制,Trident提供了Exactly once传输机制。Trident支持Java,Clojure和Scala。 当前Spark是非常受欢迎的批处理框架,包含Spark SQL,MLlib和Spark Streaming。Spark的运行时是建立在批处理之上,因此后续加入的Spark Streaming也依赖于批处理,实现了微批处理。接收器把输入数据流分成短小批处理,并以类似Spark作业的方式处理微批处理。Spark Streaming提供高级声明式API(支持Scala,Java和Python)。 Samza最开始是专为LinkedIn公司开发的流处理解决方案,并和LinkedIn的Kafka一起贡献给社区,现已成为基础设施的关键部分。Samza的构建严重依赖于基于log的Kafka,两者紧密耦合。Samza提供组合式API,当然也支持Scala。 最后来介绍Apache Flink。Flink是个相当早的项目,开始于2008年,但只在最近才得到注意。Flink是原生的流处理系统,提供high level的API。Flink也提供API来像Spark一样进行批处理,但两者处理的基础是完全不同的。Flink把批处理当作流处理中的一种特殊情况。在Flink中,所有的数据都看作流,是一种很好的抽象,因为这更接近于现实世界。 快速的介绍流处理系统之后,让我们以下面的表格来更好清晰的展示它们之间的不同: Word Count Wordcount之于流处理框架学习,就好比hello world之于编程语言学习。它能很好的展示各流处理框架的不同之处,让我们从Storm开始看看如何实现Wordcount: 首先,定义topology。第二行代码定义一个spout,作为数据源。然后是一个处理组件bolt,分割文本为单词。接着,定义另一个bolt来计算单词数(第四行代码)。也可以看到魔数5,8和12,这些是并行度,定义集群每个组件执行的独立线程数。第八行到十五行是实际的WordCount bolt实现。因为Storm不支持内建的状态管理,所有这里定义了一个局部状态。 按之前描述,Trident是对Storm的一个更高层次的抽象,Trident最大的特点以batch的形式进行流处理。除了其它优势,Trident提供了状态管理,这对wordcount实现非常有用。 如你所见,上面代码使用higher level操作,比如each(第七行代码)和groupby(第八行代码)。并且使用Trident管理状态来存储单词数(第九行代码)。 下面是时候祭出提供声明式API的Apache Spark。记住,相对于前面的例子,这些代码相当简单,几乎没有冗余代码。下面是简单的流式计算单词数: 每个Spark Streaming的作业都要有StreamingContext,它是流式函数的入口。StreamingContext加载第一行代码定义的配置conf,但更重要地,第二行代码定义batch interval(这里设置为1秒)。第六行到八行代码是整个单词数计算。这些是标准的函数式代码,Spark定义topology并且分布式执行。第十二行代码是每个Spark Streaming作业最后的部分:启动计算。记住,Spark Streaming作业一旦启动即不可修改。接下来看下Apache Samza,另外一个组合式API例子: Samza的属性配置文件定义topology,为了简明这里并没把配置文件放上来。定义任务的输入和输出,并通过Kafka topic通信。在单词数计算整个topology是WordCountTask。在Samza中,实现特殊接口定义组件StreamTask,在第三行代码重写方法process。它的参数列表包含所有连接其它系统的需要。第八行到十行简单的Scala代码是计算本身。Flink的API跟Spark Streaming是惊人的相似,但注意到代码里并未设置batch interval。 上面的代码是相当的直白,仅仅只是几个函数式调用,Flink支持分布式计算。 结论 上面给出了基本的理论和主流流处理框架介绍,下篇文章将会更深入的探讨其它关注点。希望你能对前面的文章感兴趣。 同系列文章之Storm,Trident,Spark Streaming,Samza和Flink主流流处理框架比较 | 下 在上篇文章中,我们过了下基本的理论,也介绍了主流的流处理框架:Storm,Trident,Spark Streaming,Samza和Flink。今天咱们来点有深度的topic,比如,容错,状态管理或者性能。除此之外,我们也将讨论开发分布式流处理应用的指南,并给出推荐的流处理框架。 容错性流处理系统的容错性与生俱来的比批处理系统难实现。当批处理系统中出现错误时,我们只需要把失败的部分简单重启即可;但对于流处理系统,出现错误就很难恢复。因为线上许多作业都是7 x 24小时运行,不断有输入的数据。流处理系统面临的另外一个挑战是状态一致性,因为重启后会出现重复数据,并且不是所有的状态操作是幂等的。容错性这么难实现,那下面我们看看各大主流流处理框架是如何处理这一问题。 Apache Storm:Storm使用上游数据备份和消息确认的机制来保障消息在失败之后会重新处理。消息确认原理:每个操作都会把前一次的操作处理消息的确认信息返回。 Topology的数据源备份它生成的所有数据记录。当所有数据记录的处理确认信息收到,备份即会被安全拆除。失败后,如果不是所有的消息处理确认信息收到,那数据记录会被数据源数据替换。这保障了没有数据丢失,但数据结果会有重复,这就是at-least once传输机制。 Storm采用取巧的办法完成了容错性,对每个源数据记录仅仅要求几个字节存储空间来跟踪确认消息。纯数据记录消息确认架构,尽管性能不错,但不能保证exactly once消息传输机制,所有应用开发者需要处理重复数据。Storm存在低吞吐量和流控问题,因为消息确认机制在反压下经常误认为失败。 Spark Streaming:Spark Streaming实现微批处理,容错机制的实现跟Storm不一样的方法。微批处理的想法相当简单。Spark在集群各worker节点上处理micro-batches。每个micro-batches一旦失败,重新计算就行。因为micro-batches本身的不可变性,并且每个micro-batches也会持久化,所以exactly once传输机制很容易实现。 Samza:Samza的实现方法跟前面两种流处理框架完全不一样。Samza利用消息系统Kafka的持久化和偏移量。Samza监控任务的偏移量,当任务处理完消息,相应的偏移量被移除。消息的偏移量会被checkpoint到持久化存储中,并在失败时恢复。但是问题在于:从上次checkpoint中修复偏移量时并不知道上游消息已经被处理过,这就会造成重复。这就是at least once传输机制。 Apache Flink:Flink的容错机制是基于分布式快照实现的,这些快照会保存流处理作业的状态(本文对Flink的检查点和快照不进行区分,因为两者实际是同一个事物的两种不同叫法。Flink构建这些快照的机制可以被描述成分布式数据流的轻量级异步快照,它采用Chandy-Lamport算法实现。)。 如果发生失败的情况,系统可以从这些检查点进行恢复。Flink发送checkpoint的栅栏(barrier)到数据流中(栅栏是Flink的分布式快照机制中一个核心的元素),当checkpoint的栅栏到达其中一个operator,operator会接所有收输入流中对应的栅栏(比如,图中checkpoint n对应栅栏n到n-1的所有输入流,其仅仅是整个输入流的一部分)。 所以相对于Storm,Flink的容错机制更高效,因为Flink的操作是对小批量数据而不是每条数据记录。但也不要让自己糊涂了,Flink仍然是原生流处理框架,它与Spark Streaming在概念上就完全不同。Flink也提供exactly once消息传输机制。 状态管理大部分大型流处理应用都涉及到状态。相对于无状态的操作(其只有一个输入数据,处理过程和输出结果),有状态的应用会有一个输入数据和一个状态信息,然后处理过程,接着输出结果和修改状态信息。因此,我们不得不管理状态信息,并持久化。我们期望一旦因某种原因失败,状态能够修复。状态修复有可能会出现小问题,它并不总是保证exactly once,有时也会出现消费多次,但这并不是我们想要的。 据我们所知,Storm提供at-least once的消息传输保障。那我们又该如何使用Trident做到exactly once的语义。概念上貌似挺简单,你只需要提交每条数据记录,但这显然不是那么高效。所以你会想到小批量的数据记录一起提交会优化。Trident定义了几个抽象来达到exactly once的语义,见下图,其中也会有些局限。 Spark Streaming是微批处理系统,它把状态信息也看做是一种微批量数据流。在处理每个微批量数据时,Spark加载当前的状态信息,接着通过函数操作获得处理后的微批量数据结果并修改加载过的状态信息。 1Samza实现状态管理是通过Kafka来处理的。Samza有真实的状态操作,所以其任务会持有一个状态信息,并把状态改变的日志推送到Kafka。如果需要状态重建,可以很容易的从Kafka的topic重建。为了达到更快的状态管理,Samza也支持把状态信息放入本地key-value存储中,所以状态信息不必一直在Kafka中管理,见下图。不幸的是,Samza只提供at-least once语义,exactly once的支持也在计划中。 Flink提供状态操作,和Samza类似。Flink提供两种类型的状态:一种是用户自定义状态;另外一种是窗口状态。如图,第一个状态是自定义状态,它和其它的的状态不相互作用。这些状态可以分区或者使用嵌入式Key-Value存储状态[文档一和二]。当然Flink提供exactly-once语义。下图展示Flink长期运行的三个状态。 单词计数例子中的状态管理单词计数的详细代码见上篇文章,这里仅关注状态管理部分。让我们先看Trident: 在第九行代码中,我们通过调用persistentAggregate创建一个状态。其中参数Count存储单词数,如果你想从状态中处理数据,你必须创建一个数据流。从代码中也可以看出实现起来不方便。Spark Streaming声明式的方法稍微好点: 首先我们需要创建一个RDD来初始化状态(第二行代码),然后进行transformations(第五行和六行代码)。接着在第八行到十四行代码,我们定义函数来处理单词数状态。函数计算并更新状态,最后返回结果。第十六行和十七行代码,我们得到一个状态信息流,其中包含单词数。接着我们看下Samza, 首先在第三行代码定义状态,进行Key-Value存储,在第五行到八行代码初始化状态。接着在计算中使用,上面的代码已经很直白。最后,讲下Flink使用简洁的API实现状态管理: 我们仅仅需要在第六行代码中调用mapwithstate函数,它有一个函数参数(函数有两个变量,第一个是单词,第二个是状态。然后返回处理的结果和新的状态)。流处理框架性能这里所讲的性能主要涉及到的是延迟性和吞吐量。对于延迟性来说,微批处理一般在秒级别,大部分原生流处理在百毫秒以下,调优的情况下Storm可以很轻松的达到十毫秒。 同时也要记住,消息传输机制保障,容错性和状态恢复都会占用机器资源。例如,打开容错恢复可能会降低10%到15%的性能,Storm可能降低70%的吞吐量。 总之,天下没有免费的午餐。对于有状态管理,Flink会降低25%的性能,Spark Streaming降低50%的性能。也要记住,各大流处理框架的所有操作都是分布式的,通过网络发送数据是相当耗时的,所以进了利用数据本地性,也尽量优化你的应用的序列化。项目成熟度 当你为应用选型时一定会考虑项目的成熟度。下面来快速浏览一下: Storm是第一个主流的流处理框架,后期已经成为长期的工业级的标准,并在像Twitter,Yahoo,Spotify等大公司使用。Spark Streaming是最近最流行的Scala代码实现的流处理框架。现在Spark Streaming被公司(Netflix, Cisco, DataStax, Intel, IBM等)日渐接受。Samza主要在LinkedIn公司使用。Flink是一个新兴的项目,很有前景。 你可能对项目的贡献者数量也感兴趣。Storm和Trident大概有180个代码贡献者;整个Spark有720多个;根据github显示,Samza有40个;Flink有超过130个代码贡献者。小结在进行流处理框架推荐之前,先来整体看下总结表: 流处理框架推荐应用选型是大家都会遇到的问题,一般是根据应用具体的场景来选择特定的流处理框架。下面给出几个作者认为优先考虑的点: High level API:具有high level API的流处理框架会更简洁和高效; 状态管理:大部分流处理应用都涉及到状态管理,因此你得把状态管理作为评价指标之一; exactly once语义:exactly once会使得应用开发变得简单,但也要看具体需求,可能at least once 或者at most once语义就满足你得要求; 自动恢复:确保流处理系统能够快速恢复,你可以使用Chaos Monkey或者类似的工具进行测试。快速的恢复是流处理重要的部分。 Storm:Storm非常适合任务量小但速度要求高的应用。如果你主要在意流处理框架的延迟性,Storm将可能是你的首先。但同时也要记住,Storm的容错恢复或者Trident的状态管理都会降低整体的性能水平。也有一个潜在的Storm更新项目-Twitter的Heron,Heron设计的初衷是为了替代Storm,并在每个单任务上做了优化但同时保留了API。 Spark Streaming:如果你得基础架构中已经设计到Spark,那Spark Streaming无疑是值得你尝试的。因为你可以很好的利用Spark各种library。如果你需要使用Lambda架构,Spark Streaming也是一个不错的选择。但你要时刻记住微批处理的局限性,以及它的延迟性问题。 Samza:如果你想使用Samza,那Kafka应该是你基础架构中的基石,好在现在Kafka已经成为家喻户晓的组件。像前面提到的,Samza一般会搭配强大的本地存储一起,这对管理大数据量的状态非常有益。它可以轻松处理上万千兆字节的状态信息,但要记住Samza只支持at least once语义。 Flink:Flink流处理系统的概念非常不错,并且满足绝大多数流处理场景,也经常提供前沿的功能函数,比如,高级窗口函数或者时间处理功能,这些在其它流处理框架中是没有的。同时Flink也有API提供给通用的批处理场景。但你需要足够的勇气去上线一个新兴的项目,并且你也不能忘了看下Flink的roadmap。 Dataflow和开源 最后,我们来聊下Dataflow和它的开源。Dataflow是Google云平台的一部分,Google云平台包含很多组件:大数据存储,BigQuery,Cloud PubSub,数据分析工具和前面提到的Dataflow。 Dataflow是Google管理批处理和流处理的统一API。它是建立在MapReduce(批处理),FlumeJava(编程模型)和MillWheel(流处理)之上。Google最近决定开源Dataflow SDK,并完成Spark和Flink的runner。现在可以通过Dataflow的API来定义Google云平台作业、Flink作业或者Spark作业,后续会增加对其它引擎的支持。 Google为Dataflow提供Java、Python的API,社区已经完成Scalable的DSL支持。除此之外,Google及其合作者提交Apache Beam到Apache。 结论本系列文章粗略的讲述各大流行的流处理框架,并讨论了它们的相似性、区别、折衷权衡和使用的场景。希望这些将会给你设计流处理方案有帮助。 同系列文章之Storm,Trident,Spark Streaming,Samza和Flink主流流处理框架比较 | 上 转自:http://www.36dsj.com/archives/71734 本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/6360644.html,如需转载请自行联系原作者

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册