元数据一般被称为“数据的数据”，以元数据为关键展开数据治理，能够帮助企业更好地对数据资源进行管理，理清数据之间的关系，实现更精准高效的分析和决策。本文作者从自身工作出发，对元数据的基本功能展开了介绍说明，与大家分享。

本人在一家金融科技公司做B端产品经理，大数据方向的，2019年我们公司轰轰烈烈的启动了数据中台建设，作为数据中台的重要组成部分，元数据自然被提上了日程。在产品建设过程中遇到了很多坑跟大家分享下（第一次分享有错误还请大家多多包涵）。

关于元数据的概念的科普、介绍我这里就不多说了，大家在人人都是产品经理随便搜一下就有。

一、元数据功能介绍

在做元数据之前本人也做了很多的竞品分析（简单的），像这类产品更多还是乙方比较有经验举例几个亚信、普元信息、网达、星环等等。根据我们的需求现状我们确定任何一家成熟的产品都cover不住我们的需求，对于乙方习惯于标准化，非标的需求都不太愿意做，所以我们干脆就从0到1开始建设，不用他们的产品，只用他们的技术能力。

对于要不要从0到1建设取决于数据量和数仓建设情况，如果数据量不大直接买一个成熟产品即可或者根本不需要元数据产品，毕竟没有元数据也能建立数仓的（扯远了~），每个公司对元数据的需求可能都不太一样，元数据的标准化其实不太好做（对技术要求很高），因为你要能cover住大部分用户的需求，cover不住要么用户妥协、要么你妥协二次开发一些功能给用户使用。

根据我们的需求我们规划了以下功能（简单的介绍下）：

1. 基础功能

1）数据地图：分为数据资产、元数据中心，为用户提供元数据资产统计服务。

2）数据资产统计：用户可以通过数据地图清晰的了解数据的使用情况、分布等对整个数据资产情况有个大概的了解（这种分析统计类的需求是无止尽的，做一部分常用的即可，剩下的入库自己用可视化分析工具展示）

3）元数据中心：这是元数据核心功能之一，整个元数据的输出就是数据地图，用户可以通过元数据中心查看表的元数据信息（技术元数据、业务元数据）、任务信息、血缘关系（表级、字段级）血缘分析、使用信息等等（再多就看自己公司诉求了）

4）元模型：元模型是元数据的核心功能之一，主要实现技术元数据和业务元数据的管理、维护；这里说下子模型的概念，考虑场景的多样性比如运维更关注技术元数据、业务更关注业务元数据，针对不同的库、表可以应用不同的元模型，以满足不同人群的需求。

5）管理中心：管理中心主要针对功能权限、数据权限进行管理包括权限申请、审批、实施等。

6）我的数据：为用户提供查看自身权限、建表等功能。

7）数据管理：数据管理包含元模型、数据源管理等功能，用于元数据的手动、自动采集（生产的元数据采集依赖外部平台，大数据侧元数据采集我们自己做的）

8）元数据质量：主要做元数据治理用的，包含库、表元数据治理功能，分多个维度统计元数据完成情况，并可以做相应通知等。

9）其他：还做了一些其他功能如审计等，这里不细讲了。

2. 产品架构

我简单描述下：

• 存储/计算：元数据使用MySQL进行存储、图数据库，查询使用clickhouse，缓存分布式redis；
• 服务层：服务层提供基础的平台服务能力，包括元数据管理、元数据地图、管理中心、用户权限管理等。
• 通知服务：元数据管理系统中通知类消息目前有三种呈现形式，分别为站内信、短信、邮箱；
• 元数据采集：kafka、hook插件、flume、sftp
• 安全服务：LDAP认证、kerberos

二、产品建设的准备工作

1. 需求调研

关于需求调研、分析，需求从来都是无止尽的，没有上限，作为产品心中要给自己划个底线，你的产品边界、产品定位在哪里，尤其是需求方比较强势的时候，确定好边界和底线你才知道哪些能做、哪些不能做，哪些需要重点优先建设，这样你在交付产品才能得到需求方的认可。

我们就没有守住底线接了很多运维类的需求，同时也拒绝了很多运维类的需求，因为在做下去就变成了四不像了集ETL部分功能、数据加工部分功能、数据库管理功能等等等。元数据核心还是数据采集、数据地图、元模型、数据权限，当你接了太多需求时，还是回归产品定位、明确产品边界，时间有限、精力有限我们能做的也有限。

2. 数据采集

（1）采集内容的确认

基本只要是个具备大数据环境的公司都有数据采集的能力，采集可以用现有的能力、也可以单独开发，这里还是要看你采集的内容，在确定采集方案前还是要先确定内容，内容会决定你用什么技术方案。我们采集的内容我大致分为三种类型：应用信息、库信息、表信息

1. 应用信息：应用名称（中、英文）、应用类型、应用状态、应用负责人、地址等
2. 库信息：ip地址、实例名称、JDBC地址、库名称、归属部门、服务名称、用途、字符集、版本等等
3. 表信息：owner或库名、字段名、字段类型、字段注释、大小、行数、创建时间、分区、索引等

不同的类型库采集的内容不同，这里谈一下应用信息，我们是有专门的IT系统可以直接从系统里拿到，如果没有类似的IT系统，那采集方案就要重新设计和考虑了。

这三类信息我们都是直接从IT资源管理系统（CMDB）通过kafka消费，频率3小时一次，IT资源管理系统（CMDB）会从生产数据库、各应用管理平台等通过自身的采集能力拿到。

所有新增、变更需求由技术部门快速迭代开发响应。

写到这里大家肯定认为我们省了很大的工作量，但这恰恰是我们栽的第一个坑。我会在后几个篇幅来讲遇到的坑。

元数据的采集是个非常重要的功能，产品在设计之初一定要进行充分的调研，并跟开发确定好合理的方案，但同时也要考虑工作量的问题，是否可以先做一部分，后期再迭代优化，毕竟采集是基础能力，而用户更关心数据地图、权限和元模型

（2）元模型的确认

元模型决定你要展示的元数据信息包含有哪些内容，在采集前同样要确定好元模型的内容，考虑元模型的不确定性和变化性、我们前期可以定一个基础元模型，按照数据库的类型做区分如hive、Hbase、mysql、oracle、CK、ES等元模型，针对每个元模型定一个基础的。

比如hive我们可以包含所属库名（中、英文）表名、存储位置、存储大小、创建时间、分区信息、DDL变更时间、数据变更时间等。其他如oracle、mysql类似，在不清楚业务属性的时候我们可以把技术属性先确定了。这样就可以将采集到的信息按照元模型进行展示了。最终给用户呈现的内容就是元模型+采集到的基本信息。

后续内容比较多也比较重要我放到下一个篇幅来展开讲。

#相关阅读

聊聊数据中台：元数据建设有哪些坑（二）

本文由 @逆袭的骑士 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。