华为云用户手册

Flink用户权限说明 访问并使用Flink WebUI进行业务操作需为用户赋予FlinkServer相关权限，Manager的admin用户没有FlinkServer的业务操作权限。 FlinkServer中应用（租户）是最大管理范围，包含集群连接管理、数据连接管理、应用管理、流表和作业管理等。 FlinkServer中有如表1所示三种资源权限： 表1 FlinkServer资源权限 权限名称 权限描述 备注 FlinkServer管理员权限 具有所有应用的编辑、查看权限。 是FlinkServer的最高权限。如果已经具有FlinkServer管理员权限，则会自动具备所有应用的权限。 应用编辑权限 具有当前应用编辑权限的用户，可以执行创建、编辑和删除集群连接、数据连接，创建流表、创建作业及运行作业等操作。 同时具有当前应用查看权限。 应用查看权限 具有当前应用查看权限的用户，可以查看应用。 - 父主题： Flink用户权限管理

操作场景 Hudi提供多种写入方式，具体见hoodie.datasource.write.operation配置项，这里主要介绍UPSERT、INSERT和BULK_INSERT。 INSERT（插入）： 该操作流程和UPSERT基本一致，但是不需要通过索引去查询具体更新的文件分区，因此它的速度比UPSERT快。当数据源不包含更新数据时建议使用该操作，如果数据源中存在更新数据，则在 数据湖 中会出现重复数据。 BULK_INSERT（批量插入）：用于初始数据集加载， 该操作会对主键进行排序后直接以写普通parquet表的方式插入Hudi表，该操作性能是最高的，但是无法控制小文件，而UPSERT和INSERT操作使用启发式方法可以很好的控制小文件。 UPSERT（插入更新）： 默认操作类型。Hudi会根据主键进行判断，如果历史数据存在则update如果不存在则insert。因此在对于CDC之类几乎肯定包括更新的数据源，建议使用该操作。 由于INSERT时不会对主键进行排序，所以初始化数据集不建议使用INSERT。 在确定数据都为新数据时建议使用INSERT，当存在更新数据时建议使用UPSERT，当初始化数据集时建议使用BULK_INSERT。

批量写入Hudi表 引入Hudi包生成测试数据，参考使用Spark Shell创建Hudi表章节的2到4。 写入Hudi表，写入命令中加入参数：option("hoodie.datasource.write.operation", "bulk_insert")，指定写入方式为bulk_insert，指定其他写入方式请参考表1。 df.write.format("org.apache.hudi").options(getQuickstartWriteConfigs).option("hoodie.datasource.write.precombine.field", "ts").option("hoodie.datasource.write.recordkey.field", "uuid").option("hoodie.datasource.write.partitionpath.field", "").option("hoodie.datasource.write.operation", "bulk_insert").option("hoodie.table.name", tableName).option("hoodie.datasource.write.keygenerator.class", "org.apache.hudi.keygen.NonpartitionedKeyGenerator").option("hoodie.datasource.hive_sync.enable", "true").option("hoodie.datasource.hive_sync.partition_fields", "").option("hoodie.datasource.hive_sync.partition_extractor_class", "org.apache.hudi.hive.NonPartitionedExtractor").option("hoodie.datasource.hive_sync.table", tableName).option("hoodie.datasource.hive_sync.use_jdbc", "false").option("hoodie.bulkinsert.shuffle.parallelism", 4).mode(Overwrite).save(basePath) 示例中各参数介绍请参考表1。 使用spark datasource接口更新Mor表，Upsert写入小数据量时可能触发更新数据的小文件合并，使在Mor表的读优化视图中能查到部分更新数据。 当update的数据对应的base文件是小文件时，insert中的数据和update中的数据会被合在一起和base文件直接做合并产生新的base文件，而不是写log。

