📚 课程目录第1章多租户特征平台概述

1、多租户特征平台概述

大家好，我是这次课程的主讲人。在开始之前，我想先聊聊一个很现实的问题：为什么我们需要专门搞一个「多租户特征平台」？

我见过不少团队，一开始只是给一个业务线做推荐系统。特征存储就用 Redis，特征加工靠一堆 Python 脚本。后来公司扩张，来了搜索团队、广告团队、风控团队。每个团队都自己搭一套特征服务，结果就是：同样的用户画像特征，在三个地方重复计算；同样的实时特征管道，运维起来让人崩溃。

说白了，多租户特征平台要解决的就是这个问题——让多个业务团队共享一套特征基础设施，同时互不干扰。

多租户（Multi-Tenancy）这个概念，最早是从 SaaS 领域来的。一个软件实例，服务多个客户（租户），每个租户的数据和配置逻辑隔离。

放到特征平台里，租户可以是不同的业务线、不同的产品、甚至是同一个公司内部的不同团队。比如：

这些租户共享底层的特征存储、计算引擎、发布管道。但每个租户只能看到自己的特征定义、访问自己的数据、管理自己的发布节奏。

核心要点：多租户不是简单的「分文件夹」，而是从存储、计算、权限、治理四个维度做隔离。

你可能要问：没有特征平台，我们不是也活得好好的吗？嗯，确实能活。但代价是什么？

我几年前参与过一个项目，团队花了三个月搭建特征工程管道。结果半年后，新来的同学想复用某个特征，翻遍了代码库和文档，最后发现那个特征的计算逻辑已经改了三次，文档早过时了。他只好自己重新写了一份——这就是典型的「特征重复建设」。

特征平台的价值，我总结为四点：

你想想看，如果你们公司有 5 个业务线，每个业务线 200 个特征。没有平台的话，这 1000 个特征里可能有 30% 是重复的。维护成本翻倍，出问题的概率也翻倍。

好了，既然多租户特征平台这么好，那为什么很多公司做不好？

我个人觉得，最大的坑在于「隔离」和「共享」之间的平衡。太隔离了，每个租户一套独立集群，那跟没平台有什么区别？太共享了，一个租户的异常流量可能拖垮所有人。

具体来说，有这几个核心挑战：

不同租户的特征数据必须物理或逻辑隔离。物理隔离就是各自独立的存储表或数据库；逻辑隔离则是在同一张表里通过租户 ID 区分。

我曾经见过一个事故：某团队在特征存储里误写了另一个租户的特征值，导致那个租户的模型线上效果暴跌。原因就是他们用了逻辑隔离，但没有做写入权限校验。

避坑指南：逻辑隔离虽然节省资源，但必须在 API 层做严格的租户上下文校验。我曾经因为漏掉一个批量写入接口的租户检查，差点酿成 P0 事故。

特征计算需要 CPU、内存、网络。如果某个租户的实时特征管道突然涌入大量请求，会不会把其他租户的计算资源吃光？

常见的做法是：

两个租户都定义了一个叫 user_age 的特征，但计算逻辑完全不同。怎么办？

我的习惯是：特征名必须带租户前缀，或者在元数据层强制要求租户 ID + 特征名联合唯一。比如：

# 租户 A 的特征
tenant_a:user_age = current_year - user.birth_year

# 租户 B 的特征
tenant_b:user_age = extract_from_profile(user_id, 'age')

嗯，这里要注意：特征名冲突不只是命名问题，还涉及特征血缘追踪。如果两个特征同名但不同义，下游模型可能会用错。

每个租户的发布节奏不一样。推荐团队可能每天发版，风控团队可能两周发一次。平台必须支持：

多租户环境下，监控的维度增加了「租户」这一层。你不能只看全局 QPS 和延迟，还要看每个租户的：

我习惯在监控面板上，把租户作为一个标签（tag）打在所有指标上。这样排查问题时，可以快速过滤出某个租户的异常。

说了这么多挑战，我们来看看一个典型的多租户特征平台长什么样。下面这张图是我自己总结的架构分层：

这张图展示了四个核心层级。从上到下，每一层都要考虑租户隔离。我个人觉得，最容易出问题的是「特征计算层」和「特征存储层」之间的衔接——计算完的特征怎么按租户写入存储？写入失败怎么处理？这些细节在单租户场景下可能不是问题，但在多租户下，一个租户的写入失败不能阻塞其他租户。

经验之谈：我建议在特征计算层和存储层之间加一个「异步写入缓冲队列」，每个租户独立队列。这样某个租户的存储抖动不会影响其他租户的写入。

这一章我们聊了多租户特征平台的基本概念。说白了，就是让多个业务团队共享特征基础设施，同时保证数据、资源、权限的隔离。

特征平台的价值在于复用、一致性、治理和效率。而核心挑战集中在隔离策略、资源分配、命名冲突、发布管理和监控维度上。