这两年但凡做大数平台不管你是给公司内部搭数据中台还是对外做 SaaS 化交付存储层的多租户问题早晚都会找上门。所谓多租户一句话讲清楚同一套分布式存储集群同时服务多个团队或者多个客户每个租户的数据、权限、配额相互独立该隔离的隔离该共享的共享谁也不能影响谁。很多人一开始会想这个问题不就是给每个部门开个 HDFS 目录吗真做起来才发现目录只是最浅的一层。租户怎么划分、权限靠什么管、配额怎么设、表数据和文件数据怎么对应、租户之间的共享怎么做、审计怎么追溯全套下来就是一个成体系的方案。这篇文章我把这两年做过的 HDFS、对象存储、湖仓多租户方案一次性梳理清楚包括具体命令、策略配置、踩坑记录适合数据平台工程师、架构师、运维同学参考想把自己平台对外开放的团队也能从这里找到头绪。1. 先搞清楚分布式存储里的多租户到底要解决什么1.1 数据平台发展到一定规模必然碰到的三个问题先说场景。公司内部的数据平台业务部门越来越多每个部门都要在集群上跑数、存数据第一个问题就是安全边界。你今天给市场部开了 HDFS 写权限明天市场部的实习生不小心把销售部的表目录删了一半这种事情在真实生产环境里一点不稀奇。数据不是不能共享但共享必须有边界、有审批而不是所有人对着同一个根目录裸奔。第二个问题是资源争抢。存储不是无限的就算集群有几百个节点也会被某些疯狂跑批的租户占满。我见过一个案例BI 团队在临时目录里囤了 30TB 数据不清理结果搞数据挖掘的同学往 HDFS 写任务时一直报 “Name node is in safe mode”一查才知道磁盘快满了。没有配额机制一个租户就能把全集群拖下水。第三个问题是成本归属。平台统一采购硬件、统一运维但每个部门用了多少存储、产生了多少副本占用到了年底分摊成本时一笔糊涂账。多租户方案解决了“用量可计量、归属可追踪”的问题租户的资源使用情况才能拆清楚。这三个问题叠加在一起结论就出来了存储层必须有能力把一个物理集群切分成若干个逻辑上独立的空间每个空间有自己的权限模型、资源额度、隔离策略和审计记录。这就是分布式存储多租户支持方案的真正目标。1.2 多租户隔离的三个层级存储层是最后一道防线很多人一提多租户就先想到计算层比如 Yarn 队列、Kubernetes 的 namespace但这远远不够。多租户隔离至少分三个层级接入层隔离谁能够连上集群认证怎么走用户和用户组怎么映射。这一层通常用 Kerberos、LDAP、IAM 来做。计算层隔离多个租户共享计算资源通过队列、容器、调度策略来限制资源用量。存储层隔离数据放在哪里、谁能读、谁能写、能写多少、数据是否可见由文件系统、对象存储、数据目录系统来保证。三个层级里存储层是最容易被忽视但最关键的一道防线。计算层隔离做得再好如果存储层的权限没控制住租户 A 照样可以绕过计算引擎直接读 HDFS 上的文件。存储层出问题整个隔离体系就会从底部被击穿。所以做多租户方案不管上层用了多少组件存储层必须有一套独立的、不可绕过的权限模型和配额模型。1.3 一份合格的存储层多租户方案至少要具备这四个能力结合我自己的项目经验评估一个多租户方案是否完整我会看四个能力逻辑隔离能力每个租户有一个明确的存储边界比如 HDFS 下的一个根目录或者对象存储下的一个 Bucket。租户之间默认不可见只有显式授权才能跨租户访问。配额管控能力支持按租户设置空间配额和文件数量配额。空间配额针对“数据量有多大”文件数配额针对“元数据量有多大”两者要同时管。多维权限控制能力不光是给定目录读和写的粗粒度权限还要支持库表列级别、甚至行级别的访问控制。底层的 POSIX 权限管不了业务语义需要 Ranger 这类集中式授权组件配合。审计追溯能力谁在什么时间访问了哪个路径、执行了哪些操作必须有日志和报表。租户之间发生越权争议时能追溯到具体操作者。这四个能力全部到位才能算是真正“支持多租户”否则只是做了个目录规范。2. 主流分布式存储的多租户实现路线怎么选2.1 HDFS目录加权限加配额的三板斧传统 HDFS 上的多租户方案本质上是“目录命名空间 POSIX 权限 ACL 配额”的组合拳。最常见的做法是设定一套统一的根路径规范比如/data/tenant_{租户ID}/{数仓分层}每个租户的目录归对应的租户管理员所有其他租户默认没有访问权限。这套方案的好处是简单直接HDFS 原生就支持不需要引入额外的元数据服务。但对权限的控制能力比较粗糙POSIX 权限只有 owner、group、other 三类角色粒度不够细。所以生产环境基本都会加一层Ranger在 HDFS 之上做基于资源的授权策略把用户、用户组、路径、权限组合起来管理。Ranger 的好处是策略集中维护、支持底层 HDFS 和上层 Hive、HBase 统一授权审计日志也全部收拢到一个平台。如果租户多到一定程度还可以考虑 HDFS Federation 配合 ViewFS把一个物理集群拆成多个命名空间每个租户或租户组挂载不同的逻辑路径。但这个方案运维复杂度明显上升不是租户量级达到几十上百我不太建议一上来就上。2.2 对象存储以 Bucket 为天然的租户边界对象存储做多租户比 HDFS 更有天然优势核心原因是Bucket 就是规整的隔离单元。以 MinIO、Ceph RGW 或者各类云上对象存储为例每个租户分配独立的 Bucket通过 IAM 策略、Bucket Policy 控制谁能访问哪个 Bucket配合 STS 临时凭证还可以做细粒度的临时授权。对象存储的权限模型是显式的策略模型默认 Deny显式 AllowDeny 优先。只要把租户 A 的 IAM 用户或角色限定在它的 Bucket 资源 ARN 范围内租户 A 就碰不到租户 B 的数据。相比 HDFS 的 POSIX 权限对象存储的隔离粒度更加刚性。同时 Bucket 还可以配置生命周期规则、跨区域复制、服务端加密、访问日志这些功能天然适合租户隔离。对于大数据场景对象存储通常承担两件事一是作为数据湖的底座Hive、Spark、Trino 都可以直接读写 S3 协议的数据二是作为离线归档存储把 HDFS 里的冷数据转储过来。对象存储和 HDFS 的多租户方案是可以共存的一个管数据湖底座一个管生态兼容性。2.3 湖仓一体时代Catalog 和命名空间成为新的隔离面现在越来越多平台采用湖仓一体架构用 Iceberg、Delta Lake、Paimon 这类表格式把数据组织成一张张“表”再通过 Hive Metastore 或者 Iceberg REST Catalog 来管理元数据。这种情况下多租户的隔离面从“文件目录”上移到“Catalog 和命名空间”。逻辑上你可以给租户 A 分配一个独立的 Catalog或者在一个 Catalog 下给租户分配独立的 namespace再通过 Ranger 策略控制对 database、table、column 的访问。这个方案的优势是业务语义更清楚租户看到的是库表不是裸文件路径。底层的存储路径往往统一放在一个大数据桶或一个大目录下由 Catalog 层做逻辑映射。湖仓多租户的一个关键设计点是元数据必须跟着租户走。比如一个 Iceberg 表它的元数据文件、manifest 文件、数据文件都要落在这个租户自己的存储路径下Catalog 里的归属关系也要准确。否则权限策略虽然控制了表的读但底层数据的物理路径如果暴露给其他人还是有绕过的风险。所以湖仓方案里存储层的路径规划和权限控制反而更加重要。2.4 三条路线的横向对比评估维度HDFS 目录方案对象存储 Bucket 方案湖仓 Catalog 方案隔离粒度目录级粗粒度Bucket 级天然隔离Catalog/Namespace表级语义清晰权限模型POSIXACLRanger 增强IAM/Bucket Policy显式 Deny 优先Ranger 统一支持行列级配额能力原生空间配额和文件数配额依赖账号/项目级资源组表数据统计底层存储配额租户共享需要单独授权共享目录通过 Bucket Policy 共享通过视图/共享 Catalog 实现适合场景传统数仓、离线 Hadoop 平台云原生数据湖、SaaS 存储服务湖仓一体、实时数仓、多业务线数仓运维复杂度中等较低较高需要元数据服务配套选哪条路线没有绝对答案。如果你的平台已经围绕 HDFS 构建就老老实实把 HDFS 的权限和配额做扎实如果是从零开始我更倾向于以对象存储为底座、以 Catalog 为逻辑隔离面的方案扩展性更好也更容易对接云原生生态。3. 实操落地HDFS Ranger 多租户配置的完整步骤3.1 租户目录与权限模型的规划设计我先讲一个最典型的组合底层 HDFS、上层 Hive用 Ranger 做统一授权。这个组合在真实生产环境中的覆盖率很高拿它做例子其他方案大同小异。第一步先做目录规范和权限模型设计。我建议每个租户使用独立的根路径目录名包含租户标识形如/data/tenant_a/ods /data/tenant_a/dwd /data/tenant_a/ads /data/tenant_a/tmpods放原始数据dwd放清洗后的明细数据ads放应用层数据tmp允许租户内所有成员写入但定期清理。目录的属主设成租户管理员用户属组设成租户自己的用户组比如tenant_a_admin和tenant_a_analyst。权限模型上我建议遵循“最小够用”原则租户管理员对根目录有全部权限租户内的普通成员对自己业务目录有读写权限其他租户一律不可见。跨租户访问必须通过平台审批流程显式授权而不是直接在集群上把 other 权限打开。底层 POSIX 权限尽量收紧到 750 或者 770再配合 Ranger 策略做上层控制两层叠加最稳妥。3.2 创建租户目录、ACL 与配额的命令实操把设计落到实际操作。首先创建租户目录以租户 tenant_a 为例hdfs dfs -mkdir -p /data/tenant_a/{ods,dwd,ads,tmp}然后修改属主和属组。假设tenant_a_admin是租户管理员用户tenant_a_group是租户用户组hdfs dfs -chown -R tenant_a_admin:tenant_a_group /data/tenant_a hdfs dfs -chmod -R 750 /data/tenant_a这里有个细节750 意味着租户组内成员只能进目录但不一定有权限读文件如果你希望租户内所有人都能浏览目录结构建议用755或770。我一般用770因为大数据平台上同一个租户内部通常协作比较紧密完全限制读列表会带来一堆排查上的麻烦。接着设置默认 ACL让租户组内用户在dwd目录下新建的文件默认继承组读写权限hdfs dfs -setfacl -R -m default:group:tenant_a_group:rwx /data/tenant_a/dwd如果不设置 default ACL租户成员新建的文件 owner 是自己group 是自己的主组可能就不是tenant_a_group导致组内其他人读不了。这个问题非常常见新手一般都会踩一次。然后是配额。配额一定和目录一起建好不要事后才想起来。设置空间配额之前先看看当前集群的存储总量和副本因子比如副本因子是 3那 1TB 逻辑数据实际占用约 3TB 物理空间# 文件数配额限制租户下最多 100 万个文件/目录项 hdfs dfsadmin -setQuota 1000000 /data/tenant_a # 空间配额限制租户逻辑数据总量为 1TB hdfs dfsadmin -setSpaceQuota 1t /data/tenant_asetSpaceQuota的数值建议按逻辑数据量除以压缩比来估。如果租户目录里既有 parquet 压缩数据又有临时文件我倾向于把配额设得比预期合理值高 20%避免业务正常增长天天触发告警。3.3 Ranger 策略配置的详细步骤与要点目录和配额只是基础设施真正的租户边界靠 Ranger 策略来定义。在 Ranger 里我们先创建 HDFS 服务对应集群的 NameNode。创建完成后每个租户的策略配置分成几步在 Ranger 中创建配置用户组注意要和 HDFS 上的实际 Unix 组保持一致。可以通过hadoop.security.group.mapping配成 LDAP 同步这样用户组不用手工维护。配置 HDFS 资源策略Resource Path 写成/data/tenant_a/*Select User 填租户管理组Select Permissions 勾选 Read、Write、Execute。这就是租户管理员的主策略。配置租户内的普通成员策略Resource Path 写成/data/tenant_a/{ods,dwd,ads}/*权限只给 Read 和 Write不给 Execute 也没关系HDFS 上用数据主要靠读和写。实际执行时需要能进入目录所以路径写对很关键。下面是一个简化版的 Ranger HDFS 策略 JSON 示例实际生产可以用 Ranger UI 配置也可以通过 API 导入{ serviceType: hdfs, name: tenant_a_hdfs_policy, isEnabled: true, policyItems: [ { users: [tenant_a_admin], groups: [tenant_a_admins], accesses: [ { type: read, isAllowed: true }, { type: write, isAllowed: true }, { type: execute, isAllowed: true } ], delegateAdmin: false }, { users: [], groups: [tenant_a_analysts], accesses: [ { type: read, isAllowed: true }, { type: write, isAllowed: true } ], delegateAdmin: false } ], resources: { path: { values: [/data/tenant_a/*], isRecursive: true } }, auditEnabled: true }这里有个很重要的点要说一下Ranger 里的delegateAdmin一旦勾选意味着这个用户/用户组可以给其他人授予权限一般只给平台管理员或租户管理员。普通成员千万不要给这个权限否则租户自己就能放宽策略隔离就名存实亡了。配完 HDFS 策略后还要在 Hive 服务里配库表权限。租户 A 的库做成tenant_a_db然后再按表或者按列配置策略。如果需要列级脱敏或行级过滤Ranger Hive 插件支持 column mask 和 row filter可以在不改变底层数据的情况下让不同角色看到不同粒度的数据。这个在业务上很实用比如财务数据只允许管理员看完整字段分析人员只能看到脱敏后的值。3.4 配置背后的原理为什么这样设置就能生效很多运维同学会好奇Ranger 的策略到底是怎么生效的其实原理不复杂。集群里每个需要接入授权的组件比如 NameNode、HiveServer2都内置了一个 Ranger 插件。插件会周期性从 Ranger Admin 拉取策略本地缓存后在每次请求进来时执行授权判断。你改了 Ranger 策略不会立刻全集群生效默认的刷新间隔通常在一分钟左右有的环境是 30 秒。为什么要同时保留 HDFS POSIX 权限和 Ranger 策略呢我个人的理解是它们是两道不同的校验。Ranger 策略管的是“业务规则层面谁可以访问哪个路径哪张表”而 POSIX 权限管的是“文件系统层面用户是否具备操作权限”。生产环境里最稳妥的做法是让两道校验协同工作而不是只依赖一个。这样即便 Ranger 插件挂了或者策略刷新出问题底层文件系统权限仍然挡得住未授权访问。这里也提醒一句不要随便在 HDFS 上给hdfs超级用户设置“免密登录全权操作”的共享账号方便是一时的出事是必然的。日常操作要用真实身份账号所有访问都落到审计日志里这样才能在租户间出现越权争议时查得清楚。4. 对象存储与湖仓方案S3 策略和 Catalog 隔离配置参考4.1 对象存储租户隔离的 IAM 策略配置示例如果你的数据湖底座选的是对象存储最常见的做法是一个租户一个 Bucket一个租户一个 IAM 用户或 IAM 角色。以兼容 S3 的 MinIO 为例假设租户 A 的 Bucket 叫tenant-a-bucket给租户 A 的角色配置一个最小权限策略{ Version: 2012-10-17, Statement: [ { Sid: TenantAReadWrite, Effect: Allow, Action: [ s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket ], Resource: [ arn:aws:s3:::tenant-a-bucket, arn:aws:s3:::tenant-a-bucket/* ] } ] }这样配置之后租户 A 的角色只能读写自己的 Bucket。再补充一条显式 Deny防止因为其他策略误授予了跨租户访问权限{ Version: 2012-10-17, Statement: [ { Sid: DenyOtherTenantBuckets, Effect: Deny, Action: s3:*, Resource: [ arn:aws:s3:::tenant-b-bucket, arn:aws:s3:::tenant-b-bucket/*, arn:aws:s3:::tenant-c-bucket, arn:aws:s3:::tenant-c-bucket/* ] } ] }IAM 里面 Deny 优先于 Allow只要条件里显式 Deny 了其他租户的桶不管其他策略怎么允许都无法访问。这个配置的好处是“默认拒绝、显式放行、强制否定边界”思维模型和 HDFS 的 POSIX 权限完全不同但防护效果更明确。4.2 生命周期、加密和访问日志等配套设置对象存储做租户隔离不只是权限的事运维层面还有很多配套项要设。生命周期规则是必须的比如租户的临时目录 7 天自动清理日志目录 30 天转归档、90 天删除。拿 MinIO 的 Bucket Lifecycle 配置举例{ Rules: [ { ID: expire-tmp-7d, Filter: { Prefix: tmp/ }, Status: Enabled, Expiration: { Days: 7 } } ] }这个规则要结合租户的目录规范来写所以做对象存储方案时路径设计也应该在创建 Bucket 之前就定好而不是让租户随便往桶里塞。加密方面建议开启服务端加密用 KMS 管理的密钥。每个租户可以用独立的 KMS Key这样可以做到加密密钥层面的隔离。审计方面对象存储的访问日志默认是关闭的需要单独开启并且日志要写入一个独立的管理员 Bucket租户自己无权访问。否则租户能看到自己的访问日志问题不大但如果日志里包含其他租户的请求信息那就是安全事故了。4.3 湖仓多租户Iceberg REST Catalog 与命名空间划分用 Iceberg 这类表格式搭建湖仓时多租户设计通常是两层物理存储层用 Bucket 或 HDFS 路径隔离元数据层用 Catalog/namespace 隔离。Iceberg REST Catalog 天然支持 namespace 概念。你可以为每个租户创建独立的 namespace比如tenant_a_ns然后设置该 namespace 的存储位置为s3://data-lake/tenant_a/warehouse。这样租户 A 的所有表数据、元数据文件都落在租户 A 自己的路径下。如果是 Hive Metastore 作为 Catalog也可以直接用 database 作为隔离单位CREATE DATABASE IF NOT EXISTS tenant_a_analytics LOCATION s3://data-lake/tenant_a/analytics/ WITH DBPROPERTIES ( owner tenant_a_admin, owner-type GROUP );数据湖的权限控制比传统数仓复杂因为查询引擎可能直接通过 S3 协议访问文件而不是走 HiveServer2。这个时候只靠 Catalog 权限是不够的底层存储的策略必须和 Catalog 权限同时生效。我一般建议的原则是底层存储路径和 Catalog 的 namespace 一一对应不允许任何租户、任何作业往其他 namespace 的路径下写文件这个限制通过 Ranger 在 HDFS/对象存储上兜底。5. 实战中反复踩过的坑以及排查思路5.1 权限配置生效很慢或被莫名拒绝Ranger 窗口期问题。我遇到最典型的案例在 Ranger 里给新租户加了一条策略业务方立刻去访问结果还是 Permission denied。查了半天发现 Ranger 插件默认 60 秒拉取一次策略新策略还没来得及同步到 NameNode 节点上。解决方法是把策略刷新间隔调短一些比如生产环境可以调成 30 秒或者配置完策略后手动刷新插件缓存。另一个原因是 HDFS 用户组没映射对。Ranger 策略里用的是 user group但是 HDFS 拿到的用户组是通过hadoop.security.group.mapping从系统或 LDAP 解析的两边对不上策略就永远不命中。排查时先执行hdfs groups 用户名确认用户组和 Ranger 里写的一致再做授权判断。5.2 配额明明没满却写不进去先查这三项第一种情况是 HDFS 的 Space Quota 按副本计算。租户数据明明只有 500GB配额给的是 1TB结果写不进去了。因为默认副本数是 3实际占用接近 1.5TB早就超了。这类问题在首次上线时特别多设置配额前一定要算副本因子。第二种情况是文件数配额满了。很多数仓有大量小文件1 个目录下几千万个文件很常见。这时候哪怕空间还剩好几百 GB文件数达到上限同样写不进去。排查命令hdfs dfs -count -q -h /data/tenant_a看输出的 Quota 和 Used 列对应空间和文件数两组数字。第三种情况是 Trash 没关闭或者没清理。HDFS 上删除文件默认先进回收站这些文件仍然占用空间且计入配额。规模大时Trash 里积压几百 GB 很正常。建议对租户临时目录单独设置较低的 fs.trash.interval或者制定定期清理策略。5.3 租户之间的数据共享如何设计才安全多租户并不是要完全砌死所有共享路径业务上常常需要租户之间互供数据。我推荐的方式是建立一个“共享发布区”。比如平台设立一个/data/shared/{数据集编号}的公共只读区域数据由产出方发布、平台管理员授权给指定租户的已读用户组消费方只有读权限写权限一律不给。不要在租户根目录之间建立互通的软链或者放开 other 权限。那样做短期内省事但权限面扩大了太多治理和审计都会失效。共享的数据一定要通过数据产品的方式登记说明数据负责人、更新频率、授权范围这样后续出问题才有追溯的基础。5.4 租户下线、迁移和审计要注意什么租户下线比上线更容易出问题。我的建议是分三个步骤来先把租户的状态置为只读禁止新的写入然后和业务方确认数据保留期把需要保留的数据通过 DistCp 或者对象存储复制接口迁移到归档空间最后再删除租户目录和对应策略。直接删除目录等于把审计痕迹和数据残留一起清掉了后续如果业务反悔要找回数据基本不可能。审计方面不要等到事后再补。Ranger 的审计日志从一开始就要接到统一的日志平台HDFS 的dfs.namenode.audit.log也要保留。租户管理员能看的范围应该严格限定在自己的租户相关路径上全量审计日志只有平台安全管理员能看。我见过有些团队把全量审计日志开放给租户管理员表面上是透明实际是放大了敏感信息暴露面。6. 最后分享几个我的个人经验多租户方案做得越多越觉得“能用”和“好用”之间隔着一条大沟。最早我接过一个平台项目租户目录建好了、配额设好了、Ranger 策略也配了结果用户一致抱怨不好用。后来复盘发现问题是权限模型做得太复杂一个用户要同时属于四五个组各种策略叠加之后自己也搞不清能不能访问哪些数据。后来我把角色简化成租户管理员、数据分析师、数据工程师三档并在访问界面上直接展示“我有哪些表的权限”体验立刻好了很多。另一个体会是多租户方案一定要尽早把审计做起来不要等出了数据安全事件再补。审计日志这东西平时用不上、用时真救命能帮你快速定位是谁在什么时间点读走了哪张表。最后一个小提醒不要把方案设计成一步到位的完美架构先从租户数量少、业务边界清晰的两个租户试点等目录规范、权限模型、配额策略、审计流程全部跑通再逐步扩展。多租户的核心不是一个炫酷的架构而是数据团队能够在这种隔离体系里持续高效地交付数据。