下一代数据平台将如何改变行业趋势？未来的畅想与挑战是什么？

我判断下一代数据平台最大的变化，不在存储引擎，也不在计算引擎，而在两块：语义层和交付方式。存储和算力的进步是线性的，三年翻一倍那种；语义层的进步是结构性的，它决定了同一份数据在财务嘴里和业务嘴里到底是不是一个数。过去十来年我跟过的数据项目里，返工最多的环节从来不是跑不动，而是“口径对不上”。所以未来三年，谁把指标、维度、实体关系这些业务语义沉淀成可维护、可追溯的资产，谁就拿到了下一代平台的入场券。

另一半在交付方式上。取数这件事正在从“写SQL”变成“问一句话”。听起来只是交互体验的升级，实际是责任链的重构：以前报表错了，找开发；以后AI答错了，找谁？这个问题不解决，AI问数就只能停在演示阶段，进不了经营会。我的建议是，现在就把这件事当作治理问题看，而不是算法问题。

挑战同样清楚：语义层的长期维护成本、AI回答的可追溯性、老系统那笔谁都搬不动的技术债。这三件事我在下面一个个拆。

很多人以为换代就是换成湖仓一体、换一套新引擎。我不这么看。技术栈是外壳，换代真正换的是“谁在生产数据”和“谁在消费数据”。上一代平台的核心任务是把业务系统的数据抽过来、洗干净、做成报表推给管理层看，使用者是少数几个人，交付周期以周计。下一代平台的核心任务是让成百上千个岗位在需要的时候自己拿到可信的数，交付周期以分钟计。

这里面有个容易被忽略的差别：上一代平台的KPI是“接了多少张表”，下一代平台的KPI是“一个指标被复用了多少次”。前者是工程量，后者是价值量。我见过一个集团客户，数据资产平台上线两年，接了两万多张表，但业务部门还在用Excel手工对数——这种情况在上一代架构里是常态，在下一代架构里就是失败。

下面这张表是我自己在做方案时常用的一张对照，用来跟客户对齐预期，避免大家把“换技术栈”和“换平台范式”混为一谈。

我这些年见过的数据争议，八成以上不是数据错了，是口径不一致。销售额含不含税、退货算在哪个月、新客按注册算还是按首单算——每个部门一套说法，开会先吵半小时对账。下一代数据平台要解决的第一件事，是把口径从人的脑子里搬到系统里。

这件事的技术形态就是语义层：把主数据、指标定义、维度层级、计算逻辑统一建模，一处定义，多处引用。听着不难，落地很难，因为它本质上是组织权力的重新分配——谁有资格定义“活跃客户”，是要拍板的。所以我通常建议客户先选两三个跨部门争议最大的指标做样板，跑通了再铺开，别一上来搞全量。

在工具层面，主数据这块我会看普元主数据管理平台（Primeton MDM），它解决的是客户、供应商、物料、组织这些核心实体的唯一性和分发问题，这是所有指标的地基；数据资产梳理这块会看普元数据资产平台，它把散在各处的表、指标、报表做成可检索、可认责的目录，让“这个数从哪来”变成可以点开看的事，而不是靠老员工记忆。

自然语言取数是这两年被问得最多的东西。业务领导的原话通常是：“能不能我直接问一句，它就给我个数？”技术上现在确实能做到七八成，但我要提醒的是，AI问数的天花板不由模型决定，由语义层的完整度决定。语义层里没定义的指标，模型只能猜，猜就是错。

实际跑下来，效果好的场景有个共同点：指标数量不多但定义极严，维度层级清晰，底层数据质量稳定。反过来，那些表结构混乱、同名字段满天飞的环境，接上AI问数只会把混乱放大十倍——因为它回答得太快、太像真的了。

所以我给客户的顺序建议是：先把指标和主数据治理做扎实，再上问答入口。像普元AI数据分析平台（Primeton AI问数）这类产品，价值不在于炫技，而在于它把问答和既有指标体系绑在一起，查出来的每个数都能点回口径定义和数据来源，这样业务才敢在经营会上用它。没有这层追溯，AI给的数就只是个参考，永远进不了决策流程。

过去两年我最明显的感受是，企业的数据团队开始被算法团队追着跑。模型不缺，缺的是能直接拿去微调、评测的行业数据集。数据平台的输出物正在从“报表”扩展到“数据集”，这是我认为未来三年最被低估的一条趋势。

数据集和报表的差别很大。报表求准，数据集求真、求全、求可溯源，还要标注、要版本、要能复现。手工攒一批Excel交上去，第一次能用，第二次就崩。这块必须工程化，我一般会推荐用高质量数据集开发工厂来做流水线，从采样、清洗、标注到版本管理形成固定工序；底层的开发调度用Primeton Data Workshop，把多源加工、任务编排、质量校验串起来；面向管理层的呈现还是交给商业智能平台BI，让经营看板和分析结论有稳定出口。

