一、 为什么需要“多租户”？一个简单的比喻

想象一下，你管理着一栋大型写字楼（这就是我们的Hadoop集群）。这栋楼里有水、电、网络等公共资源（对应集群的CPU、内存、磁盘I/O、网络带宽）。现在，有A、B、C三家公司（租户）要入驻。

如果没有管理，会怎样？A公司可能因为搞大型活动，把整栋楼的电都用光了，导致B和C公司无法办公。或者，C公司的员工可能不小心走进了A公司的办公室，看到了不该看的商业文件。

这显然不行！所以，我们需要做两件事：

  1. 资源隔离：给每家公司分配固定的电额度、网络带宽，确保一家公司的狂欢不会影响其他公司的正常运营。
  2. 权限管理：给每家公司独立的门禁和办公室钥匙，确保他们只能进入自己的区域，访问自己的文件。

在Hadoop世界里，“多租户”就是这个意思。让多个团队或项目（租户）共享同一个庞大的集群，但又能公平地使用资源，并且数据彼此隔离，互不干扰。这能极大提升硬件利用率，降低成本。

二、 资源隔离的核心：YARN队列与容量调度器

Hadoop的资源管理由YARN负责。它就像这栋写字楼的“物业管理中心”。实现资源隔离，主要靠配置Capacity Scheduler（容量调度器） 和它的队列。

技术栈：Apache Hadoop 3.x

队列可以理解成物业划分好的“资源包”。我们通过配置capacity-scheduler.xml文件来定义这些包。

示例1：配置一个基础的、支持多租户的队列结构 假设我们有“平台部”和“业务部”两个大租户，业务部下又有“数据分析组”和“算法组”两个小团队。

<!-- 文件：$HADOOP_HOME/etc/hadoop/capacity-scheduler.xml -->
<!-- 技术栈：Apache Hadoop 3.x -->

<!-- 1. 启用容量调度器 -->
<property>
    <name>yarn.resourcemanager.scheduler.class</name>
    <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
</property>

<!-- 2. 定义根队列下的子队列 -->
<property>
    <name>yarn.scheduler.capacity.root.queues</name>
    <value>platform, business</value> <!-- 根队列下有两个一级队列：平台部和业务部 -->
</property>

<!-- 3. 为一级队列分配资源容量（百分比） -->
<property>
    <name>yarn.scheduler.capacity.root.platform.capacity</name>
    <value>40</value> <!-- 平台部占用集群40%的资源 -->
</property>
<property>
    <name>yarn.scheduler.capacity.root.business.capacity</name>
    <value>60</value> <!-- 业务部占用集群60%的资源 -->
</property>

<!-- 4. 在‘business’队列下再创建子队列 -->
<property>
    <name>yarn.scheduler.capacity.root.business.queues</name>
    <value>analytics, algorithm</value> <!-- 业务部下分两个二级队列 -->
</property>

<!-- 5. 为二级队列分配其父队列（business）的资源 -->
<property>
    <name>yarn.scheduler.capacity.root.business.analytics.capacity</name>
    <value>70</value> <!-- 数据分析组占用业务部70%的资源，即集群总资源的60%*70%=42% -->
</property>
<property>
    <name>yarn.scheduler.capacity.root.business.algorithm.capacity</name>
    <value>30</value> <!-- 算法组占用业务部30%的资源，即集群总资源的60%*30%=18% -->
</property>

<!-- 6. 设置用户限制，防止单个用户独占队列 -->
<property>
    <name>yarn.scheduler.capacity.root.business.analytics.user-limit-factor</name>
    <value>2</value> <!-- 单个用户最多可以使用该队列（analytics）2倍的额定容量，即84%的业务部资源，在资源空闲时 -->
</property>

<!-- 7. 设置最大容量，允许队列在兄弟队列空闲时借用其资源 -->
<property>
    <name>yarn.scheduler.capacity.root.business.analytics.maximum-capacity</name>
    <value>90</value> <!-- analytics队列最多可以占用其父队列（business）90%的资源，防止它完全饿死algorithm队列 -->
</property>

配置详解与关联技术：

  • 层级结构：队列是树形结构，资源从根队列向下分配。这非常灵活，可以匹配公司的组织架构。
  • 弹性与公平：capacity是保证的最低额度，maximum-capacity是能借到的最高额度，user-limit-factor控制用户级别的公平性。这三者结合，既保证了基本权益，又提高了整体资源利用率。
  • 队列映射：通常结合Linux的用户/用户组，通过配置yarn.scheduler.capacity.queue-mappings，将不同的Linux用户提交的任务自动路由到指定的队列。例如，用户alice属于analytics组，她提交的作业会自动进入business.analytics队列。

三、 数据权限的守护神：HDFS ACL与Kerberos

