数据资源平台与云资源系统一体化建设：从元数据治理到成本管控实战

接手这个“No.4 信息资源系统”项目的时候，我第一反应是：这就是把数据资源平台和云资源系统捏到一块儿来做。做了十几年信息化，这类项目见过不少，但真正能把自己家数据管好、又把云资源管顺的，其实不多。数据资源平台管的是“数据怎么来、怎么治理、怎么用”，云资源系统管的是“计算、存储、网络这些底座怎么分配、怎么监控、怎么控制成本”，两者联合起来，才是真正意义上的信息资源底座。这套东西适合谁参考？主要是企业内部信息化团队、数据架构师、运维负责人，以及正准备立项做数据中台或云管平台的同事。这篇我把从需求梳理、平台选型、落地实施到问题排查的完整过程都写出来，尤其是那些文档里查不到的弯路和经验。

1. 整体设计思路：为什么要把“数据”和“云”放在一个盘子里

1.1 数据资源与云资源的关系，不是简单拼凑

很多企业前期数据平台和云资源是分开建设的：大数据团队买一套商业数据治理产品，运维团队再上一套云管平台，两条线各管各的。结果就是数据平台要扩容，得走线下去找运维审批资源；运维想了解哪些业务系统在用哪些数据，只能靠表格统计。两套系统各自闭环，信息断层严重。

这次我们反着来，从一开始就明确：数据资源平台负责数据资产化，云资源系统负责算力和存储的供给，两者之间必须有联动。举个例子，数据开发跑一个离线任务，需要申请10台虚拟机和2TB存储；过去是发邮件审批，现在云资源系统里创建一个项目空间，配额自动分配下去，数据平台的任务调度器拿到资源标签就能直接调度，整个过程留痕、可追溯。

这么做的好处很直接：

• 资源使用有据可查，哪条数据链路消耗了多少CPU、内存、存储，一目了然；
• 数据的权限和资源配额可以联动，避免“数据开了权限却没有资源跑任务”的尴尬；
• 成本能归属到业务方向，财务算账时不吵架。

1.2 自研、商业产品还是开源组合，选型背后的权衡

方案选型阶段，我们内部吵了很久。商业套件成熟，但数据治理功能往往偏重，很多模块买回来就是摆设；纯自研周期长，风险高；开源组合自由度大，但要投入人力维护。

最终选了“开源核心组件+自研封装”的路线。数据资源平台使用Apache Atlas做元数据和血缘管理，用DataHub或者自研的目录服务做资产展示；云资源系统基于OpenStack和Kubernetes做统一管理，外层自研一个资源管控服务。这么说吧，底层轮子尽量不重复造，但面向用户的交互、流程、权限体系全部自己写，这样既控制成本，又能保证贴合内部流程。

对比考虑过VMware vRealize这类商业云管，功能很强，但问题在于：它对国内企业的资源命名规范、审批流和审批人习惯支持一般，定制开发费不低。而开源组合在API层面更友好，我们团队可以完全掌控。

1.3 总体架构分层，核心是“解耦”

整个系统架构分四层：

• 接入层：负责对接业务系统的数据源、虚拟化平台、容器集群；
• 服务层：数据资源平台包含元数据采集、数据质量、数据服务；云资源系统包含资源纳管、配额管理、监控告警；
• 核心层：统一权限中心、统一任务调度、统一消息通知；
• 展示层：数据资产门户、资源管理大屏、项目工作台。

每层之间只通过标准API交互。这个设计不是说技术上多高级，而是保证两边团队能并行开发，数据组和云平台组只需要约定接口协议，内部怎么实现互不干扰。实测下来这个决策大大减少了联调痛苦。

2. 数据资源平台：资产化治理，核心在元数据和数据质量

2.1 元数据管理和数据血缘，建议上线就做

数据资源平台的名字听着抽象，但落地时第一个重点就是元数据管理。所谓元数据，直白说就是“数据的数据”，比如一张订单表，它的字段含义、类型、负责人、更新频率都是元数据。

