先把话说清楚：这篇文章不打算教你调模型，也不打算横向比较各种训练框架。我们讨论的是一件更朴素、却经常把项目拖进泥潭的事——模型写好了、特征也算出来了，可线上推理要用的那批特征到底放在哪里、要吃掉多少内存、多久刷新一次、刷新的那一瞬间会不会把在线库写爆。Feast 是一个用 Python 开发的开源 Feature Store（特征平台）项目，它用声明式的特征定义来管理特征，避免每个团队各写各的特征计算逻辑。听起来它像个"治理工具"，可只要你真把它部署起来就会发现，它骨子里是一个容量规划问题：一台机器装不下所有东西，而装错地方往往比装少了更麻烦。
我们在机房这边接过的机器学习类客户里，特征平台是最容易"配置拍脑袋"的一类。原因很简单：它同时具备键值型服务的内存敏感、批处理作业的带宽敏感、以及配置中心的可用性敏感，三种气质混在一个系统里，用任何一种单一思路去估配置都会踩坑。所以下面这篇，我们把容量账拆成三条线来讲：在线库按实体数算，物化作业按吞吐算，注册表按可用性算。三条线并行，而不是一台机器装所有东西。
在线库是内存账：容量约等于活跃实体数 × 特征数 × 单值体积，三个因子都必须按你自己的数据实测，没有一个能抄别人的。 很多人第一步就错在把"注册用户总数"直接当成在线库的行数，于是内存预算凭空翻了好几倍，机器租回来才发现一半内存空着。
物化是吞吐账：瓶颈通常不在 CPU，而在"从离线库读"和"往在线库写"这两端的带宽与写入速率。 增量物化比全量物化便宜得多，但它有一个硬前提——数据必须有可靠的时间戳和更新标记，否则增量就变成了漏数。
注册表虽小，却站在每一次在线查询的关键路径上。 读不到注册表，在线读取就直接失败；它应该被当作一个配置服务来对待，而不是一个躺在临时目录里、随时可能被清理脚本删掉的数据文件。
TTL 是成本旋钮，同时也是可用性旋钮。 设长了在线库持续膨胀，设短了冷实体在线上查不到值，正确的做法是对齐"实体活跃窗口"，而不是拍一个整数。
买它的理由是一致性，不是性能。 训练/推理不一致和特征穿越这两个问题，靠写文档、靠人肉约定是治不住的，得靠平台机制。至于能带来多少效果提升，本文不给百分比，那得你自己的线上实验说了算。
不是所有做模型的团队都需要特征平台。如果你的团队只有两个人、一个模型、特征全是跑批算完塞进一张表、线上直接读那张表，那引入 Feast 属于给自己找活干。真正需要它的，是下面这几类场景，它们有一个共同点：同一份数据既要喂给训练、又要喂给线上推理，而且两边的口径必须一致。
风控是特征平台最典型的落点。一笔交易进来，模型要在极短时间内拿到这个用户的历史行为特征并给出评分。这类场景的难点不在于模型多复杂，而在于"线上此刻能拿到的特征"必须和"训练时用的特征"是同一套定义、同一套计算逻辑。如果训练时用了一批跑批算出来的统计值，线上却临时用流式口算了一个近似值，两者的差异会被模型放大成完全不同的决策。更麻烦的是，风控特征往往跨多个数据源：账户侧、交易侧、设备侧、外部名单侧，每个源都有自己的更新节奏，靠人去对齐几乎必然出错。
推荐场景的特征有两个特点：数量多、更新频率差异大。用户侧的长期偏好可能一天更新一次，商品侧的曝光计数可能几分钟就要刷新，而上下文特征（时间、位置、设备）根本不需要进在线库，随请求带进来就行。如果所有特征都按"最新鲜"的标准去物化，在线库的写入压力会高得离谱；如果统一按最慢的节奏去物化，推荐的实时性又没了。特征平台在这里的价值，是允许你按 Feature View 的粒度分别定义时效，让不同频率的特征各走各的物化节奏。
反作弊特征对时效最敏感，同时也最容易踩"特征穿越"的坑。举个例子：你在训练样本里加了一个"该设备是否已被标记为黑产"的字段，这个字段是事后回溯打标的，那么在预测历史样本时，你其实用到了当时还不存在的信息，模型线下 AUC 漂亮得不像话，一上线就现原形。反作弊团队用特征平台，一半是为了时效性，另一半是为了把时间点连接这件事强制做对。
最后一个信号来自组织层面：当你发现"用户近 7 天登录次数"这个指标，风控团队写了一份 SQL、推荐团队写了一份、反作弊团队又写了一份，三份口径各不相同，谁也说不清哪份是对的——这时候你需要的是特征平台。它用声明式的特征定义把口径固定下来，让所有团队复用同一份 Feature View。这件事的技术含量不高，但省下来的人力成本往往比省下来的机器成本高一个量级。
特征平台这个词容易被讲玄，其实它要治的病只有两个，而且都能用人话讲明白。第一个叫训练/推理不一致（training-serving skew），第二个叫特征穿越。这两个病不治，你后面所有的容量规划都是在给一个错误的系统做优化。
先说训练/推理不一致。假设你在做一个"订单是否会退款"的模型。训练的时候，算法同学写了一段 SQL，从数仓里把每个订单的各类统计特征算出来，生成样本、训练模型，线下指标很好。到了线上，工程同学为了低延迟，用另一段代码、甚至另一种语言重新实现了这套特征计算——比如从缓存里取、从接口里拼。问题来了：两段代码对"近 7 天"的定义不一样，一个算的是自然日、一个算的是滚动窗口；对缺失值的处理不一样，一个填零、一个丢弃；对时区、对去重、对边界的处理也都不一样。模型在训练时看到的特征分布，和线上真正喂进去的特征分布，是两套东西。这就是训练/推理不一致，它不会报错，只会让模型效果悄悄退化，而且极难排查。
再说特征穿越，它更隐蔽。还是退款预测这个例子：你要预测"昨天的订单会不会退款"，样本里的标签当然是已知的。可如果特征里混进了一个"该订单是否被客服介入过"的字段，而客服介入往往发生在退款之后，那么这个字段在预测时点上根本不存在。模型在训练时却能通过这个字段一眼看出结果，线下指标虚高，线上完全失效。换成一句更好记的话：预测昨天的订单时，用了只有今天才知道的字段。特征穿越的可怕之处在于，它让离线评估指标彻底失去参考价值，团队会以为自己做了一个很好的模型，直到上线那天才发现。
治这两个病的方法，就是"同一份定义 + 时间点连接（point-in-time join）"。同一份定义解决训练/推理不一致：线上和线下都从同一个 Feature View 取特征，取的是同一套声明，不存在两份实现；时间点连接解决特征穿越：生成训练样本时，对每个样本的那个预测时刻，只去关联"在这个时刻之前就已经存在"的特征值，未来的值一律不参与。Feast 这类特征平台的价值，就在于把这两件事变成默认行为，而不是靠每个工程师自觉。
要把容量账算清楚，得先把 Feast 的概念模型理顺。它只有四个核心对象，每个对象在容量模型里扮演的角色完全不同，混着谈一定算错。下面按"它是什么—它落在哪个存储—它消耗什么"的顺序讲。
Entity（实体）是特征所描述的主语，比如用户、商品、设备。它在容量模型里的意义非常直接：实体就是在线库的键。你在在线库里存多少行，取决于有多少个需要在线服务的实体，而不是取决于你有多少条原始日志。一个用户可能产生几千条行为日志，但在线库里他只占一行。想明白这一点，容量估算就成功了一半。反过来，如果实体定义得不合理——比如把"用户 + 会话"定义成实体，那在线库的行数就会从用户量级炸到会话量级，内存直接失控。
Feature View（特征视图）是一组同源特征，加上它的数据来源，再加上它的时效性（TTL）。"同源"这个词很重要：来自同一个表、同一套更新逻辑的特征放在一个视图里，共享同一个物化节奏。在容量模型里，Feature View 决定了两件事：一是特征数这个乘数因子，二是物化作业的调度单元。你把一百个特征塞进一个视图，它们就得一起物化，哪怕其中九十个是几天才变一次的静态属性；把它们拆开，就能各自走各自的节奏，代价是物化作业数量变多、调度变复杂。
Feature Service（特征服务）是把多个 Feature View 组装成"某个模型要用的那一组特征"。它本身不怎么占空间，但它是一个非常有用的工程边界：模型在上线时只声明自己依赖哪个 Feature Service，不关心底下有几个视图、来自哪张表。这样做的好处是，当你发现某个视图要换数据源、要改 TTL 的时候，影响面是可枚举的——反向查一下哪些 Feature Service 引用了它就行。在容量规划上，Feature Service 是"单次在线查询要读多少个键"的决定因素：一个服务里挂了五个视图，一次查询可能就要打五次在线库，这直接影响在线库的 QPS 预算。
Registry（注册表）是保存特征定义的对象，可以放在文件系统、对象存储、数据库等位置，具体支持哪些方式以官方适配文档为准。它的体量极小——就是一堆特征定义的元数据，通常几兆到几十兆的量级，跟在线库比起来可以忽略不计。但容量规划里最忌讳的就是"因为小所以不管"：每次在线读取通常都要读注册表，读不到注册表，在线查询就失败。所以它不是数据文件，它是配置服务，必须按服务的标准对待：备份、版本化、不放临时目录。这一条我们后面单独展开。
在线库（Online Store）用于线上推理的低延迟读取，通常是键值型存储，Redis 一类，具体支持哪些后端以官方文档为准。它里面放的是"实体 × 特征"的最新值——注意是最新值，不是历史序列。所以它的容量可以用一个连乘框架来估算：容量 ≈ 活跃实体数 × 特征数 × 单值体积。这个框架里的三个因子，每一个都必须按你自己的数据实测，本文不给出任何具体字节数，因为不同特征类型（数值、类别、嵌入向量、稀疏列表）的单值体积差异可以是数量级级别的，抄任何现成数字都必然算错。
三个因子里，最容易被算错的不是特征数，也不是单值体积，而是第一个——活跃实体数。这里有个反直觉的点：活跃实体数 ≠ 用户总数。你的产品可能有几千万注册用户，但其中大部分是沉默用户：三个月没登录、半年没交易、设备早就不在了。这些用户在未来一段时间里几乎不可能触发一次实时推理，把他们的最新特征值常驻在内存里，是纯粹的资源浪费。真正需要进在线库的，是"在实体活跃窗口内可能产生推理请求"的那批实体：活跃用户、在售商品、在线设备、近期有过交易的账户。这个判断做对了，内存预算往往能砍掉一个数量级；做错了，你就在为一堆永远不会来的请求付内存钱。
怎么确定活跃窗口？它不是拍脑袋来的，而是从业务里推出来的。对风控来说，活跃窗口可能是"近期有过交易行为的账户"；对推荐来说，可能是"近期有曝光的商品"；对反作弊来说，可能是"近期活跃的设备"。把窗口定下来，再去数这个窗口内的实体基数，得到的数字才是有意义的。这里还要提醒一句：实体键的构造方式会直接改变基数。同一个用户，按"用户 ID"算是一行，按"用户 ID + 设备 ID"算可能就是三行，按"用户 ID + 场景"算又是另一种数法。所以在数活跃实体数之前，先把实体键的口径定死，否则算出来的数字毫无意义。
单值体积这个因子，很多人会忽略它的"隐性膨胀"。一个浮点特征和一个类别特征，序列化之后占用的空间可能差很多；一个上百维的嵌入向量，单个体积可能顶得上几十个标量特征；如果你在线上库里存的是某种结构化包装（带时间戳、带状态标记、带版本号），那么每个值除了特征本身，还要额外背上这些元数据的开销。所以实测的方法应该是：拿一批真实数据，按你实际要用的序列化方式写进在线库，然后用存储自身的统计工具去看实际占用，再除以实体数，得到单值体积的经验值。所有的"网上说每个值大概多少字节"都不可信，只有你自己写进去的那批数据可信。
最后补充一个容易被低估的点：在线库的内存账里，还要给"写入期间的膨胀"留量。物化作业在跑的时候，同一批键可能被新旧两版数据同时占用；如果存储本身有过期回收机制而不是即时回收，那么被 TTL 淘汰的数据也不会立刻释放内存。所以按稳态算出来的容量，通常还要再留一部分余量给这些瞬时状态。留多少，同样取决于你用的后端实现和实测数据，本文不给具体倍数。
Materialization（物化）是把离线库里的特征批量推送到在线库的过程，Feast 提供全量物化与增量物化两类动作，具体命令形态以官方 CLI 文档为准。物化是特征平台里唯一一个"会周期性冲击系统"的组件，它的容量账和在线库完全不同：在线库算的是"装得下吗"，物化算的是"推得完吗"。
物化作业的瓶颈，几乎从来不在 CPU。它卡在两端：一端是从离线库读——离线库通常是数仓或对象存储上的列存文件，你要按时间范围扫出一批特征，这里消耗的是扫描带宽和离线库的并发查询能力；另一端是往在线库写——键值型存储在批量写入时有自己的写入速率上限，超过之后要么延迟飙升，要么触发限流。这两端谁先到顶，取决于你的数据是"宽而少"还是"窄而多"：特征列特别多、实体相对少，通常是离线库侧先吃紧；实体特别多、特征少，通常是在线库侧先吃紧。做容量规划时，两边都要估，不能只估一边。
全量与增量的取舍，核心是"每次要搬多少数据"。全量物化把某个时间范围内的所有特征值重新推一遍，好处是简单、不依赖数据质量、能自动修复历史上漏掉的数据，坏处是数据量巨大，而且随着实体规模增长，单次作业时长会线性变长，直到塞不进可用窗口。增量物化只推"上次物化之后发生变化的那部分"，作业量通常小得多，但对数据有硬要求：必须有可靠的时间戳和更新标记。所谓可靠，包含三层意思——时间戳本身不能缺失或为默认值；时间戳的语义要统一（是数据生成时间、入库时间、还是业务发生时间，必须全链路一致）；时间戳要能覆盖所有更新路径，如果有一部分数据是通过旁路直接改的、没打时间戳，那这部分更新就会被增量物化永久漏掉。
周期怎么定，其实是由两个约束夹出来的。上界来自业务：特征允许多旧？风控的实时特征可能要求分钟级新鲜度，用户长期偏好可能天级就够了。下界来自系统：一次物化要跑多久、跑的时候会不会影响在线库的正常读、能不能错开业务高峰。当"业务要求的新鲜度"比"一次物化能跑完的周期"还短时，就说明你的物化方式该换了——要么从全量切到增量，要么把大视图拆成小视图分批推，要么接受更长的周期并改用实时特征补充。这里不给具体参数值，因为每个系统的实体规模、特征数、后端性能都不一样，只能给这个决策框架，具体参数需要你自己实测后确定。
还有一个工程上的现实：首次上线那次物化，永远是最难受的一次。因为在线库是空的，你需要把历史上所有活跃实体的特征值一次性灌进去，这一次的量级和日常增量完全不是一个概念。很多团队按日常增量估了配置，结果栽在首次全量上——要么跑不完，要么把在线库写爆。所以规划时一定要单独算"首次灌库"这笔账，并且为它准备一个独立的、错峰的执行窗口。
把前面几节拆开讲的三条线合起来，就是下面这张表。它不是通用概念罗列，而是按"容量由什么决定"和"常见的低估点"这两个维度对齐的对照，你可以直接拿它当上线前的核对清单用。表里不给具体数值，因为每个因子都依赖你自己的实测数据。
| 组件/存储 | 主要消耗什么 | 容量由什么决定 | 常见的低估点 | 选型时该怎么留量 |
|---|---|---|---|---|
| 在线库（键值） | 内存为主，持久化盘为辅 | 活跃实体数 × 特征数 × 单值体积，三者均需实测 | 把注册用户总数当成活跃实体数；忽略序列化元数据的隐性膨胀；忽略写入期与回收期的瞬时占用 | 按"活跃窗口内实体基数"留量，内存给稳态值之外的余量，持久化盘按能否容忍重建来定 |
| 离线库（列存/数仓） | 磁盘容量 + 扫描带宽 + 并发查询能力 | 特征历史保留时长 × 实体规模 × 特征列数 | 只算存储不算扫描，样本生成时把数仓出口带宽打满，拖垮同库的其他业务 | 容量与扫描带宽分开估算，先定死历史保留期限，必要时把特征表与业务表隔离 |
| 物化作业 | 网络出口 + 在线库写入速率 + 调度算力 | 单次需同步的实体数 × 特征数 ÷ 可用写入窗口 | 按日常增量估配置，栽在首次全量灌库上；低估全量物化的写放大会把在线库写爆 | 按最坏窗口（首次全量 + 故障后补数）留量，优先走增量，并为错峰执行预留独立窗口 |
| 注册表 | 可用性、读写稳定性、备份与版本管理 | 特征定义数量与历史版本数，体量极小 | 当成数据文件放在会被清理的临时目录；不做版本化，改坏了无法回滚 | 按配置服务对待：多副本或可靠后端、定期备份、纳入版本管理、不放临时位置 |
| 训练样本生成的临时空间 | 临时磁盘容量 + 中间文件读写 IO | 样本行数 × 特征列数 × 时间点连接带来的中间结果放大倍数 | 只按最终样本集大小预留，忽略 point-in-time join 过程中的中间表膨胀 | 按最终样本量的数倍预留临时空间，作业结束即清理，避免长期占用系统盘 |
这张表里最值得单独拎出来的是最后一行。训练样本生成的临时空间，是几乎所有人都会漏掉的一项。时间点连接不是简单地把两张表拼起来，它要在每个样本的预测时刻上做一次"截至该时刻的最新值"查找，中间结果往往比最终样本集大不少。如果你的临时目录正好挂在系统盘上，一次大样本作业就可能把根分区写满，连带影响机器上所有其他服务。这个坑和特征平台本身的选型没有必然关系，但它是"上线前配置没算全"的典型症状。
Registry（注册表）保存的是特征定义，可以放在文件系统、对象存储、数据库等位置，具体支持方式以官方为准。它的体量小到让人本能地忽略：一堆 YAML 或者一张小表，几兆到几十兆，跟几个 GB 的在线库比起来就是零头。但容量规划里最忌讳的，就是"因为小所以不管"。
原因在于它所处的位置：每次在线读取通常都要读注册表。在线库里存的是"实体 × 特征"的值，可这些值要怎么解释、属于哪个 Feature View、TTL 是多少、类型是什么，全在注册表里。换句话说，注册表是在线查询的关键路径上的一环——在线库活着、注册表挂了，在线查询照样失败。这就意味着，注册表的可用性要求和在线库是同一个量级的，而不是和它的体量一个量级。
既然是服务，那就得按服务的规矩办。第一是位置：不要放在会被清理的临时目录里。很多团队图省事，把注册表放在某个容器的临时卷或者某个定期清理的中间目录，结果某天清理脚本一跑，特征定义全没了，线上推理全线报错，而此时在线库里的数据其实一个字节都没丢——这种故障最难查，因为你会本能地去找在线库的问题。第二是备份：注册表要有独立的备份策略，且备份频率要能覆盖"误改"这种场景。特征定义是会被人改的，改错了要能快速回到上一个可用版本。第三是版本化：把特征定义纳入版本管理，让每次变更可追溯、可回滚、可评审，这本来就是特征平台要解决的治理问题的延伸。第四是访问稳定性：如果注册表放在远端存储上，要考虑它和在线服务之间的网络路径是否稳定、是否需要本地缓存，具体机制视版本与后端而定。
还有一个容易被忽略的点：注册表是"写少读多"，而且读的次数极高。这意味着它的读写比例特征和在线库很像，但容量需求和在线库完全不像。用"小"去推"简单"，是这里最容易犯的思维错误。
TTL（时效性）定义在 Feature View 上，它决定了一个特征值在在线库里能留多久。它同时是成本旋钮和可用性旋钮，两个方向都会咬人，所以不能拍整数，得算。
设长了会怎样？在线库会持续膨胀。因为 TTL 过期是特征值被清理的主要机制，如果 TTL 设成远超实体活跃窗口的长度，那么大量"已经不会再产生请求"的实体，它们的值还会继续占着内存。回到前面那个例子：一个半年没来的用户，如果 TTL 设得比半年还长，他那一行就还躺在线上库里，为一次永远不会发生的查询付着内存钱。实体规模越大，这个浪费越可观。
设短了会怎样？更糟，因为它是功能性问题。冷实体查不到值：一个用户两个月没来，今天突然回来了，如果 TTL 只有一个月，那么他在线库里的特征值已经被清掉了，在线查询返回空。模型拿到一堆缺失值，要么走兜底逻辑，要么给出一个质量很差的评分。在风控这类场景里，"查不到"往往比"查到一个旧值"更危险，因为它可能直接触发默认放行。
那应该怎么定？答案是把 TTL 对齐"实体活跃窗口"。逻辑是这样的：先问业务，一个实体多久没有行为之后，我们基本可以断定它不会再触发实时推理了？这个时长就是活跃窗口。TTL 应该略大于这个窗口——略大是为了留出缓冲，避免边界抖动导致刚过窗口的实体被误清；但不应该大太多，否则就是在养一批不会再来的数据。同时要注意，不同的 Feature View 可以有不同的 TTL：高频行为特征可以短一些，静态属性可以长一些甚至很长，这正是把特征按来源和更新频率分组的好处之一。
还有一层需要考虑：TTL 和物化周期是耦合的。如果 TTL 比物化周期短，那么两次物化之间，一部分值会先过期，出现"本来应该有值、结果查不到"的空档；如果 TTL 远长于物化周期，那意味着你在为一个很旧的值付内存。所以定 TTL 的时候，要和物化周期一起看，两者至少要在同一量级上协调，具体数值以你自己的实测与业务需求为准。
这是下单时最实际的一个问题：能不能一台机器全装了？答案是"能跑，但要想清楚争的是什么"。三个组件的气质完全不同，它们争抢的资源也完全不同，混部的问题是资源错配，而不是算力不够。
在线库争的是内存和低延迟的稳定访问。它对内存容量敏感（前面算过那笔账），同时对延迟抖动敏感——如果同一台机器上有个批处理作业正在猛吃 CPU 或者猛刷磁盘，在线库的响应时间就会被拖着走。在线库最怕的，是有人跟它抢内存、抢 CPU 时间片、抢磁盘 IO。
物化作业争的恰恰是这些：它在跑的时候需要大量内存做中间缓存，需要持续的 CPU 做序列化和转换，需要占满网络出口把数据推到在线库，还需要往磁盘写中间文件。换句话说，物化作业是一个典型的"短时间内把机器资源吃满"的任务，而在线库是一个"必须随时保持资源余量"的服务。这两者的资源曲线是天然冲突的——一个要在几小时内把机器压满，另一个要求任何时候都不能被压满。
注册表争的又不一样，它争的是可用性和不被误删。它的资源需求极小，但它的可用性要求和在线库同级。把它和在线库放一起，风险在于"一损俱损"：机器挂了，特征定义和特征值一起没了；把它和物化作业放一起，风险在于物化作业的临时文件清理可能波及它，或者机器被批处理压垮后注册表读不出来。
所以取舍逻辑是这样的：如果规模小、实体数不多、物化窗口宽松，混部完全可行，但至少要做到两点——给物化作业设资源上限，别让它把内存吃干；给注册表找一块不会被清理的持久化位置并做备份。如果规模上来了，或者在线服务的延迟要求变严了，就该拆：在线库单独占一台内存型机器，保证它的内存和延迟不被批处理干扰；物化作业放在能扛批处理的地方，最好和离线库在同一侧，减少跨机传输；注册表按配置服务对待，用可靠的后端承载，并做多副本或定期备份。拆到什么程度，取决于你的实体规模和延迟要求，本文不给具体配置数字，只给这个判断框架。
还有一条实操建议：不管最终怎么部署，物化作业的时间窗口一定要和在线服务的业务高峰错开。这是零成本的优化，但能避开绝大多数"线上延迟突然变差"的排查。
配置算完了，上线之前还有四件事值得逐条过一遍。这四件事都不是性能问题，但每一件都能让整个平台白干。
第一件：时间戳质量。增量物化能不能用、point-in-time join 能不能做对，全押在这一条上。要确认的是三件事：时间戳字段有没有缺失或默认值；时间戳的语义在全链路上是否统一（业务发生时间、数据生成时间、入库时间三者必须选一个并贯彻到底）；所有更新路径是否都打了时间戳，有没有旁路直接改数据的情况。这一条不过关，就老老实实走全量物化，别硬上增量。
第二件：实体键口径。同一个"用户"，在训练样本里用的是什么键，在线上查询时传进来的是什么键，两者必须是同一个东西。常见的坑包括：一个用业务 ID、一个用内部自增 ID；一个带了渠道前缀、一个没带；一个区分了大小写、一个没区分；复合实体的拼接顺序不一致。这个问题在上线前不查，上线后表现为"大部分实体查得到、少部分永远查不到"，排查起来极费时间。
第三件：TTL 设定。按上一节的思路，把 TTL 和实体活跃窗口对齐，并和物化周期一起复核，确保不会出现"两次物化之间值先过期"的空档。上线后要观察一段时间实际命中率，如果冷实体缺失比例异常高，就说明 TTL 定短了。
第四件：在线库的持久化策略。在线库是键值型内存存储，但"内存"不代表"丢了无所谓"。要想清楚一个问题：如果在线库进程重启或者机器重启，数据需要多久重建？重建的方式是重新跑一次全量物化，还是依赖持久化文件恢复？这两种选择的代价完全不同——前者意味着你要能承受一次完整物化的时间窗口内服务降级，后者意味着你要为持久化文件准备可靠的磁盘和备份。这个问题在下单配置时就要回答，因为它直接决定磁盘怎么配。具体机制与持久化方式以你所选后端的官方文档为准。
回到服务器租用本身。特征平台这类业务的形态比较特别：它同时需要一个内存充裕、延迟稳定的键值服务节点，以及一个能吃批处理的作业节点，两者之间还要有稳定的内网传输。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
选型上有两个建议。第一，在线库节点优先看内存容量和内存带宽，其次看持久化盘的可靠性，CPU 反而不是瓶颈；如果在线库要和在线推理服务放一起，还要把推理所需的资源一并算进去。第二，物化作业节点优先看网络出口和磁盘 IO，能把作业节点放在靠近离线库的一侧，就尽量放近一些，减少大批量特征数据跨网传输的时间和成本。至于具体选多大内存、多大带宽、要不要拆成两台，建议把前面算出来的活跃实体数、特征数、单值体积、单次物化数据量这几个数字整理好，再和我们一起做一次核算，比凭经验拍配置靠谱得多。
最后给一份可以直接打印出来逐条打勾的清单。资源和延迟相关的部分：在线库内存是否按"活跃窗口内实体基数 × 特征数 × 实测单值体积"算过，而不是按注册用户总数估的？单值体积是否用真实数据实测过，有没有把序列化元数据的开销算进去？在线库内存是否为写入期和回收期的瞬时膨胀留了余量？物化作业是否按"首次全量"这个最坏场景单独算过一次，而不只是按日常增量算的？物化窗口是否和在线服务的业务高峰错开了？离线库侧的扫描带宽是否单独估过，会不会影响同库的其他业务？训练样本生成的临时空间是否按最终样本量的数倍预留，且没有挂在系统盘上？
延迟相关的部分：在线服务的延迟要求是多少，需要在下单前明确，因为它是"是否要拆机部署"的判断依据；在线库与在线推理服务之间是同机还是跨机，跨机的话内网路径是否稳定；注册表到在线服务的读取路径是否可靠，是否需要本地缓存机制（视版本与后端而定）；在线库重启后重建需要多久，这个时间是否在可接受范围内。以上各项的具体数值都要以你自己的实测为准，本文不提供任何现成的延迟数字。
如果你准备为特征平台下单，建议在询价前先把下面这些信息整理好，这样拿到的方案才是对得上号的：活跃实体数的量级（不是注册用户总数，是活跃窗口内的实体基数）；单个实体的特征数与特征类型构成（标量、类别、向量分别占多少）；特征数据的更新频率分布，以及需要多新鲜；预计的历史特征保留时长；单次全量物化的大致数据量；在线服务的延迟目标；是否需要跨地域部署以及数据是否需要跨地域同步。这些信息不需要精确到个位，量级正确就够了。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。我们的做法是先把你这三笔账（在线库的内存账、物化作业的吞吐账、注册表的可用性账）分别算清楚，再决定是合成一台还是拆成两台、内存与带宽各留多少余量，而不是先报一台机器再往上加。涉及具体费用的一律走参考预算与询价流程，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