将Hudi表数据同步到Hive 通过执行run_hive_sync_tool.sh可以将Hudi表数据同步到Hive中。 例如：需要将HDFS上目录为hdfs://hacluster/tmp/huditest/hudimor1_deltastreamer_partition的Hudi表同步为Hive表，表名为table hive_sync_test3，使用unite、country和state为分区键，命令示例如下： run_hive_sync_tool.sh --partitioned-by unite,country,state --base-path hdfs://hacluster/tmp/huditest/hudimor1_deltastreamer_partition --table hive_sync_test3 --partition-value-extractor org.apache.hudi.hive.MultiPartKeysValueExtractor --support-timestamp 表1 参数说明 命令 描述 必填 默认值 --database Hive database名称 N default --table Hive表名 Y - --base-file-format 文件格式 (PARQUET或HFILE) N PARQUET --user Hive用户名 N - --pass Hive密码 N - --jdbc-url Hive jdbc connect url N - --base-path 待同步的Hudi表存储路径 Y - --partitioned-by 分区键- N - --partition-value-extractor 分区类，需实现PartitionValueExtractor ，可以从HDFS路径中提取分区值 N SlashEncodedDayPartitionValueExtractor --assume-date-partitioning 以yyyy/mm/dd进行分区从而支持向后兼容。 N false --use-pre-apache-input-format 使用com.uber.hoodie包下的InputFormat替换org.apache.hudi包下的。除了从com.uber.hoodie迁移项目至org.apache.hudi外请勿使用。 N false --use-jdbc 使用Hive jdbc连接 N true --auto-create-database 自动创建Hive database N true --skip-ro-suffix 注册时跳过读取_ro后缀的读优化视图 N false --use-file-listing-from-metadata 从Hudi的元数据中获取文件列表 N false --verify-metadata-file-listing 根据文件系统验证Hudi元数据中的文件列表 N false --help、-h 查看帮助 N false --support-timestamp 将原始类型中'INT64'的TIMESTAMP_MICROS转换为Hive的timestamp N false --decode-partition 如果分区在写入过程中已编码，则解码分区值 N false --batch-sync-num 指定每批次同步hive的分区数 N 1000 Hive Sync时会判断表不存在时建外表并添加分区，表存在时对比表的schema是否存在差异，存在则替换，对比分区是否有新增，有则添加分区。 因此使用hive sync时有以下约束： 写入数据Schema只允许增加字段，不允许修改、删除字段。 分区目录只能新增，不会删除。 Overwrite覆写Hudi表不支持同步覆盖Hive表。 Hudi同步Hive表时，不支持使用timestamp类型作为分区列。 父主题： Hudi写操作

Hudi Compaction操作说明 Compaction用于合并mor表Base和Log文件。 对于Merge-On-Read表，数据使用列式Parquet文件和行式Avro文件存储，更新被记录到增量文件，然后进行同步/异步compaction生成新版本的列式文件。Merge-On-Read表可减少数据摄入延迟，因而进行不阻塞摄入的异步Compaction很有意义。 异步Compaction会进行如下两个步骤： 调度Compaction：由入湖作业完成，在这一步，Hudi扫描分区并选出待进行compaction的FileSlice，最后CompactionPlan会写入Hudi的Timeline。 执行Compaction：一个单独的进程/线程将读取CompactionPlan并对FileSlice执行Compaction操作。 使用Compaction的方式分为同步和异步两种： 同步方式由参数hoodie.compact.inline控制，默认为true，自动生成compaction调度计划并执行compaction： 关闭同步compaction datasource写入时可以通过 .option("hoodie.compact.inline", "false") 来关闭自动compaction。 spark-sql写入时可以通过set hoodie.compact.inline=false;来关闭自动compaction。 仅同步生成compaction调度而不执行compaction ·datasource写入时可以通过以下option参数来实现： option("hoodie.compact.inline", "true"). option("hoodie.schedule.compact.only.inline", "true"). option("hoodie.run.compact.only.inline", "false"). ·spark-sql写入时可以通过set以下参数来实现： set hoodie.compact.inline=true; set hoodie.schedule.compact.only.inline=true; set hoodie.run.compact.only.inline=false; 异步方式由spark-sql来实现。 如果需要在异步compaction时只执行已经产生的compaction调度计划而不创建新的调度计划，则需要通过set命令设置以下参数： set hoodie.compact.inline=true; set hoodie.schedule.compact.only.inline=false; set hoodie.run.compact.only.inline=true; 更多compaction参数请参考compaction&cleaning配置章节。 为了保证入湖的最高效率，推荐使用同步产生compaction调度计划，异步执行compaction调度计划的方式。 父主题： Hudi数据管理维护

