加过一些数据开发的社群，经常会有人问元数据系统怎么开发，大概网上很难搜到相关的好文章。
什么是元数据
首先，元数据的概念，通常解释为数据的数据，这个太难看懂了，需要换个角度解释。
举个例子，网上商城描述一本图书，会把书分类到某个学科，还会描述其价格、作者、出版社、语言、用户评价等，这些图书的额外描述就可以认为是元数据。这些图书的元数据可以用于图书馆管理，或者网上购物时的搜索和筛选。
再举个例子，一张图片，图片本身是数据，那元数据就是图片的文件名称、格式、尺寸、光圈大小、拍摄时间、拍摄地点、主题、人物等。照片有了元数据，就可以用于照片归类管理和检索，很多网络相册都提供了按时间、地点、人物筛选照片的功能。
数据仓库的元数据是什么
这个没有标准答案，因为每家公司的数据仓库不一样，从而其元数据也就不一样。参考Kimball的数据仓库经典理论，数据仓库的元数据可以这么划分
- 业务元数据：表和字段的业务含义、责任人、用户文档、培训资料
- 技术元数据：数据库描述、建表语句、存储路径、执行计划、备份计划、安全策略
- 过程元数据：假设数据每天跑一次，那每天几点开跑，几点跑完，最新的数据量，消耗的资源，数据质量校验结果，每天被查询的情况
值得一提的是，很多地方提到的开源的元数据系统，往往只做了技术元数据的一部分，仅仅是大数据基础设施的技术元数据。
数据仓库为什么需要元数据系统
因为有需求，能产生价值，或者提升效率，所以数据仓库需要元数据系统。特别是数据仓库达到一定规模后，靠脑力记不住数据仓库本身的所有信息。这里列举一些典型场景：
-
开发者
- 希望找到快速找到表或字段的业务含义，以便写出准确的SQL
- 希望知道一张表是不是已经更新了，或者每天什么时候可以用，防止用了旧数据
- 当有问题时，希望知道表的责任人是谁，方便联系咨询
- 用到一张陌生的表时，希望看看别人是怎么用
- 当一张表要发生变更或出错，希望知道对别人有没有影响
- 一张表的数据被人篡改或误删，找到是谁操作的，便于挽回损失
-
数据仓库管理者
- 数据仓库里到底有哪些数据了，有多少表，多少数据量
- 每天有多少人在用数据仓库，有多少任务在跑，消耗了多少资源
- 每天的任务是否按时完成，是否有数据质量问题
- 是否有任务消耗了太多系统计算资源，要找出来做性能优化
有些使用场景可以算作是数据管理/治理的需求，这个怎么划分不重要，首先得要有这些数据
元数据系统的本质
一个电商平台，它的核心数据是订单、商品，除了有面向用户的商品浏览和下单系统，还需要有个后台系统来管理订单、商品。同样道理，一个数据仓库最核心的东西就是表以及表里的数据，除了有个开发平台或报表系统开发这些表和数据，还需要有个系统来管理、监控这些表和数据的生产和使用，这就是数据仓库的元数据系统。
大数据时代，连自己的数据都管不好，怎么去用好那么多业务数据？
怎么开发一个元数据系统
实践证明，开发一个数据仓库元数据系统，技术上并不难，是个业务复杂度远大于技术复杂度的系统。
把需求搞清楚，做好设计，自然能做个有用的元数据系统。