我们上线后的第一件事，是把所有业务系统的库表元数据自动采集进来。以MySQL、Oracle、Hive、Kafka这些常见数据源为主，通过采集任务每天定时同步表结构变更，然后在元数据详情页展示字段注释和负责人。这项工作是后面所有能力的地基，没有完整准确的元数据，数据目录就是空架子。

血缘追踪也是比较容易被低估的功能。推荐至少做到字段级血缘：一张报表的某个指标，能追溯到从原始表哪个字段加工而来。初期可以只做“表到表”的血缘，但要预留字段级的能力。实际做的时候要注意：很多商业工具的血缘是基于SQL解析实现的，调度脚本里如果写了临时表，血缘就会断。我们当时的做法是让数据开发提交任务时主动登记“输入表-输出表”映射，再定期用脚本扫描HQL做交叉验证，两条腿走路。

注意：血缘解析不要迷信自动化。存储过程、动态SQL、多层嵌套视图，任何工具解析都可能出错，人工补录机制必须要有。

2.2 数据质量校验规则，不用一开始铺太全

数据质量模块如果设计得太复杂，往往用不起来。我们只做了几个核心维度的校验：完整性、唯一性、一致性、有效性、及时性。对这五个维度，刚开始每类业务表只加上3到5条关键规则，比如“订单金额不能为空”“订单日期不能早于创建时间“”用户ID在用户主表中必须存在”。

规则要配置成可动态启停，避免开发和运维吵架。规则引擎的任务跑完出报告，评分不合格的表自动生成待办推给责任人。这里分享一个经验：数据质量规则不要弄得像考试一样求全责备，指标能覆盖最关键风险点就够了。优先级是“先保证核心业务表关键字段”，再逐步扩大范围。

2.3 数据服务化：把数据装进API，而不是甩数据库连接串

数据资源平台另外一个容易被忽视但是价值很高的模块，就是数据服务。过去业务系统要数据，直接给数据库账号，结果连库的表越开越多，无法审计，严重影响性能。这次我们要求统一走数据服务API，通过平台发布接口，调用方申请权限，走统一鉴权和限流。

数据服务层我们用了Spring Cloud Gateway做转发，底层支持连接Hive、MySQL、Redis多种数据源。发布API时只需要配置SQL和参数，系统自动生成文档和调用示例。调用方拿到的是只读查询权限，而且有超时熔断，不会因为一条慢查询拖垮库。

这块实际操作时有一个小技巧：数据服务不要直接对原始表查询，建议在中间层建清洗后的汇总表或宽表，服务层只对接中间层。这样性能和安全性都可控，也方便后续做加密脱敏。

2.4 主数据和标准管理，见效慢但一定要留坑

主数据管理最容易做成“看起来很厉害但没人用”的模块。我们做了一个轻量版本：只统一了客户、组织和物料三类主数据的编码规则，并通过API向上游业务系统下发。这个模块不建议一开始就大张旗鼓做全量集中治理，先从容易出成绩的对象开始，否则动了各业务系统的核心编码，项目会陷入长期拉锯。

3. 云资源系统：核心是纳管、配额和成本可视化

3.1 资源纳管：虚拟机、容器、物理机统一建模

云资源系统首先要把“家底”摸清楚。我们内部有VMware虚拟化集群，也有一部分Kubernetes容器平台，还有少量物理裸机。纳管的第一步是统一资源建模：每台设备有资产编号、所属项目、所在机房（或可用区）、规格信息（CPU核数、内存、磁盘），全量入库。

通过vCenter API和K8s API做自动发现，每10分钟同步一次状态。做了两周后效果就很明显，之前的Excel台账直接废弃。资源界面能让运维一眼看到某项目的虚拟机和Pod分别用了多少资源，有没有超配。注意超配问题很关键，很多虚拟化平台超分会严重超配，统计时要把“已分配”和“已使用”两套口径分开，否则决策会出错。

3.2 配额管理与审批流：管住“谁用了多少资源”

云资源系统最敏感的就是配额。没有配额管理，开发能申请到大量资源，然后利用率极低，成本失控。我们按“项目空间”维度做配额：每个项目可申请的CPU、内存、存储总量有上限，超额必须走审批。

