大数据平台 CDP 中如何配置 hive 作业的 YARN 队列以确保SLA?

简介: 大数据平台 CDP 中如何配置 hive 作业的 YARN 队列以确保SLA?

大数据平台 CDP 中如何配置 hive 作业的 YARN 队列以确保SLA?

大家知道,在生产环境的大数据集群中,在向资源管理器YARN提交作业时,我们一般会将作业提交到管理员指定的队列去执行,以利用 YARN 队列的资源隔离性确保作业能够获得足够的资源进行执行,从而确保SLA。

1 CDH 中如何指定 HIVE 作业执行时的 YARN 队列?

在以往的的大数据平台 CDH中:

  • YARN 默认使用的资源调度器是公平调度器 org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler;
  • HIVE 作业一般也是使用 hive on mr或hive on spark 执行引擎;
  • 处于安全考量,一般推荐HIVE使用kerberos认证和sentry授权,此时要求关闭hive 代理功能,即hive.server2.enable.doAs=false;

此时为确保不同业务用户的 HIVE 作业提交到不同的 YARN 队列中,一般有两种选择:

  • 在提交作业前手动指定队列,一般是通过 set mapreduce.job.queuename/mapred.job.queue.name/mapred.job.queuename = xxx 手工指定;(mapreduce.job.queuename is the new parameter name; mapred.job.queuename is changed to mapred.job.queue.name in hive-3.0.0 by HIVE-17584, and picked up by cdh in 2.1.1-cdh6.3.2)
  • 在 CDH 服务端"动态资源池配置"中配置"放置规则",指定使用基于用户名匹配到的指定队列(一般是 root.users.[username]);

640.png


比如某业务用户dap提交的 hive 作业,在没有手动指定队列时,其使用的队列是 root.users.dap,达到了资源隔离的目的:(此时 HIVE 使用 kerberos 认证和 sentry 授权,关闭了 hive 代理功能,即 hive.server2.enable.doAs=false):

640.png


2 CDP 中默认配置下 HIVE 作业执行时的 YARN 队列?

在大数据平台 CDP 中:

  • YARN 默认使用的资源调度器是容量调度器 org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler;
  • HIVE 作业使用 hive on tez 执行引擎,不再支持 hive on mr/spark;
  • 处于安全考量,一般推荐HIVE使用kerberos认证和ranger授权(cdp不再支持sentry),并要求关闭hive 代理功能,即hive.server2.enable.doAs=false;

此时在没有手动指定队列时,所有 HIVE 作业执行时的 YARN 队列,是 default 或 root.users.hive,并不能达到资源隔离的目的:

640.png


此时有以下几点需要注意:

  • 当没有配置放置规则时,hive作业使用的是default 队列;
  • 当如下配置放置规则时,hive作业使用的是root.users.hive;

640.png


  • 此时CDP中一些相关的参数的默认值如下:

640.png


那么如何达到不同业务用户的 HIVE 作业提交到不同的 YARN 队列,以达到资源隔离的目的呢?请继续看。

3 CDP 中如何手动指定 HIVE 作业执行时的 YARN 队列?

CDP中要达到不同业务用户的 HIVE 作业提交到不同的 YARN 队列,以达到资源隔离的目的,一种方法是手动指定YARN 队列。

由于CDP使用的是容量调度器而不是公平调度器,且只支持HIVE ON TEZ 而不是 hive on mr/spark,所以指定方式略有不同:

  • 手动指定队列名时,由于hive on tez 背后有 tez session pool 和 tez default sessions 的概念,其指定方式略有不同,推荐使用参数 tez.queue.name 而不是 mapreduce.job.queuename/mapred.job.queue.name 指定队列名;
  • 可以登录时指定队列名:比如 beeline -u "jdbc:hive2://cdp3:10000/hs_ods;principal=hive/_HOST@HUNDSUN.COM;" --hiveconf tez.queue.name=root.dap2 或者 beeline -u "jdbc:hive2://cdp3:10000/hs_ods;principal=hive/_HOST@HUNDSUN.COM?tez.queue.name=root.dap2";
  • 可以登录后提交SQL前指定队列名,比如 set tez.queue.name=root.users.dap;
  • 为确保客户端手动指定的YARN 队列不会被覆盖,需要确保 CDP 服务端容量调度器的参数 yarn.scheduler.capacity.queue-mappings-override.enable 为 false,该参数默认值即为 false;