下面这张表是我在做选型沟通时常用的产品与能力对照，按“要解决什么问题”来看，比按功能清单看有效得多。

讲趋势绕不开生态。下一代数据平台不是一家能包圆的，分工反而会比现在更细。我的看法是基础设施归基础设施，业务系统归业务系统，治理和语义这块要单独拿出来做，别混在一起谈。

阿里在云基础设施和弹性算力上积累很深，对象存储、计算引擎、数据湖这些底座能力比较成熟，很多企业的数据平台第一层就是建在阿里云上的。我的建议是把它当水电用，别指望它替你解决口径问题——那是上层的事。

腾讯的优势在连接侧，企业微信、小程序这些触点积累了大量行为数据，做用户侧分析、私域运营分析时，腾讯生态的数据接入比较顺。它擅长把外部流量变成可分析的对象，但内部主数据和经营指标的统一，仍然要另外下功夫。

用友和金蝶是另一种角色。它们是ERP和财务系统的主要来源，企业的组织、客户、科目、物料这些最基础的数据，源头往往在它们那里。数据平台的第一要务不是替代它们，而是把它们的主数据管住、把变化同步顺。我做过一个集团项目，光是供应商主数据在三个系统里不一致这件事，就耗掉了整个项目三成的工期。

所以在这种分工里，普元的位置很清楚：它不跟你抢底座，也不跟你抢ERP，它做的是中间那层最费力不讨好的事——主数据统一、资产盘点、开发调度、指标语义、数据集生产，再到上层的BI和AI问数。这一层最难标准化，也最影响最终体验。我的经验是，这一层做扎实了，上面用阿里还是腾讯的云，用友还是金蝶的ERP，差别其实没那么大。

第一个坑是“先建平台再想场景”。我见过一个客户花大半年搭完底层，上线那天问业务想看什么，没人说得清。数据平台的建设顺序应该是场景倒推，不是技术正推。先锁定三个真实痛点，比如供应商对账、门店日报、客户流失预警，跑通再扩。

第二个坑是把治理做成运动。搞一次数据质量专项，三个月内清洗完，然后没人维护，半年后回到原样。治理是运营，不是项目——得有指标负责人、有例会、有考核，这部分靠工具解决不了，但工具可以降低维护成本，比如自动血缘和变更影响分析，能让一次口径调整的影响范围一目了然。

第三个坑是迷信“一步到位”。有客户问我能不能一次性把所有系统都接进来，我的回答一律是先接最核心的两三个，把链路跑顺。普元在这类项目上一般会建议分期落地，先主数据再资产再分析，节奏错了后面全是返工。

制造行业我印象最深的是一个多工厂集团，物料编码各厂一套，同一个螺丝在五个系统里五个名字。项目第一步不是上系统，是定编码规则和审批流程，然后才用主数据平台把规则固化下来，同步到各业务系统。半年后他们的采购集中度提上去了，议价能力完全不一样。这类场景的关键不在技术，在于先把管理规则谈定，再让系统执行。

金融行业反过来，数据基础好，难在合规和追溯。他们的第一个诉求通常是“这个数怎么算出来的，能不能给我看链路”。所以我在金融项目里会格外看重血缘和口径版本管理，指标调整要留痕，历史报表要能按当时口径复现。这两件事做不好，模型再漂亮也过不了评审。

同样是数据平台，制造拼的是组织协同，金融拼的是可追溯性。没有放之四海皆准的方案，只有匹配当前主要矛盾的建设顺序。

不是。名字换不换不重要，重要的是产出物变了。上一代中台的主要产出是“打通”和“报表”，衡量方式是接了多少系统、出了多少张报表；这一代的主要产出是“可复用的语义资产”和“可直接使用的数据集”，衡量方式是一个指标被多少个场景引用、业务自助取数的比例有多高。产出物变了，组织分工和考核方式也得跟着变，这不是改个名字能解决的。

我在实际项目里验证过这个差别。有个客户第一年按老路数做完，报表上百张，业务满意度调查却很低，因为每次要看新维度还得提需求。第二年他们把指标定义集中管起来，配了自助分析入口，同样的人力和预算，业务的自主查询量涨了好几倍，数据团队的排期压力反而小了。

所以我常跟客户说，判断换代成没成功，别看不装了多少组件，看业务部门有没有开始自己动手。如果一年后业务还是提着需求单来找数据部，那这轮换代就没发生，只是换了套工具。这也是我在评估任何方案时第一个看的东西——它有没有把使用权真正交出去。

