血缘分析是分析元数据的上游数据信息，用于追溯元数据的来源和加工过程。
在【元数据】-【元数据管理】-【元数据分析】模块，选择【血缘分析】进入，选中居民生活分析主题下的水费表，然后点击血缘分析。
得到血缘分析结果如下：
点击各节点中的倒三角可将元数据展开到更细粒度的级别展示。
由血缘分析结果，我们可以看到：水费表关联的是数据仓库中的街道用水用电信息表表，数据仓库中的街道电费表、街道水费表又和业务库中居民生活信息表、街道企业信息表存在间接关联关系。通过血缘分析，水费表的数据来源和加工过程一目了然。
点击【保存】可将分析结果保存到我的分析。
对于保存的结果，我们可以在【元数据】-【元数据管理】-【元数据分析】-【我的分析】里进行查看、重命名和删除等操作。
1. 原理
血缘分析图中，元数据节点展开后显示的元数据是由元数据的组合关系决定。比如，居民生活分析主题展开后显示了用水用电报表分析，则说明居民生活分析主题这个元数据的组合中一定有用水用电报表分析。
元数据节点之间的连线则是根据元数据的依赖关系生成。元数据采集时会自动生成依赖关系，也可以手动维护依赖关联。比如，数据仓库中的街道用水用电信息表指向了政务数据分析中的水费表，也就是说水费表主题表依赖于街道用水用电信息表，那么在水费表这个元数据的依赖中一定有街道用水用电信息表。
2. 元数据解析优化
1、ktr脚本中sql片段解析出来的字段级依赖，需要区分依赖类型。
ktr脚本端KTR挂载点(KTRPos)下的KTR字段(KTRField) -> KTR字段(KTRField) 的连线，和库表端目录(Catalog)下的字段(Column) -> 字段(Column) 的连线，均区分直接依赖、间接依赖。
例如下方sql，case when 后的字段col1和字段c1之间是间接依赖，then 后的字段col2、col3和字段c1之间是直接依赖。
insert into table1 select case when t2.col1='abcd' then t2.col2 when t2.col1='efg' then t2.col3 end as c1 from table2 t2 |
table2的col1、col2、col3字段，会影响table1的c1字段。
2、临时表 temp.col1 依赖于 物理表1.col1，物理表2.col2 依赖于 temp.col1，那么就需要在 物理表1.col1 和 物理表2.col2 之间形成依赖关系。
至于物理表字段之间是直接依赖还是间接依赖，需要根据实际场景进行区分。
例如：物理表1.col1 ---> temp1.col1 ----> temp2.col2 ----> temp3.col3 ----> 物理表2.col2，只有当 物理表1.col1 ---> temp1.col1 和 temp3.col3 ---> 物理表2.col2 均为直接依赖时，物理表1.col1 和 物理表2.col2 之间才是直接依赖，否则为间接依赖。
insert into table2 select col3 from temp3;
insert into temp3 select col2 from temp2;
insert into temp2 select col1 from temp1;
insert into temp1 select col1 from table1; |
具体来说，当完整链路是：物理表1.col1 ---> temp1.col1 ----> temp2.col2 ----> temp3.col3 ----> 物理表2.col2 。
情况1 物理表1.col1->temp1.col1是直接，temp3.col3->物理表2.col2也是直接，那不管中间的临时过程是直接还是间接，物理表1.col1->物理表2.col2都是直接。
情况2 物理表1.col1->temp1.col1是间接，或者temp3.col3->物理表2.col2是间接，那不管中间的临时过程是直接还是间接，物理表1.col1->物理表2.col2都是间接。
3、ktr脚本中sql片段解析出来的表级依赖，需要区分依赖类型。
ktr脚本端KTR挂载点(KTRPos)下的KTR表(KTRTable) -> KTR表(KTRTable) 的连线，和库表端目录(Catalog)下的表(Table) -> 表(Table) 的连线，均区分直接依赖、间接依赖。
如果两张表下的字段之间存在直接依赖，则两张表间为直接依赖，否则为间接依赖。
例如下方sql，table2的col1字段与table1的c1字段是间接依赖，table2的col2字段和col3字段与table1的c1字段是直接依赖，table1和table2的字段间存在直接依赖，所以table1和table2间是直接依赖。
insert into table1 select case when t2.col1='abcd' then t2.col2 when t2.col1='efg' then t2.col3 end as c1 from table2 t2 |
4、采集解析ABI5.2.4的ETL模块，sql输入组件、sql组件中的sql片段(含case when)解析出来的字段级依赖、表级依赖。
移除sql输入组件下的sql输入表，只保留sql输入字段，sql字段仍然指的是最外层字段。但源表与sql输入组件、源表字段与sql输入字段间的依赖从sql内容中解析得到。
例如下方sql，sql输入字段对应的是end后的c1字段和as后的c2字段。依赖关系从sql内容中解析，即依赖关系为table1.col1 ---> sql输入字段c1（间接依赖）、table2.col2 ---> sql输入字段c2（直接依赖）。
select case when t1.col1='1' then 'abc' when t1.col1='2' then 'edf' end as c1, t2.col2 as c2 from table1 t1 left join table2 t2 on t1.col1=t2.col1 |
3. 元数据解析数据工厂组件优化
SQL组件表、SQL组件字段 这两种元模型，只有在SQL组件的SQL语句是update/delete（即不会生成库表与库表，字段与字段间的依赖关系）等语句时生效，解析SQL中涉及到的表与字段，生成SQL组件表、SQL组件字段元数据，并与对应的实际库表、实际字段建立依赖关系
SQL组件表与SQL组件字段形成上下级关系。
示例1：
SQL组件xx1的SQL如下：
INSERT INTO tb1 (id, name) SELECT id, name FROM tb2 |
生成
元数据：
SQL组件xx1
依赖：
tb1 依赖 tb2
tb1.id 依赖 tb2.id
tb1.name 依赖 tb2.name
示例2：
SQL组件xx2的SQL如下：
UPDATE TB1 SET NAME=xxx where ID=xxx |
生成
元数据：
SQL组件xx2
SQL组件表TB1
SQL组件字段NAME
SQL组件字段ID
依赖：
SQL组件表TB1 依赖 库表TB1
SQL组件字段NAME 依赖 库表字段TB1.NAME
SQL组件字段ID 依赖 库表字段TB1.ID
请先登录