一、背景：

        用户经常会针对数据存在质量的存疑，反馈数据不准。开发人员排查数据质量问题步骤：首先和业务人员对接了解是哪里数据不准确，要定位是哪张报表，然后查看报表后面数据来源，然后一路排查数仓。往往定位到数据问题耗时比较高，开发断层导致找到相关任务比较难。

二、解决办法：

        通过血缘解析，把报表数据来源去向的信息都提取出来，方便：开发人员迅速找到相关任务。

三、解决思路：

        Kettle的转换和作业存储底层是通过xml实现。作业是由转换组成，转换由组件组成。可以通过解析xml找到来源表和去向表。帆软Finereport的报表cpt和 frm底层存储也是xml，可以解析xml获取数据集，解析sql获取到表和字段。最终得到报表名，报表路径，数据库表，数据集。

tips:还可以进一步解析作业调度（主流调度工具：crontab，airflow,azkanban,ooize）可以解析出作业调度信息。

四、具体实现：

  4.1.Kettle血缘：

        首先要找到输入输出组件，一般输入组件包含如图 4-1所示，输出如图 4-2所示(实际转换中还可能使用追加流或者SQL脚本，这里只说常见的) 。一般Kettle转换(输入输出组件不同找到来源和目标方式不同)如图 4-3 所示。我们以文本编辑器打开转换文件Ktr,会以图 4-4 所示 。 如果内容比较乱，可以找一个xml解析工具格式化一下。可以清晰的看到转换是存在<step>节点里，如图 4-5所示。根据里面的<type>找到输入和输出组件。然后输入如果是表输入，通过sql查询的，用sql parser解析获取到表和字段信息。数据连接是存在<connection>节点里(这里如果数据以JNDI的方式存储的需要解析JNDI文件获取到数据配置信息)，如图 4-6所示，可以获取到数据库信息。组件连接信息是在<order>节点里面(这里比较复杂是要考虑数据分发和数据复制)。这样一个完整的转换解析就完成。作业同理。一般作业和转换是发布在服务器上，需要遍历服务器目录下所有的以ktr和kjb结尾文件。

图 4-1

图 4-2

图 4-3

图 4-4

        

图 4-5

图 4-6

4.2 FIneReport血缘：

        FineReport报表存储文件是以cpt和frm结尾，以文本编辑器打开，如图 4-7所示。可以找到数据集是存在<TableData>节点下，可以拿到查询的sql，然后用sql parser解析获取到表和字段，在<DatabaseName>里面可以拿到数据连接名，这里可以在帆软内置库中找到数据连接名的具体链接信息，用于打通和Kettle之间的联系。

图4-7

图 4-8

4.3 调度解析：

        调度工具比较多，这里讲一下Crontab和Airflow。Crontab一般会可以通过crontab -l 命令获取调度的信息。解析信息可以拿到作业的计划调度时间(更深一层可以考虑获取作业执行日志拿到实际调度时间。然后针对调度进行运营管理)。Airflow由内置数据库，可以获取到作业和调度信息，然后去找到作业文件找到具体的作业(这里不过多介绍Airflow，只讲一下思路)。

五、实现效果：

        以上所有数据和获取到进行加工处理。最终展示如表 4-1所示：

表 4-1

来源层	来源表	来源字段	目标层	目标表	目标字段	作业名	计划调度	实际调度
SAP	KNAL	fleld1	ODS	ods_sap_knal	fleld2	job1	* * * * 8	* * * * 8
ODS	ods_sap_knal	fleld2	DWD	dwd_custom_detd	fleld3	job2	* * * * 10	* * * * 10
DWD	dwd_custom_detd	fleld3	DWS	dws_custom_detd	fleld4	job3	* * * * 11	* * * * 11
DWS	dws_custom_detd	fleld4	FR	custom.cpt	fleld5		* * * * 12	* * * * 12

以上列表只是参考，实际有很多复杂情况。

关于上表每行解释：

1. 来源层，这个数据一般是系统名和数仓名。这里数仓名一般是通过解析表明获取到。可以参考数仓规范(一般数仓运营会将弄作业监控命名规范)。
2. 来源表，这个是上面解析sql或者转换解析获取到(在输出规范一般要要求表名规范)
3. 来源字段，同上(实际数仓运营会拿到字段里数据长度和字段类型以及长度进行管理)
4. 目标层，同来源层
5. 目标表，同来源表
6. 目标组队那，同来源字段
7. 计划调度时间，这里要考虑作业会存在多个调度频率，一般会存多行，在实际展示会根据crontab解析给出未来十个调度时间(如每天八点更新，这里就会给出后面十天八点的时间)
8. 实际调度时间，这里获取方式比较多，一种通过日志解析，还有可以在作业执行的时候将时间写入到数据库，但是这种作业失败就拿不到数据，所以通常会解析日常，还可以监控作业执行情况。(一般有能力的会由作业监控平台)

图形展示(os：自己用的d3.js做出来效果不如这个所以不放实际效果图了)如下，鼠标移动到线条可以看到作业名和调度时间。

五、扩展：

        这里讲的是传统数仓，传统数仓一般没有血缘，所以数据发生质量问题排查比较耗时。现在数据中台基本由数据血缘功能，大部分基于Atlas。但是如果存在临时表，就会存在血缘中断。还有是通过解析sql,但是这种缺点是要找到所有任务。这两个都无法获取到所有的数据血缘，所以有的产品会有血缘录入的功能进行补充。

        上面只讲了帆软FineReport，帆软还有FineBI，在FineBI里是有血缘的，如果要做整体的管理，可以考虑将FineBI的数据获取到和所有的血缘进行融合。

以上只是个人在工作中针对传统数仓的数据治理的一些实践。其实还有很多ETL工具如DataStage、Informatica、Airflow、Datax等等之类的，可以根据以上逻辑进行血缘解析。