TBDS智算平台架构
企业把 AI 用起来，通常要跨过四道边界：数仓出宽表、脚本加工标注、GPU 训练、批处理回写。每一次交接都是一次落盘、一次格式转换、一次跨团队协同；数据一旦离开平台，权限与血缘随之中断。算力切分难、资源垄断、工程繁复、中间态失控------这些都不是某一环的技术选型问题，而是链路被切成几段的结果。
TBDS 智算平台以统一分布式运行环境和跨引擎共享存储为基础，将数据加工、模型训练与批量推理组织为同一集群内的一条任务链。原本跨系统发生的多次导出、传输和回写，被收敛为平台内部的数据流转；权限、配额、审计和异构资源调度也随之纳入企业既有管理体系，AI 作业不再游离于数据治理之外。
在已落地的券商和电网场景中，平台减少了跨系统数据搬运与人工交接，端到端处理耗时缩短 50%，同时提高了 CPU 与 GPU 的协同效率，资源使用率提升超过30%，并缩短了从数据准备到结果产出的链路，单个 AI 场景从需求到可用结果可由月级压缩至天级。
下面重点以多模态数据处理和金融风控建模为例，介绍如何利用 TBDS 智算平台完成数据加工、XGBoost 模型训练与批量推理。
多模态数据处理
企业沉淀的多模态数据通常以文件形式分散在数据湖中，包括票据、合同、证照、回单、报表以及图片、音频和视频等。这些数据虽然规模庞大，却难以直接参与检索、分析和模型训练。多模态处理的目标，是将原始文件转化为可查询、可计算、可追溯的数据资产。
传统链路为何难以规模化
传统多模态数据处理通常需要组合多类工具：原始文件存放在 HDFS、NAS 或对象存储中；Python、Spark、OpenCV 和 FFmpeg 负责文件解析、拆页、抽帧与格式转换；CUDA、PyTorch 等工具承载计算密集型处理；Python 脚本、ETL 工具或 Airflow 负责结果拼接与任务衔接；最终结果分别写入 Hive、Parquet、Elasticsearch 或向量数据库。
传统多模态数据处理流程
各类工具能够解决单点问题，但没有形成统一的数据处理体系，随着数据规模和处理阶段增加，系统集成与运维成本持续上升。
TBDS的多模态数据解决方案
TBDS 围绕这一问题构建了完整的多模态数据处理能力：数据科学集群负责大规模分布式处理，Xpark 提供约 40 个常用多模态算子，AI Function 将模型能力封装为标准 SQL 函数，处理结果统一写入 Lance 表，并由 Gravitino 管理表及版本元数据。CPU、GPU 与国产信创算力由平台统一供给，用户可以根据数据规模、开发方式和业务场景选择相应入口。
TBDS 一体化流水线架构
以一批存量扫描件为例：约 50 万份 PDF 与图片文件，总量约 8 TB，拆页后合计约 400 万页。处理过程不仅需要完成文件解码、拆页、版面分析、OCR 和字段抽取，还需要保留每个字段与原始文件、页码及页面位置之间的对应关系，以支持后续复核、审计与模型训练。
准备数据科学集群
用户首先通过 TBDS 控制台创建数据科学集群，根据任务规模选择 CPU、GPU 或国产信创算力，并设置节点规格与集群规模。集群部署、资源调度、任务隔离和运行监控均由平台统一完成，不需要自行搭建和维护分布式环境。
TBDS创建数据科学集群
TBDS 环境已集成 Xpark、TBDS Daft/Lance、TBDSFS Client 等数据多模态数据处理组件。用户也可以通过依赖包管理统一安装运行依赖，由平台分发到集群节点，保持各 Worker 的环境一致。依赖调整时只需更新版本，无需重新制作整个集群镜像，也无需逐节点登录安装。
完成集群和依赖配置后，用户即可在 Studio 中开发调试，并通过 WeData 将任务上线为周期性或依赖触发的生产作业。
在 TBDS 数据科学集群中完成端到端处理
如图所示，原始扫描件从 TBDSFS 直接读取，在同一数据科学集群内依次完成解码、拆页、版面分析、OCR 和字段抽取。
基于 TBDS 数据科学集群的存量扫描件处理流程
TBDS 为不同处理需求提供三种开发方式：
-
常见的文本、图像、音频和视频处理，可直接使用 Xpark 内置的约 40 个多模态算子；
-
企业已有的文档解析、OCR 等算法，可以封装为自定义 UDF，在数据科学集群中分布式执行；
-
复杂字段抽取和语义判断，可以通过 AI Function 调用统一推理服务。
各阶段分别声明需要的 CPU 或 GPU 资源。文件解码和拆页使用 CPU，OCR 等计算密集型环节按需使用 GPU 或国产信创算力。数据分片、任务分发、并发执行、失败重试和资源回收由 TBDS 平台自动完成。
以下代码展示从湖内文件读取到 Lance 入湖的完整主干：
docs = ray.data.read_binary_files(
"tbdsfs://warehouse/scan_docs",
include_paths=True
)
pages = docs.map_batches(DecodeAndSplit, num_cpus=2)
pages = pages.map_batches(LayoutAnalyzer, num_cpus=2)
pages = pages.map_batches(OcrRecognizer, num_gpus=0.5)
result = pages.map_batches(FieldExtractor, num_cpus=1)
result.write_lance("tbdsfs://warehouse/document_fields")这段代码完成从湖内文件读取到 Lance 入湖的完整过程。开发人员只需关注解码、版面分析、OCR 和字段抽取逻辑；需要增加文件格式、更换 OCR 组件或调整抽取规则时，只需修改对应算子，不需要重新设计数据分片和调度流程。
对于已有标准能力的场景，则无需重复开发上述处理类，直接使用 Xpark 内置算子或 AI Function 即可完成相应处理，借助TBDS提供的多模态处理的工具库，大部分核心数据处理工作可以在50行代码左右完成开发和调试。
实际收益
多模态处理的价值，不只是单个算子更快，而是减少环境搭建、工具拼接和数据交接，让开发时间更多投入到业务规则与算法本身。
在已落地的业务实践中：
-
提升资源利用率。 CPU 与 GPU 按算子需求混合编排，GPU 不再等待上游人工准备数据；细粒度切分和流水并行进一步减少资源空转。
-
缩短处理周期。 内置算子、自定义 UDF 与统一推理服务在同一环境中协同，降低常见处理的开发量，端到端处理耗时缩短 50%。
-
压缩交付周期。 集群、存储、依赖、算子和调度均由平台提供，单个 AI 场景从需求到可用结果可由月级压缩至天级。
机器学习
挑战
传统上，训练一个机器学习模型通常要横跨三套系统：数据加工在数据平台上完成，模型训练在专门的训练环境里进行，批量推理再部署到推理系统。以 XGBoost 风控建模为例，链路如下：
传统机器学习模型训练架构
这种架构带来三个问题：样本表要从数据平台导出、再到训练环境导入，一份数据存两处；三套系统各自申请算力，忙闲错开也无法互补，资源利用率低；模型训完还要手动拷贝到推理环节，容易出错且难以追溯。几轮来回搬运的耗时，往往超过计算本身，同时异构的集群，也会带来很大的运维成本。
TBDS 智算平台通过架构上的创新解决这些问题：数据加工、模型训练、批量推理在同一个集群、同一个作业内依次完成，一次提交，环节之间不需要导出再导入。仍以 XGBoost 风控建模为例------训练一个风控模型，全流程包括数据准备、清洗、回溯打标、特征工程、模型训练、全量打分六个环节，前四步在数据处理阶段完成，后两步分别对应训练与批量推理：
TBDS机器学习传统模型训练Pipeline
数据处理：使用如第2章所示的组件即可完成读取交易日志与案件表，完成清洗、回溯打标和特征工程，生成训练样本。
模型训练： 使用 XGBoost 对样本进行分布式训练，按需配置 CPU 或 GPU 资源，产出的风控模型保存至 TBDSFS。
批量推理： 通过 Ray Data 批量处理待评估交易，调用训练好的 XGBoost 模型 完成风险打分，将评分结果写回 TBDSFS。
全流程可通过 WeData 配置任务依赖与定时调度，自动衔接各阶段，避免手工操作，降低50%训练耗时。
数据处理
以 XGBoost 风控模型的数据准备为例，数据加工主要包括三类工作：首先，对交易、客户与授信数据进行去重、异常识别和缺失处理；其次，按照观察期与表现期关联风险事件，构造正负样本，避免使用预测时点之后的信息；最后，围绕客户或账户生成近 7 天、30 天、90 天的交易金额、交易频次、波动程度和授信使用率等时序特征。
在 TBDS 中，Hive、Iceberg、Lance 表统一存储于 TBDSFS，并由 Gravitino 管理元数据；表关联、时间窗口和聚合统计可通过 SQL 或 Xpark DataFrame 完成，批量 Python 转换可使用 Ray Data Dataset API，自定义并行逻辑可使用 Ray Core Task、Actor。若案件材料包含非结构化文本，还可通过 SQL AI Function 提取风险类型与标签。处理后的样本以表的形式写回 TBDSFS，供后续训练直接使用，参考第2章节多模态数据处理部分，这里不再赘述。
模型训练
训练环节直接使用 3.2 产出的风控训练样本集。样本数据已经完成质量处理、特征与标签组装以及时间切分，统一存储在 TBDSFS，并由 Gravitino 管理表及版本元数据。训练作业从 TBDSFS 直接加载训练集和验证集，无需将数据导出到专门的训练环境，也不再额外保存一份训练副本。
对于单机可承载的中小规模样本，算法工程师在训练函数内直接将数据转换为 XGBoost DMatrix 并执行原有 xgboost.train() 逻辑，TBDS 为其分配多核 CPU 或单机 GPU；当样本量超出单机处理能力或业务要求缩短训练时间时，只需在提交任务时声明 Worker 数量与资源规格，TBDS 即在数据科学集群内拉起多个 Worker 分布式执行，底层调度、数据分发、故障恢复由平台接管。
特征口径、XGBoost 参数、评估指标和模型格式保持不变。样本数据始终留在 TBDSFS，平台在运行时按 Worker 数量进行数据分片和分发，无需提前制作固定分片，也无需迁移数据集。训练所需 CPU 和 GPU 按需申请、任务结束后释放，与数据加工和批量推理共用同一资源池，避免长期预占训练算力。
在分布式模式下，TBDS 负责 Worker 启动、数据分片、资源配置、指标采集、checkpoint 保存和失败重试；梯度同步与模型更新仍由 XGBoost 分布式后端完成。平台不改变算法框架本身，算法工程师面对的是同一套训练数据、参数和模型产物，扩展训练规模主要体现为资源配置变化，而不是重新设计建模方式。
TBDS 传统机器学习模型训练流程图
训练完成后，模型文件和 checkpoint 统一写入 TBDSFS，模型仓库登记版本、评估指标、文件路径和训练样本版本。批量推理和在线服务按版本加载同一产物。WeData 将样本构建、训练和批量推理编排为依赖链：样本就绪后触发训练，训练成功后触发全量打分，上游失败时下游不启动。
LightGBM、TensorFlow、Hugging Face 等框架的训练任务也可以运行在这套平台能力之上，团队不需要将已有模型改写为平台专用算法。
离线批量推理
模型训练完成后，需要对全量数据执行风险打分，产出可直接供下游使用的评分表。这类任务数据量大、模型相对固定、没有单请求低时延要求，与在线推理属于不同负载，应采用面向吞吐的批处理方式。
需要特别注意的是，不能把分布式 DataFrame 直接整体交给单机模型。XGBoost 需要 DMatrix，PyTorch 需要 tensor；如果先把分布式数据收集到单机再转换，分布式执行就会退化为单机瓶颈。TBDS 因此采用按批调度的批量推理运行方式：平台负责批次切分、分发和并发，模型每次处理一个内存占用可控的批次。
TBDS 离线批量推理
具体执行过程如下：特征表由平台切分为多个批次，分发到常驻推理 Worker；每个 Worker 在启动时加载一次模型，随后复用该模型处理持续流入的批次；推理结果直接写回 TBDSFS。数据始终以批次形态在集群内流动，不汇聚到单机，也不经过独立在线服务。
这种方式带来四点收益：
-
**不引入在线服务。**模型在 Worker 进程内部加载，无需部署独立的推理服务，链路更短、效率更高，GPU 推理同样适用。
-
数据不回单机。 批次由平台分发到各 Worker，内存占用恒定可控；数据量上涨后提高并发度即可线性扩展。
-
模型只加载一次。 加载发生在 Worker 初始化阶段，之后每个批次复用，避免了逐批重复加载带来的额外时延。
-
输入输出同在 TBDSFS。 评分结果与特征表落在同一套存储和版本体系里，Spark SQL 与下游 BI 直接可读，不产生新的数据孤岛；作业由 WeData 每日调度，与上游特征加工、模型训练串成一条依赖链。
将 XGBoost 模型替换为深度学习模型时，数据读取、批次切分和并发调度方式可以保持一致，只需根据模型运行要求调整执行逻辑、依赖和资源声明。
实际收益
TBDS 通过统一计算、存储和调度体系，将数据加工、模型训练和批量推理贯通在同一架构内，价值主要体现在三个方面：
减少交接。 样本、模型和推理结果不再跨平台导入导出，改动特征口径后可以在原链路内重跑；
提高算力利用率。 数据加工、训练和推理共用资源池，任务按需申请、结束后释放，避免为单一阶段长期保留机器；
加快迭代。 算法工程师面对同一套数据、参数和模型产物，单机到集群的扩展不再要求整体迁移开发环境。
在已落地项目中，这套方式使数据准备、训练和打分之间的人工交接显著减少，端到端处理耗时缩短 50%，项目交付周期由月级缩短至天级。
业务场景与结语
典型业务场景与收益
结语
企业 AI 建设的难点，已经从"是否拥有模型和算力"转向"能否把数据、算力、模型和治理组织成可持续运行的生产链路"。如果数据加工、训练和推理仍分散在多套系统中，再强的单点能力也会被环境等待、数据搬运和人工交接抵消。
TBDS 智算平台的核心价值，是把这些环节收敛到企业已有的数据平台能力之上：同一集群承载多种计算负载，同一存储承载数据与模型产物，同一元数据体系管理版本、权限和血缘，同一调度系统组织从数据准备到结果回写的完整链路。
这套架构并不要求企业推倒重建已有系统，也不要求算法团队改变熟悉的开发方式。它所做的是消除链路之间不必要的边界，让数据不再反复搬运、算力不再长期空转、模型不再依赖人工交接，使 AI 项目从一次性交付走向可复制、可治理、可持续演进的生产能力。