本地数据准备管道中的多客户项目隔离

为一个企业客户交付数据准备服务时，隔离很简单：只有一份数据集。当你同时管理五个、十个甚至二十个客户项目时，隔离就变成了一个运营问题，处理不好会带来法律、合规和质量风险。

这是一份写给 ML 服务提供商的技术指南，适用于同时为多个企业客户运行本地数据准备管道的团队。文章讲清楚隔离为什么重要、有哪些可选做法，以及如何在不让运维开销随客户数量线性增长的前提下实现项目分离。

为什么客户隔离重要

法律分离

每一次企业客户合作都在合同之下进行：主服务协议（MSA）、工作说明书（SOW）、保密协议（NDA），或者三者兼有。这类合同通常明确约定，客户的数据不得与其他客户的数据混同。如果客户 A 的训练数据被误放进客户 B 的导出文件，就构成合同违约。在受监管行业，这还可能同时构成监管违规。

数据保密

企业数据默认就是机密的。医疗客户的临床记录、律师事务所的特权文件、金融机构的交易流水，这些都不应该被正在做另一个客户项目的人看到。即使在你自己团队内部，访问权限也应该按项目划定范围。

训练数据交叉污染

这是最容易被低估的技术风险。如果客户 A 的数据混进了客户 B 的训练集，训练出来的模型就被污染了：它可能带上客户 A 所在领域的模式、术语或信息。这种事情真实发生过，通常出现在管道共用中间存储、导出脚本读取了错误的项目目录，或者标注队列没有正确过滤的时候。

审计追踪独立性

每个客户的数据谱系必须可以独立导出。当客户 A 要求一份审计报告、说明其数据经历过的每一次转换时，这份报告必须只包含他们自己的数据：不引用其他客户，不夹带共享的处理日志，也不留下来源含糊的记录。

客户隔离的几种做法

为每个客户单独安装一套

最保守的做法：为每个客户完整安装一套独立的工具实例。机器独立、存储独立、用户账户独立。

优势： 隔离程度最高。没有共享状态、没有共享存储、没有共享配置。

劣势： 运维开销随客户数量线性增长。十个客户意味着十套安装要维护、十份更新要打、十套环境要监控。对于一个要同时推进很多项目的小团队，这很快就撑不住了。

单一工具内的项目级隔离

一套安装，内置项目分离：每个客户的数据放在一个命名的、彼此隔离的项目里。项目之间不共享数据、标注、配置或导出产物。用户按显式权限被分配到项目上。

优势： 无论客户数量多少，运维开销都是恒定的。只有一套安装要维护，只有一份更新要打，项目之间切换也很快。

劣势： 前提是工具真的在项目级别强制执行隔离，既在界面上，也在存储层和审计追踪里。并非所有工具都做到了这一点。

RBAC（基于角色的访问控制）

在共享基础设施之上叠加访问控制。用户只看得到自己被授权访问的项目，管理员看得到全部项目。

优势： 灵活，适合部分成员需要跨多个客户工作的团队结构。

劣势： 单靠 RBAC 无法在管道层面阻止数据交叉污染。它挡住的是未授权的界面访问；如果底层管道共用存储或处理队列，RBAC 就只是一道界面上的护栏，算不上数据隔离保证。

文件系统隔离

每个客户的数据放在单独的文件系统路径、分区或卷上。管道脚本通过参数指定要操作的路径。

优势： 实现简单，任何工具都能配合。

劣势： 依赖纪律。一个路径参数配错，数据就会在项目之间泄漏。没有内置的强制机制，隔离的可靠程度完全取决于团队有多细心。

运营挑战：5 到 20 个并发项目

大多数 ML 服务提供商是在从 2 到 3 个并发项目扩张到 5 到 20 个的时候撞上隔离问题的。到了这个规模，为每个客户单独装一套的人均开销变得昂贵，而共享基础设施这类做法的风险也开始变得真实。

现实的问题是：如何在不搭建 15 套独立环境的前提下管理 15 个客户项目，同时仍然保证客户 A 的数据永远不会碰到客户 B 的管道？

这需要工具原生的隔离，也就是把隔离做进工具的数据模型里，而不是靠外挂的文件系统约定或 RBAC 覆盖层。每个项目都应该是一等实体，拥有自己的：

数据存储（摄取的文件、中间转换结果、最终导出物）
标注配置（分类体系、标注规范、标注员分配）
管道配置（清洗规则、增强设置、导出格式）
审计追踪（仅覆盖该项目、可独立导出的数据谱系）
命名（客户标签、项目标识、合作编号）

自建隔离与工具原生隔离

维度	自建（Docker + 脚本）	工具原生隔离
每个项目的搭建时间	2 到 4 小时（容器配置、卷挂载、脚本参数化）	几分钟（创建项目、分配团队）
交叉污染风险	中等（取决于脚本是否写对）	低（由工具架构强制保证）
每个客户的审计追踪	自行开发（导出逻辑要自己写）	内置（按项目导出数据谱系）
10 个项目时的维护量	高（10 个容器、10 份配置）	低（一套安装、10 个项目）
团队上下文切换	慢（切换容器、重新加载状态）	快（在工具内切换项目）
合规证据	需要从日志里拼凑	每个项目一份报告

自建方式在小规模下是够用的。一旦并发项目数超过团队可靠维护这套基础设施的能力，它就会垮掉。

审计追踪的要求

对受监管行业的企业客户来说，审计追踪本身就是一项交付物。每个客户都需要看到：

哪些数据进入了管道：源文件、格式、时间戳
应用了哪些转换：清洗规则、脱敏步骤、增强操作
由谁执行：标注这类人工步骤的操作人归属
导出了哪些数据：输出文件、格式、时间戳、行数
哪些被排除、为什么排除：未通过质量检查的记录、无法解析的文件

这份谱系必须能按客户单独导出，不出现对其他客户数据或操作的任何引用。如果你的审计追踪是一份覆盖所有项目的单一日志文件，交给客户之前就得先过滤和脱敏，而这个动作本身又会引入出错的风险。

落地实施

如果你打算自己搭，下面是最小可用的隔离架构：

每个客户项目一个目录根。 所有数据，原始的、中间的、导出的，都放在这个根目录下面，不与其他项目根共享任何东西。
管道配置按项目存放。 清洗规则、标注分类体系和导出设置都存在项目目录里，不放在全局。
按项目记录审计日志。 每一次操作都写入项目目录内的日志文件。全局日志可以引用项目 ID，但不应包含项目本身的数据。
访问范围划分。 团队成员被分配到项目上，他们的工具和面板只显示自己被分配的项目。
导出校验。 在把数据集交付给客户之前，先验证导出中的每一条记录都能追溯回正确的项目根，且没有混入外来记录。

这些用自建基础设施都能做到，同时也正是 Ertas Data Suite 这类工具原生就在处理的管道工作。Ertas 支持多项目管理，项目可以打上客户标签，审计追踪按项目独立，数据谱系内置，并且全部在本地部署运行，不依赖互联网连接。对于同时推进多个合作的服务提供商来说，这省掉了本来需要定制开发的那套隔离基础设施。

这一环的位置

客户隔离是数据准备服务实践的运营地基。缺了它，从少数几个客户扩张到很多客户会带来无法接受的风险。有了它，并发项目的数量就由团队产能决定，而不再受基础设施约束。