640.png


不过很多管理员倾向于将参数 yarn.scheduler.capacity.queue-mappings-override.enable 改为 true,以禁止用户在客户端随意指定队列,所以此时用户通过 set tez.queue.name=root.users.dap 手动指定的队列,会被服务端的队列放置规则等配置覆盖:

640.png


#用户在客户端指定的yarn 队列,会被服务端的放置规则覆盖,YARN RM 相关日志:
2022-09-21 09:39:01,306 INFO org.apache.hadoop.yarn.server.resourcemanager.RMAppManager: Placed application with ID application_1663663279733_0012 in queue: dap, original submission queue was: root.dap2
#用户在客户端指定的yarn 队列,会被服务端的放置规则覆盖,yarn 相关源码
org.apache.hadoop.yarn.server.resourcemanager.RMAppManager#copyPlacementQueueToSubmissionContext:
  private void copyPlacementQueueToSubmissionContext(
      ApplicationPlacementContext placementContext,
      ApplicationSubmissionContext context) {
    // Set the queue from the placement in the ApplicationSubmissionContext
    // Placement rule are only considered for new applications
    if (placementContext != null && !StringUtils.equalsIgnoreCase(
        context.getQueue(), placementContext.getQueue())) {
      LOG.info("Placed application with ID " + context.getApplicationId() +
          " in queue: " + placementContext.getQueue() +
          ", original submission queue was: " + context.getQueue());
      context.setQueue(placementContext.getQueue());
    }
  }
# 参数 yarn.scheduler.capacity.queue-mappings-override.enable 改为 true说明:
This function is used to specify whether the user specified queues can be overridden, this is a Boolean value and the default value is false.
If a queue mapping is present, will it override the value specified by the user? This can be used by administrators to place jobs in queues that are different than the one specified by the user.

4 CDP 中应如何配置服务端的队列放置规则,以达到不同业务用户的 HIVE 作业提交到不同的 YARN 队列?

CDP 中应如何配置服务端的队列放置规则,以达到不同业务用户的 HIVE 作业提交到不同的 YARN 队列,从而达到资源隔离的目的呢?CDP官方有如下建议:

640.png


  • 按照官方建议,修改 cdp yarn 服务端的配置,打开 yarn 基于标签的调度策略并允许 hive 用户使用基于标签的调度策略:

640.png


  • 按照官方建议,修改 cdp hive on tez 服务端的配置,关闭 tez default sessions, 允许 tez session 使用指定的yarn队列:

640.png


640.png

  • 通过 cdp 的 yarn queue manager ui 配置容调度器的放置规则 placement rules:

640.png


  • 通过 cdp 的 yarn queue manager ui,打开参数 yarn.scheduler.capacity.queue-mappings-override.enable,以覆盖用户在客户端手动指定的队列,从而禁止用户在客户端随意指定队列(该参数是否开启,视乎管理员对集群的管理规范):

640.png


再次提交作业,可以发现业务用户dap的作业提交到了rootusers.dap,达到了资源隔离的目的:

640.png


