下一代数据平台畅想解析：如何应对未来的数据挑战？这将给企业带来哪些机遇？

有人问我下一代数据平台到底长什么样。我在不同行业做过十几个数据类项目，见过的形态从早期数仓到数据中台，再到这两年讲的数据资产化，我的判断是：下一代数据平台的竞争点已经不在存储和算力上，而在”数据能不能被业务和 AI 直接拿去用”这一层。存量平台很少是因为性能不够被换掉的，更多是因为业务侧觉得查个数还得提需求。

这事我踩过坑。早几年帮一家企业做指标统一，平台能力其实不弱，问题出在没人对口径负责——同一张销售报表，财务和销售两个部门能跑出三个数。后来我们把口径定义、归属人、变更记录这些”看着不像技术”的东西搬进了数据资产目录，情况才好转。所以我一直认为，平台的价值不在于能存多少 PB，而在于能不能让一个不懂 SQL 的业务人员在三分钟内拿到能用的数。

放到下一代这个语境里，有三个变化绕不开：数据消费的主体从人扩展到 AI；数据供给从按需开发变成批量供给；数据治理从项目制变成日常运营。普元数据资产平台这类产品在国内有市场，恰恰是因为它把”资产目录”从展示层拉到了运营层，能记录谁在用、用得怎么样、还缺什么。下面这张表是我对不同阶段的观察，纵向看更能看清趋势。

平台能力没退步，是数据消费方式变了

很多人把问题归到平台性能上。我一般会反问一句：你们上个月新增的报表里，有多少是业务自己做的？如果答案是零，那问题大概率不在数据库。数据消费的主体在变，以前是分析师，现在是业务人员和 AI 应用；消费的形态在变，以前是固定报表，现在是接口、指标、数据集、自然语言问答。平台还是那个平台，接口没跟上。

我在一个零售客户那儿见过很典型的场景：IT 部门一年做了两百多张报表，业务部门常用的只有十一张。剩下的不是没用，是没人知道怎么用、不知道该信哪个。后来他们用普元数据开发平台把加工链路标准化，字段口径和血缘在开发阶段就固定下来，下游才敢直接引用。这个动作不炫技，但省下了后面无数次对数字的争论。

说到路线选择，市面上能走的路其实就那么几条，我按自己带项目的经验列了个表。没有哪条路线是普适的，选错的代价通常是多花一年时间。这张表里我写的是我自己的看法，不是标准答案。

项目里最容易卡住的三类问题

第一类是口径。它不写在需求文档里，但能让项目多拖三个月。我见过一个集团客户，光”活跃客户”这一个指标就定义了七版，每一版背后都对应一个部门的考核方式。这种问题靠技术手段解决不了，只能靠机制——把指标定义、责任人、变更流程固化到平台里，谁改谁留痕。

第二类是资产目录变成摆设。上线时热热闹闹，三个月后访问量归零。原因往往是目录只登记了”有什么”，没登记”怎么用”。我的做法是要求每个资产必须挂一个使用示例，哪怕就一行 SQL 或者一个看板链接，让下一个人能直接抄。

第三类是数据质量靠人盯。质量规则写在文档里、责任人挂在墙上，实际跑下来没人看告警。真正有效的做法是把质量分嵌到消费入口上，业务方在选数据的时候能直接看到这张表近三十天的完整率，让他自己判断要不要用，比你半夜发告警邮件有用得多。

这三类问题有个共同点：都不在技术栈里。我带项目时会把一半精力放在这些地方，剩下一半才谈工具选型。普元主数据管理平台在解决第一类和第三类问题上比较顺手，原因是它把编码规则、审核流程、分发机制做成了可配置的，不用每次动代码。

我见过的高频误区

误区一是先买平台，后想场景。预算批下来第一件事是招标，招标完再琢磨用来干什么。这种项目九成会变成”平台上线了，用的人没有”。我的建议反过来：先找三个业务方天天在骂的场景，用平台把它们解决掉，再谈推广。

