当前位置: 首页 > 知识库问答 >
问题:

单个配置单元应用程序(作业)是否产生多个纱线应用程序?

郑博厚
2023-03-14

提交给Yarn的单个配置单元查询是否会创建多个作业(即多个Yarn应用程序)?在这里,我把工作和应用放在纱线的语境中思考是一样的。

根据我的理解--Yarn为“Application”创建一个应用程序主程序(AM)。因此在这里可以将单个配置单元查询视为“应用程序”。因此,资源管理器将在某个节点上创建容器,并在该容器中启动AM。该容器反过来可以创建多个“任务”(而不是应用程序),即为该AM保留的其他容器内的映射器和还原器(在相同或不同的节点上--这在这里并不重要)。现在,所有这些应用程序主程序的集合都在解决提交给Yarn的单个配置单元查询。事实上,这就是为什么我们说AM是每个应用程序。由于我们只提交了一个配置单元查询,因此从YARN的观点来看,只有一个应用程序。因此,当我启动下面的YARN命令时,它应该只显示一个正在运行的应用程序:-

yarn application -list

这样的认识正确吗?或者,如果我们为一个配置单元查询生成了多个映射器和还原器,则会调用多个YARN应用程序?

共有1个答案

金旺
2023-03-14

你一开始是对的:

  • 由MapReduce创建的纱应用程序称为作业。所以application=job。正确。
  • 每个作业有一个AM。正确。

从那以后,你说的就有点混淆了。html" target="_blank">配置单元查询不是应用程序。配置单元查询由配置单元转换为链接的MapReduce作业。因此,当您执行一个复杂的Hive查询时,Hive将提交必要的MapReduce作业(它们是YARN应用程序),依次运行以获得您的最终结果。

例如,让我们采取以下SQL查询:

SELECT SUM(total) as sumtotal, city
FROM donations
GROUP BY city
ORDER BY sumtotal;

如果要用MapReduce手动解决这个问题,需要创建2个作业:

  • 作业1-聚合:将输入映射到(city,total)对并reduce获得每个城市的和值
  • 作业2-排序:将作业1的结果映射到反向对(总计,城市),并让shuffle/reduce对它们进行排序

详细的解释和说明如何解决这与乔布斯先生在这里。

如果在配置单元中运行该查询,则输出如下所示:

INFO  : number of splits:3
INFO  : Submitting tokens for job: job_1454508485700_0039
INFO  : The url to track the job: http://ubuntu0:8088/proxy/application_1454508485700_0039/
INFO  : Starting Job = job_1454508485700_0039, Tracking URL = http://ubuntu0:8088/proxy/application_1454508485700_0039/
INFO  : Kill Command = /home/hduser/hadoop/bin/hadoop job  -kill job_1454508485700_0039
INFO  : Hadoop job information for Stage-1: number of mappers: 3; number of reducers: 3
INFO  : 2016-02-10 22:21:15,773 Stage-1 map = 0%,  reduce = 0%
INFO  : 2016-02-10 22:22:08,421 Stage-1 map = 11%,  reduce = 0%, Cumulative CPU 99.2 sec
INFO  : 2016-02-10 22:22:17,019 Stage-1 map = 44%,  reduce = 0%, Cumulative CPU 127.32 sec
INFO  : 2016-02-10 22:22:20,694 Stage-1 map = 67%,  reduce = 0%, Cumulative CPU 134.32 sec
INFO  : 2016-02-10 22:22:21,906 Stage-1 map = 78%,  reduce = 0%, Cumulative CPU 135.2 sec
INFO  : 2016-02-10 22:22:32,877 Stage-1 map = 89%,  reduce = 0%, Cumulative CPU 147.49 sec
INFO  : 2016-02-10 22:22:35,379 Stage-1 map = 100%,  reduce = 0%, Cumulative CPU 149.85 sec
INFO  : 2016-02-10 22:22:39,108 Stage-1 map = 100%,  reduce = 44%, Cumulative CPU 160.65 sec
INFO  : 2016-02-10 22:22:41,578 Stage-1 map = 100%,  reduce = 56%, Cumulative CPU 170.0 sec
INFO  : 2016-02-10 22:22:42,792 Stage-1 map = 100%,  reduce = 60%, Cumulative CPU 171.87 sec
INFO  : 2016-02-10 22:22:44,022 Stage-1 map = 100%,  reduce = 89%, Cumulative CPU 183.23 sec
INFO  : 2016-02-10 22:22:46,540 Stage-1 map = 100%,  reduce = 100%, Cumulative CPU 183.23 sec
INFO  : Ended Job = job_1454508485700_0039
INFO  : number of splits:2
INFO  : Submitting tokens for job: job_1454508485700_0040
INFO  : The url to track the job: http://ubuntu0:8088/proxy/application_1454508485700_0040/
INFO  : Starting Job = job_1454508485700_0040, Tracking URL = http://ubuntu0:8088/proxy/application_1454508485700_0040/
INFO  : Kill Command = /home/hduser/hadoop/bin/hadoop job  -kill job_1454508485700_0040
INFO  : Hadoop job information for Stage-2: number of mappers: 2; number of reducers: 1
INFO  : 2016-02-10 22:23:16,180 Stage-2 map = 0%,  reduce = 0%
INFO  : 2016-02-10 22:23:46,453 Stage-2 map = 50%,  reduce = 0%, Cumulative CPU 13.39 sec
INFO  : 2016-02-10 22:23:47,715 Stage-2 map = 67%,  reduce = 0%, Cumulative CPU 14.73 sec
INFO  : 2016-02-10 22:23:48,945 Stage-2 map = 100%,  reduce = 0%, Cumulative CPU 17.38 sec
INFO  : 2016-02-10 22:24:10,960 Stage-2 map = 100%,  reduce = 71%, Cumulative CPU 25.33 sec
INFO  : 2016-02-10 22:24:13,383 Stage-2 map = 100%,  reduce = 98%, Cumulative CPU 31.32 sec
INFO  : 2016-02-10 22:24:14,616 Stage-2 map = 100%,  reduce = 100%, Cumulative CPU 32.61 sec
INFO  : MapReduce Total cumulative CPU time: 32 seconds 610 msec
INFO  : Ended Job = job_1454508485700_0040
INFO  : Moving data to: /user/hduser/donors/hive_output_part2 from hdfs://ubuntu0:9000/user/hive/warehouse/.hive-staging_hive_2016-02-10_22-20-50_281_4971139345555329337-4/-ext-10001
INFO  : Table default.hive_output_part2 stats: [numFiles=0, numRows=14966, totalSize=0, rawDataSize=321343]
No rows affected (207.86 seconds)