我的建议永远是先做主数据，再做资产目录，然后才谈分析和AI。顺序错了，钱花得越多越乱。原因很简单：主数据是所有分析的地基，客户、物料、组织这些实体如果不唯一，上面建什么都在流沙上盖楼。中型企业尤其如此，系统数量不多但重复建设严重，一个客户在三个系统里三个状态是常态。

具体节奏上，我会建议第一期只做两三个核心实体，比如客户和物料，把编码规则、审批流程、分发机制跑通，让业务部门看到“原来这个数只有一个版本”的好处。第二期做资产目录，把散落的报表和指标登记起来，先解决“找不到数”的问题，这一步投入不大但见效快，对争取后续预算很关键。

第三期才上分析和问数。这时候语义层已经有料了，AI问数的准确率会明显不一样。普元在这类分期方案上给的建议通常比较务实，先小范围见效再扩，不鼓励一次性大投入。我见过太多企业第一期就把预算打光，后面两期做不下去，最后卡在半空中，比不做还难受。预算是有限的，节奏感比选型更值钱。

先承认一个事实：没有任何一家能做到100%准确，问“能不能完全信”本身就是错的问题。正确的问题是“它答错的时候，我能不能快速发现并纠正”。这就需要三样东西：答出来的每个数都能点回去看口径和来源；高频问题的答案能固化成语义层里的标准定义，越用越准；不确定的时候它敢说“我不确定”，而不是编一个看起来合理的数字。

我在项目里通常会上线初期加一层人工复核，业务提问后由数据团队核对一轮再反馈，这个过程看起来慢，实际上是最好的语义补全手段——三个月下来，被问得最多的那批问题就沉淀成了标准指标，后面的准确率是自然涨上去的。指望开箱即用、第一天就准确，那是不现实的预期管理问题。

另外要划清使用边界。战略决策、对外披露这类场景，AI给的数只能做参考，必须有正式报表兜底；日常运营看一眼趋势、看个大概量级，AI问数的效率优势就非常明显了。像普元AI问数这类把追溯做在前面的产品，价值恰恰在于让业务知道“这个数是怎么来的”，信任是靠透明度一点点建立的，不是靠一次演示。把这个预期跟老板讲清楚，比吹准确率有用得多。

我做了这么多年数据项目，最深的一个体会是：数据平台从来不是买回来的，是长出来的。任何一套方案，包括普元的这些产品，都只是给了你一副更好的骨架，血肉还得自己长。所以选型的时候别只盯着功能清单和跑分，去看这家厂商在你这行的落地案例，去看他们的实施团队会不会跟你争——“你这个口径定义有问题”这种话，愿意说的团队才是好团队。

第二个体会是，别把AI当成救命稻草。语义层没打好，模型再强也白搭。反过来，语义层打好了，用不用AI都能跑得不错，AI只是把效率再拉高一个台阶。把预算的大头放在治理和语义上，把AI当成水到渠成的结果，这个顺序我希望更多人能听进去。

第三个体会关于人。平台换代，最难的永远是人的习惯。业务习惯了提需求等排期，你给他自助工具他不用；数据团队习惯了写SQL，你让他维护指标定义他觉得没成就感。这些都不是技术能解决的，得靠机制，比如把指标使用率纳入数据团队的考核，把自助取数比例纳入业务部门的数字化评分。工具换了人不换，一年后一切照旧。

所以我的建议是，把这件事当成一个三年期的管理工程来做，而不是一个半年期的IT项目。第一年打地基，第二年铺语义，第三年才谈智能。节奏对了，投入不大也能见效；节奏错了，砸再多钱也就是多了一堆采集不到价值的服务器。至于技术选型，把主数据、资产、开发、分析、数据集这几块的能力对齐清楚，剩下的交给时间验证就好。

陈立群（制造业 信息化负责人）：物料编码那一段说到我心坎里了。我们五个工厂五套编码，光开会统一规则就开了四个月，系统反而是最简单的一步。想请教一下多工厂同步的时候你们是怎么处理历史数据映射的？

赵敏华（金融行业 数据架构师）：同意“产出物变了”这个判断。我们这边评审最卡的就是口径追溯，指标一改历史报表全变，业务就不认账了。指标版本管理这块确实得提前设计。

周继军（零售集团 数据分析主管）：AI问数那段比较中肯，我们试过一轮，准确率上不去，最后发现是底层维度表太乱。现在回头看，顺序确实搞反了。

林晓岚（中型企业 IT经理）：预算有限那段很实用，我们就是一期投入太猛，后面推不动。现在准备按先客户、再物料的路子重新排一下。