Hudi表类型 Copy On Write 写时复制表也简称cow表，使用parquet文件存储数据，内部的更新操作需要通过重写原始parquet文件完成。 优点：读取时，只读取对应分区的一个数据文件即可，较为高效。 缺点：数据写入的时候，需要复制一个先前的副本再在其基础上生成新的数据文件，这个过程比较耗时。且由于耗时，读请求读取到的数据相对就会滞后。 Merge On Read 读时合并表也简称mor表，使用列格式parquet和行格式Avro两种方式混合存储数据。其中parquet格式文件用于存储基础数据，Avro格式文件（也可叫做log文件）用于存储增量数据。 优点：由于写入数据先写delta log，且delta log较小，所以写入成本较低。 缺点：需要定期合并整理compact，否则碎片文件较多。读取性能较差，因为需要将delta log和老数据文件合并。

问题 Hive同步数据时报错： Caused by: java.sql.SQLException: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. The following columns have types incompatible with the existing columns in their respective positions :__col1,__col2

查看Ranger审计信息内容 使用Ranger管理员用户rangeradmin登录Ranger管理页面，具体操作可参考登录Ranger WebUI界面。 单击“Audit”，查看相关审计信息，各页签内容说明请参考表1，条目较多时，单击搜索框可根据关键字段进行筛选。 表1 Audit信息 页签 内容描述 Access 当前 MRS 不支持在线查看组件资源的审计日志信息，可登录组件安装节点，进入“/var/log/Bigdata/audit”目录下查看各组件的审计日志，日志中主要字段含义如下： result：策略校验结果，0表示拒绝，1表示允许。 policy：匹配生效的策略ID，对应页面中策略的“Policy ID”，若为-1表示未匹配到策略。 action：表示执行的操作权限，对应策略中的“Permissions”中勾选的操作权限。 access：表示执行的操作，各个组件支持的access各不相同。 Admin Ranger上操作审计信息，例如安全访问策略的创建/更新/删除、组件权限策略的创建/删除、role的创建/更新/删除等。 Login Sessions 登录Ranger的用户会话审计信息。 Plugins Ranger内组件权限策略信息。 Plugin Status 各组件节点权限策略的同步审计信息。 User Sync Ranger与LDAP用户同步审计信息。

回答 JobHistory服务更新页面上的app时，会根据HDFS上的part文件大小变更与否判断是否刷新首页面的app显示信息。如果文件为第一次查看，则将当前文件大小与0作比较，如果大于0则读取该文件。 分组的情况下，如果执行的app没有job处于执行状态，则part文件为空，即JobHistory服务不会读取该文件，此app也不会显示在JobHistory页面上。但如果part文件大小之后有更新，JobHistory又会显示该app。

问题 执行大数据量的Spark任务（如2T的TPCDS测试套），任务运行成功后，在spark-sql退出时概率性出现RejectedExecutionException的异常栈信息，相关日志如下所示： 16/07/16 10:19:56 ERROR TransportResponseHandler: Still have 2 requests outstanding when connection from linux-192/10.1.1.5:59250 is closedjava.util.concurrent.RejectedExecutionException: Task scala.concurrent.impl.CallbackRunnable@5fc1ab rejected from java.util.concurrent.ThreadPoolExecutor@52fa7e19[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 3025]