配额计算参考了历史同期消耗，并叠加业务增长系数，公式大致是：

• 配额 = 近30天日平均消耗 × 1.5（弹性系数） + 高峰缓冲
• 高峰缓冲 = 近30天最大日消耗 - 近30天日平均消耗

虚拟机创建和容器资源变更都接入审批流。审批页里会自动显示当前项目配额剩余量，避免审批人翻表格算账。这个功能上线后效率提升明显，原来申请资源来回半天，现在只要审批人在手机端点一下就行。

3.3 计量计费：从成本模糊到按项目分摊

成本可视化是我个人觉得整个项目里最有“老板感知”的部分。云资源系统每天从虚拟化和容器平台采集资源用量，结合采购单价，折算成每个项目的日成本。月底生成账单，直接同步到财务系统。

计量计费不必追求绝对精确，主要看趋势和占比。比如项目A的云资源成本占了全公司40%，其中存储费用占比异常高，那就要去看是不是存了太多不常访问的数据，可以推动做冷热数据分层。

3.4 监控与告警预留了“关联分析”能力

云资源系统的监控不能只盯着CPU和内存。我们把“资源监控”和“数据平台任务”做了联动：离线任务失败时，能直接关联到对应计算集群当时的负载、IO延迟、内存使用率。排查效率会提升很多。监控告警可以做两套，一套是底层基础设施的实时指标，一套是业务视角的资源饱和度。两套分开，告警不互相淹没。

4. 实操过程：从调研到上线，分五步走

4.1 需求调研阶段：别只盯着部门领导，多问一线用户

启动前我们花了两周做需求调研，访谈对象包括：CIO、数据架构师、运维负责人、数据分析师、数据开发。这里我的建议是，每个角色都要约1到2次深聊，而且要追问“现在干活最烦的是什么”，而不是“你希望系统有什么功能”。

汇总后的痛点非常典型：

• 数据开发不知道有哪些表能用，靠口口相传；
• 运维不清楚每个项目占了多大云资源，月底成本靠倒推；
• 数据质量出现问题，没人知道找谁修；
• 申请资源流程长，紧急需求跑不过审批。

这些痛点后来直接转化成了平台的核心功能列表。调研一定要重视一线声音，特别是数据开发，他们是被动使用这个系统最多的人，他们觉得难用，项目推广就失败了一半。

4.2 平台部署规划：硬件不重要，网络策略才重要

这套系统本身没有特别夸张的硬件要求，中等配置即可：数据资源平台和云资源系统的服务端用16核CPU、32GB内存起步即可，存储根据元数据规模和采集频率估算，通常1到2TB足够跑一年。重要是提前规划好网络策略。

数据采集服务需要访问各业务系统的数据库，云资源系统需要调用虚拟化和容器平台的API，这些往往不在同一个网段，需要提前梳理端口和防火墙策略。我们第一批元数据采集任务失败的原因，基本都是网络不通，而不是程序Bug。

4.3 分阶段实施路线：先“通”后“治”，再“用”

落地节奏建议分三批：

第一批：打通基础设施。部署云资源系统，完成VMware和K8s集群纳管，实现资源自动发现和配额管理。同时把数据资源平台的元数据采集搭好，至少做到所有核心库表可见。

第二批：做深治理。完善数据质量规则，跑通数据服务和API网关，为主数据编码改造做准备。云资源系统这边把计量计费和成本报表上线。

第三批：做优体验。数据资产门户、资源大屏、移动端审批全部完善，开始做数据资源和云资源联动的场景，比如按项目维度同时展示“数据资产清单+资源配额消耗”。

这个节奏的关键是：第一、二批让系统可用，第三批让系统好用。如果一开始就追求完美，项目周期会拉得很长。

4.4 关键配置参考：任务调度的几个参数

元数据采集和数据质量任务都用调度框架管理，统一用的DolphinScheduler。几个关键参数我们的配置供参考：