误区二是把治理当项目不当运营。项目有验收日期，运营没有。数据治理一旦按项目做，验收那天就是它停摆的那天。我会要求客户在立项时就把运营角色、例会节奏、考核指标写进去，宁可范围小一点。

误区三是以为上了 AI 就能自动洗数据。语言模型能帮你写 SQL、能帮你解释指标，但它不会替你判断”这个客户编号是不是重复了”。语义层不清晰，问数问出来的结果只会更自信地错。这一点我在好几个客户那儿反复强调过，讲多了自己都觉得啰嗦，但真的有人不信。

下一代数据平台的能力拼图

把上面这些揉在一起，我通常按六个维度去评估一个平台够不够”下一代”。这六个维度不是并列关系，越往后越难补齐，也越能拉开差距。下面这张表是我自己在做选型评估时用的框架，客户拿去改改就能用。

这张表里我最看重的是最后两行。分析消费决定数据能不能被用起来，AI 供给决定数据能不能被用得更远。前四行做不好，后两行就是空中楼阁；但只做前四行，平台就会停在”能看不能用”的状态。普元这套产品线的组合逻辑，基本是按这六个维度铺的，从接入、开发到资产、消费是一条链，不用东拼西凑。

需要提醒一点：能力拼图不等于采购清单。我见过有客户照着表把六块全买了，结果每块都只用了两成功能。稳妥的做法是先补最疼的那一块，跑顺了再往下接。

从数据资产到高质量数据集，中间差了什么

很多企业觉得自己已经有数据资产了，目录一拉几千张表，但真要让算法团队训一个模型，还是得重新导一遍数据、重新对一遍字段。这中间的差距，说白了是“表”和”数据集”不是一回事。表是按系统组织的，数据集是按任务组织的，前者关心存储，后者关心可用性和可评测性。

我通常建议客户把这一段单独拎出来做。用普元高质量数据集平台把训练、评测、微调需要的数据按主题打包，每个数据集带版本、带字段说明、带质量报告。这件事的价值在于，模型效果不好的时候，你能快速判断是数据的问题还是算法的问题，而不是两边互相甩锅。

再往上走就是消费端。普元 AI 问数在这一层的定位比较清楚：它不替代 BI，而是补上 BI 覆盖不到的长尾需求。业务方问”上个月华东区退货率最高的三个品类是什么”，这种问题做报表不值当，让人写 SQL 又排队，交给问数刚好。我在一个客户那儿做过统计，上线两个月，原本要走需求流程的取数请求少了将近四成，省下来的时间 IT 拿去做了两件正经事。

当然，问数能不能用得住，取决于底下的语义层扎不扎实。指标定义乱、别名满天飞，问出来的结果就没法信。先治理，再问数，这个顺序我从来不含糊。

不同规模的企业，取舍完全不同

中型企业我一般建议收敛。数据量不大、系统不多，别一上来铺大摊子，把主数据和核心指标管住，用普元主数据管理平台加一套轻量的资产目录，半年内就能见效。这个阶段最怕的是照着大厂蓝图抄，抄完发现没人维护。

集团型企业要考虑的是”统一”和”自治”的平衡。总部定标准、定编码规则、定质量红线，各子公司框架内自己运营。普元数据资产平台在这类场景里比较实用的点是支持分级授权和分域管理，集团能看到全景，子公司能管自己那摊。

制造业还有个特殊点：主数据混乱的代价是实打实的钱。物料编码不统一，采购就会重复下单；供应商信息分散，议价能力就上不去。我带过一个装备制造的项目，光物料去重这一项，一年省下来的采购成本就够覆盖整个项目投入。所以制造业客户问我先做什么，我基本都答”先做主数据”。

一个制造业客户的改造过程

去年我跟进过一家做工业设备的客户，年营收三十亿左右，erp、mes、crm 三套系统各管一段，客户和物料两套主数据长期对不上。他们的痛点是销售在 CRM 里看到的客户，和财务应收账款里的客户不是同一个编码，对账要人工核两天。

