zhoujie:
sr正常使用，在sr中创建hive catalog
CREATE EXTERNAL CATALOG hive_catalog
【背景】在fe和be中添加了core-site.xml、hdfs-site.xml、hive-site.xml、krb5.conf 在fe/conf/fe.conf 文件中添加了export HADOOP_USER_NAME = hive
错误信息核心：
ERROR 1064 (HY000): hdfsOpenFile failed, file=hdfs://nameservice1/.../000000_0. err_msg: error=Error(255): Unknown error 255, root_cause=GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt): file = hdfs://nameservice1/.../000000_0
GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt) 表明 StarRocks 尝试访问 HDFS 时，Kerberos 认证失败，没有找到有效的 Kerberos Ticket Granting Ticket (TGT)。
问题分析与排查步骤：
您已经采取了一些正确的 Kerberos 配置步骤，但 HDFS 访问仍然失败，这通常意味着 Kerberos 认证信息没有正确地传递或加载到 BE 节点（因为 HDFS 访问是在 BE 节点进行的）。
1. 确认 Kerberos 配置文件和权限
虽然您提到了在 FE 和 BE 中添加了配置文件，但需要仔细核对以下几点：
krb5.conf ：krb5.conf 文件在 所有 BE 节点 上的路径是正确的，并且 StarRocks 进程可以读取。通常建议放在 /etc/krb5.conf 或 BE 进程能访问的路径。
Hadoop 配置文件： 确保 core-site.xml 和 hdfs-site.xml 在 所有 BE 节点 上配置正确，特别是 HDFS 相关的 Kerberos 配置（如 hadoop.security.authentication=kerberos , dfs.namenode.kerberos.principal , dfs.datanode.kerberos.principal 等）。
Keytab 文件： 确认 /home/bsmp/portal/.keytab/hive.keytab 文件在 所有 BE 节点 上都存在，并且 StarRocks BE 进程拥有 读权限 。由于这个路径看起来是用户目录下的路径，权限问题非常常见。
2. Catalog 属性中的 Kerberos 配置
您在 CREATE EXTERNAL CATALOG 语句中配置了 Kerberos 认证，这是正确的：
PROPERTIES(
“type” = “hive”,
“hive.metastore.uris” = “thrift://cdp02.:9083”,
“hadoop.security.authentication” = “kerberos”,
“hadoop.kerberos.keytab” = “/home/bsmp/portal/.keytab/hive.keytab”,
“hadoop.kerberos.principal” = “hive/admin@AOTAIN.COM”
);
关键点： StarRocks 默认使用 Catalog 属性中提供的 keytab 和 principal 去进行 Kerberos 登录（ kinit ）来访问 HDFS。
3. HADOOP_USER_NAME 环境变量 (FE/BE)
您在 fe/conf/fe.conf 中添加了 export HADOOP_USER_NAME = hive 。
FE 节点： HADOOP_USER_NAME 环境变量主要用于 FE 节点在访问 HDFS 时（例如加载数据或某些元数据操作）模拟用户。对于 Kerberos 认证，这个变量通常不是主要因素，主要的认证依赖于 Catalog 中配置的 keytab 和 principal 。
BE 节点： BE 节点 才是实际执行查询和访问 HDFS 文件的进程。您需要确保 BE 节点 也能正确处理 Kerberos 认证。
4. 针对 3.1.11 版本的 Kerberos 访问 HDFS 检查
在 StarRocks 中，HDFS 的访问是在 BE 进程中完成的。如果 Kerberos 认证失败，通常需要在 BE 侧进行排查。
建议的排查步骤：
A. 验证 Keytab 和 Principal
在 任一 BE 节点 上，使用 Catalog 中配置的 Keytab 和 Principal 尝试手动登录，验证 Keytab 是否有效：
# 替换为您的实际路径和 Principal
kinit -kt /home/bsmp/portal/.keytab/hive.keytab "hive/admin@AOTAIN.COM"
# 检查是否成功获取 TGT
klist
如果 kinit 失败，说明 Keytab 文件或 Principal 名称有误，或者 Principal 不匹配 Keytab 中的加密密钥。
B. 检查 BE 日志
检查 BE 节点的 be.INFO 或 be.WARNING 日志，搜索相关的 Kerberos 错误信息。BE 在尝试连接 HDFS 时，会记录认证失败的详细信息。
C. 确保 BE 进程能读取 Keytab
将 Keytab 文件放置在一个所有 BE 节点都能访问且 BE 进程有读取权限的路径下，例如 /opt/starrocks/keytabs/hive.keytab ，然后更新 Catalog：
ALTER EXTERNAL CATALOG hive_catalog
SET PROPERTIES (
"hadoop.kerberos.keytab" = "/opt/starrocks/keytabs/hive.keytab"
);
D. 检查 NameNode Principal (如果适用)
如果 HDFS 启用了 Kerberos， hdfs-site.xml 中通常需要配置 NameNode 的 Kerberos Principal。虽然 StarRocks 会尝试使用 Catalog 中配置的 principal 去访问 HDFS，但有时也需要确保 BE 能够解析到正确的 NameNode Principal。
在 hdfs-site.xml 中，检查以下配置是否正确：
<property>
<name>dfs.namenode.kerberos.principal.pattern</name>
<value>...</value>
</property>
总结：
您遇到的问题是典型的 Kerberos 认证失败。由于 HDFS 访问发生在 BE 节点，请将排查重点放在 所有 BE 节点 上的 Kerberos 配置文件、Keytab 文件的路径和权限。最常见的原因是 BE 节点无法访问或读取 Keytab 文件 ，或者 Keytab 文件本身与 Principal 不匹配 。