回答 通过集群将非ViewFS文件系统配置为ViewFS时，ViewFS中的文件夹的用户权限与默认NameService中的非ViewFS不同。因为目录权限不匹配，所以已提交的MR作业运行失败。 在集群中配置ViewFS的用户，需要检查并校验目录权限。在提交作业之前，应按照默认的NameService文件夹权限更改ViewFS文件夹权限。 下表列出了ViewFS中配置的目录的默认权限结构。如果配置的目录权限与下表不匹配，则必须相应地更改目录权限。 表1 ViewFS中配置的目录的默认权限结构 参数 描述 默认值 默认值及其父目录的默认权限 yarn.nodemanager.remote-app-log-dir 在默认文件系统上（通常是HDFS），指定NM应将日志聚合到哪个目录。 logs 777 yarn.nodemanager.remote-app-log-archive-dir 将日志归档的目录。 - 777 yarn.app.mapreduce.am.staging-dir 提交作业时使用的staging目录。 /tmp/hadoop-yarn/staging 777 mapreduce.jobhistory.intermediate-done-dir MapReduce作业记录历史文件的目录。 ${yarn.app.mapreduce.am.staging-dir}/history/done_intermediate 777 mapreduce.jobhistory.done-dir 由MR JobHistory Server管理的历史文件的目录。 ${yarn.app.mapreduce.am.staging-dir}/history/done 777

ZooKeeper常用配置参数 参数入口： 请参考修改集群服务配置参数，进入ZooKeeper“全部配置”页面。在搜索框中输入参数名称。 表1 参数说明 配置参数 说明 默认值 skipACL 是否跳过ZooKeeper节点的权限检查。 no maxClientCnxns ZooKeeper的最大连接数，在连接数多的情况下，建议增加。 2000 LOG _LEVEL 日志级别，在调试的时候，可以改为DEBUG。 INFO acl.compare.shortName 当Znode的ACL权限认证类型为SASL时，是否仅使用principal的用户名部分进行ACL权限认证。 true synclimit Follower与leader进行同步的时间间隔（单位为tick）。如果在指定的时间内leader没响应，连接将不能被建立。 15 tickTime 一次tick的时间（毫秒），它是ZooKeeper使用的基本时间单位，心跳、超时的时间都由它来规定。 4000 ZooKeeper内部时间由参数ticktime和参数synclimit控制，如需调大ZooKeeper内部超时时间，需要调大客户端连接ZooKeeper的超时时间。 父主题： 使用ZooKeeper

操作场景 该操作指导用户对ZooKeeper的znode设置权限。 ZooKeeper通过访问控制列表（ACL）来对znode进行访问控制。ZooKeeper客户端为znode指定ACL，ZooKeeper服务器根据ACL列表判定某个请求znode的客户端是否有对应操作的权限。ACL设置涉及如下四个方面。 查看ZooKeeper中znode的ACL。 增加ZooKeeper中znode的ACL。 修改ZooKeeper中znode的ACL。 删除ZooKeeper中znode的ACL。 ZooKeeper的ACL权限说明： ZooKeeper目前支持create，delete，read，write，admin五种权限，且ZooKeeper对权限的控制是znode级别的，而且不继承，即对父znode设置权限，其子znode不继承父znode的权限。ZooKeeper中znode的默认权限为world:anyone:cdrwa，即任何用户都有所有权限。 ACL有三部分： 第一部分是认证类型，如world指所有认证类型，sasl是kerberos认证类型； 第二部分是账号，如anyone指的是任何人； 第三部分是权限，如cdrwa指的是拥有所有权限。 特别的，由于普通模式启动客户端不需要认证，sasl认证类型的ACL在普通模式下将不能使用。本文所有涉及sasl方式的鉴权操作均是在安全集群中进行。 表1 Zookeeper的五种ACL 权限说明 权限简称 权限详情 创建权限 create(c) 可以在当前znode下创建子znode 删除权限 delete(d) 删除当前的znode 读权限 read(r) 获取当前znode的数据，可以列出当前znode所有的子znodes 写权限 write(w) 向当前znode写数据，写入子znode 管理权限 admin(a) 设置当前znode的权限

回答 可能原因为IBM的JDK和普通JDK的jaas.conf文件格式不一样。 在使用IBM JDK时，建议使用如下jaas.conf文件模板，其中“useKeytab”中的文件路径必须以“file://”开头，后面为绝对路径。 Client {com.ibm.security.auth.module.Krb5LoginModule requireduseKeytab="file://D:/install/HbaseClientSample/conf/user.keytab"principal="hbaseuser1"credsType="both";};

