在数据中台和数据治理体系中元数据采集是一项比较基础的能力。很多人在第一次使用元数据管理功能时会有一个比较直接的疑问数据源已经通过数据连接接入平台为什么还需要再执行元数据采集这两个步骤解决的问题并不相同。数据连接主要解决的是平台是否具备访问数据源的能力。而元数据采集关注的是数据源内部有哪些数据对象、这些对象是什么结构以及这些结构后续是否发生变化。因此元数据采集的作用并不是重新复制一遍业务数据而是从数据库、文件系统或对象存储中获取数据对象的结构信息和基础描述信息并统一沉淀到元数据平台中。本文结合 qData 数据中台专业版的元数据管理流程主要说明几个问题元数据采集具体会采集哪些信息结构化数据和文件类数据如何进行采集采集任务、采集实例和最新元数据之间是什么关系数据结构发生变化后如何进行版本记录和对比已采集的元数据如何进一步用于数据资产注册。数据连接已经做了为什么还需要元数据采集假设企业已经通过 qData 建立了一个 MySQL 数据连接。完成连接后平台解决的是能否访问这个数据库。但对于后续数据治理而言仅仅“能够连接”还不够。平台还需要进一步知道数据库里面有哪些表每张表有哪些字段字段是什么类型哪些字段是主键、外键结构最近有没有发生变化哪些元数据已经经过确认哪些表后续需要纳入数据资产管理所以从数据治理视角来看数据连接更像是建立了一条访问通道而元数据采集才开始进一步识别和管理通道背后的数据对象。一、元数据采集到底是在“采”什么元数据经常被定义为“描述数据的数据”。放到企业数据平台里可以把它理解得更具体一些元数据描述的是一份数据本身的技术结构和基本属性而不是再次复制其中的业务数据。例如一张订单表里可能保存着几百万条订单记录。元数据采集不会再把这几百万条订单复制到元数据平台而是识别表叫什么属于哪个数据库包含哪些字段字段叫什么字段是什么数据类型长度、精度、小数位是多少是否必填是否属于主键、外键当前表和字段是什么结构。对于数据库类结构化数据可以把采集层级理解为数据源 → 数据库 → 数据表 → 字段只有把这些技术信息采集出来平台才真正知道一个数据源中存在什么数据对象以及这些数据对象当前是什么状态。不只是数据库文件类数据也可以进入元数据管理企业数据并不全部存储在数据库中。实际业务环境中还存在大量CSV、JSON、SQL、文档等文件。这些文件可能分布在不同的文件系统或对象存储中。因此qData 同样支持针对文件类数据进行元数据采集。与数据库不同文件类元数据更加关注文件名称文件类型文件大小存储位置来源系统更新时间等。也就是说无论是数据库中的表和字段还是文件系统中的文件对象元数据采集首先解决的都是同一个问题先把企业中分散存在的数据识别出来。二、这些元数据是怎么进入 qData 的元数据并不会自动出现在平台中而是通过元数据采集任务从指定数据源中获取。qData 可以根据数据类型创建结构化采集任务非结构化采集任务。对于**结构化数据**创建采集任务时第一步仍然是确定数据从哪里来。平台会关联相应的来源系统和数据连接并获取数据库类型、IP、端口、账号等连接信息。之后再进一步确定这次需要采集哪些内容。采集范围既可以覆盖整个数据源也可以根据数据治理范围自定义选择其中部分数据库。因此元数据采集并不意味着每次都必须“全量扫描”企业可以根据实际数据管理边界决定哪些数据库需要进入平台。同时业务系统中的数据库结构并不是长期不变的所以元数据采集任务还可以配置调度周期。例如每天固定时间执行一次元数据采集。这样平台获取的就不只是数据源第一次接入时的结构而能够持续同步源端最新的元数据状态。对于非结构化数据文件系统和对象存储中的文件也可以通过对应的数据连接将相关文件信息采集至元数据平台。整个采集过程可以概括为确定数据来源 → 确定采集范围 → 设置采集周期 → 执行采集任务其中采集任务定义的是“去哪里采、采什么、什么时候采”而每一次真实执行则会产生对应的采集实例。这个区别对于后续运行管理非常重要。三、采集任务执行完以后先看“这次有没有采成功”创建采集任务并不代表元数据已经成功进入平台。每次任务真正执行后都可以通过采集实例查看这一次具体的运行结果。采集实例会记录本次采集是否成功数据来自哪里采集耗时采集数量开始时间结束时间对应采集日志。它首先解决的是一个运行层问题“这一次到底有没有采成功实际采到了多少”对于周期性运行的元数据采集任务而言这一步也为后续异常排查提供了基本依据。四、采集成功以后元数据进入“最新元数据”当一次采集成功后真正获取到的数据结构信息会进入 qData数据中台 的最新元数据中。对于数据库类型的数据可以按照来源系统、数据库等层级查看当前已经采集的数据表。列表中能够进一步看到表名称、表注释、所属库、采集来源、当前状态等。进入具体表详情后还可以继续查看字段级信息包括字段名称字段注释数据类型字段长度字段精度小数位是否必填是否主键是否外键等。到这里数据连接与元数据采集之间的区别就更加直观。连接之前平台不知道这个数据源建立数据连接后平台知道“这里有一个数据库我能够访问它。”元数据采集完成以后平台则进一步知道数据库里面有哪些表、每张表有哪些字段、字段是什么类型以及当前结构是什么。文件元数据同样进入统一管理文件类数据采用类似逻辑。完成采集后可以在**最新元数据文件**中查看已经识别到的文件名称、文件类型、物理存储信息、来源信息以及修改时间等。进入文件详情后还能够进一步查看对应数据连接、文件路径、文件大小、来源系统以及相关责任信息。这样原本分散在不同数据库、文件系统和对象存储中的表、字段和文件信息就能够统一沉淀到元数据平台中。五、源系统一直在变化元数据如何保持同步如果元数据只采集一次它能够反映的只是某一个时间点的数据结构。但企业业务系统实际上一直在变化。例如一次系统升级之后可能出现新增字段删除字段修改原有字段。这意味着元数据管理不能只回答“现在是什么结构”还需要进一步回答“它和以前相比发生了什么变化”qData 通过周期性元数据采集持续获取源端最新结构同时保留相应的元数据版本。从最新结构继续看到“版本与变更”在表的版本与变更中可以查看不同元数据版本以及每一次版本对应的变化情况。例如某个版本新增了一个字段另一个版本删除了一个字段。这些变化都会通过版本记录保留下来。如果需要进一步判断两个版本之间究竟有哪些具体差异还可以通过元数据对比。选择基准版本 对比版本进行比较。这样元数据管理回答的问题就从“现在有什么”扩展为“以前是什么样现在又变成了什么样”对于数据平台长期治理而言这比单纯展示当前表结构更有价值因为很多数据问题本身就来自上游结构变化。六、确认后的元数据可以进一步“定版”对于经过确认、希望相对稳定保留的元数据版本qData 还可以进一步形成定版元数据。定版之后仍然可以查看对应的表结构和字段信息。这里需要特别区分一个概念定版元数据并不等于把元数据自动转换成数据标准。它更接近于将某个已经采集、确认过的元数据版本固定下来作为后续统一查看、管理和使用的相对稳定基础。因此从一次元数据采集到长期管理实际上形成了一条持续演进链路采集 → 更新 → 版本记录 → 变化对比 → 定版确认这也说明企业元数据管理并不应该只是“一次摸底”而需要随着源系统变化持续更新。七、采完元数据以后还能继续做什么如果元数据采集最后只是停留在“查看表和字段”它的价值仍然比较有限。当平台已经知道企业有哪些数据以及这些数据是什么结构之后下一步就可以继续进入数据资产建设。在 qData 数据资产模块中可以从已经采集的元数据里选择数据库表将相应的数据表进一步注册为数据资产。注册过程中可以直接选择现有元数据同时继续补充资产名称表类型数仓分层业务分类数据分域所属主题表命名规范资产描述等信息。这里实际上体现了元数据与数据资产之间的区别和联系。元数据回答“技术上有什么”数据资产回答“业务上是什么”元数据首先回答的是“技术上有什么数据”例如这张表叫什么来自哪个数据库有哪些字段结构是什么但进入数据资产管理之后还需要进一步回答“这份数据在企业里面到底是什么”例如属于哪个业务属于哪个数据域位于什么数仓层级应该如何分类由谁进行管理因此可以把整个过程理解为数据连接 → 元数据采集 → 元数据管理 → 元数据确认 → 数据资产注册元数据采集先把数据的技术结构识别出来之后再继续补充业务属性和管理属性逐步将原本散落在各业务系统中的数据纳入统一的数据资产管理体系。这也是为什么企业数据资产建设通常不能绕开元数据。因为在讨论“哪些数据值得作为资产管理”之前首先要知道企业到底有哪些数据。回头看一条元数据管理链路到底经历了什么把前面的过程重新串起来可以得到一条比较完整的 qData 元数据管理链路① 建立数据连接让平台能够访问数据库、文件系统或对象存储。② 创建元数据采集任务确定来源系统、数据连接、采集范围以及调度周期。③ 执行采集通过采集实例确认执行结果、采集数量、耗时以及日志。④ 进入最新元数据查看当前数据表、字段或文件的最新结构信息。⑤ 周期持续采集随着源系统变化持续获取最新结构。⑥ 版本与变更记录新增字段、删除字段以及不同版本的结构变化。⑦ 元数据对比比较两个版本之间的具体差异。⑧ 定版元数据将经过确认的元数据版本进一步固定和沉淀。⑨ 数据资产注册从已有元数据中选择数据表并补充业务分类、数据分域、数仓分层等资产属性。这样一来元数据采集就不再是一个孤立的技术动作而成为从数据发现到资产建设之间的一项基础能力。总结从完整流程来看元数据采集并不是简单获取数据库中的表数量和字段数量而是数据治理过程中用于识别数据结构、维护当前状态和跟踪结构变化的一项基础工作。在 qData 中这条流程可以概括为数据连接 → 元数据采集 → 最新元数据 → 周期更新 → 版本与变更 → 元数据对比 → 定版元数据 → 数据资产注册其中数据连接负责建立访问通道元数据采集负责获取表、字段、文件等数据对象的技术信息周期采集和版本管理则用于持续记录源端结构变化。当这些技术元数据经过确认后还可以继续补充业务分类、数据分域、数仓分层等属性并注册为数据资产。因此从技术实现和数据治理流程来看元数据采集主要解决三个问题第一当前有哪些数据第二这些数据是什么结构第三这些结构后来发生了什么变化。只有先建立相对完整、可持续更新的元数据基础后续的数据资产管理、数据标准、数据血缘以及其他治理工作才有比较明确的数据对象作为管理基础。