注意：采集任务并发不能拍脑袋调大。我们有一次把并发调到16，结果把生产库的连接池打满，直接影响业务。最佳实践是先小后大，观察源库CPU和连接数再逐步增加。

4.5 权限体系：数据权限和资源权限分开看

权限设计容易踩坑。建议数据权限由数据Owner负责审批，资源权限由项目负责人审批，两套权限模型统一在统一权限中心里管理，但审批流分开。不要混着来，否则数据库权限开到了一堆人，云资源申请还是走形式。

角色模型参考：

• 超级管理员：系统配置、全局审计；
• 数据Owner：管理元数据、数据质量、数据服务权限；
• 项目管理员：管理项目空间下的资源配额、成员、审批；
• 普通成员：申请资源和数据服务API，查看自己的资产和数据。

5. 常见问题与排查技巧实录

5.1 元数据采集不全，大多是网络和账号权限问题

上线第一个月，我们统计到有大约20%的表没有采集到元数据。排查路径一般是：

• 先看采集任务日志，网络是否超时；
• 再确认数据库账号是否有表结构查询权限，很多只给了DML权限，查不了information_schema；
• 最后看是不是表名忽略了大小写规则。

还有一个容易被忽略的场景：某些老系统用的是Oracle，schema里有一堆临时表、系统表，采集任务必须做白名单过滤，否则采集出一堆无用元数据，影响检索效果。

5.2 数据质量规则误报率过高，怎么调整

我们最初配置“订单金额不为空”规则时，发现误报率高达30%。排查下来原来是源系统的历史脏数据太多，早期有一些订单金额确实为空但业务上不关注。这类问题不能全盘兜底，最好按数据分区配置规则生效范围，比如只校验最近180天的数据，历史脏数据走专项治理。

另外，规则阈值要保留调节空间。建议质量评分体系做“趋势对比”，哪怕当前分数不高，只要持续上升，就说明治理在改善，这对汇报很有利。

5.3 云资源成本数据对不上账，两个坑要避开

计量计费上线后第一周，财务反馈成本数据对不上采购金额。排查发现两个原因：

一是虚拟机磁盘使用量统计口径错误，vCenter上报的磁盘是配置容量，不是实际消耗量，需要换算； 二是容器集群的资源单价没有包含节点本身的系统预留部分，一个8核节点分配给Pod的只有7核，剩下1核要给系统组件。

修正方法是建立一个“资源单价折算表”，把系统预留、管理组件开销统一折算进单价，而不是事后分摊。

5.4 云资源系统API偶发超时，限流要做好

云资源系统开放API给数据平台调用后，出现过几次超时告警。原因是批量数据接口被一个耗时操作占满线程池。后来给API网关加了每个应用每分钟的调用配额，并对慢查询设置了超时熔断，核心接口响应时间从平均800ms降到200ms以内。

提示：每次新增API，一定要设置默认限流，不要默认放开。线上环境的访问量往往在节假日高峰突然上涨，在高并发下才想起来做限流就晚了。

6. 项目落地后的几点实际收益

云资源配额上线一个季度后，虚拟机和存储资源申请量明显下降，因为各项目组开始自己盯着余量，不再盲目申请。数据资源平台方面，数据服务API累计被调用了几十万次，真正实现了“让数据安全地流动起来”。更关键的是，老板能看到每一分云开销花在哪个项目上了，数据治理也不再是空口号。

如果你们也准备做类似的信息资源系统，建议先明确一个边界：不要企图一个系统解决所有问题。数据资源的治理是逐步深化的，云资源系统的管控也是逐步细化的，两个模块能集成联动已经是很好的状态。抓住元数据、数据质量、资源配额、成本分摊这几个刚需，项目就成功了大半。

最后分享一个实在的心得：这种平台型项目，最难的往往不是技术，是让用户“愿意用”。我们在每个功能上线时都配了10分钟以内的短视频操作说明，建了答疑群，前两个月几乎天天在群里回答问题。等用户形成习惯后，平台的口碑就自然起来了。系统建设的路很长，但先让核心场景跑顺、让人爱用，比什么都重要。