DataHub学习过程遇到的问题

关于DataHub学习中遇到的问题

上篇文章初步搭建起来Datahub，但是仍然还有许多理论上的知识需要去学习。关于后续的操作内容，我会记录在上一篇的安装教程里。关于理论上的东西，大部分就记录在本帖子中好了。

带着问题进行出发学习，本文所有内容都是在阅读官方架构文章后，自己的理解以及简单总结，下面贴上原文链接DataHub：解释流行的元数据架构.

接下来提出我目前遇到的三个问题：
1 : 元数据的摄入方式，手动第一次摄入之后，后续应该如何维持数据的时效性？ 是内部会自动去拉取数据，还是需要手动写定时任务去执行摄入的操作。
2 : 血统分析，如何进行查看上下游，因为正常来说能表现关系的sql语句是在我们的HDFS内部，执行的时候是靠这个里面的内容能发现关系，datahub也最多只有HiveServer2暴露的
端口信息是如何将整体血统关系爬出来并且在UI页面上展示呢？ 还是说只能一个个靠手动去添加
3 : 内部数据是怎么传的，如果要用自己的UI界面的话，那应该如何解决，如果想要添加想要查看的东西应该如何操作

然后是我根据官方架构文档进行的版本迭代理解。

根据官方一代架构描述
一代架构为： 页面APP + 数据库 + ES搜索引擎 + 元数据仓库 HIVE kafka
执行流程为： 使用爬虫程序对元数据进行爬取，这个爬虫程序为单进程，每天执行一次，然后将爬到的数据丢到 数据库+ES库 里方便页面查询搜索。 爬取过程中，会将原始数据转化为元数据模型，该操作是嵌入在爬虫程序摄入数据的操作中。
支持的操作： 除了这些简单的页面流程操作，该架构还支持处理批处理作业，例如Spark大规模处理元数据，计算关系等。 然后同样塞进 数据库+ES中

优点：很少的数据架构，一个数据库 + ES + 爬虫程序。
缺点：1.爬取数据，爬数据需要在一个通道上进行爬取，简单来说就是元数据提供的外部访问接口。但是接口的稳定性是个不确定因素。
    a.比如说在生产环境机器紧张的情况下，爬取的情况就得看机器的压力如何，假如压力大的情况下，你的爬虫程序应该停止，而不是继续给生产提供的端口增加压力。
    b.然后就是安全验证问题，生产机器并不一定会让你使用爬虫来获取验证，比如防火墙，比如安全验证，或者密码校验，这个密码也是经常更改。
    c.每次爬取都是全量数据，而不是增量数据，数据量大的情况下，每天爬取全量，会让运维人员很不爽，因为不管什么时间去爬都注定他会耗费大量时间和端口性能
这在生产环境是不被允许的
    d.数据新鲜度，爬虫程序压力大导致程序暂停引发另外一个问题，数据的新鲜度，比如你凌晨爬取前一天的数据，是没什么问题，而当天的增量数据想要管理只能等待第二天进行查看管理。 貌似数据是没有问题，但是你当天出的数据不能管理，这本身就不够合理。 理想的效果应该是，首次爬取，后面可以动态获取，然后只更新增量。

二代架构描述
二代架构为：页面APP + 数据库 + ES搜索引擎 + 元数据仓库 HIVE kafka + API Server
执行流程为：二代架构将页面APP拆分，拆为元数据存储服务之前的服务，即之前从DB里拿数据改为从服务接口API获取数据，该接口也可以接收元数据仓库HIVE Kafka之类推过来的数据，然后入DB以及ES.流程与一代类似，只不过通过加入了一个API服务接口然后改变了之前程序直接从DB库里拿模型数据的方式。而是由API接口返回。

优点：可以解决团队合作的问题，推拉模式可以让你和你的团队更好的进行合作，比如由之前的暴力爬取，改由他们推送到API接口即可，也可以通过指定字段来设置你的数据集的标签
缺点：a.没有更改日志，第二代架构提供了一个基于微服务的 API 来读写元数据，但没有内置支持从外部系统流式传输对元数据的更改或订阅元数据更改流发生在数据目录中。
   [用人话来说就是，元数据更改获取不到，比如你HIVE的表加字段啊，或者什么的，二代的API他搞不到，也没法记录下来，也没法展示，我猜测是API接口人家制定的规范应该就没有考虑还将表什么的变化之类的东西传递进来，API 他也最多负责数据进来，数据出去，而且还是已经建好的模型数据之类的吧]，
  反正人家文档里说了，作为一流的产品，现代数据目录应该能够能够实时订阅元数据的变化。 可以这么理解，这个表什么时候增加了什么字段，之前啥样之后啥样要记录下来。
  这样的话方便以后定位问题。同事官方还说了，没有这种元数据日志，也无法后续扩展反应式系统，例如数据触发器或访问控制滥用检测系统。
  具体他说的日志，可以看这篇文章，注意，他说的日志和什么程序日志不一样，不是程序运行的日志，而是元数据的数据日志。详细日志说明情况可以查看这边文章日志的解释
  这个架构太依赖一个中心化团队，拥有元数据模型、运行中心元数据服务以及数据存储和索引，以及支持所有下游消费者以及他们想要访问元数据的不同方式。这严重限制了中央系统为公司中存在的用例（生产力、治理、AI 可解释性等）提供支持的能力。[去中心化是现代技术架构的一个很大的趋势]

三代架构
背景： 三代技术机构关键形成的原因是，基于中央服务的元数据系统很难跟上企业对元数据用例的需求(没有去中心化以及实时观察到数据的日志信息)
  三代架构需要解决的就是，元数据本身是自由流动，基于事件，基于可订阅的。第二个就是去中心化
第 1 步：面向日志的元数据架构
元数据提供者可以推送到基于流的 API 或针对目录的服务 API执行CRUD操作，具体取决于他们的偏好。对元数据的由此产生的更改将反过来生成元数据更改日志。对于所有需要的查询模式，该元数据日志可以自动且确定性地具体化为适当的存储和索引（例如，搜索索引、图形索引、数据湖、olap 存储）。这产生了一个为现代企业做好准备的非捆绑元数据数据库架构，如下图所示。现在日志是元数据领域的中心，如果出现任何不一致，您可以随意引导图形索引或搜索索引，并确定性地修复错误。
说人话就是：这回架构的数据源来自数据日志。然后通过日志还可以去创建存储和索引，如果数据不一致可以根据图形索引或者搜索索引去进行修复。

	三代技术架构不说人话的太多了，机器翻译也不太看的懂，反正看明白他解决了什么问题也能继续往下进行。

总结：三代架构是可以实现数据日志动态变化的订阅以及发布，数据摄入过一遍之后即可从页面进行管理。
  血缘上下游 ： 目前根据我的推测，如果可以动态数据的变化日志，那么是可以推出上下游关系的，比如说 B 表，数据来源为 A 表，当数据进行插入时。三代架构是可以根据这个关系分析出上游为 A ， 下游为 B， 然后再来一张C表， C表数据源为B表，那么同理可以得出B表的下游为 C表。这样可以动态将数据血缘变化再页面上快速的进行查看。

然而实际的情况是，我的datahub在启动的情况下，并不能获取到我动态添加的增量的表，无法看到上下游信息。目前我搭起来的情况像是一代架构。

还有涉及到一些模型的创建，以及对模型的操作。目前依旧没有头绪。开头提到的三个问题，第一个问题在架构层面知道是可以动态获取的，但是实际操作中我并没有获取到，不知道是我搭的有问题还是哪里有问题。后面两个问题，暂时没有解决。后学的学习中如果能够解决的话我会记录下来