HDFS权限管理完全手册：保障大数据安全的最佳实践

元数据框架

标题

HDFS权限管理完全手册：保障大数据安全的最佳实践

关键词

HDFS权限管理；大数据安全；POSIX模型；ACL（访问控制列表）；Apache Ranger；Kerberos认证；细粒度授权

摘要

HDFS作为Hadoop生态的核心分布式文件系统，其权限管理是大数据安全的基石。本文从第一性原理出发，系统拆解HDFS权限管理的理论框架、架构设计与实现机制，结合企业级实践覆盖从基础POSIX权限到高级ACL、Ranger集成的全流程。无论是入门级运维工程师还是资深架构师，都能通过本文掌握：

  1. HDFS权限管理的核心逻辑与历史演化；
  2. 从“身份认证→授权检查→审计追溯”的完整安全链路；
  3. 企业级落地的最佳实践（如Kerberos+Ranger的协同、多租户隔离、跨集群权限同步）；
  4. 应对云原生、AI时代的权限管理演化方向。

1. 概念基础：HDFS权限管理的底层逻辑

要理解HDFS权限管理，需先回归分布式文件系统的本质需求：在多租户、跨节点的环境中，确保“正确的用户以正确的方式访问正确的数据”。

1.1 领域背景化：HDFS的安全痛点

HDFS的设计目标是高吞吐、高可靠的大规模数据存储，但早期版本（Hadoop 1.x）的安全机制几乎空白——默认允许匿名访问，权限检查仅依赖简单的文件属性。随着大数据从“实验性”走向“企业核心资产”，以下痛点倒逼权限管理升级：

  • 多租户隔离：企业内多个部门共享集群时，需防止部门A的数据被部门B非法访问；
  • 细粒度控制：仅靠“用户/组/其他”的粗粒度权限无法满足“允许Alice读取目录但禁止写入”的需求；
  • 身份伪造：缺乏强认证机制，攻击者可冒充合法用户篡改数据；
  • 审计追溯：无法记录“谁在什么时候访问了什么数据”，导致安全事件无法溯源。

1.2 历史轨迹：从粗放到精细的演化

HDFS权限管理的发展可分为三个阶段：

阶段 版本 核心能力 局限性
1. 基础POSIX模型 Hadoop 1.x 继承Linux文件系统的“用户-组-其他”权限位（rwx） 粗粒度、无强认证、无审计
2. 扩展ACL Hadoop 2.x 支持针对特定用户/组的额外权限（如user:alice:rwx） 缺乏集中管理、无法跨服务协同
3. 企业级治理 Hadoop 3.x+ 集成Apache Ranger（集中权限管理）、Kerberos（强认证）、Atlas（数据血缘审计） 需额外组件部署，学习成本较高

1.3 问题空间定义：权限管理的三要素

HDFS权限管理的核心问题可拆解为三个相互依赖的维度：

  1. 身份认证（Authentication）：确认“谁在访问数据”（如Kerberos验证用户身份）；
  2. 授权（Authorization）：确认“该用户能对数据做什么”（如POSIX权限、ACL、Ranger政策）；
  3. 审计（Audit）：记录“用户做了什么”（如Ranger的审计日志、HDFS的NameNode日志）。

三者构成“认证→授权→审计”的安全三角，缺一不可——没有认证的授权是“无的放矢”，没有审计的授权是“无法追溯”。

1.4 术语精确性：避免概念混淆

  • 用户（User）：HDFS中的身份主体，对应操作系统用户或Kerberos主体（如alice@EXAMPLE.COM）；
  • 组（Group）：用户的集合，用于批量授权（如data_scientists组）；
  • 权限位（Permission Bits）：POSIX模型中的r（读）、w（写）、x（执行），对应用户（u）、组（g）、其他（o）三个维度；
  • ACL（Access Control List）：扩展的权限列表，允许针对特定用户/组设置权限（补充POSIX的粗粒度不足）；
  • 超用户（Superuser）：HDFS的“root”用户（默认是hdfs），拥有所有权限；
  • 服务主体（Service Principal）：Kerberos中服务的身份（如namenode/node1.example.com@EXAMPLE.COM）。

2. 理论框架：从第一性原理推导权限模型

HDFS权限管理的理论基础是访问控制模型，其核心是解决“主体（Subject）→操作（Action）→资源（Resource）”的三元关系。

2.1 第一性原理推导：权限的数学表达

