关于大数据:数据系统架构2元数据管理

7次阅读

共计 1940 个字符，预计需要花费 5 分钟才能阅读完成。

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

场景 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 来定义数据集来实现数据的展现，零碎级别上因为存在配置信息，所以能够明确的晓得每个数据集中的表数据被利用展现到了哪里；
烟囱式个性化报表：这个没有太好的方法，只能通过特定的性能来补录利用信息，对应的性能应该反对各类利用数据起源信息的配置，达到数据链路一个补充的性能。

至此，大抵通过以上的信息收集与全链路数据关系的买通，咱们大抵能够解决最开始所形容的那些问题。