一种传统数仓中的数据源管理解决方案的构想

最新推荐文章于 2024-02-20 23:03:14 发布

AmazingJadeWu

最新推荐文章于 2024-02-20 23:03:14 发布

阅读量538

点赞数 1

分类专栏：大数据文章标签：数据源管理数据血缘

本文链接：https://blog.csdn.net/u013668852/article/details/96718908

版权

本文探讨了在大数据背景下，企业如何管理和追踪数据源，尤其是在多系统间数据传输的血缘关系。通过分析Datax、Sqoop和Flume的数据导入方式，提出利用元数据获取和Hook功能来实现数据源监控和数据血缘的补充。Apache Atlas的Hook功能为解决此问题提供了思路，Datax和Flume也支持类似的机制，为构建全面的数据源管理系统奠定了基础。

摘要由CSDN通过智能技术生成

数据源管理背景描述

大数据+AI是时代的必然走向，很多企业已经初步或较为完整的建立了数据仓库，数仓能力是数据驱动的必要能力。日渐庞大的数据量，要求企业必须能够有效地管理自己拥有的数据，那围绕这个领域，很多公司或开源组织都有所尝试，典型的如数据血缘，而今天讨论的内容也是这个问题的一个子集。

就一个企业而言，其使用的数据承载平台可能是多样化的。目前很多企业的数仓是以HDFS+Hive的技术栈来实现，并且其数据血缘关系也仅仅在Hive层面打通，这个局域的数据血缘图谱或许已经能够满足其80%以上的需求。但这仍然不够，对于跨系统之间的数据传输的数据血缘是无法得到的，这个问题在很多公司会变得比较棘手，规模越大的公司，这个问题会愈加尖锐，如google或Linkedin。google公司内部采用了很多存储平台，这些存储平台之间的数据集的交换会很频繁，系统之间的数据血缘的隔离，必然会导致数据使用非常的困难，针对这个问题，google通过收集不同系统之间的数据信息来解决这个问题，相关的实现可以参考google的goods论文，linkedin也是在该论文的基础之上做了一些完善。

很多企业规模不是那么大的公司或部门，对多系统之间的数据血缘也不是强依赖的，它可能仅在公技部门提供的数仓平台工具上建立了自己业务线的数仓，就像我们这里现在的情况一样。但不可避免的问题源数据据到数仓的链路的信息是相对比较缺失的，外部数据源的多样化特点决定了数据进入数仓可能会千差万别，给数据源的管理带来了很大的困难，尤其是中间再经过人事变动，会导致之后的源数据会丢失等等，因此我们想将数据源这块给监控起来，并能够将数据源到数仓这个链路的数据血缘弥补起来。

方案构想

这块内容涉猎的不多，仅做一些设想。

首先看下当前外部数据源导入的可能的主流方式：Sqoop，Datax，flume（其他待补充）。
是不是可以把问题等价于如何将这几种数据导入的方式监控起来？如果假设成立，那以什么样的方式来解决？

以前接触过Apache Atlas的，Apache Atlas通过Hook功能来解决不同系统之间数据传输的元数据采集，这给当下要解决的问题带来新思路。不知道是Sqoop给Atlas留的Hook的口子，还是Atlas利用了Sqoop，但这些都不重要，重要的是这种方案是可以重用的，其他的Hadoop生态体系下都有类似的Hook功能，如Storm，Hive，Impala, Hbase等，如果对这些数据导入的渠道有监控的需要，都可以重用，此处先感谢Atlas提供的思路以及其对这项工作的推进。Datax和flume也可以利用类似的方案，经过调研，Datax支持Hook功能，而flume支持Custom Reporting，如果能够将这些不同的数据导入的方式的元数据统一起来，进而做自己想做的事情，如数据源管理（至于管理要做什么事情，要看业务的需求），或绘制数据血缘。