聊聊数据中台：元数据建设有哪些坑（二）31
编辑导读：在进行数据地图的工作中，需要注意两个核心功能，即元数据信息的展示和血缘关系。本文将围绕这两个点展开分析，希望对你有帮助。
上期讲到数据地图，这一期重点来讲，开始之前说点别的，类似元数据、ETL 平台类的产品、非常考验开发的技术水平。 这里有个问题，作为产品需不需要参与每个技术方案的评审？这里我建议在时间允许的情况下尽量都参与下，很多时候开发给的技术方案都是为了实现而实现，而需求从来都不是一层不变的，在定一个技术方案的时候也要考虑万一我的需求或者场景变了的情况下，是否都能够满足？ 而且技术方案变化也是很正常的事情，除非你们有 CTO 专门帮你们订好方案和评审。这里我建议产品尽量参与下，很多问题都可以在初期就可以避免。 数据地图最核心的功能有两个：元数据信息的展示、血缘关系。 元数据信息的展示上期已经讲过了，根据采集的信息 + 元模型进行展示，这里需要考虑的问题就是要尽量全，要对展示的信息进行一个分类，不然会很乱。 我这里分了几种：技术信息、业务信息、权限信息。这里我只说下权限信息，用户在查询元数据的时候我们要给出权限的信息，读、写还是无权限等，同时还要提供数据预览的功能，当用户无法通过技术属性和业务属性直观的了解数据时，还是可以通过查看数据内容去理解数据（建议限制 20 条）。 关于血缘关系需求： 血缘是元数据最核心的功能了，关于如何提血缘的需求产品要多听听用户和技术的声音，血缘存在一个覆盖率的问题，是 100% 还是 90% 以上即可？ 用户都希望可以实现 100%，但现实是打脸的，每个公司的场景都不一样很难有公司说我们 cover 你们公司所有场景，可以保证血缘 100% 解析。如果真有要么这个公司技术水平非常高，要么是忽悠你。 SQL 作为一门语言它可以有成千、上万中写法，还可能会引用各种函数、这里还存在书写不规 范的情况谁敢保证能够 100% 覆盖？ PS：我这里说的血缘是指要到字段级的。 关于血缘需求的第一个建议： 实现不了的，列出来，订好规范尽量避免这种写法出现，比如银行会有类似 10 大铁律，发现即惩罚，来避免出现解析不了的情况。 能实现的要 100% 覆盖，出现就是 bug。 长期、大量测试要有，覆盖主要业务场景。 关于血缘需求的第二个建议： 按照行业 TPC-DS 的评测标准，100% 覆盖。 超出的按照新需求迭代开发，不算 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、AmazonNeptune、JanusGraph、ArangoDB，是市场上最为知名的五大图数据库品牌，我们用的是 Neo4j。 科普性的我尽量少讲，让大家更关注元数据本身，感兴趣的看下这个连接： https://www.zhihu.com/question/19916683 开源 NoSQL世界上最先进的图数据库之一，提供原生的图数据存储，检索和处理； 采用属性图模型（Property graph model），极大的完善和丰富图数据模型； 专属查询语言 Cypher，直观，高效。 跟 ETL 如何对接？如何确保 SQL100% 覆盖？ 我总结产品问题：凡是跟其他系统对接的都是坑。 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，感兴趣的可以去研究研究。 转载：http://www.myzaker.com/article/5f0d17128e9f0974f32cc682/ |