5 知识总结

  • CDP 中默认使用容量调度器,CDH 默认使用公平调度器;
  • CDP 和 CDH 都推荐不启用代理(hive.server2.enable.doAS=FALSE;
  • CDP 中默认情况下,所有 HIVE 作业执行时的 YARN 队列都是 default 或 root.users.hive,并不能达到资源隔离的目的;
  • CDP 中为达到不同业务用户的 HIVE 作业提交到不同的 YARN 队列从而达到资源隔离的目的,用户可以在客户端通过参数 tez.queue.name 手动指定队列;
  • 为确保用户在客户端通过参数 tez.queue.name 手动指定的队列,不被服务端公平调度器的放置规则覆盖,需要确保参数 yarn.scheduler.capacity.queue-mappings-override.enable为false;
  • CDP 中为达到不同业务用户的 HIVE 作业提交到不同的 YARN 队列从而达到资源隔离的目的,推荐管理员修改 cdp yarn 服务端的配置以打开 yarn 基于标签的调度策略并允许 hive 用户使用基于标签的调度策略,并修改 cdp hive on tez 服务端的配置以关闭 tez default sessions并允许 tez session 使用指定的yarn队列,同时通过 yarn queue manager ui 配置公平调度器的放置规则;(背后配置的是 capacity-scheduler.xml中的参数,如 yarn.scheduler.capacity.queue-mappings/yarn.scheduler.queue-placement-rules.app-name/yarn.scheduler.capacity.queue-mappings-override.enable/yarn.scheduler.capacity.root..acl_submit_applications/yarn.scheduler.capacity.root..acl_administer_queue 等);

6 相关参数

#yarn
yarn.resourcemanager.application-tag-based-placement.enable: Whether to enable application placement based on user ID passed via application tags. When it is enabled, userid=<userId> pattern will be checked and if found, the application will be placed onto the found user's queue, if the original user has enough rights on the passed user's queue.
yarn.resourcemanager.application-tag-based-placement.username.whitelist: Comma separated list of users who can use the application tag based placement, if it is enabled.
#tez
tez.am.resource.memory.mb
tez.am.resource.cpu.vcores
tez.task.resource.memory.mb
tez.task.resource.cpu.vcores
tez.session.client.timeout.secs: default 2 mins. Time (in seconds) to wait for AM to come up when trying to submit a DAG from the client. Only relevant in session mode. If the cluster is busy and cannot launch the AM then this timeout may be hit. In those case, using non-session mode is recommended if applicable. Otherwise increase the timeout (set to -1 for infinity. Not recommended)
tez.session.am.dag.submit.timeout.secs: default 5 mins.Time (in seconds) for which the Tez Application Master should wait for a DAG to be submitted before shutting down.Only relevant in session mode. Any negative value will disable this check and allow the AM to hang around forever in idle mode.
tez.am.mode.session: Boolean value. Execution mode for the Tez application. True implies session mode. If the client code is written according to best practices then the same code can execute in either mode based on this configuration. Session mode is more aggressive in reserving execution resources and is typically used for interactive applications where multiple DAGs are submitted in quick succession by the same user. For long running applications, one-off executions, batch jobs etc non-session mode is recommended. If session mode is enabled then container reuse is recommended.
tez.queue.name: String value. The queue name for all jobs being submitted from a given client.
tez.local.mode: Boolean value. Enable local mode execution in Tez. Enables tasks to run in the same process as the app master. Primarily used for debugging.
#hive
hive.server2.enable.doAs
hive.tez.container.size
hive.tez.cpu.vcores
hive.server2.tez.default.queues:A list of comma separated values corresponding to YARN queues of the same name. When HiveServer2 is launched in Tez mode, this configuration needs to be set for multiple Tez sessions to run in parallel on the cluster.
hive.server2.tez.initialize.default.sessions: default true.This flag is used in HiveServer2 to enable a user to use HiveServer2 without turning on Tez for HiveServer2. The user could potentially want to run queries over Tez without the pool of sessions.
hive.server2.tez.sessions.init.threads: If hive.server2.tez.initialize.default.sessions is enabled, the maximum number of threads to use to initialize the default sessions.
hive.server2.tez.queue.access.check: Whether to check user access to explicitly specified YARN queues. yarn.resourcemanager.webapp.address must be configured to use this.
hive.server2.tez.sessions.custom.queue.allowed:default true. Whether Tez session pool should allow submitting queries to custom queues. The options are true, false (error out), ignore (accept the query but ignore the queue setting).
hive.server2.tez.session.lifetime: default 162h. The lifetime of the Tez sessions launched by HS2 when default sessions are enabled.Set to 0 to disable session expiration
hive.server2.tez.sessions.per.default.queue
hive.server2.tez.interactive.queue
hive.server2.tez.sessions.restricted.configs
CDP: tez.queue.name/mapreduce.job.queuename/mapred.job.queue.name
CDH: mapreduce.job.queuename/mapred.job.queue.name/mapred.job.queuename


相关实践学习
简单用户画像分析
本场景主要介绍基于海量日志数据进行简单用户画像分析为背景,如何通过使用DataWorks完成数据采集 、加工数据、配置数据质量监控和数据可视化展现等任务。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps&nbsp;
相关文章
|
2月前
|
分布式计算 DataWorks 调度
maxcompute配置问题之优先级如何解决
MaxCompute配置是指在使用阿里云MaxCompute服务时对项目设置、计算资源、存储空间等进行的各项调整;本合集将提供MaxCompute配置的指南和建议,帮助用户根据数据处理需求优化其MaxCompute环境。
31 1
|
2月前
|
存储 分布式计算 Hadoop
maxcompute配置问题之加速查询超时配置回退如何解决
MaxCompute配置是指在使用阿里云MaxCompute服务时对项目设置、计算资源、存储空间等进行的各项调整;本合集将提供MaxCompute配置的指南和建议,帮助用户根据数据处理需求优化其MaxCompute环境。
31 1
|
2月前
|
SQL 分布式计算 DataWorks
maxcompute配置问题之配置回退的参数如何解决
MaxCompute配置是指在使用阿里云MaxCompute服务时对项目设置、计算资源、存储空间等进行的各项调整;本合集将提供MaxCompute配置的指南和建议,帮助用户根据数据处理需求优化其MaxCompute环境。
38 2
|
2月前
|
分布式计算 安全 专有云
maxcompute配置问题之不能正常执行如何解决
MaxCompute配置是指在使用阿里云MaxCompute服务时对项目设置、计算资源、存储空间等进行的各项调整;本合集将提供MaxCompute配置的指南和建议,帮助用户根据数据处理需求优化其MaxCompute环境。
23 1
|
2月前
|
分布式计算 大数据 数据处理
maxcompute配置问题之配置文件key参数如何解决
MaxCompute配置是指在使用阿里云MaxCompute服务时对项目设置、计算资源、存储空间等进行的各项调整;本合集将提供MaxCompute配置的指南和建议,帮助用户根据数据处理需求优化其MaxCompute环境。
46 2
maxcompute配置问题之配置文件key参数如何解决
|
2月前
|
SQL 分布式计算 MaxCompute
maxcompute之配置报错如何解决
MaxCompute配置是指在使用阿里云MaxCompute服务时对项目设置、计算资源、存储空间等进行的各项调整;本合集将提供MaxCompute配置的指南和建议,帮助用户根据数据处理需求优化其MaxCompute环境。
33 0
|
2月前
|
SQL 存储 分布式计算
maxcompute配置问题之配置mc内容如何解决
MaxCompute配置是指在使用阿里云MaxCompute服务时对项目设置、计算资源、存储空间等进行的各项调整;本合集将提供MaxCompute配置的指南和建议,帮助用户根据数据处理需求优化其MaxCompute环境。
30 1
|
5天前
|
SQL 分布式计算 Hadoop
利用Hive与Hadoop构建大数据仓库:从零到一
【4月更文挑战第7天】本文介绍了如何使用Apache Hive与Hadoop构建大数据仓库。Hadoop的HDFS和YARN提供分布式存储和资源管理,而Hive作为基于Hadoop的数据仓库系统,通过HiveQL简化大数据查询。构建过程包括设置Hadoop集群、安装配置Hive、数据导入与管理、查询分析以及ETL与调度。大数据仓库的应用场景包括海量数据存储、离线分析、数据服务化和数据湖构建,为企业决策和创新提供支持。
35 1
|
2月前
|
数据采集 分布式计算 监控
maxcompute配置问题之需要配置如何解决
MaxCompute配置是指在使用阿里云MaxCompute服务时对项目设置、计算资源、存储空间等进行的各项调整;本合集将提供MaxCompute配置的指南和建议,帮助用户根据数据处理需求优化其MaxCompute环境。
23 0
|
2月前
|
SQL 分布式计算 DataWorks
maxcompute配置问题之连接oss报错如何解决
MaxCompute配置是指在使用阿里云MaxCompute服务时对项目设置、计算资源、存储空间等进行的各项调整;本合集将提供MaxCompute配置的指南和建议,帮助用户根据数据处理需求优化其MaxCompute环境。
29 0