从集合论出发，权限管理可形式化为以下模型：

  • 主体集合 ( S )：所有访问HDFS的用户/服务（如alice, hive）；
  • 资源集合 ( R )：HDFS中的文件/目录（如/user/alice/data.txt）；
  • 操作集合 ( A )：允许的行为（如read, write, execute）；
  • 授权函数 ( f: S \times R \rightarrow 2^A )：定义主体对资源的允许操作集合。

例如，若alice对/user/alice/data.txt有读权限，则 ( f(alice, /user/alice/data.txt) = {read} )。

2.2 核心模型：POSIX与ACL的协同

HDFS的基础权限模型是POSIX扩展模型，包含两层权限检查：

  1. 基础权限位：文件/目录的mode属性（如0755对应rwxr-xr-x）；
  2. ACL扩展：当基础权限无法满足需求时，通过ACL补充特定用户/组的权限。
2.2.1 POSIX权限的计算逻辑

HDFS的权限位与Linux完全一致，通过三位八进制数表示：

  • 第一位：用户（u）的权限（r=4, w=2, x=1）；
  • 第二位：组（g）的权限；
  • 第三位：其他（o）的权限。

例如：

  • 0755：用户有rwx，组和其他有r-x；
  • 0644：用户有rw-，组和其他有r–。

关键规则：

  • 目录的x权限是“进入目录”的必要条件（即使有r权限，无x则无法列出目录内容）；
  • 文件的x权限是“执行文件”的必要条件（对HDFS而言，通常仅脚本或可执行文件需要）。
2.2.2 ACL的补充逻辑

当需要给特定用户/组额外权限时，ACL（访问控制列表）是解决方案。HDFS的ACL支持两种条目：

  1. 访问条目（Access Entry）：允许或拒绝主体的操作；
  2. 默认条目（Default Entry）：为目录的子文件/目录设置默认权限（仅目录有效）。

ACL的格式为：type:name:perm，其中：

  • type：user（用户）、group（组）、other（其他）、mask（掩码，限制组和其他的权限）；
  • name：用户或组的名称（other无需名称）；
  • perm：rwx的组合。

示例：给用户bob授予/user/alice目录的读写权限：

hadoop fs -setfacl -m user:bob:rw- /user/alice

ACL与POSIX的协同规则：

  1. 若存在ACL条目，优先检查ACL；
  2. mask条目会覆盖组的基础权限（例如，若mask是r--，则组的w权限会被屏蔽）；
  3. other条目与POSIX的o权限一致。

2.3 理论局限性：POSIX+ACL的不足

尽管POSIX+ACL满足了基础需求，但仍有以下局限：

  • 无集中管理：权限配置分散在每个文件/目录，大规模集群下难以维护；
  • 无跨服务协同：Hive、Spark等计算引擎的权限无法与HDFS统一（例如，Hive表的权限无法自动同步到 underlying HDFS文件）；
  • 无动态调整：无法根据用户行为（如访问频率）动态调整权限；
  • 无细粒度审计：仅能记录NameNode的操作日志，无法关联数据血缘。

2.4 竞争范式分析：从RBAC到ABAC

为解决POSIX+ACL的不足，工业界提出了更高级的访问控制模型：

  1. RBAC（角色-Based访问控制）：将权限分配给角色，用户通过关联角色获得权限（如data_scientist角色拥有/user/data的读权限）；
  2. ABAC（属性-Based访问控制）：基于主体属性（如部门、职位）、资源属性（如数据分类、敏感度）、环境属性（如时间、IP）动态授权（如“仅允许风控部门在工作时间访问敏感数据”）。

HDFS的企业级解决方案（如Apache Ranger）已支持RBAC，并逐步向ABAC演进。

3. 架构设计：HDFS权限管理的组件与交互

HDFS权限管理的架构是分布式与集中式的结合，核心组件包括NameNode、Kerberos KDC、Apache Ranger Admin，以及客户端。

3.1 系统分解：核心组件的角色

组件 角色 核心功能
NameNode 权限检查核心 存储文件元数据（权限、ACL）；处理客户端的权限请求；与Ranger同步政策
Kerberos KDC 身份认证中心 发放TGT（票据授予票据）和服务票据；验证用户身份
Apache Ranger Admin 集中权限管理 定义全局权限政策（如“允许data_scientists组读/user/data”）；同步政策到NameNode；记录审计日志
客户端 权限上下文载体 获取Kerberos票据；向NameNode发送权限请求；执行文件操作
DataNode 数据存储节点 存储数据块；根据NameNode的指令提供数据（不直接做权限检查，除非启用加密区域）