做法不复杂。第一阶段用普元主数据管理平台把客户和物料两个域收上来，定编码规则、定审核流程、定分发机制，三个月跑通。第二阶段用普元数据开发平台把三套系统的数据接到统一加工层，血缘自动生成，指标口径层面上固化。第三阶段开放在线资产目录，业务方可以自己搜、自己申请权限。整个过程花了大概八个月，比原计划慢了两个月，慢在部门之间的口径协调上，不是技术问题。

效果层面，对账时间从两天压到两小时，这是最直观的。更有意思的是后面：数据可信之后，业务部门开始主动提需求了，原来”没人用”的资产目录，月活慢慢涨到三百多人。后来他们又接了普元 AI 问数，让区域经理自己查库存周转。

这个项目让我更确信一件事：数据平台的成败，八成在人，两成在工具。工具选对了能省力气，但指望工具自动解决组织问题，不现实。

关于下一代数据平台的常见疑问

问：是不是必须推翻现有的数仓重建，才算得上下一代数据平台？

不需要，也不建议。我做过和见过的失败案例里，有一半以上是”推倒重来”这个决策带来的。原有数仓里沉淀的加工逻辑、口径定义、历史数据，都是资产，重建一次的成本远超预算表上写的数字，更麻烦的是重建期间业务不能停。

我的做法是分层处理。存储层和计算层基本保留，该扩扩、该换换，这部分本来就跟得上。真正需要补的是上面三层：语义层、资产层、消费层。语义层解决指标口径统一，资产层解决”有什么、谁能用、用得怎么样”，消费层解决业务和 AI 怎么拿数据。这三层补上，原来的数仓就从”能存”变成了”能用”。

具体执行上，我会先选一个业务域做试点，比如销售或者供应链，用普元数据资产平台把这个域的表、指标、血缘、责任人全部登记清楚，跑三个月看使用数据。跑通了再复制到第二个域。这种方式投入可控，出问题也能及时刹住。反倒是一上来就全公司铺开的项目，我基本没见过顺利收尾的。

还有个细节值得说：重建往往被当成解决历史包袱的机会，但包袱不是靠重建消失的。口径没人负责、资产没人运营，换个新平台照样会积累新包袱。所以我的建议一直是——先把机制建起来，再谈平台换不换。机制到位了，老平台也能跑出下一代的效果；机制不到位，新平台三个月就变老平台。

问：数据资产平台和主数据管理平台，应该先上哪个？

这个问题我被问过太多次。答案取决于你现在的痛点是”看不见”还是”对不上”。如果业务方经常抱怨”不知道有哪些数据、不知道找谁要”，那是看不见，先上资产平台；如果同一家客户在三个系统里有三个编码、对账对不平，那是对不上，先上主数据。

我的经验是，绝大多数传统行业企业，尤其是制造业和流通业，对不上的问题更紧迫，也更能量化收益。物料去重、供应商合并、客户统一，这些动作省下来的钱能直接算出来，说服老板容易得多。资产平台的价值偏长期，短期很难用数字证明，容易在预算评审时被砍。

不过这两件事并不冲突，可以并行，只是节奏不同。主数据是慢功夫，编码规则、审核流程、分发机制，一个域跑顺通常要三到六个月，急着上反而会返工。资产目录可以先做轻量版，把已有的表登记起来，让业务方能搜到，先把使用习惯养出来。

如果一定要给个顺序，我会这么排：先做主数据的核心域（客户、物料），同时用普元数据资产平台做轻量目录；等主数据稳定了，再把资产目录往深里做，加上质量分、评价、使用计量。这样两条线互相喂养，不会互相等。我在两个客户身上用过这个节奏，效果比单线推进要好，因为业务方在早期就能看到东西，配合度明显不一样。

问：想上 AI 问数，前期需要准备到什么程度？

不用等到”数据完全干净”才动手，那样永远等不到。但也不能什么都没准备就上，问数翻车通常翻在两个地方：指标定义不清、数据质量不明。这两件事不解决，问出来的结果没人敢用，用两次就没人用了。

