义乌网站设计网站服务器是什么意思
一、背景：
用户经常会针对数据存在质量的存疑，反馈数据不准。开发人员排查数据质量问题步骤：首先和业务人员对接了解是哪里数据不准确，要定位是哪张报表，然后查看报表后面数据来源，然后一路排查数仓。往往定位到数据问题耗时比较高，开发断层导致找到相关任务比较难。
二、解决办法：
通过血缘解析，把报表数据来源去向的信息都提取出来，方便：开发人员迅速找到相关任务。
三、解决思路：
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 |
以上列表只是参考，实际有很多复杂情况。
关于上表每行解释：
- 来源层，这个数据一般是系统名和数仓名。这里数仓名一般是通过解析表明获取到。可以参考数仓规范(一般数仓运营会将弄作业监控命名规范)。
- 来源表，这个是上面解析sql或者转换解析获取到(在输出规范一般要要求表名规范)
- 来源字段，同上(实际数仓运营会拿到字段里数据长度和字段类型以及长度进行管理)
- 目标层，同来源层
- 目标表，同来源表
- 目标组队那，同来源字段
- 计划调度时间，这里要考虑作业会存在多个调度频率，一般会存多行，在实际展示会根据crontab解析给出未来十个调度时间(如每天八点更新，这里就会给出后面十天八点的时间)
- 实际调度时间，这里获取方式比较多，一种通过日志解析，还有可以在作业执行的时候将时间写入到数据库，但是这种作业失败就拿不到数据，所以通常会解析日常，还可以监控作业执行情况。(一般有能力的会由作业监控平台)
图形展示(os：自己用的d3.js做出来效果不如这个所以不放实际效果图了)如下，鼠标移动到线条可以看到作业名和调度时间。
五、扩展：
这里讲的是传统数仓，传统数仓一般没有血缘，所以数据发生质量问题排查比较耗时。现在数据中台基本由数据血缘功能，大部分基于Atlas。但是如果存在临时表，就会存在血缘中断。还有是通过解析sql,但是这种缺点是要找到所有任务。这两个都无法获取到所有的数据血缘，所以有的产品会有血缘录入的功能进行补充。
上面只讲了帆软FineReport，帆软还有FineBI，在FineBI里是有血缘的，如果要做整体的管理，可以考虑将FineBI的数据获取到和所有的血缘进行融合。
以上只是个人在工作中针对传统数仓的数据治理的一些实践。其实还有很多ETL工具如DataStage、Informatica、Airflow、Datax等等之类的，可以根据以上逻辑进行血缘解析。