您可以看到Hive也创建了两个作业,一个接着一个。您可以看到两次记录的“启动作业”,以及两次生成的新作业URL。

 类似资料:
  • 问题内容: 对于那些在生产环境中运行Go后端的人: 运行Go Web应用程序的堆栈/配置是什么? 除了人们使用标准库net / http包来保持服务器运行之外,在该主题上我还没有看到太多内容。我阅读了使用Nginx将请求传递到Go服务器的信息- 使用Go的 Nginx 在我看来,这有点脆弱。例如,如果重新启动计算机(没有其他配置脚本),服务器将不会自动重新启动。 是否有更可靠的生产设置? 除了我的

  • 下面是如何通过配置单元jdbc运行查询的 我可以在yarn UI中看到应用程序的详细信息。但是现在我想通过java代码获取这个工作的应用程序id,有没有可能这样做呢?如果是,那又是怎样做的呢?

  • 问题内容: 如果我有一个Java项目,其中包含几种不同类型的文件(图片,声音等)和多个jar依赖项,那么将它们打包到一个可以双击的jar中的好方法是什么? 我知道jar本身很笨,因为它们不会在内部查找它们所依赖的文件(这是我在稍有沮丧(轻描淡写)后才意识到的)。-如果jar A取决于jar B中包含的类,则将jar B放入jar A中将不起作用。Jar A必须与jar B在同一目录中。 …现在,我

  • 问题内容: 我正在处理一个系统,该系统在其自己的JVM中为每个客户运行Java应用程序。现在,我们有大约六个专用服务器,它们总共运行近100个JVM,以及用于管理这些JVM的自定义脚本集。此设置实际上已经表明了它的年龄:管理许多JVM已成为监视/管理的噩梦,并且我们一直在处理堆大小调整问题。我们想采用一种更现代的方法,并在每台物理计算机的单个应用服务器中运行一堆应用程序。但是,将应用程序保持隔离确

  • 我的应用程序有多个线程将消息发布到单个RabbitMQ集群。 阅读rabbit文档:我阅读了以下内容: 对于使用多个线程/进程进行处理的应用程序,每一个线程/进程打开一个新通道,并且不在它们之间共享通道是非常常见的。 而且我明白,与其开通多个连接(昂贵) 不如开通多个通道。 但是为什么不对所有线程使用单个通道呢? 在单个通道上使用多个通道有什么好处?

  • 想改进这个问题吗 通过编辑这篇文章,更新问题,以便用事实和引文来回答。 我有一个网站,由大约20个Java Web应用程序(基于Servlet/JSP的Web应用程序)组成,大小不一,每个应用程序处理网站的不同区域。 所有20个war的总大小为350mb,然而,通过将它们结合起来,我预计最终能够减少这一大小,并实现组合缓存的好处。 最好将它们分开,还是将它们合并到一个Uber webapp war