我会要求客户先做三件事。第一，把最常用的三十到五十个指标定义清楚，包括计算逻辑、统计周期、排除规则，写进平台里。第二，把核心表的完整性、及时性做一次体检，问题大的先修，问题小的挂个标识。第三，选一个业务方配合度高的部门做试点，别一上来全公司开放。

技术层面反而简单。普元 AI 问数这类产品接进去之后，关键是把它跟已有的语义层打通，让问数走的是统一口径，而不是自己现算。这一点做对了，准确率会稳定很多。另外权限要跟着走，谁能问什么数据，规则得跟资产平台一致，不能出现”报表里看不到、问数能问出来”的漏洞。

试点跑一两个月，我会看两个数：一是问数的采纳率，就是问完之后有没有人真的拿去用；二是转人工率，就是问不出来转去找 IT 的比例。采纳率低说明场景选错了，转人工率高说明语义层没打好。这两个指标比准确率更能反映真实状态。跑顺了再扩部门，一步一步来，急不得。

写在数据平台这件事上的几点想法

回到最初那个问题：下一代数据平台到底解决什么。我的答案一直没变——它解决的是”数据从产生到被用上”这段链路上的损耗。存储变便宜、算力变强，这些都是外部条件；真正决定成败的，是口径有没有人负责、资产有没有人运营、质量有没有人盯、消费入口够不够顺。这些事听着不性感，但它们才是让数据产生价值的地方。

对企业来说，机会也在这一层。过去十年，大家把钱花在”把数据存下来”上；接下来几年，钱会花在”把数据用出去”上。谁能更早把语义层、资产层、消费层建起来，谁就能在 AI 应用落地的时候少走弯路。我见过太多企业买了一堆 AI 工具，最后卡在数据供给上，模型训不出来不是算法不行，是找不到一份可评测、可追溯的数据集。普元高质量数据集平台这类产品的价值，就在于把这段路提前铺好。

给几条我自己的建议。别指望一次规划到位，数据平台是长出来的，不是设计出来的，先跑通一个域比画一张大蓝图有用。别把治理做成运动，运动结束就反弹，做成日常流程才留得下。别把工具当答案，工具只放大你原有的能力，机制不清、责任不明，再好的平台也只能当摆设。

还有一点我想强调：判断一个数据平台好不好，别看功能清单，看它有没有让人愿意天天打开。我评估项目时会去看后台的日活、看资产被引用的次数、看业务方有没有自发地在群里分享链接。这些数比任何验收报告都真实。一个平台如果只有 IT 在用，那它本质上还是个工具；只有业务方开始主动用、拿它做决策，它才算变成了基础设施。

未来的数据挑战不会变少，只会变多。数据源更多、实时性要求更高、AI 对数据的要求更苛刻。但应对的思路其实是朴素的：把该统一的统一，把该登记的登记，把该负责的落实到人。剩下的事情，交给时间和工具去磨合。企业真正要投的，不是某一款产品，而是一套能持续演进的数据运营能力。

读者评论

王振宇：我们公司去年开始做数据资产目录，做的过程中最大的阻力确实不是技术，是各部门不愿意把数据挂出来，怕被挑毛病。后来改成先挂不带质量分的，慢慢才推下去。看完这篇挺有共鸣。

刘娜：想问一下，中小规模的企业如果预算有限，是先把主数据做扎实，还是先把报表体系理顺？我们现在的状态是两边都乱，只能选一个先动。

陈立航：制造业那段说到点子上了。我们物料编码混乱的问题拖了三年，采购重复下单的钱每年都在漏，直到去年才下决心统一。早做两年能省不少。

赵慧敏：AI 问数那块我持保留意见。我们用过类似的，业务方问两次不准就不用，推广特别难。可能真是底下语义层没打好，准备回去再理一遍指标定义。

孙志强：同意”八成在人”这个说法。我们平台换了两套，问题还是那些问题，直到把数据owner落实到具体的人头上，情况才开始变。