火花思维：基于离线标签知识库和实时数仓实现轻量级算法服务的技术方案

背景

• 开发周期短，能够在 4 个工作周内完成模型开发和工程部署上线；

  
  

• 迭代敏捷：模型调整与线上环境解耦，能够在若干工作日内完成迭代和发布；

  
  

• 采用成熟技术栈，门槛较低，支持分析师开发，为大型企业中短期运营策略提供支线算法服务，或是为中小企业提供基础算法服务；

  
  

• 能实现多种算法任务（如：分类、聚类），且有较好的模型表现；

  
  

• 整套系统可实现自动化“定期重新训练”，以保持模型对数据动态变化的适应性；

  
  

• 复用性强、延展性好，支持基于同一数据底层和技术底座实现多个算法服务。

  
  

技术框架

• 绕开了模型线上部署的环境要求，规避了实时推理的计算压力，而 Doris 高效的列式存储和压缩技术，又以较低的成本存储了大量哈希表数据，显著降低了在线服务资源消耗情况，确保了方案的低门槛、低负载、低成本优势；

  
  

• 全链路技术风险可控，Hive SQL + Python 技术栈成熟稳定；而 Flink + Doris，也是最近市面上实时数仓的主流实现方式，虽然为控制 Doris 服务器成本，一般会有 3-5min 左右延迟（伪实时），但对于火花大部分业务场景来说，已然够用；

  
  

• 离线与实时解耦，保证了系统的灵活性和稳定性，与传统复杂的 MLOps 流程不同，该方案离线与实时部分功能明确，互不依赖；既可实现二者的故障隔离，增强了系统的鲁棒性，又因模型优化调整在离线部分完成，不影响实时服务的连续和稳定，提高了迭代的敏捷性；

  
  

• 同时，依托 Athena 数据工厂的周期调度功能，可实现日/周/月维度的模型自动化“重新训练”，以较低的运维成本实现了对业务变化和数据漂移的自适应，确保模型性能持续稳定；

  
  

• 具备良好的复用性和扩展性，基于同一技术底座，可支持多种算法任务（如分类、聚类等）的并行构建，便于支持不同场景的业务需求；而随着业务发展，增减特征或调整模型，无需对整体框架进行调整，具有较好的扩展性；且该技术框架可与其他系统和平台轻松集成，满足企业级应用对系统兼容性的要求。

  
  

关键技术节点

• 整个自动化标签筛选分为两步，先通过 Hive SQL 对初始训练集各特征下标签，最近 n 个月的样本量进行统计；一般经验来说，对于集成树模型（如随机森林、 XGBoost、LightGBM），一个特征下的单个标签所需的最小样本量要 >= 30；这里还可结合具体的业务场景，对于样本量绝对值（>=30 情况下）较小或占比较低的标签，我们认为其未来出现概率较低，没必要为其浪费哈希表空间资源，直接予以剔除；

  
  

• 随后，关联初始训练集和标签样本量筛选表（上述筛选结果），对于筛选结果中过滤掉的标签，全部合并到该特征下的“其他”标签中，生成过渡训练集，对该训练集在 one-hot 编码后，进行模型训练，继而打印 SHAP 值或树模型特征贡献度，通过贡献度绝对值或者其占总贡献度比值，进一步筛选有价值标签，在样本量筛选的基础上生成最终各特征下标签筛选表；

  
  

• 将最终的将标签筛选表与过渡训练集关联，同理：对过滤掉的标签，全部合并到对应特征下的“其他”标签中，生成最终训练集；同时，将标签筛选结果同步到 Doris 中，按同样的方式进行标签合并，以实现离线和实时模块，标签“减枝”处理逻辑一致；

• 通过上述两个步骤，在每次模型自动化“重新训练”时，就同时完成了标签筛选工作，并将标签合并逻辑同步到实时环境中。

• 以一个两层“打印”的哈希表为例：第一层采用 5 个特征（x1-x5）进行训练（Python 任务），并构建对应的哈希表，在同一 Python 任务中，同时完成模型训练、训练集预测（y1’）、哈希表预测（y1）和结果写入的流程（注意：这里 y1’和 y1 的都是经过离散处理后的标签值）；

  
  

• 在第二层中，以第一层的训练集预测结果（y1'）和另外 5 个特征（x6-x10）构建一个新的训练集，同时根据上一层哈希表预测结果（y1'）和这 5 个特征构建一个新的哈希表，在训练完第二层模型后对哈希表完成预测并写入 Hive SQL 中；最终将离线标签知识库 1 和 2（哈希表预测结果）同步到 Doris 表中，完成整个模型工程化部署。

  
  

• 逐层“打印”哈希表方案理论上可无限延伸，但考虑到工程链路过长、复杂性过高影响该方案的使用价值，以火花的经验来看，建议控制在 5-6 层左右，覆盖 20-30 个左右的特征，基本可保证一个较好的模型效果。

  
  

• 虽然通过拆表的方式，解决了哈希表过大带来的读写困难和成本挑战，但是以损失一定的模型效果为代价：对于集成树模型来说，其一大优势是：能够学习到特征间的非线性关系，而分层打印的方式，使得层与层间特征的非线性关系学习不充分或者无法学习，未能充分发挥树模型的优势，损失了一定的模型效果；不过，我们在前期对标签筛选的越充分，则每一层可容纳的特征量越多，通过 SHAP 值分析特征间的交互作用，尽量在同一层中放入交互作用明显的特征，以保证非线性关系能尽量充分学习，保证模型效果。

  
  

• 历史“字典”较哈希“字典”有如下明显优势：

  
  

  表更小，往往不需要采用逐层“打印”的方式，工程链路更短、部署方案更简单，更能发挥出“轻量级”的技术方案优势；

  
  

  一次性完成所有特征的模型训练和知识库“离线预计算”，充分发挥树模型学习非线性关系的优势，避免逐层学习带来的信息损失。

  
  

• 但同时，历史“字典”的局限性也非常明显：可能存在相当一部分用户，无法进行有效预测；对于一个标签组合，如果其所有标签或者大部分标签都在训练集中出现过（没出现过的标签已封装成了“其他”），但这个组合没有在历史“字典”中出现过，那么便不能在历史“字典”中查到，但能在哈希“字典”中查到其对应概率值，且能获得较准的预测结果；另外，历史“字典”的特征承载量也有一定上限天花板，如果特征越多，其历史“字典”查询成功率也会逐步下降，按火花的经验来看，对于可用历史“字典”的的业务场景，其特征上限在 40 个左右，超过这个范围，其查询成功率会低于业务可接受阈值（<70%）；

• 所以，我们需要根据具体的业务场景和特征分布情况选择适用的“字典”部署方案，对于预期未来大部分的特征组合都在过去出现过的业务场景，我们便可选用“历史”字典方案；反之，则需要选用“哈希”字典；注意：选用“历史”字典时，一定要先回测历史查询成功率情况，并在上线后对该指标进行密切监控，当查询成功率明显低于某一业务可接收阈值时，需要及时迭代为“哈希”字典方案。

实现案例

总结与展望