导读

在生成式人工智能（Gen-AI）迅猛发展的今天，数据基础设施（Data Infra）正面临前所未有的挑战与机遇。9月12日的外滩大会，举办了一场以“Gen-AI时代下，Data Infra的重构与机遇”为主题的圆桌讨论。云器科技联合创始人&CTO关涛、阿里云计算平台资深产品专家黄博远、蚂蚁集团数字增长平台与服务总经理师文汇共同探讨了这一时代性议题。

本文主要针对以下内容进行探讨：

• Gen-AI时代下，Data Infra哪个核心痛点，使得其必须从‘优化’走向‘重构’？
• 新一代 Data Infra 应该是什么样的？
• 统一大平台 vs. 可插拔架构，架构选择背后的思考？
• 数据基础设施建设中的血泪经验？
• 新一代数据基础设施催生的商业机遇与价值

为何必须“重构”？——新范式下的核心痛点

Q：在大模型的冲击下，各位认为当前数据基础设施（Data Infra）最核心、最无法回避的痛点是什么？是怎样的关键变化，让我们从一般优化迈入“重构”这一步？

关涛：数据技术演进至今经历三次重构，大模型提供高阶智能计算与非结构化数据的处理能力

谈到“重构”，我们其实是在讨论向前演进。我们可以从数据技术发展的历史视角来看——我在这个领域已有 18 年经历，数据技术是一个长期演进的过程。早在 1970 年代数据库时代，第一轮突破就来自于关系模型（Relational Model）的提出，它专注于结构化数据处理，由此诞生了现代数据库技术和 Oracle 等伟大公司。这是一次理论突破驱动的创新，也就是第一次重构。

到了 2020 年左右，大数据兴起，带来了第二轮创新——规模驱动创新 。数据规模扩大百倍之后，催生了新的能力。如今我们熟知的 Google、字节等流量型公司，以及蚂蚁的快速支付能力，背后都是由大数据技术支撑的。海量数据使得人的行为可被分析和利用。

而大模型时代，叠加了理论驱动（如深度学习）和规模驱动**（模型规模带来“涌现”能力）** 。这两者结合，构成了数据架构向第三代的演进：从数据库时代，到大数据时代，再到大模型时代。这一变化带来了两方面的重大影响：第一，是一种全新的计算能力——不同于以往关系模型的高阶智能；第二，是更大规模的数据处理能力。以往我们主要处理的是可被结构化的数据（约10%），而如今像视频、语音等非结构化数据（占90%）也变得可处理。正是这两点，带来了强烈的重构需求。

黄博远：计算范式变革推动重构，用户体验变化要求底层引擎升级

我对这个问题的看法和关涛非常相似。当前数据平台之所以需要重构，是因为底层计算范式已经发生变化。回顾我们多年从事大数据和 AI 的经历，此前的两代计算范式分别是 SQL 和 MapReduce。而如今，几乎所有底层引擎都在支持向量计算、非结构化数据处理，并集成 AI 函数（AI functions）。这种计算范式的转变，也引发了用户使用模式（Pattern）的变化：以前大家写 SQL、写 MapReduce，而现在可能通过自然语言或上下文（Context）定义目标。

这种变化将自上而下推动重构：用户使用方式变了，上层平台就必须调整；为了适配新的计算模式，底层引擎也需升级。例如，NVIDIA 之前分享中提到，很多场景需借助异构计算加速。如果我们不能快速转向异构计算以高效处理非结构化数据，整体效率就无法保障，最终会影响用户体验。所以说，当前这个时代，数据平台确实面临一次重构，我们也期待更彻底的变革。

师文汇：不仅是“重构”，更是“重新定义”，以新范式去承接尚未察觉的问题和需求

我刚刚听下来，觉得大家的观点很一致。我认为不仅是“重构”，很多东西其实是被“重新定义”（Redefine）的。关涛老师提到，过去几十年我们建立了一门基于关系代数的科学，衍生出 SQL 语言，非常适合处理表格或图结构等结构化数据。但如果我们面对文本、多模态等非结构化数据，还缺乏类似的统一方法。

举一个简单例子：昨天我们讨论视频数据处理时提到，当前音视图文的压缩和存储，大多为了码率和还原度设计，并未针对大模型优化。我们是不是可以重新设计，让非结构化数据更易被组织和使用？也就是所谓“Coding for AI”。