配置方法 导出集群中的证书： 安装集群客户端，例如安装路径为“/opt/client”。 执行以下命令，切换到客户端安装目录。 cd /opt/client 执行以下命令配置环境变量。 source bigdata_env 生成证书文件 keytool -export -alias fusioninsightsubroot -storepass changeit -keystore /opt/client/JRE/jre/lib/security/cacerts -file fusioninsightsubroot.crt 将集群中的证书导入第三方JDK或者JRE中 将1中生成的fusioninsightsubroot.crt文件复制到第三方JRE节点上，设置好该节点的JAVA_HOME环境变量后，执行以下命令导入证书： keytool -import -trustcacerts -alias fusioninsightsubroot -storepass changeit -file fusioninsightsubroot.crt -keystore MY_JRE/lib/security/cacerts 'MY_JRE'表示第三方JRE安装路径，请自行修改。

推荐资源配置 mor表： 由于其本质上是写增量文件，调优可以直接根据Hudi的数据大小（dataSize）进行调整。 dataSize如果只有几个G，推荐跑单节点运行spark，或者yarn模式但是只分配一个container。 入湖程序的并行度p设置：建议p = (dataSize)/128M，程序分配core的数量保持和p一致即可。内存设置建议内存大小和core的比例大于1.5:1 即一个core配1.5G内存， 堆外内存设置建议内存大小和core的比例大于0.5:1。 cow表： cow表的原理是重写原始数据，因此这种表的调优，要兼顾dataSize和最后重写的文件数量。总体来说core数量越大越好（和最后重写多少个文件数直接相关），并行度p和内存大小和mor设置类似。

Hudi Cleaning操作说明 Cleaning用于清理不再需要的版本数据。 Hudi使用Cleaner后台作业，不断清除不需要的旧版本数据。通过配置hoodie.cleaner.policy和hoodie.cleaner.commits.retained可以使用不同的清理策略和保存的commit数量。 执行cleaning有两种方式： 同步clean由参数hoodie.clean.automatic控制，默认自动开启。 关闭同步clean： datasource写入时可以通过.option("hoodie.clean.automatic", "false")来关闭自动clean。 spark-sql写入时可以通过set hoodie.clean.automatic=false;来关闭自动clean。 异步clean可以使用spark-sql来执行，详情可以参考章节CLEAN。 更多clean相关参数请参考compaction&cleaning配置章节。 父主题： Hudi数据管理维护

回答 建议在使用Hudi时，schema应该以向后兼容的方式演进。此错误通常发生在使用向后不兼容的演进方式删除某些列如“col1”后，更新parquet文件中以旧的schema写入的列“col1”，在这种情况下，parquet尝试在传入记录中查找所有当前字段，当发现“col1”不存在时，发生上述异常。 解决这个问题的办法是使用所有schema演进版本来创建uber schema，并使用该schema作为target schema。用户可以从hive metastore中获取schema并将其与当前schema合并。

操作步骤 创建工作流，请参考使用Hue创建工作流。 在工作流编辑页面，选择“子Workflow”按钮，将其拖到操作区中。 在弹出的“Sub workflow”窗口中配置“Sub-workflow”的值，例如从下拉列表中选取“Java-Workflow”（这个值是已经创建好的工作流之一），然后单击“添加”。 单击Oozie编辑器右上角的。 保存前如果需要修改作业名称（默认为“My Workflow”），可以直接单击该名称进行修改，例如“Subworkflow-Workflow”。 保存完成后，单击，提交该作业。 作业提交后，可通过Hue界面查看作业的详细信息、日志、进度等相关内容。

命令格式 Add或Update参数值： SET parameter_name=parameter_value 此命令用于添加或更新“parameter_name”的值。 Display参数值： SET parameter_name 此命令用于显示指定的“parameter_name”的值。 Display会话参数： SET 此命令显示所有支持的会话参数。 Display会话参数以及使用细节： SET -v 此命令显示所有支持的会话参数及其使用细节。 Reset参数值： RESET 此命令清除所有会话参数。