3.2 组件交互模型：权限检查的完整流程

以下是客户端读取HDFS文件的权限检查流程（Mermaid流程图）：

DataNode NameNode Apache Ranger Admin Kerberos KDC 客户端 DataNode NameNode Apache Ranger Admin Kerberos KDC 客户端 alt [权限通过] [权限拒绝] 请求TGT（使用用户名/密码） 返回TGT 请求NameNode服务票据（使用TGT） 返回服务票据 发送读请求（携带服务票据） 验证服务票据有效性 确认身份合法 查询该用户的权限政策 返回允许的操作（如read） 检查本地POSIX权限/ACL 指示DN提供数据块 返回数据块 返回PermissionDeniedException 记录审计日志（用户、操作、资源、结果）

3.3 可视化表示：HDFS权限管理架构图

1. 身份认证
2. 权限请求
3. 政策查询
4. 元数据检查
5. 数据指令
6. 审计日志
7. 身份验证

客户端

Kerberos KDC

NameNode

Apache Ranger Admin

HDFS元数据存储

DataNode

Elasticsearch/Kibana

3.4 设计模式应用：权限检查的实现技巧

HDFS权限管理的核心设计模式包括：

  1. 拦截器模式（Interceptor）：NameNode通过拦截器（如AccessControlInterceptor）拦截所有客户端请求，执行权限检查；
  2. 观察者模式（Observer）：Ranger政策变更时，通过观察者模式通知NameNode同步政策（避免轮询）；
  3. 缓存模式（Cache）：NameNode缓存Ranger政策（默认缓存1分钟），减少对Ranger的请求次数，提升性能；
  4. 责任链模式（Chain of Responsibility）：权限检查按“Kerberos认证→Ranger政策→POSIX权限→ACL”的顺序执行，前一步通过才进入下一步。

4. 实现机制：从代码到性能优化

本节将深入HDFS权限管理的实现细节，包括算法复杂度、代码示例、边缘情况处理。

4.1 算法复杂度分析：NameNode的权限检查

NameNode的权限检查性能直接影响整个集群的吞吐量，其核心操作的复杂度如下：

  • Kerberos认证：O(1)（验证服务票据的有效性，依赖对称加密）；
  • Ranger政策查询：O(1)（缓存命中时）或O(log n)（缓存未命中时，Ranger内部用索引查询政策）；
  • POSIX权限检查：O(1)（直接读取文件元数据的mode属性）；
  • ACL检查：O(k)（k为ACL条目的数量，通常k很小，因此可视为O(1)）。

结论：NameNode的权限检查是常数时间复杂度，不会成为集群的性能瓶颈（除非Ranger政策数量级达到百万级，此时需优化缓存策略）。

4.2 优化代码实现：从命令行到Java API

4.2.1 命令行工具：基础权限操作
  • 设置POSIX权限： 
    # 给/user/alice目录设置755权限（用户rwx，组r-x，其他r-x）
hadoop fs -chmod 755 /user/alice
  • 设置ACL： 
    # 给用户bob授予/user/alice的rw权限
hadoop fs -setfacl -m user:bob:rw- /user/alice
# 查看ACL
hadoop fs -getfacl /user/alice
  • 删除ACL： 
    hadoop fs -setfacl -x user:bob /user/alice
4.2.2 Java API：自定义权限检查

以下是使用Hadoop Java API检查文件权限的示例：

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.fs.permission.AclEntry;
import org.apache.hadoop.fs.permission.FsPermission;
import org.apache.hadoop.security.UserGroupInformation;

import java.io.IOException;
import java.util.List;

