赞
踩
最近公司有数据治理方面的需求,业务运营过程中发现很多的数据用了不同的数据源导致最终的指标结果出现很多的偏差,由于大部分指标都是通过hive、clickhouse、starrock等类sql引擎计算得到,所以开发了一款将sql文件转换成前端图形化做数据溯源的工具,将代码开源到并记录了整个开发过程如下:
血缘关系指的是表、字段之间的依赖关系,想要获取表和字段的依赖关系,就要回答那极哲学问题,表和字段从哪里来,到哪里去。
1、日志表,这种主要是客户端手动埋点或者做埋点sdk,埋点上传服务器,服务器再转发到集群。2、业务表,这种主要是业务活动中产生业务过程数据,主要通过添加数据库到集群的同步任务,T+1同步到集群。
我们梳理了两条路线:
线路一:埋点-》指标
线路二:业务库-》指标
只需要把两条数据链路每个环节的来源和目标以及来源到目标的过程梳理完成也就形成了数据血缘关系。
(1)埋点-》数据进去数仓-》形成指标
(2)业务库-》数据进去数仓-》形成指标
会发现其实两条链路中只是从数据产生到数据进数据仓库这部分不一样,从进入数仓到形成指标这部分是一致的。
(1)埋点-》数据进入数仓
(2)业务库-》数据进入数仓
(3)数据进入数仓-》形成指标
这部分主要血缘关系的梳理主要是梳理埋点和数仓的贴源层关系,分析埋点和数仓贴源层的关系,需要我们做数据埋点的时候形成埋点文档,确认每个埋点对应的数据接入任务以及每个埋点对应数据仓库对应贴源层的表,每一次的埋点方案需要对应的归档管理,或者有对应的埋点管理系统。输出埋点方案包含对应的埋点的上传策略、埋点的传输数据格式、数仓接入数据任务、最终落到数仓表的位置。通过这些内容我们可以知道埋点和数仓贴源层的对应关系。
这部分主要是确认每个数据同步任务的源和目标
这部分是数仓的建设部分,从数仓的贴源层到最终的数据指标模型,指标加工部分,我们一般使用sql的方式来实现, 就需要我们分析模型构建的sql,分析每一条sql的源表和插入表。
合并这三部分我们会最终得到一个完成的数据血缘关系。
具体实现细节可以参考:https://blog.csdn.net/weixin_43130481/article/details/136803590
sql分析工具:http://www.sqlxy.com.cn/
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。