我们是否需要一种更原子的编码格式或数据组织形式，以便更高效地处理这类数据？因此，我认为“重构”是为了解决已知问题，而“重新定义”更是面向未来——以新范式去承接尚未察觉的问题和需求。

新一代数据底座的核心能力是什么？

Q：大家从“Why”的角度深入探讨了“重构”这一命题，聊完“Why”之后自然要关注“What”。因此第一个问题想请教关涛：目前行业趋势普遍倡导Lakehouse架构，您认为Lakehouse需要哪些新的核心能力？

关涛：Lakehouse架构已经Must-Have形态

这个问题非常关键。Lakehouse在过去三四年间已逐渐成为主流形态，如今构建数据平台若未采用Lakehouse架构，几乎会被视为不合时宜。它从可选项变成了默认选项。这一转变背后，主要有三方面原因：

第一，AI技术引入了第二个计算引擎 。传统架构主要依赖单一的数据分析引擎，而现在需要同时支持AI引擎和数据分析引擎。双引擎架构对系统设计提出了更高要求，必须实现深度解耦——数据本身需要开放可访问，元数据需具备开放性，权限体系也需重新梳理和编织，以确保两个引擎能高效、协同地工作。

第二，半结构化和非结构化数据的存储/处理能力变得至关重要 。AI新引擎能够理解音视频等复杂数据类型，这使得大量非结构化数据得以进入数据平台。Lakehouse架构因其“湖”的特性，能够存储任何格式的数据，但现有格式可能尚未完全适应这一变化，未来很可能涌现新的数据格式来更好地承接和管理这类数据。

第三，计算模式正在发生根本性变化 。大模型支持百万级Token的上下文窗口，听起来很大，但折算成数据量仅约4MB。若用大模型推理手机中1TB的数据，需执行25万次操作。这表明AI计算对数据输入的要求高度精准，需从海量数据中精确定位并抽取少量相关信息馈送给模型，而非传统大数据模式下更常见的扫描（SCAN）、聚合（Aggregate）和连接（JOIN）操作。这种转变类似于搜索引擎的架构——用户输入查询词，系统从全网快速检索并返回最相关的少数结果。因此，计算模式需从以扫描和聚合为核心，转向“扫描聚合+高阶精细化抽取”并重，更关注位置信息（Position）和记录定位（Record），从而支撑这种智能检索的需求。

统一大平台 vs. 可插拔架构，平台方如何抉择？

张婧 ：博远是来自阿里云计算平台，文汇是蚂蚁集团数智增长与平台服务总经理，两位的工作都围绕“平台”展开。那么，从平台方的视角出发，在进行架构选型时，你们会更倾向于一个统一的大平台来管理所有数据，还是更偏向解耦可插拔的架构？这背后的核心思考是什么？

黄博远：构建以可插拔数据引擎为基座的“数据神经中枢”

我从2016/2017年开始从事大数据相关工作，当时就和关涛一起探索一体化平台的路径。在我看来，“一体化”和“可插拔”并不矛盾 ，尤其在当前的技术背景下。作为平台方，统一管理元数据、集中控制元数据，对模型理解数据至关重要——我现在主要精力投入在AI平台，明显感受到模型迭代非常快，但如何将物理世界中的数据高效供给模型，反而成了巨大挑战。可以说，物理世界与数字世界的连接，正是构建在数据平台之上。

如今我们需要的不仅是一站式平台，更是一个“数据神经中枢”。模型如同超级大脑，但若没有中枢支撑，它无法感知真实世界的变化。因此，我们正在努力将多种计算模式与引擎整合起来——目前确实很难靠单一引擎处理所有问题，特别是在非结构化数据涌入的背景下。关涛之前提出的Lakehouse理念也启发我们思考：如何让结构化和非结构化数据的元信息在一个神经中枢上流动。

以前我们谈一站式管理，虽利于统一管控，但也伴随着高复杂度。这就好比开汽车容易，但驾驶波音747则需专业训练。而现在，大模型为我们提供了一种“自动驾驶”般的能力，去驾驭这些数据。如果中枢能触达多样数据，并由一个强大的AI大脑进行高效处理，其能力已远超少数管理人员或工程师。因此，我认为当前的数据平台应致力于构建一个以可插拔数据引擎为基座的神经中枢，真正连接物理世界的数据与数字世界的模型，成为两者之间的纽带。

师文汇：从 user friendly 到 agent friendly

