数据系统架构-2.元数据管理

叶之城

已于 2022-09-30 19:44:51 修改

阅读量712

点赞数 1

分类专栏：数据系统文章标签：系统架构大数据 hadoop

于 2022-09-30 18:51:54 首次发布

本文链接：https://blog.csdn.net/lovelysweeter/article/details/127127867

版权

数据系统专栏收录该内容

11 篇文章 2 订阅

订阅专栏

2.元数据管理篇

目标

通过收集与整合各个系统信息，打造数据全链路血缘关系。

序

场景1：报表A的数据和报表B的数据不一致，能帮忙看下是什么问题吗？
场景2：我改动一个hive表，下游任务是否会有影响？
场景3：原始日志打印字段结构变化了，我该通知哪些人？

上述的场景大致上，就是在全链路中从源头找下游，或者是从下游找数据源头的问题。大多数情况下，我们在一个系统中是能在一定程度上找到对应的数据依赖等关系的，但是跨系统、跨模块之后很多时候除了对应的开发人员并不知道具体的信息了，比如一个报表对应的统计任务是哪个？口径是什么？一般只有对应开发人员清楚，在排查口径问题的时候需要找到对应开发人员，才能找到对应的信息。那么我们就需要这么一个元信息管理系统，告诉每个人数据全链路的血缘关系，并且包含各种相关信息，减少沟通成本、提升数据问题排查与处理的效率。

接下来大致介绍一下，各个模块我们需要收集哪些信息，这些信息如何串联起来形成一个有机的整体，解决“数据迷雾”的问题。

元数据链路

在这里插入图片描述

(图-整体架构详见第一篇数据之旅-开篇)
我们对照着大数据技术架构图，一步一步看看各个部分数据如何一步一步串联到一起。大致上就是在收集与整理，每个模块的输入与输出、内容是什么等相关信息。

最大可能通过各种系统管理获取各种信息，最差的情况在各个系统维护页面采用手动录入。

整体链路：【基础数据】<->【数据存储-数据仓库】<->【任务调度关系】<->【结果数据存储】<->【数据应用】

1.【基础数据】<->【数据存储】
在这里插入图片描述

输入与输出：这2个模块之间的关系，维护来自【日志采集系统】，如上篇文章中的设计，我们可以从该系统的得知每一份前后端日志、源表被采集至哪个kafka中，保存至哪个HDFS目录里。

内容：并且在【日志采集系统】中，在申请的采集的时候，需要记录采集日志的内容，前端日志收集包含哪些pagetype与actiontype、后端日志收集action。就算当时没有准确记录，在后续的【日志抽象-指标定义系统】由于需要做统计开发，那需要反推数据维护，要不无法定义数据指标口径。

2.【数据存储-数据仓库】

离线的数据分为2种，结构数据和非结构化数据。

结构化的数据，如前端日志在上传至HDFS之后可以直接映射成前端日志表；
非结构化的数据需要通过【配置化ETL】先经过一次ETL形成最基础的后端日志表。
这2张前后端基础日志表和源表，就形成了数据仓库的基础，是之后数仓各个层次表的根基数据。

3.【数据存储-数据仓库】<->【任务调度关系】

离线数据仓库与任务的关系，可以通过2种方式收集，表述了Hive-Hive表的关系。

自动化：通过解析hiveSQL的语句中的输入与输出，收集到各个表之间的输入与输出关系；
任务配置手动记录：在调度系统中配置任务信息的时候，记录对应的输入与输出表信息。
通过调度系统，我们可以得知2个依赖，【任务依赖链路】与【表关系链路】，为之后通过【日志抽象-指标定义系统】定义指标打通表与指标打下数据基础。

实时任务

个性化开发：只能通过任务配置手动维护消费的topic信息，以及后续的输入信息；
实时统计系统数据：在配置统计规则的时候，即可以知道对应任务使用了那个topic信息。

4.【任务调度关系】<->【结果数据存储】

这一部分数据其实是整个链路中缺失最严重的部分，导致从数据下游找数据来源十分麻烦，我们知道一个数据来自某个表，这个表的数据来自哪个任务却不清楚，目前采用了在调度任务的名称上加上输出的方式，十分的不优雅和高效。

我想这部分最好是在调度系统里进行充分的集成，比如抽取任务、hive写入mysql表、hive写入redis、hbase等等，尽可能的把所有数据输出可以通过配置来实现数据的写入，解决结果数据输出到哪里的问题。

**5.【结果数据存储】<->【数据应用】 **

在这里插入图片描述

数据集BI：这个数据展示系统，可以通过SQL来定义数据集来实现数据的展示，系统级别上由于存在配置信息，所以可以明确的知道每个数据集中的表数据被应用展示到了哪里；
烟囱式个性化报表：这个没有太好的办法，只能通过特定的功能来补录应用信息，对应的功能应该支持各类应用数据来源信息的配置，达到数据链路一个补充的功能。