资源隔离了，但数据呢？HDFS自带的POSIX权限（user/group/others）有时不够用，比如你想让另一个组的特定用户也有读权限。这时就需要ACL（访问控制列表）。

示例2：使用HDFS ACL进行精细化的文件权限控制 假设/data/sales目录属于platform:sales团队，现在需要让business.analytics组的bob用户有读权限，同时让platform组的admin用户有全部权限。

# 技术栈：Apache Hadoop HDFS Shell

# 1. 首先，检查并启用ACL功能（通常在hdfs-site.xml中设置 dfs.namenode.acls.enabled=true）
# 假设已经启用。

# 2. 查看目录现有的默认权限和ACL
hdfs dfs -getfacl /data/sales
# 输出可能类似：
# user::rwx
# group::r-x
# other::r-x

# 3. 为目录设置默认ACL，这样在此目录下新建的文件/目录会自动继承这些权限
hdfs dfs -setfacl -m default:user:bob:r-x /data/sales
# -m: 修改ACL
# default: 设置默认ACL
# user:bob:r-x： 用户bob拥有读和执行权限

# 4. 同时，为现有目录本身也添加一条ACL条目，让bob现在就能访问
hdfs dfs -setfacl -m user:bob:r-x /data/sales

# 5. 为admin用户添加所有权限（rwx）
hdfs dfs -setfacl -m user:admin:rwx /data/sales

# 6. 再次查看ACL，确认设置成功
hdfs dfs -getfacl /data/sales
# 输出现在会增加：
# user:bob:r-x
# default:user:bob:r-x
# user:admin:rwx

权限管理的基石：Kerberos 以上ACL和用户映射，都基于一个前提：系统知道“你是谁”。在生产环境中，绝不能依靠简单的用户名，因为可以被伪造。这就需要Kerberos——一个网络认证协议。 你可以把它理解成一家高级会所。进入集群（会所）前，你必须先向Kerberos服务器（前台）证明身份，获取一个有时效的“票据”（Ticket）。之后在集群内的所有操作（访问HDFS、提交YARN作业），都需要出示这个票据，服务端会验证其真伪。这样，就实现了真正的、强制的用户身份认证，为后续的授权（ACL，队列映射）打下了坚实基础。没有Kerberos的多租户环境，就像用纸糊的锁看门，极不安全。

四、 实践中的关键点与场景分析

应用场景：

  1. 大型企业数据平台：不同事业部共享集群，核心数据团队（平台部）保障基础设施，业务部门专注应用。
  2. 云服务提供商：为多个外部客户提供Hadoop即服务（HaaS），必须实现严格的资源与数据隔离。
  3. 高校或研究机构：不同院系、实验室的项目共享计算资源，避免重复建设。

技术优缺点：

  • 优点：
    • 成本效益：硬件集中，利用率高，避免“烟囱式”集群。
    • 管理统一：运维、监控、升级在一个点进行，效率高。
    • 弹性共享：资源可动态调配，应对波峰波谷。
  • 缺点：
    • 配置复杂：队列设计、ACL、Kerberos集成需要精细规划。
    • “吵闹的邻居”：虽然隔离了CPU/内存，但磁盘I/O和网络带宽的完全隔离较难，一个高IO任务可能影响他人。
    • 安全性要求高：一旦配置出错，可能导致数据泄露或越权访问。

注意事项：

  1. 规划先行：队列结构必须与组织结构匹配，并预留“default”队列处理未映射的任务。
  2. 容量设计：capacity不是静态的，需要根据业务增长定期回顾调整。初期可以设置得宽松一些（maximum-capacity较高）。
  3. 监控告警：必须对队列资源使用率（如Pending内存）、用户作业量进行监控，及时发现资源瓶颈或滥用。
  4. Kerberos是关键：不要试图跳过它。虽然引入后运维复杂度增加（如票据续期、Keytab管理），但这是生产级多租户的必选项。
  5. 结合其他技术：对于极致隔离需求，可以考虑结合Docker容器（通过YARN的DockerContainerExecutor）将任务跑在容器内，实现更彻底的环境隔离。

文章总结： Hadoop多租户管理，是一个“管理”问题在先，“技术”问题在后的系统工程。核心思想是通过YARN队列实现资源隔离，通过HDFS ACL和Kerberos实现权限控制。成功的秘诀在于：

  1. 清晰的蓝图：设计出贴合实际使用的队列和目录结构。
  2. 精细的规则：利用容量调度器的各项参数（容量、最大值、用户限制）平衡保障与弹性。
  3. 坚固的基石：部署Kerberos，构建不可伪造的身份体系。
  4. 持续的运营：配合监控工具，观察资源使用情况，并不断优化配置。

它并非一劳永逸，而是一个需要随着业务发展不断调整和优化的持续过程。当你妥善地配置好这一切，一个庞大、高效且井然有序的“数据写字楼”就能稳健运行，支撑起各类数据应用的蓬勃发展。