我与博远的理解较为一致。蚂蚁内部有一个 slogan，叫“从 user friendly 到 agent friendly”，和黄老师说的很像——数据不再只是给人用，更多是在服务 agent。

面对架构选择，蚂蚁坚持“开放兼容、自主可控”的原则。这意味着我们既注重统一规划，也积极融入开源和外部生态。具体来说，系统分为几个层次：

最底层是“通算与计算结合”，将通信和计算视为一个整体资源池，所有计算任务基于此运行。

中间层是“Unified Catalog”（统一元数据目录），这在大规模非结构化数据环境下尤为关键。正如关涛所说，目前超过90%的数据属于非结构化，分散且难以被理解和发现。统一的元数据管理能够有效告知中枢——或者说AI大脑——数据在哪里、是什么。

最上层是面向开发者的。这一层有趣的地方在于，是否可以通过一种统一的查询语言（unified query language）整合音、视、图、文等多模态数据的处理。同时，我们和Anthropic等公司的探索方向类似，正将数据处理方式从“pipeline-centric”转向“agentic-centric”。前者依赖人工优化，而后者希望agent能自主完成数据的持续改进。本质上，这是从“以模型为核心”到“以数据为核心”的转变，agent将主动从数据中提取智能，推动系统效果不断进化。

来自一线的血泪经验：我们踩过哪些“坑”？

张婧 ：在蚂蚁这样的大型企业体量下，支持大规模 AI 应用的数据基础设施建设过程中，踩过最大的“坑”是什么？有哪些值得分享的血泪经验？

师文汇：如何有效应对“面向不确定性”的程序设计挑战

确实踩过不少坑，过程其实挺痛的。我举几个例子：

第一，以往我们做 Java 或 C++ 这类程序设计时，基本是基于状态机（State Machine）的——所有的业务场景和状态流转都能被预先完整地设计和描述清楚。比如用户购买商品并支付，流程是可被良好定义的。但进入 AI 时代，许多环节充满了不确定性，研发模式发生了根本性变化。我们面临的挑战，是如何有效应对这种“面向不确定性”的程序设计。我们尝试构建了 Agent 平台，借鉴了类似 SOP（标准作业程序）的范式，但更关键的是，数据平台如何为开发者提供一套可控的 CI/CD Pipeline，帮助他们更好地管理质量，并建立数据的 Benchmark 体系。

第二个坑，可能做数据的同学，包括关涛，都会深有同感：我们过去做数据工程，很多研发和设计是“面向结果”的。最终产出的可能是一张表或一个图，但中间过程缺乏沉淀——既缺少工程化的过程记录，也缺乏对架构的中间状态管理。这导致一个严重问题：当数据量极大时，你却找不到所需数据，或者无法追溯数据的来源。我们曾有一个非常痛心的案例：在一个重要场景中，使用了一份已经停滞两年、完全过时（Stale）的数据。在 AGI 时代，这个问题可能会更严重。因为大家都知道，一旦数据被污染，模型性能（Benchmark 分数）可能虚假地飙升。在多人协同开发中，很容易将受污染的数据带入大模型或 AI Agent。如何有效管理这些数据，尤其是非结构化数据？之前徐磊也提到，非结构化数据处理的关键在于Feature Engineering。在我们内部，每一行数据可能对应上千个特征——这本身就是大数据处理范式的重大转变：以前我们做 CRUD，现在更关注 Scoring、Filtering、Curation、Refinement和 Selection。所有这些原子语义都变了，下游的血缘关系和特征关联，都直接影响最终效果。但若中间过程丢失，我们既难以复现已成功的工作，也无法在出错时快速定位——问题究竟出在哪儿？与哪份数据相关？

张婧 ：接下来想请教博远，作为云厂商的代表，您经常与各类企业客户交流。在您观察中，企业在建设New Data Infra时，遇到的具体困难主要有哪些？是组织架构、人才缺失，还是历史技术债务等问题？

黄博远：企业从POC到生产可用存在巨大鸿沟

我主要分享两方面：一是我们平台上客户的痛点，二是我们作为云厂商自身遇到的挑战——说实话，我们自己的“痛”可能更深刻。

首先从客户侧来看，自2023年底起，AI应用热潮兴起，许多企业认为AI无所不能，但一个显著的痛点是：从感受到AI的“Aha moment”（惊喜时刻），到真正在生产 pipeline 中稳定可用，中间存在巨大的转化落差。