public class HdfsPermissionExample {
    public static void main(String[] args) throws IOException {
        // 1. 初始化配置（需指定core-site.xml和hdfs-site.xml路径）
        Configuration conf = new Configuration();
        conf.set("fs.defaultFS", "hdfs://namenode:9000");

        // 2. 登录Kerberos（若启用Kerberos）
        UserGroupInformation.setConfiguration(conf);
        UserGroupInformation.loginUserFromKeytab("alice@EXAMPLE.COM", "/path/to/alice.keytab");

        // 3. 获取FileSystem实例
        FileSystem fs = FileSystem.get(conf);
        Path path = new Path("/user/alice/data.txt");

        // 4. 检查POSIX权限
        FsPermission permission = fs.getFileStatus(path).getPermission();
        System.out.println("POSIX权限: " + permission);

        // 5. 检查ACL
        List<AclEntry> acls = fs.getAclStatus(path).getEntries();
        System.out.println("ACL条目:");
        for (AclEntry acl : acls) {
            System.out.println(acl.getType() + ":" + acl.getName() + ":" + acl.getPermission());
        }

        // 6. 检查是否有读权限
        boolean hasReadPermission = fs.access(path, FsAction.READ);
        System.out.println("是否有读权限: " + hasReadPermission);
    }
}
4.2.3 Ranger API：集中管理权限政策

Apache Ranger提供REST API用于创建/查询权限政策，以下是使用curl创建政策的示例：

# 创建政策：允许data_scientists组读/user/data目录
curl -u admin:admin -X POST -H "Content-Type: application/json" \
http://ranger-admin:6080/service/public/v2/api/policy \
-d '{
    "serviceName": "hdfs",
    "name": "data_scientists_read_access",
    "resources": {
        "path": ["/user/data"]
    },
    "policyItems": [
        {
            "accesses": [{"type": "read"}],
            "users": [],
            "groups": ["data_scientists"],
            "roles": []
        }
    ],
    "enabled": true
}'

4.3 边缘情况处理：避免权限漏洞

4.3.1 超用户的权限豁免

HDFS的超用户（默认是hdfs）拥有所有权限，包括绕过POSIX/ACL/Ranger政策的能力。最佳实践：

  • 限制超用户的使用（仅用于集群维护）；
  • 通过Ranger的“Superuser Policy”限制超用户的操作（如禁止删除重要目录）。
4.3.2 回收站的权限管理

HDFS的回收站（/user/<username>/.Trash）默认保存删除的文件30天。风险：若用户删除文件后，其他用户可访问其回收站中的文件（因为回收站的权限继承自用户目录）。解决方案：

  • 设置回收站目录的权限为700（仅用户自己可访问）；
  • 定期清理回收站（如通过 cron 任务）。
4.3.3 跨集群复制的权限同步

使用distcp复制跨集群数据时，需确保目标集群的权限与源集群一致。解决方案：

  • 使用-p参数保留权限（hadoop distcp -p /source /target）；
  • 若目标集群启用Ranger，需同步Ranger政策（可通过Ranger的REST API批量导入）。

4.4 性能考量：优化权限检查的吞吐量

  • 缓存Ranger政策：NameNode默认缓存Ranger政策1分钟（可通过dfs.ranger.policy.cache.ttl.ms调整），提升政策查询性能；
  • 减少ACL条目数量：ACL条目过多会增加NameNode的检查时间，建议优先使用RBAC（通过Ranger角色）；
  • 异步审计日志：Ranger的审计日志默认同步写入，可改为异步写入（ranger.audit.provider.async.enabled=true），减少对NameNode的影响；
  • 启用NameNode高可用：NameNode是权限检查的单点，需启用HA（Active-Standby）确保高可用性。

5. 实际应用：企业级落地的最佳实践

本节将结合真实场景，讲解HDFS权限管理的落地步骤与注意事项。

5.1 实施策略：分步推进的四阶段

企业落地HDFS权限管理需遵循“先基础后高级，先认证后授权”的原则，分为四个阶段：

阶段1：启用Kerberos认证（强身份验证）

Kerberos是Hadoop生态的标准认证协议，需先部署KDC（Key Distribution Center），再配置HDFS、YARN、Hive等组件使用Kerberos。步骤：

  1. 安装KDC（如MIT Kerberos或Active Directory）；
  2. 为HDFS服务创建主体（如namenode/node1.example.com@EXAMPLE.COM）；
  3. 配置core-site.xml启用Kerberos： 
    <property>
    <name>hadoop.security.authentication</name>
    <value>kerberos</value>
</property>
  4. 为用户生成keytab文件（如alice.keytab），用于无密码登录。
阶段2：配置基础POSIX权限（粗粒度隔离）

启用Kerberos后，需为每个用户/组配置基础权限，确保部门间数据隔离。示例：

  • 为data_scientists组创建目录/user/data_scientists，权限设为770（仅组内用户可访问）；
  • 为analysts组创建目录/user/analysts，权限设为770。
