有赞数据仓库元数据系统实践.docxVIP

有赞数据仓库元数据系统实践 公司业务连续快速进展，又多了几个新业务线，有更多部门的用户在使用数据仓库。作为数据仓库的管理者，会遇到更多的问题。数据仓库的管理者期望能便利的看到系统或各个表的形态，数据仓库的用户期望能查到更多表的业务信息。而此时数据仓库还是一个黑盒，双方需求都不能满足，日常沟通、问题验证的成本很高，需要更多元数据的采集和呈现。 参考 Kimball 的数据仓库理论，把元数据分为这三类： 技术元数据，如表结构、文件路径/格式； 业务元数据，如责任人、归属的业务、血缘关系； 过程元数据，如表每天的行数、大小、更新时间。 尽量把这三类数据都自动采集或计算猎取，然后在 web 页面上呈现或对外供应接口。这是当前版本的元数据系统，下面列举我们实现的核心功能。 血缘关系 “表”是元数据系统的后台规律核心，数据仓库是构建在 Hive 之上，而 Hive 的原始数据往往来自于生产系统，也可能会把计算结果导出到外部存储，所以我们认为 Hive 表、mysql 表、hbase 表、BI 报表都是“表”，这些“表”间关系是一个 DAG，也就是血缘关系。 表间的关系全部体现在 SQL 和 ETL 任务里。 SQL：晚期我们把 SQL 提交到 Hive 服务端做 explain，得到 import 和 output。为了支持字段级血缘分析，以及支持 Presto SQL 方言，我们对 Hive 供应的笼统语法树解析代码做了修改。 ETL：我们的 ETL 工具基于开源的 datax，数据源/目标包括了 Hive、mysql、Elasticsearch、HBase、kafka 等，每天收集这些 ETL 任务，并记录好源头和目标即可。 MapReduce/Spark 脚本：有不少这类离线计算，大部分都会用到 Hive 表，但是很难从 python/scala 这样的高级编程言语代码里解析出表名，此处做人工介入，创建或修改任务时，需要记录这个任务读写了哪张表。 血缘关系案例 有了血缘关系，基于开源 jsmind 库做了呈现，可以让用户清楚看到一张表的上下游，更便利地查找表。基于血缘关系可以做很多事情，例如： 结合表的更新时间，还可以找到调度 DAG 的关键路径，帮忙定位功能瓶颈； 当表消灭变更时，可以通知下游责任人，以及自动对下游任务做 SQL 的静态检查； 协助生命周期管理，找到没有被使用的表/字段； 协助维护字段的全都性，如注释、校验规章复用。 Hive 表行数/更新时间 我们记录了每个离线计算任务对应的 Hive 表，当某个任务执行结束，会马上做表行数/更新时间的采集。 文件大小/更新时间：metastore 有记录但是不准。我们完全基于 hdfs，读取文件的属性作为 Hive 表的大小与更新时间。再依据任务的启动时间，就可以得到计算出表所对应任务的执行时长。 行数：格外重要且明智的选择，使用 Presto 对全表或分区做 count 计算，这个 SQL 的执行效率是惊人的。对 orc 文件，简约的 count 计算，Presto 并不会整个文件扫描，而仅仅读取 orc 文件的 index data 部分就可以得到行数。在实际运转中，几亿行的表都可以秒级得到行数。为了采集表的行数，我们下定打算把全部 Hive 表的存储格式改成? orc。 表行数、文件大小、更新时间、运转时长的数据采集一段时间后，就可以构成曲线图，数据仓库管理员和开发者都可以从这个图中发觉规律或数据质量问题，甚至业务系统开发者也会通过这个曲线图来查看业务量变化趋势。外行数采集的功能基础之上，我们还做了数据质量校验、数值分布探查等功能。把多个关键表的产出时间绘制到一张图里，可以清楚的看出数据仓库的稳定情况。 ? live表历史趋势案例 计算资源管理 前面提到离线任务结束，会做表大小/行数采集，同样的道理，也可以到 yarn 上采集相关任务使用的资源情况。假如是 MapReduce 任务，可以采集到完整的CPU、内存、磁盘 IO 使用情况，而 spark 任务则只能采集到 CPU 使用情况。把这些资源使用情况绘制成曲线图，很简约发觉 SQL 的变更或特别情况。也可以把消耗的资源换算成硬件成本，找到最消耗资源的表或业务，督促开发者优化。 计算资源趋势图案例 数据同步规章描述 有赞的业务进展快，同时也意味着业务数据模型变化快，经常会发生业务表增减字段、拆表、迁库等动作，基于元数据的数据同步配置，很大程度避开了由于配置不全都导致的错误。在 mysql 侧，基于表结构的准实时同步，元数据维护了字段-表-库的映射关系，甚至记录了表迁移前后的地址映射关系，依据最新的形态动态生成数据同步配置。在 Hive 侧，记录了表能否分区、分区键、文件格式、hdfs 路径等信息，用于生成读写 Hive