例如在2024年初，RAG（检索增强生成）技术非常火热，很多客户希望快速构建自己的RAG应用。我们作为云厂商也提供了相应工具，最初承诺一天可构建，后来甚至优化到半小时以内。表面看来，基于企业内部数据搭建一个问答式的RAG系统似乎很简单，技术也很成熟。但真正从概念验证（POC）走向规模化落地并产生实际收益的项目非常少。究其原因，主要有三大挑战：

一是确定性问题。大模型本身具有不可控性，比如连续询问相同问题，可能会得到不同答案。随着 Agentic（智能体）技术的引入，更多数据 pipeline 由模型自主驱动，一旦流程不可控，企业客户很难接受。

二是可解释与可视化。即便结果不确定，企业也期望能够清晰理解模型的推理过程。此前有一个开源项目 Defi 很受欢迎，它其实并非“AI Native”的编排方式，但很多企业客户却偏爱它，为什么？因为由大模型自动生成的 pipeline 往往与企业设想的逻辑差别很大。客户需要 pipeline 可观、可控，符合企业内部固定流程——他们不希望系统过于“创造性”或频繁“涌现”，反而期待稳定可靠。

三是安全挑战。企业将数据放到云上，必然非常关心安全。尽管我们提供等保认证和各种安全解决方案，但一旦追求极致安全，系统复杂度就会大幅上升。客户的需求往往非常细致，比如同一公司不同部门之间的数据也需严格隔离。端到端的安全保障及权限精细化管理，仍是一个亟待解决的难题。

总而言之，从 POC 到生产可用，AI 在前者推进得非常快，但后者仍存在巨大鸿沟。这些问题往往需要平台方与产品团队积累大量实战经验才能更好应对。

第二个我想分享的痛点，涉及基础设施（Infrastructure）本身，这也是我们自身踩坑最深的地方。

2023–2024年间，我们认为训练与推理应该分开部署：推理似乎不需要高性能网络，机器间无需紧密互联。于是我们削减高端网卡和交换机的配置以降低成本。但现在情况变了——模型越来越大，分布式推理成为常态，这给基础设施带来全新挑战。如果底层架构灵活性不足，比如机房和机架已固定，再想新增网线或交换机就非常困难。

同样，CPU 与 GPU 的配比也是个大问题。在“Physical AI”真正到来之前，很多人并不重视一台 GPU 服务器应该配多少 CPU。早期搜推广系统追求高 CPU 密度，到了大模型时代大家又转向高 GPU 密度，而现在 Physical AI 的兴起，又让我们发现很多计算仍依赖于 CPU。这种变化对架构提出了新要求。

值得庆幸的是，阿里云早在2015/2016年设计服务器时，那时候关涛提出了一种“机头-机尾”架构：机头部署 CPU、内存，连接 VPC 网络，机尾则专门放置 GPU。当时我觉得有些过度设计，但现在看来非常前瞻——它极大提升了 CPU/GPU 配比的灵活性，且无需改动机架，只需考虑电力支持即可。

所以说，基础设施需具备高度灵活性以应对变化，尤其当底层物理资源（如水电、网络）需调整时，是否能快速响应是企业面临的一大挑战。对于大多数企业，如果聚焦于上层应用与数据平台，或许无需过度关心这些底层细节；但作为云厂商，我们必须直面这些痛点，并致力于为客户提供更稳定、更灵活的底层支持。

风口浪尖：新基建催生的商业机遇与价值

张婧 ：现在我们聚焦今天的另一个关键词——“机遇”。在新一代数据基础设施（Data Infra）的技术升级背景下，其所催生的新商业模式和价值增长点在哪里？在各位看来，这一轮重构带来的最大商业机遇是什么？

黄博远：数据领域有望实现三位数增长，智能体或催生“硅基原生”应用

在我看来，这个领域依然充满潜力（promising）。若谈机遇，可从两个层面展开：

第一是当前已显现的机遇。对数据领域而言，最大的机遇无疑在AI。如今数据平台能否被AI广泛应用至关重要。以LessDB为例，许多自动驾驶客户选择Less格式进行数据处理，效率显著提升。当前，预训练（Pre-training）或许已接近瓶颈，但强化学习（Reinforcement Learning）正兴起。越来越多企业不再专注于超大规模预训练，而是转向后训练（Post-training），无论是有监督微调（SFT）还是强化学习（RL）。这对数据平台带来一系列新机会：例如在RL中，如何制定合理的策略（Policy）以快速提升模型能力？如何让模型更易理解对错？目前最直接的方法是通过数据进行验证。因此，数据平台需思考其处理能力能否应对AI后训练中的这些挑战。若能解决，数据领域也有望实现三位数增长，并进一步增强AI能力。