阶段3：引入ACL（细粒度授权）

当基础权限无法满足需求时，使用ACL补充特定用户的权限。示例：

  • 允许alice（属于data_scientists组）写入/user/analysts目录： 
    hadoop fs -setfacl -m user:alice:rwx /user/analysts
阶段4：集成Apache Ranger（集中管理）

当集群规模超过100节点或用户数量超过500时，需使用Ranger实现集中权限管理。步骤：

  1. 安装Ranger Admin（需依赖MySQL/PostgreSQL、Solr）；
  2. 在Ranger中注册HDFS服务（输入NameNode地址、Kerberos主体）；
  3. 创建角色（如data_scientist），并关联权限（如/user/data的读权限）；
  4. 将用户添加到角色中（如将alice添加到data_scientist角色）；
  5. 配置NameNode同步Ranger政策（修改hdfs-site.xml）： 
    <property>
    <name>dfs.permissions.enabled</name>
    <value>true</value>
</property>
<property>
    <name>dfs.ranger.enabled</name>
    <value>true</value>
</property>
<property>
    <name>dfs.ranger.admin.url</name>
    <value>http://ranger-admin:6080</value>
</property>

5.2 集成方法论：与计算引擎的协同

HDFS的权限需与Hive、Spark等计算引擎协同，确保“SQL操作的权限与HDFS文件权限一致”。示例：

  • Hive集成：Hive的表权限（如GRANT SELECT ON TABLE my_table TO GROUP data_scientists）需同步到HDFS的 underlying 文件（/user/hive/warehouse/my_table）；
  • Spark集成：Spark作业的运行用户需与HDFS的用户一致（通过spark.yarn.principal和spark.yarn.keytab配置）。

5.3 部署考虑因素：高可用与灾备

  • NameNode HA：启用Active-Standby NameNode，确保权限检查服务的高可用性；
  • Ranger HA：部署多个Ranger Admin节点（通过负载均衡器访问），避免单点故障；
  • Kerberos灾备：部署备用KDC，确保认证服务的连续性；
  • 数据加密：启用HDFS的透明数据加密（TDE），即使权限泄漏，数据也无法被读取（通过dfs.encryption.zones.enabled配置）。

5.4 运营管理：监控与审计

  • 监控权限变更：使用Ranger的审计日志（存储在Solr或Elasticsearch）监控权限变更，如“谁修改了/user/data的政策”；
  • 定期权限审计：每月审计一次权限政策，删除不再需要的权限（如离职用户的权限）；
  • 处理权限申诉：建立权限申诉流程（如通过Jira），用户可申请访问特定数据，管理员审核后授予权限；
  • 应急响应：若发生权限泄漏（如用户非法访问数据），需立即：
    1. 禁用该用户的Kerberos主体；
    2. 撤销该用户的所有权限；
    3. 分析审计日志，定位泄漏原因；
    4. 修复权限政策，防止再次发生。

6. 高级考量：云原生与未来演化

随着大数据向云原生、AI方向发展，HDFS权限管理需应对新的挑战与机遇。

6.1 扩展动态：云原生HDFS的权限管理

云厂商的HDFS服务（如AWS EMR、Cloudera Data Platform CDP）已集成托管式权限管理，无需企业自行部署Kerberos、Ranger：

  • AWS EMR：使用IAM（Identity and Access Management）管理HDFS权限，支持角色-Based访问；
  • CDP：集成Cloudera Ranger和Cloudera Atlas，实现“权限+数据血缘”的统一治理；
  • 阿里云EMR：支持RAM（Resource Access Management）与Kerberos的协同，兼容开源HDFS的权限模型。

6.2 安全影响：AI时代的权限风险

AI模型训练需要访问大量数据，若权限管理不当，可能导致数据泄漏或模型中毒（攻击者注入恶意数据）。应对策略：

  • 数据分类：将数据分为“公开”“内部”“敏感”三级，为每级数据设置不同的权限（如敏感数据仅允许AI工程师在隔离环境中访问）；
  • 模型权限：限制AI模型的输出权限（如禁止模型输出敏感数据）；
  • 行为分析：使用AI工具（如Ranger的Anomaly Detection）检测异常访问（如某用户突然访问大量敏感数据）。

6.3 伦理维度：数据隐私与合规

