数据产品平台导航器
内容提要
文章以CNCF平台工程成熟度模型为框架，指导数据网格自服务平台的建设。平台需弥合高层数据产品概念与底层技术间的鸿沟。成熟度分为暂定、运营、可扩展、优化四级，涵盖投资、采用、接口、运营、度量五方面。仅靠工单或脚本自动化仍让开发者手动拼接组件，导致认知负担高、影子IT盛行。可扩展级是数据网格成功的最低门槛：平台以数据产品为中心自动完成供给与集成，降低门槛、促进自愿采用。优化级进一步融入开发者IDE/CLI，并形成联邦平台生态。
延伸解读
平台缺口：数据网格落地的真正障碍
文章指出，数据网格的高层概念（数据产品、数据契约）与底层技术（计算、存储、目录、查询引擎等）之间存在“平台缺口”。单一技术无法覆盖完整数据产品，而直接使用这些技术又缺乏必要抽象，导致团队难以理解数据产品在技术栈中的形态。因此，自服务平台的核心任务是在现有技术之上构建抽象层，以数据产品为中心整合供给与集成，而非简单堆叠工具。
可扩展级为何是数据网格成功的最低门槛
文章将成熟度分为暂定、运营、可扩展、优化四级。暂定级依赖个人关系与手动拼装，运营级虽引入工单或脚本自动化，但开发者仍需自行粘合组件，认知负担高、影子IT盛行。只有达到可扩展级，平台才以数据产品为抽象自动完成供给与集成，降低使用门槛，使自愿采用成为可能。文章强调，许多数据网格旅程卡在运营级，正是因为只自动化了单个技术组件，而未改善整体开发者体验。
成熟度模型是投资与沟通的指南针
文章建议用CNCF平台工程成熟度模型评估当前状态，识别摩擦最大的方面，再小步迭代改进。模型涵盖投资、采用、接口、运营、度量五个方面，其中投资与采用偏重人员、政策和流程，接口与运营偏重技术。文章提醒，各方面不必同步推进，但需保持平衡，避免过度投资某一领域。该模型还能帮助平台团队向利益相关者解释进展、优先级与投资价值，从而获得支持与资金。
Q&A
数据网格自服务平台为什么需要平台工程成熟度模型来指导？
因为平台团队常难以说明进展、排定优先级和证明投资价值，而CNCF平台工程成熟度模型提供了评估和推进平台能力的框架，可作为数据网格旅程的导航器，帮助识别高摩擦方面并迭代改进。
什么是数据网格中的“平台鸿沟”？
平台鸿沟指高层数据网格概念（如数据契约、数据产品）与底层数据技术（计算、存储、摄取、目录、查询引擎等）之间缺乏必要抽象而造成的脱节。单个数据产品需要多种技术组合，但没有一种技术能覆盖整个数据产品，导致团队难以直接使用技术，阻碍数据网格采用。
暂定级和运营级平台分别有什么典型问题？
暂定级平台是临时混乱的：开发者通过个人关系找不同工程师手动申请组件，没有数据产品或数据契约概念，认知负担高、技术碎片化、影子IT盛行。运营级平台虽通过工单系统或IaC脚本标准化了技术供给，但开发者仍需手动拼接组件，等待时间长、知识瓶颈高，常导致“科学怪人”式数据产品和影子IT。
可扩展级平台如何改变数据产品开发者的体验？
可扩展级平台以数据产品为中心提供自助服务门户和后端。开发者只需在门户中定义数据产品的架构规格（输入输出端口、转换代码、数据契约），平台后端便自动编排和集成所有底层技术资源（如Git仓库、CI流水线、S3桶、Iceberg数据库、Spark作业），将它们连接成标准化的数据产品。这大幅降低认知负担，消除知识瓶颈，强制架构标准，并鼓励自愿采用。
为什么说可扩展级是数据网格成功的最低门槛？
暂定级是混乱，运营级虽有序但认知负担高、开发者体验碎片化，常导致低采用率和影子IT。只有可扩展级平台让开发者与数据产品抽象交互，移除底层技术复杂性，使自愿采用成为可能，从而支持多领域团队去中心化 ownership，这是数据网格成功的前提。
优化级平台在可扩展级基础上增加了哪些能力？
优化级平台深度集成到开发者日常环境（IDE插件或CLI），让开发者无需切换上下文即可创建、开发、部署和监控数据产品。同时形成联邦平台生态，其他团队可直接向平台后端贡献能力，中央平台团队不再是瓶颈。此外，平台管理整个数据产品生命周期，支持技术演进时的迁移，并能跟踪使用情况以修剪未使用的产品和功能。
平台成熟度与用户采用率之间有什么关系？
在运营级及以下，领导层需通过政策强制推行平台，但工程师会绕开难用的平台走影子IT，采用率低。只有达到可扩展级，使用平台比自建更简单，才出现“内在拉力”，自愿采用成为可能。即便如此，采用率也不会一夜飙升，平台团队仍需宣传和教育用户。