第二是数据更宏大的机遇。模型变强后，如何真正发挥作用？我观察到，虽然数据与AI圈内人士频繁使用AI，但周围许多人仍较少接触AI。做好模型的核心目标，是实现另一种“涌现”——业务的涌现。要实现这一点，需注意到平台使用者可能不再仅是数据或AI原生用户，而可能出现“硅基原生”应用。这类新应用通过什么与模型连接？依然是数据。目前我尚未有完整答案，但若我们能率先发现智能体（Agent）对数据存储和计算的独特需求，并提前布局，或最早把握此风口，数据平台可能迎来十倍甚至百倍的增长。

因此，这两个层面——先服务好AI，再通过AI服务好业务——若能把握，必将为数据领域带来巨大成功。

师文汇：增长与创新双轮驱动，Data Infra成为AI创新发动机

我从企业视角补充两点思考，分为增长和创新两个层面：

在增长层面，我深信“万物 Scaling Law”。当前许多关键领域（如搜索、推荐、广告）的模型本质是分类模型。大模型出现后，这些模型可被升级迭代：原本仅能使用表格数据（Tabular Data）做分类，现在可整合多模态数据、文本数据，甚至外部世界的数据。这不仅能提升业务效果，更为增长提供持续动能。全球类似工作很多，如Meta的GR、快手的OneRec，都试图通过更大量数据提升业务效果。

在创新层面，蚂蚁内部AI应用和AI+业务蓬勃开展，智能体（Agent）数量快速增长。我们需思考如何助力业务创新——无论是AI对原有业务的改造，还是打造AI Native应用。例如，开发生产级Agent可能需要两个月加七天：其中两月用于数据处理（Scoring、Filtering、Mixing、Selection等），剩余七天则用于将其转化为SOP（标准作业程序）、调试Agent效果并进行Benchmark测试。因此，我们希望数据基础设施（Data Infra）能成为面向AI创新的发动机。

关涛：让90%的人能直接受益于数据价值

我举一个具体例子，可能更直观。

创业前，我和博远在阿里云共事。当时阿里90%的数据由我们管理。我们曾统计一个指标：有多少人能直接使用数据？阿里内部数据平台日活（DAU）约为30%。创业后我发现，这已属较高水平——许多企业可能不足10%，仅依赖少数数据分析师，上百人需通过这几人获取数据。

在阿里时我们分析：为何无法突破30%？那70%的人为何不用？主因是他们不会写SQL——在阿里，需写SQL的岗位基本都学了，包括运营同学。但如HR、非技术背景的业务人员，可能从未接触过SQL。大模型改变了这一点：通过聊天方式，用户可更自然与机器交互。平台从“面向人”转向“面向机器”，由此衍生大量商业机会，让90%的人能直接受益。这正是价值体现的一个小例子。

给实践者的一句金玉良言

张婧 ：在圆桌最后，请三位嘉宾分别用一句话建议，送给现场各位：如果要推进这件事，最应避免的是什么？最重要的是什么？请每位给出一句金句建议。谢谢！

**关涛 ：**我代表的大多是中小厂商视角。对多数企业而言，你可能并不具备“AI三件套”（算法、算力、数据）——中小企业往往无力自训模型，所用硬件也大同小异。此时，最核心的差异化要素就是你企业自身的数据。当与同类企业竞争，使用相同模型、相同硬件持续升级时，你的核心竞争力就在于数据。因此我的建议是：投资数据！投资数据！投资数据！

**黄博远 ：**我个人的建议是：要聚焦在自己特定领域的客户价值。如今我们构建了太多 Infra、太多平台，大厂在这些方面确有优势；但作为创业者，在细分领域实现突破，是打造自身核心竞争力、快速取得成功的重要捷径。

**师文汇 ：**我的建议比较简单：找一个靠谱的场景，先搞起来！

**张婧 ：**谢谢大家！今天的圆桌讨论到此结束，感谢各位。

🎁 新用户专享福利

✅  1 TB 存储 · 1 CRU时/天计算 · 1 年全托管体验

➤ 即刻访问云器官网领取：https://www.yunqi.tech/product/one-year-package