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

元数据地图

上期讲到数据地图，这一期重点来讲，开始之前说点别的，类似元数据、ETL平台类的产品、非常考验开发的技术水平。

这里有个问题，作为产品需不需要参与每个技术方案的评审？这里我建议在时间允许的情况下尽量都参与下，很多时候开发给的技术方案都是为了实现而实现，而需求从来都不是一层不变的，在定一个技术方案的时候也要考虑万一我的需求或者场景变了的情况下，是否都能够满足？

而且技术方案变化也是很正常的事情，除非你们有CTO专门帮你们订好方案和评审。这里我建议产品尽量参与下，很多问题都可以在初期就可以避免。

数据地图最核心的功能有两个：元数据信息的展示、血缘关系。

元数据信息的展示上期已经讲过了，根据采集的信息+元模型进行展示，这里需要考虑的问题就是要尽量全，要对展示的信息进行一个分类，不然会很乱。

我这里分了几种：技术信息、业务信息、权限信息。这里我只说下权限信息，用户在查询元数据的时候我们要给出权限的信息，读、写还是无权限等，同时还要提供数据预览的功能，当用户无法通过技术属性和业务属性直观的了解数据时，还是可以通过查看数据内容去理解数据（建议限制20条）。

关于血缘关系需求：

血缘是元数据最核心的功能了，关于如何提血缘的需求产品要多听听用户和技术的声音，血缘存在一个覆盖率的问题，是100%还是90%以上即可？

用户都希望可以实现100%，但现实是打脸的，每个公司的场景都不一样很难有公司说我们cover你们公司所有场景，可以保证血缘100%解析。如果真有要么这个公司技术水平非常高，要么是忽悠你。

SQL作为一门语言它可以有成千、上万中写法，还可能会引用各种函数、这里还存在书写不规范的情况谁敢保证能够100%覆盖？

PS：我这里说的血缘是指要到字段级的。

关于血缘需求的第一个建议：

1. 实现不了的，列出来，订好规范尽量避免这种写法出现，比如银行会有类似10大铁律，发现即惩罚，来避免出现解析不了的情况。
2. 能实现的要100%覆盖，出现就是bug。
3. 长期、大量测试要有，覆盖主要业务场景。

关于血缘需求的第二个建议：

1. 按照行业TPC-DS的评测标准，100%覆盖。
2. 超出的按照新需求迭代开发，不算bug。

说明：TPC-DS算是比较通用的大数据领域SQL测试标准，还有TPC-BB, TPC-H。

TPC-DS提供99个SQL查询（SQL99或2003），分析数据量大，测试数据与实际商业数据高度相似，同时具有各种业务模型（分析报告型，数据挖掘型等等）。

以下为TPC-DS详细信息：

https://cloud.tencent.com/developer/news/83351

血缘影响分析：

在规划影响分析时，我也参考了其他厂商做的，比如普元、亚信、阿里云，主要场景基本类似，主要分析字段或者表发生变更时对下游链路的影响。我们做的比较简单，提供表、字段的血缘分析，可以通过查询表或字段来分析整个血缘链路的影响，尤其是链路较多的时候会用到。

血缘从哪里解析？存哪里？

用过ETL的都知道，ETL也有血缘或者叫依赖关系，一般情况都是ETL先建设，元数据都是后建设，血缘本质是解析SQL输出表与表之间的关系，而SQL基本都是来自于ETL的任务，所以大部分的做法都是ETL将实时传给元数据，元数据进行解析，我们也是类似。

这里就涉及一个存储的问题了，传统的数据库肯定是没有问题的，但传统的数据库存在打开慢的情况，尤其是血缘链路长的时候（几百个表），这里的建议就是使用图数据库在存储血缘关系。

Neo4j、TigerGraph、Amazon Neptune、JanusGraph、ArangoDB，是市场上最为知名的五大图数据库品牌，我们用的是Neo4j。

科普性的我尽量少讲，让大家更关注元数据本身，感兴趣的看下这个连接：

https://www.zhihu.com/question/19916683

• 开源 NoSQL 数据库，原生的图数据库，2003 年开始开发，使用 scala和java 语言，2007年开始发布；
• 世界上最先进的图数据库之一，提供原生的图数据存储，检索和处理；
• 采用属性图模型（Property graph model），极大的完善和丰富图数据模型；
• 专属查询语言 Cypher，直观，高效。

跟ETL如何对接？如何确保SQL100%覆盖？

我总结产品问题：凡是跟其他系统对接的都是坑。

刚刚提到的血缘100%覆盖，但是这中间还有个问题，如果ETL不能100%的把SQL传给你，你就算实现了100%解析也没用。

ETL的逻辑：保存-提交-次日运行。

我们的方案：任务提交时触发通过kafka将SQL以及任务信息传给元数据。后续再讲这个方案到底哪里有问题。

表的任务信息如何展示？

这里就又有问题了，在元数据里都是以表作为纬度去查看它的其他信息，但是在ETL里面都是以任务为纬度去查看它的表信息，这里就出现一个表可能会有多个任务的情况，但实际上我们只关心它的数据来源是哪个任务。

解决方案：ETL任务、目标表、源表对应关系，简单来说就是提供我们要的表跟它的任务对应关系接口。

还是那句话凡是跟其他系统对接的都是坑。

表的使用信息怎么拿到？

在查看表的元数据过程中，用户还会关系这个表是否有人使用过，尤其是类似仓库的数据，你建好的主题域、集市表根本没什么人用，那是不是考虑后续不维护了或者自身找原因是不是不满足用户需求。需求很简单，但是实现很麻烦。

类似的指标数据我们定了好几个，这里我拿出其中的1个展开讲。

表的使用次数：

表的使用次数非常麻烦，因为这里有个准确性的问题，你要多准？100%准确么？还是大概准确就可以？

数据中台怎么会没有查询平台那，类似即系查询、tableau等等都可以查看数据，如果要大概准确可以从即系查询平台拿到，如果要100%准确那就麻烦了。

解决方案：

最全的日志都在底层，我们是从从hive拿到的metastore日志，这个绝对是100%准确，我们是通过SFTP定时从hive拿到metastore日志然后在做解析，这里时效性就没办法保障了，如果要做到实时使用flume会影响即系查询的查询性能，这个是运维不允许的，所以我们只做到准确性，不保障时效性（T+1）。

表发生表更了如何捕获？

生产表发生变更了如何捕获？

我们的做法时每次全量同步做merge，将变更内容做记录。

最麻烦就是Hive元数据变更的捕获了？

我的了解应该还是有很多方案，我们的方案是：通过hive hook+kafka来实现，hook是hive的一个插件可以实现很多功能，我们这里用它来捕获DDL事件，并将结果通过kafka传给元数据做解析。

我了解大厂在血缘的解析这块用的就是hook，感兴趣的可以去研究研究。

今天先介绍到这里~

作者：hackmonster，知乎号：hackmonster

原文链接：https://www.zhihu.com/question/19916683/answer/459757696

本文作者 @逆袭的骑士 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！