示例 添加（Add）或更新（Update）： SET enable.unsafe.sort=true 显示（Display）属性值： SET enable.unsafe.sort 显示段ID列表，段状态和其他所需详细信息的示例，然后指定要读取的段列表： SHOW SEGMENTS FOR TABLE carbontable1; SET carbon.input.segments.db.carbontable1 = 1, 3, 9; 多线程模式查询指定段示例如下： CarbonSession.threadSet ("carbon.input.segments.default.carbon_table_MulTI_THread", "1,3"); 在多线程环境中使用CarbonSession.threadSet查询段示例如下（以Scala代码为例）： def main(args: Array[String]) { Future { CarbonSession.threadSet("carbon.input.segments.default.carbon_table_MulTI_THread", "1") spark.sql("select count(empno) from carbon_table_MulTI_THread").show() }} 重置（Reset）： RESET

操作步骤 使用Ranger管理员用户rangeradmin登录Ranger管理页面，具体操作可参考登录Ranger WebUI界面。 在首页中单击“HDFS”区域的组件插件名称，例如“hacluster”。 单击“Add New Policy”，添加HDFS权限控制策略。 根据业务需求配置相关参数。 表1 HDFS权限参数 参数名称 描述 Policy Name 策略名称，可自定义，不能与本服务内其他策略名称重复。 Policy Conditions IP过滤策略，可自定义，配置当前策略适用的主机节点，可填写一个或多个IP或IP段，并且IP填写支持“*”通配符，例如：192.168.1.10,192.168.1.20或者192.168.1.*。 Policy Label 为当前策略指定一个标签，可以根据这些标签搜索报告和筛选策略。 Resource Path 资源路径，配置当前策略适用的HDFS路径文件夹或文件，可填写多个值，支持使用通配符“*”（例如“/test/*”）。 如需子目录继承上级目录权限，可打开递归开关按钮。 如果父目录开启递归，同时子目录也配置了策略，以子目录策略为准。 non-recursive：关闭递归 recursive：打开递归 Description 策略描述信息。 Audit Logging 是否审计此策略。 Allow Conditions 策略允许条件，配置本策略内允许的权限及例外，例外条件优先级高于正常条件。 在“Select Role”、“Select Group”、“Select User”列选择已创建好的需要授予权限的Role、用户组或用户，单击“Add Conditions”，添加策略适用的IP地址范围，单击“Add Permissions”，添加对应权限。 Read：读权限 Write：写权限 Execute：执行权限 Select/Deselect All：全选/取消全选 如需让当前条件中的用户或用户组管理本条策略，可勾选“Delegate Admin”使这些用户或用户组成为受委托的管理员。被委托的管理员可以更新、删除本策略，还可以基于原始策略创建子策略。 如需添加多条权限控制规则，可单击按钮添加。如需删除权限控制规则，可单击按钮删除。 Exclude from Allow Conditions：配置排除在允许条件之外的例外规则。 Deny All Other Accesses 是否拒绝其他所有访问。 True：拒绝其他所有访问。 False：设置为false，可配置Deny Conditions。 Deny Conditions 策略拒绝条件，配置本策略内拒绝的权限及例外，配置方法与“Allow Conditions”类似，拒绝条件的优先级高于“Allow Conditions”中配置的允许条件。 Exclude from Deny Conditions：配置排除在拒绝条件之外的例外规则。 例如为用户“testuser”添加“/user/test”目录的写权限，配置如下： 表2 设置权限 任务场景 角色授权操作 设置HDFS管理员权限 在首页中单击“HDFS”区域的组件插件名称，例如“hacluster”。 选择“Policy Name”为“all - path”的策略，单击按钮编辑策略。 在“Allow Conditions”区域，单击“Select User”下选择框选择用户。 设置用户执行HDFS检查和HDFS修复的权限 在“Resource Path”配置文件夹或文件。 在“Allow Conditions”区域，单击“Select User”下选择框选择用户。 单击“Add Permissions”，勾选“Read”和“Execute”。 设置用户读取其他用户的目录或文件的权限 在“Resource Path”配置文件夹或文件。 在“Allow Conditions”区域，单击“Select User”下选择框选择用户。 单击“Add Permissions”，勾选“Read”和“Execute”。 设置用户在其他用户的文件写入数据的权限 在“Resource Path”配置文件夹或文件。 在“Allow Conditions”区域，单击“Select User”下选择框选择用户。 单击“Add Permissions”，勾选“Write”和“Execute”。 设置用户在其他用户的目录新建或删除子文件、子目录的权限 在“Resource Path”配置文件夹或文件。 在“Allow Conditions”区域，单击“Select User”下选择框选择用户。 单击“Add Permissions”，勾选“Write”和“Execute”。 设置用户在其他用户的目录或文件执行的权限 在“Resource Path”配置文件夹或文件。 在“Allow Conditions”区域，单击“Select User”下选择框选择用户。 单击“Add Permissions”，勾选“Execute”。 设置子目录继承上级目录权限 在“Resource Path”配置文件夹或文件。 打开递归开关按钮，“Recursive”即为打开递归。 （可选）添加策略有效期。在页面右上角单击“Add Validity period”，设置“Start Time”和“End Time”，选择“Time Zone”。单击“Save”保存。如需添加多条策略有效期，可单击按钮添加。如需删除策略有效期，可单击按钮删除。 单击“Add”，在策略列表可查看策略的基本信息。等待策略生效后，验证相关权限是否正常。 如需禁用某条策略，可单击按钮编辑策略，设置策略开关为“Disabled”。 如果不再使用策略，可单击按钮删除策略。

回答 当Yarn配置“yarn.log-aggregation-enable”为“true”时，就开启了container日志聚合功能。日志聚合功能是指：当应用在Yarn上执行完成后，NodeManager将本节点中所有container的日志聚合到HDFS中，并删除本地日志。详情请参见配置Container日志聚合功能。 然而，开启container日志聚合功能之后，其日志聚合至HDFS目录中，只能通过获取HDFS文件来查看日志。开源Spark和Yarn服务不支持通过WebUI查看聚合后的日志。 因此，Spark在此基础上进行了功能增强。如图1所示，在HistoryServer页面添加“AggregatedLogs”页签，可以通过“logs”链接查看聚合的日志。 图1 聚合日志显示页面

操作场景 Spark是内存计算框架，计算过程中内存不够对Spark的执行效率影响很大。可以通过监控GC（Garbage Collection），评估内存中RDD的大小来判断内存是否变成性能瓶颈，并根据情况优化。 监控节点进程的GC情况（在客户端的conf/spark-default.conf配置文件中，在spark.driver.extraJavaOptions和spark.executor.extraJavaOptions配置项中添加参数："-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps" ），如果频繁出现Full GC，需要优化GC。把RDD做Cache操作，通过日志查看RDD在内存中的大小，如果数据太大，需要改变RDD的存储级别来优化。

操作步骤 优化GC，调整老年代和新生代的大小和比例。在客户端的“conf/spark-default.conf”配置文件中，在spark.driver.extraJavaOptions和spark.executor.extraJavaOptions配置项中添加参数：-XX:NewRatio。如：" -XX:NewRatio=2"，则新生代占整个堆空间的1/3，老年代占2/3。 开发Spark应用程序时，优化RDD的数据结构。 使用原始类型数组替代集合类，如可使用fastutil库。 避免嵌套结构。 Key尽量不要使用String。 开发Spark应用程序时，建议序列化RDD。 RDD做cache时默认是不序列化数据的，可以通过设置存储级别来序列化RDD减小内存。例如： testRDD.persist(StorageLevel.MEMORY_ONLY_SER)

回答 当前可以通过以下3种方式创建UDF： 在Hive端创建UDF。 通过JD BCS erver接口创建UDF。用户可以通过Spark Beeline或者JDBC客户端代码来连接JDB CS erver，从而执行SQL命令，创建UDF。 通过spark-sql创建UDF。 删除UDF失败，存在以下两种场景： 在Spark Beeline中，对于其他方式创建的UDF，需要重新启动Spark服务端的JDBCServer后，才能将此类UDF删除成功，否则删除失败。在spark-sql中，对于其他方式创建的UDF，需要重新启动spark-sql后，才能将此类UDF删除成功，否则删除失败。 原因：创建UDF后，Spark服务端的JDBCServer未重启或者spark-sql未重新启动的场景，Spark所在线程的FunctionRegistry对象未保存新创建的UDF，那么删除UDF时就会出现错误。 解决方法：重启Spark服务端的JDBCServer和spark-sql，再删除此类UDF。 在Hive端创建UDF时未在创建语句中指定jar包路径，而是通过add jar命令添加UDF的jar包如add jar /opt/test/two_udfs.jar，这种场景下，在其他服务中删除UDF时就会出现ClassNotfound的错误，从而导致删除失败。 原因：在删除UDF时，会先获取该UDF，此时会去加载该UDF对应的类，由于创建UDF时是通过add jar命令指定jar包路径的，其他服务进程的classpath不存在这些jar包，因此会出现ClassNotfound的错误从而导致删除失败。 解决方法：该方式创建的UDF不支持通过其他方式删除，只能通过与创建时一致的方式删除。

回答 使用yarn application -kill applicationID命令后Spark只会停掉任务对应的SparkContext，而不是退出当前进程。如果当前进程中存在其他常驻的线程（类似spark-shell需要不断检测命令输入，Spark Streaming不断在从数据源读取数据），SparkContext被停止并不会终止整个进程。 如果需要退出Driver进程，建议使用kill -9 pid命令手动退出当前Driver。

回答 Spark SQL可以将表cache到内存中，并且使用压缩存储来尽量减少内存压力。通过将表cache，查询可以直接从内存中读取数据，从而减少读取磁盘带来的内存开销。 但需要注意的是，被cache的表会占用executor的内存。尽管在Spark SQL采用压缩存储的方式来尽量减少内存开销、缓解GC压力，但当缓存的表较大或者缓存表数量较多时，将不可避免地影响executor的稳定性。 此时的最佳实践是，当不需要将表cache来实现查询加速时，应及时将表进行uncache以释放内存。可以执行命令uncache table table_name来uncache表。 被cache的表也可以在Spark Driver UI的Storage标签里查看。

回答 造成该现象的原因是NodeManager重启。使用ExternalShuffle的时候，Spark将借用NodeManager传输Shuffle数据，因此NodeManager的内存将成为瓶颈。 在当前版本的 FusionInsight 中，NodeManager的默认内存只有1G，在数据量比较大（1T以上）的Spark任务下，内存严重不足，消息响应缓慢，导致FusionInsight健康检查认为NodeManager进程退出，强制重启NodeManager，导致上述问题产生。 解决方法： 调整NodeManager的内存，数据量比较大（1T以上）的情况下，NodeManager的内存至少在4G以上。

回答 Spark的表管理层次如图1所示，最底层是Spark的临时表，存储着使用DataSource方式的临时表，在这一个层面中没有数据库的概念，因此对于这种类型表，表名在各个数据库中都是可见的。 上层为Hive的MetaStore，该层有了各个DB之分。在每个DB中，又有Hive的临时表与Hive的持久化表，因此在Spark中允许三个层次的同名数据表。 查询的时候，Spark SQL优先查看是否有Spark的临时表，再查找当前DB的Hive临时表，最后查找当前DB的Hive持久化表。 图1 Spark表管理层次 当Session退出时，用户操作相关的临时表将自动删除。建议用户不要手动删除临时表。 删除临时表时，其优先级与查询相同，从高到低为Spark临时表、Hive临时表、Hive持久化表。如果想直接删除Hive表，不删除Spark临时表，您可以直接使用drop table DbName.TableName命令。