欧盟GDPR、中国《个人信息保护法》等法规要求数据最小权限原则（即用户仅能访问完成工作所需的最少数据）。实践建议：

  • 权限最小化：授予用户权限时，遵循“按需分配”原则（如仅允许读取某张表的部分列）；
  • 数据脱敏：对敏感数据（如手机号、身份证号）进行脱敏处理（如替换为哈希值），即使权限泄漏，也无法获取原始数据；
  • 审计追溯：保留至少6个月的审计日志，确保合规检查时可溯源。

6.4 未来演化向量：零信任与AI驱动

HDFS权限管理的未来趋势包括：

  1. 零信任架构（Zero Trust）：遵循“永不信任，始终验证”的原则，即使用户在企业内网，也需重新认证（如多因素认证MFA）；
  2. AI驱动的权限推荐：通过分析用户的历史访问行为，自动推荐合适的权限（如“用户alice最近经常访问/user/data，建议授予读权限”）；
  3. 实时权限调整：根据环境变化（如用户的IP地址变为外部网络），实时调整权限（如禁止外部IP访问敏感数据）；
  4. 跨云权限同步：支持多云环境下的权限统一管理（如AWS EMR与Azure HDInsight的权限同步）。

7. 综合与拓展：从技术到战略

7.1 跨领域应用：数据湖与湖仓一体的权限管理

HDFS是数据湖的核心存储，湖仓一体架构（如Delta Lake、Apache Iceberg）的权限管理需与HDFS协同：

  • Delta Lake：使用HDFS的权限模型管理Delta表的元数据和数据文件；
  • Apache Iceberg：支持Iceberg的权限政策与HDFS的权限政策同步（通过Ranger集成）。

7.2 研究前沿：ABAC与区块链的结合

学术界正在研究基于区块链的ABAC模型，用于HDFS的权限管理：

  • 区块链存储权限政策（不可篡改）；
  • ABAC模型根据主体、资源、环境属性动态授权；
  • 解决Ranger的“单点故障”问题（区块链的去中心化特性）。

7.3 开放问题：大规模集群的权限一致性

当集群规模超过1000节点或用户数量超过10000时，权限政策的一致性成为挑战：

  • 如何确保所有NameNode节点的Ranger政策缓存一致？
  • 如何快速同步权限变更（如删除一个用户的所有权限）？
  • 如何处理跨数据中心的权限同步？

7.4 战略建议：企业的权限管理 roadmap

  1. 短期（0-6个月）：启用Kerberos认证，配置基础POSIX权限；
  2. 中期（6-12个月）：引入ACL和Ranger，实现集中管理；
  3. 长期（12+个月）：升级到ABAC模型，集成AI驱动的权限推荐，支持云原生与跨云管理。

结语：权限管理是大数据安全的基石

HDFS权限管理不是“一次性配置”，而是持续的过程——需随着集群规模、业务需求、法规要求的变化不断优化。本文从理论到实践，覆盖了HDFS权限管理的全生命周期，希望能帮助企业建立“认证-授权-审计”的完整安全链路，保障大数据资产的安全。

正如《Hadoop权威指南》作者Tom White所说：“HDFS的权限管理不是障碍，而是保护数据价值的必要手段”。只有做好权限管理，大数据才能真正成为企业的核心竞争力。

参考资料

  1. Hadoop官方文档：https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html
  2. Apache Ranger官方文档：https://ranger.apache.org/
  3. 《Hadoop权威指南》（第4版），Tom White著
  4. NIST大数据安全标准：SP 800-189
  5. Cloudera数据治理白皮书：https://www.cloudera.com/content/dam/cloudera/resources/whitepapers/data-governance-whitepaper.pdf
# hdfs # hadoop # 大数据
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

cover

【IDEA小说阅读】W-Reader：支持在线搜索的IDEA小说阅读插件

avatar 2048 AI社区
cover

有没有能保留原文意思，又能降重降AI的软件？

avatar 2048 AI社区

上下文协议（MCP）Java SDK 指南

我们先通过这个类，定义一个非常简单的 MCP 工具，用来打印收到的提示词（prompt），该方法返回一个.build();});这里我们首先定义了输入的 JSON Schema，用来为用户输入建立一个清晰的契约。接着，使用该输入 Schema 来实例化一个Tool，在处理逻辑中提取出prompt参数，并最终返回包含该prompt的结果。在本文中，我们首先回顾了 MCP 及其 Java SDK 的整

avatar 2048 AI社区