Vol . 22
数说
数据血缘构建及应用
2023第8期
总第22期
数据血缘专题
北京市朝阳区朝外大街甲6号万通中心D座25层 数据部
风向
一线
热点
什么是数据血缘，如何做好数据血缘分析？
字节跳动数据血缘技术实现与具体用例
数据治理：数据血缘关系
目录/contents
一、前言
数据血缘是元数据管理、数据治理、数据质量的重要一环，追踪数据的来源、处理、出处，对数据价值评估提供依据，描述源数据流程、表、报表、即席查询之间的流向关系，表与表的依赖关系、表与离线ETL任务，调度平台，计算引擎之间的依赖关系。数据仓库是构建在Hive之上，而Hive的原始数据往往来自于生产DB，也会把计算结果导出到外部存储，异构数据源的表之间是有血缘关系的。
数据血缘用途：
- 追踪数据溯源：当数据发生异常，帮助追踪到异常发生的原因；影响面分析，追踪数据的来源，追踪数据处理过程。
- 评估数据价值：从数据受众、更新量级、更新频次等几个方面给数据价值的评估提供依据。
- 生命周期：直观地得到数据整个生命周期，为数据治理提供依据。
- 安全管控：对源头打上敏感等级标签后，传递敏感等级标签到下游。
本文介绍携程数据血缘如何构建及应用场景。第一版T+1构建Hive引擎的表级别的血缘关系，第二版近实时构建Hive，Spark，Presto多个查询引擎和DataX传输工具的字段级别血缘关系。
二、构建血缘的方案
2.1 收集方式
方案一：只收集SQL，事后分析。
当SQL执行结束，收集SQL到DB或者Kafka。
- 优点：当计算引擎和工具不多的时候，语法相对兼容的时候，用Hive自带的LineageLogger重新解析SQL可以获得表和字段级别的关系。
- 缺点：重放SQL的时候可能元数据发生改变，比如临时表可能被Drop，没有临时自定义函数UDF，或者SQL解析失败。
数据血缘构建及应用
转自数据仓库与Python公众号 作者cxzl25
原文链接：
https://mp.weixin.qq.com/s/cz9I09ouo-h4Qj2WAlOkEg
方案二：运行时分析SQL并收集。
当SQL执行结束后立即分析Lineage，异步发送到Kafka。
- 优点：运行时的状态和信息是最准确的，不会有SQL解析语法错误。
- 缺点：需要针对各个引擎和工具开发解析模块，解析速度需要足够快。
2.2 开源方案
Apache Atlas
Apache Atlas是Hadoop社区为解决Hadoop生态系统的元数据治理问题而产生的开源项目，它为Hadoop集群提供了包括数据分类、集中策略引擎、数据血缘、安全和生命周期管理在内的元数据治理核心能力。官方插件支持HBase、Hive、Sqoop、Storm、Storm、Kafka、Falcon组件。
Hook在运行时采集血缘数据，发送到Kafka。Atlas消费Kafka数据，将关系写到图数据库JanusGraph，并提供REST API。
其中Hive Hook支持表和列级别血缘，Spark需要使用GitHub的hortonworks-spark/spark-atlas-connector，不支持列级别，Presto则不支持。
Linkedin DataHub
WhereHows项目已于2018年重新被LinkedIn公司设计为DataHub项目。它从不同的源系统中采集元数据，并进行标准化和建模，从而作为元数据仓库完成血缘分析。
社区提供了一个Demo，演示地址：
https://demo.datahubproject.io/
与Airflow集成较好，支持数据集级别血缘，字段级别在2021Q3的Roadmap。
驱动力
数说
三、携程方案
携程采用了方案二，运行时分析SQL并收集分析结果到Kafka。由于开源方案在现阶段不满足需求，则自行开发。
由于当时缺少血缘关系，对数据治理难度较大，表级别的血缘解析难度较低，表的数量远小于字段的数量，早期先快速实现了表级别版本。
在16-17年实现和上线了第一个版本，收集常用的工具和引擎的表级别的血缘关系，T+1构建关系。
在19年迭代了第二个版本，支持解析Hive，Spark，Presto多个查询引擎和DataX传输工具的字段级别血缘关系，近实时构建关系。
四、第一个版本-表级别血缘关系
4.1 处理流程
针对Hive引擎开发了一个Hook，实现ExecuteWithHookContext接口，从HookContext可以获得执行计划，输入表，输出表等丰富信息，异步发送到Kafka，部署的时候在hive.exec.post.hooks添加插件即可。
在17年引入Spark2后，大部分Hive作业迁移到Spark引擎上，这时候针对Spark SQL CLI快速开发一个类似Hive Hook机制，收集表级别的血缘关系。
传输工具DataX作为一个异构数据源同步的工具，单独对其开发了收集插件。
在经过解析处理后，将数据写到图数据库Neo4j，提供元数据系统展示和REST API服务，落地成Hive关系表，供用户查询和治理使用。
4.3 痛点
- 随着计算引擎的增加，业务的增长，表级别的血缘关系已经不满足需求。
- 覆盖面不足，缺少Spark ThriftServer , Presto引擎，缺少即席查询平台，报表平台等。
- 关系不够实时，期望写入表后可以快速查询到关系，用户可以直观查看输入和输出，数据质量系统，调度系统可以根据任务ID查询到输出表，对表执行质量校验任务。
- 图数据库Neo4j社区版为单机版本，存储数量有限，稳定性欠佳，当时使用的版本较低，对边不能使用索引(3.5支持)，这使得想从关系搜索到关联的上下游较为麻烦。
驱动力
数说
五、第二版本-字段级别血缘关系
之前实现的第一个版本，对于细粒度的治理和追踪还不够，不仅缺少对字段级别的血缘关系，也不支持采集各个系统的埋点信息和自定义扩展属性，难以追踪完整链路来源，并且关系是T+1，不够实时。
针对各个计算引擎和传输工具DataX开发不同的解析插件，将解析好的血缘数据发送到Kafka，实时消费Kafka，把关系数据写到分布式图数据JanusGraph。
4.2 效果
在元数据系统上，可以查看一张表多层级的上下游血缘关系，在关系边上会有任务ID等一些属性。
5.1 传输工具DataX
阿里开源的Druid是一个 JDBC 组件库，包含数据库连接池、SQL Parser 等组件。通过重写MySqlASTVisitor、SQLServerASTVisitor来解析MySQL / SQLServer的查询SQL，获得列级别的关系。
5.2 计算引擎
计算引擎统一格式，收集输入表、输出表，输入字段、输出字段，流转的表达式等一些信息。
Hive
参考 org.apache.hadoop.hive.ql.hooks.LineageLogger 实现，异步发送血缘数据到 Kafka。
Atlas的HiveHook也是实现ExecuteWithHookContext接口，从HookContext获得LineageInfo，也可以参考HIVE-19288 引入的org.apache.hadoop.hive.ql.hooks.HiveProtoLoggingHook，采集更多引擎相关的信息。
其中遇到几个问题：
- 通过HiveServer2执行获取的start time不正确
HIVE-10957 QueryPlan's start time is incorrect in certain cases
- 获取执行计划空指针，导致收集失败
SparkHIVE-12709 further improve user level explain获取执行计划有可能出现卡住，可以加个调用超时。
前置条件：引入 SPARK-19558 Add config key to register QueryExecutionListeners automatically，实现自动注册QueryExecutionListener。
实现方式：通过实现QueryExecutionListener接口，在onSuccess回调函数拿到当前执行的QueryExecution，通过LogicalPlan的output方法，获得所有Attribute，利用NamedExpression的exprId映射关系，对其进行遍历和解析，构建列级别关系。
覆盖范围：Spark SQL CLI、Thrift Server、使用Dataset/DataFrame API（如spark-submit、spark-shell、pyspark）
遇到问题：
- 使用analyzedPlan而不是optimizedPlan，optimizer的执行计划可能会丢失一些信息，可以在analyzedPlan的基础上apply一些有助于分析的Rule，如CombineUnions。
- 传递的初始化用的hiveconf/hivevar变量被Thrift Server忽略，导致初始化Connection没有办法埋点。
驱动力
数说
打上Patch SPARK-13983 ，可以实现第一步，传递变量，但是这个变量在每次执行新的statement都重新初始化，导致用户set的变量不可更新。后续给社区提交PR SPARK-26598，修复变量不可更新的问题。SPARK-13983 Fix HiveThriftServer2 can not get "--hiveconf" and "--hivevar" variables since 2.0SPARK-26598 Fix HiveThriftServer2 cannot be modified hiveconf/hivevar variables
- Drop Table 的限制，DropTableCommand执行成功的时候，该表不一定在之前存在过，如果在Drop之前存在过，元数据也已经被删除了，无从考证。
在DropTableCommand增加了一个标志位，真正在有执行Drop操作的话再置为True，保证收集的血缘数据是对的。
- 使用Transform用户自定义脚本的限制
PrestoTransform不像java UDF，只输入需要用到的字段即可，而是需要将所有后续用到的字段都输入到自定义脚本，脚本再决定输出哪些字段，这其中列与列之间的映射关系无法通过执行计划获得，只能简单的记录输出列的表达式，如transform(c1,c2,c3) script xxx.py to c4。
开发Presto EventListener Plugin，实现EventListener接口，从queryCompleted回调函数的QueryCompletedEvent解析得到相应的信息。
上线的时候遇到一个无法加载Kafka加载StringSerializer的问题（StringSerializer could not be found）。
Kafka客户端使用 Class.forName(trimmed, true, Utils.getContextOrKafkaClassLoader()) 来加载Class，优先从当前线程的ContextClassLoader加载，与Presto的ThreadContextClassLoader有冲突，需要初化始KafkaProducer的时候，将ContextClassLoader暂时置为NULL。https://stackoverflow.com/a/50981469/1673775
5.3 图数据库JanusGraph
JanusGraph是一个开源的分布式图数据库。具有很好的扩展性，通过多机集群可支持存储和查询数百亿的顶点和边的图数据。JanusGraph是一个事务数据库，支持大量用户高并发地执行复杂的实时图遍历。
生产上，存储我们使用Cassandra，索引使用Elasticsearch，使用Gremlin查询/遍历语言来读写JanusGraph，有上手难度，熟悉Neo4j的Cypher语法可以使用cypher-for-gremlin plugin。
驱动力
数说
以下是数据血缘写入图数据库的模型，Hive字段单独为一个Lable，关系型DB字段为一个Label，关系分两种，LABELWRITE，LABELWRITE_TTL。
只有输入没有输出（Query查询操作），只有输出没有输入（建表等DDL操作）也会强制绑定一个来源系统的ID及扩展属性。
在生产上使用JanusGraph，存储亿级的血缘关系，但是在开发过程中也遇到了一些性能问题。
- 写入速度优化
以DB名+表名+字段名作为唯一key，实现getOrCreateVertex，并对vertex id缓存，加速顶点的加载速度。
- 关系批量删除
关系LABELWRITETTL表示写入的关系有存活时间（TTL-Time to live），这是因为在批量删除关系的时候，JanusGraph速度相当慢，而且很容易OOM。比如要一次性删除，Label为WRITE，x=y，写入时间小于等于某个时间的边，这时候Vertex和Edge load到内存中，容易OOM。g.E().hasLabel("WRITE").has("x",eq("y")).has("publishedDate",P.lte(new Date(1610640000))).drop().iterate()尝试使用多线程+分批次的方式，即N个线程，每个线程删除1000条，速度也不太可接受。这时候采用了折中的方案，需要删除关系用另外一种Label来表示，并在创建Label指定了TTL，由于Cassandra支持cell level TTL，所以边的数据会自动被删除。但是ES不支持TTL，实现一个定时删除ES过期数据即可。
GPU平台 （PySpark）
通过ETL任务ID，查询任务ID，报表ID，都可以获取到输入，输出的表和字段的关系。
5.5 局限
使用MapReduce、Spark RDD读写HDFS的血缘暂时没有实现。
思路可以在JobClient.submitJob的时候采集输入和输出路径，又或者通过HDFS的AuditLog、CallerContext来关联。
5.6 效果
在第一版使用图的方式展示血缘关系，在上下游关系较多的时候，显示较为混乱，第二版改成树状表格的方式展示。
字段operator在调度系统Zeus被转换成hive_account，最后输出是ArtNova报表系统的一张报表。
驱动力
数说
5.4 覆盖范围
Zeus调度平台 （ETL操作INSERT、CTAS，QUERY）
Ad-Hoc即席查询平台 （CTAS，QUERY）
报表平台 （QUERY）
元数据平台 （DDL操作）
六、实际应用场景
6.1 数据治理
- 通过血缘关系筛选，每天清理数千张未使用的临时表，节约空间。
- 作为数据资产评估的依据，统计表、字段读写次数，生成的表无下游访问，包括有没有调度任务，报表任务，即席查询。
6.2 元数据管理
- 统计一张表的生成时间，而不是统计整个任务的完成时间。
- 数据异常，或者下线一张表、一个字段的时候，可以找到相关的ETL任务或者报表任务，及时通知下游。
- 统计表的使用热度，显示趋势。
6.4 敏感等级标签
当源头的数据来自生产DB时，生产DB有些列的标签已打上了敏感等级，通过血缘关系，下游的表可以继承敏感等级，自动打上敏感标签。
七、总结
以上描述了携程如何构建表和字段级别的血缘关系，及在实际应用的场景。
随着业务需求和数据的增长，数据的加工流程越来越复杂，构建一套数据血缘，可以轻松查询到数据之间的关系，进行表和字段级的血缘追溯，在元数据管理，数据治理，数据质量上承担重要一环。
驱动力
数说
6.3 调度系统
得益于在图数据库JanusGraph可以使用关系边的key作为索引，可以根据任务ID可以轻松获得该任务输入和输出表。
- 当配置一个任务A的依赖任务列表的时候，可以使用推荐依赖，检查依赖功能，获得任务A的所有输入表，再通过输入的表获得写入任务ID列表，即为任务A所需依赖的任务列表。
- 在任务结束后，获取该任务所有输出的表，进行预配的规则进行数据质量校验。
驱动力
风向
大数据时代，数据的来源极其广泛，各种类型的数据在快速产生，也在爆发性增长，这导致了数据之间的关系也变得越发复杂。
因此对数据工程师来说，如何管理表之间、代码之间的复杂关系，从而更好地认识和理解业务系统与底层表的关系、底层表的表间关系，理清当前数据（字段、关键指标或者数据标签）从哪里来？到哪里去？搞清楚哪些下游系统在使用这些数据等成为一件很重要的事。
什么是数据血缘，如何做好数据血缘分析？
转自亿信华辰微信公众号
原文链接：
https://mp.weixin.qq.com/s/Pzl2ALkZQfcknzbGxpdZUg
而要解决这个事，我们就不得不提到元数据管理中的数据血缘。数据血缘描述了数据的来源和去向，以及数据在多个ETL处理过程中的转换，因此，数据血缘是组织内使数据发挥价值的重要基础能力。今天小亿就来为大家分享下什么是数据血缘，以及如何做好血缘分析？
驱动力
风向
一、什么是数据血缘
数据血缘，又称数据血统、数据起源、数据谱系，是指数据的全生命周期中，数据从产生、处理、加工、融合、流转到最终消亡，数据之间自然形成一种关系。其记录了数据产生的链路关系，这些关系与人类的血缘关系比较相似，所以被成为数据血缘关系。
比如，数据A经过ETL处理生成了数据B，那么我们就说数据A与B有着血缘关系，且数据A是数据B的上游数据，同时数据B是数据A的下游数据。按血缘对象来分，可分为系统级血缘、表级血缘、字段（列）级血缘。不管是结构化数据还是非结构化数据，都必定存在数据血缘关系。
（4）层次性：数据的血缘关系是具备层级关系的，就如同传统关系型数据库中，用户是级别最高的，之后依次是数据库、表、字段，他们自上而下，一个用户拥有多个数据库，一个数据库中存储着多张表，而一张表中有多个字段。他们有机结合在一起，形成完整的数据血缘关系。
三、数据血缘分析主要应用在哪方面？
而数据血缘分析是元数据管理的重要应用之一，其梳理系统、表、视图、存储过程、ETL、程序代码、字段等之间的关系，并采用图数据库进行可视化展示。简单地说就是通过可视化展示数据是怎么来的，经过了哪些过程、阶段及计算逻辑。
二、数据血缘关系的4个特征
与人类社会中的血缘关系不同，数据的血缘关系包含4个特有的特征：
（1）归属性：数据是被特定组织或个人拥有所有权的，拥有数据的组织或个人具备数据的使用权，实现营销、风险控制等目的。
（2）多源性：这个特性与人类的血缘关系有本质的差异，同一个数据可以有多个来源。来源包括，数据是由多个数据加工生成的，或者由多种加工方式或加工步骤生成的。
（3）可追溯：数据的血缘关系体现了数据的全生命周期，从数据生成到废弃的整个过程，均可追溯。
驱动力
风向
场景和真实的业务价值。而数据血缘则提供了一种基于数据实际应用的价值评估方法：使用者越多（需求方）、使用量级越大、更新越频繁的数据往往更有价值。
（1）数据受众：在血缘关系图上，右边的数据流出节点表示受众，亦即数据需求方，数据需求方越多表示数据价值越大；
（2）数据更新量级：数据血缘关系图中，数据流转线路的线条越粗，表示数据更新的量级越大，从一定程度上反映了数据价值的大小；
（3）数据更新频次：数据更新越频繁，表示数据越鲜活，价值越高。在血缘关系图上，数据流转线路的线段越短，更新越频繁。
3.数据质量评估
数据血缘清晰的记录了数据来源以及数据流转过程中的处理方式和处理规则，能实现对各个数据节点的分析和数据质量评估。
4.数据归档参考
数据血缘中记录了数据的去向，可清晰的掌握数据被消费的情况，一旦数据没有消费者，那也就意味着数据已经失去价值。此时，可以对数据进行进一步评估，考虑进行归档或销毁处理。
四、如何做好数据血缘关系分析？
数据血缘分析作为数据血缘的应用方式，不是单纯的一种技术手段或一个工具，而是一个贯穿数据生命周期的过程，涉及流程、技术、产品等多维度的内容。在此，我们将数据血缘分析分为三大模块：数据血缘建设，数据血缘分析，数据血缘可视化。
1.数据血缘建设
数据血缘建设并不是去建设数据血缘关系，因为数据血缘关系是数据流转过程中自动产生的是生而有之的。数据血缘建设的目标是当这些生而有之的数据血缘关系产生时，能被及时、准确的记录和存储下来。因此，数据血缘建设并不是一个指定的动作，而是一种管理流程和数据意识，需要延伸到数据产生之前，从数据存储的设计开始。
数据血缘建设是数据血缘分析的前提条件，准确、完整、及时记录信息才能带来有效的血缘分析效果，考虑到部分数据源本身的数据血缘建设准备较差，在某些业务场景中需要人工介入进行梳理。
1.数据溯源
溯源，指的是探寻事物的根本、源头。我们分析处理的数据，可能来源很广泛，不同来源的数据，其数据质量参差不齐，对分析处理的结果影响也不尽相同。当数据发生异常，我们需要能追踪到异常发生的原因，把风险控制在适当的水平。
换句话说，依托于数据血缘的可塑性特点，根据血缘中的数据链路关系，可实现指定数据的来源、去向的追溯，可帮助用户理解数据含义、在全流程上定位数据问题、进行数据关联影响分析等，解决多层复杂逻辑处理后的数据难以理解、难以应用、出现问题难以定位的问题。
2.数据价值评估
数据价值是数据管理的核心标准，不管是数据交易中的数据定价还是数据安全的保护等级，数据价值都是一个重要的参考因素。因此，如何准确地评估数据价值成为了企业面临的一大难题。
传统的数据价值评估，往往完全依靠相关法规要求和业务经验，缺少在具体应用场景中的评估依据，数据价值评估脱离了数据的应用
驱动力
风向
业务需求的差异将决定血缘分析层次和血缘层级的差异，进而体现在数据血缘图谱上，因此数据血缘图谱也许要基于数据血缘层级进行分层展现，直观的从应用层级、数据层级、字段层级呈现数据的血缘关系。
在具体的应用中，首先业务需求差异和可采集分析的血缘信息的影响，数据血缘图谱的呈现方式可能存在差异，但其整体形态基本一致：以某个数据为核心节点，体现该节点的数据来源、数据去向、流转路径以及路径中的处理方式和处理。因此，数据血缘可视化视图中应该当至少包含以下元素：
（1）数据节点
标记数据的具体信息，如所有者、层次信息、终端信息等，根据不同的血缘层次和业务需求，数据节点的信息有所有差异。根据数据类型的不同，数据节点有可以分为：主节点，数据流入节点、数据流出节点。
①主节点：主节点是数据血缘图谱的核心，是我们当前需要观察的数据，它只有一个，整个图谱呈现的就是它的血缘关系；主节点应该是可以且方便切换的。
②数据流入节点：数据流入节点标记主节点的数据来源，是主节点的父节点，它可能有多个甚至多层。
③数据流出节点：数据流出节点标记主节点的数据去向，是主节点的子节点，同样可能有多个或多层；在数据流出节点中有一种特殊的终端节点，数据到达终端节点后，将不再向别处流转。
（2）流转线路
标记数据的流转路径，通常从流入节点汇聚到主节点，再主节点扩散到流出节点。在流转线路中，不仅可标记出数据的流向和流转关系，还可以通过线路的粗细、长短等标记数据量级和更新频次。
（3）处理节点
标记数据流转过程中的处理方式和处理规则，通常用于数据节点之间的流转线路中。通过处理节点，可以直观地了解到数据在两个节点之间流转时，通过什么样的规则进行了怎样的处理。
2.数据血缘分析
数据血缘分析针对数据流转过程中产生并记录的各种信息进行采集、处理和分析，对数据之间的血缘关系进行系统性梳理、关联、并将梳理完成信息进行存储。考虑到企业的数据庞杂问题，数据血缘分析往往需要借助工具或系统展开，实现血缘信息数据的自动采集、自动分析。
数据血缘分析通常会按数据血缘的层级进行，层级基于业务需求和某些数据特性可能有差别，常见的分析层级为应用（业务系统）级、数据（表/文件）级和字段级。数据血缘分析的目标是实现数据来源的精确追踪、流转过程的准确还原、数据去向的精准定位。
3.数据血缘可视化
血缘分析完成后，需要依靠可视化技术将分析结果清晰、直观地传递给用户，帮助客户进行二次分析和具体应用。数据血缘图谱是血缘分析中最常用可视化方案。
驱动力
风向
亿信华辰元数据管理平台EsPowerMeta是基于B/S架构的软件平台，架构分为5层，数据源层、采集层、数据层、功能层和访问层，其不仅适配各种数据库、各类ETL、各类数据仓库和报表产品，还适配各类结构化或半结构化数据源。
五、数据血缘分析时的注意事项
数据血缘分析时，需要考虑以下几个方面：
1.全面性
数据处理过程实际上是程序对数据进行传递、运算演绎和归档的过程，数据的流动性和数据间的复杂关系，将导致某一数据的细微变动引起多个系统的数据发生变化。为了确保数据血缘的完整性，必须将整个系统能够作为数据血缘的分析对象，真正做到追源头溯尾。
2.及时性
据和数据之间的关系可能是随时变动的 ，为了保证数据血缘的准确性和可用性，血缘分析必须与数据保持同步更新，确保数据血缘的分析结果面向最新的数据和数据关系。
3.适用性
血缘分析技术和实现有多种，分析的广度、深度、维度也有不同，但所有的技术都是为需求服务的，血缘分析需要在实现需求目标的前提下展开。
六、小结
随着数据的爆发式增长，数据之间的关系也变得越发复杂。在这样的背景下，具备可塑性、归属性等特征的数据血缘将数据治理过程中发挥越来越大的作用。数据的血缘对于分析数据、跟踪数据的动态演化、衡量数据的可信度、保证数据的质量具有重要的意义。
但数据血缘应用需要依赖丰富的可分析数据、强大的数据采集和血缘分析能力、清晰直观的血缘图谱，是一个贯穿数据生命周期的持续性工程。这里亿信华辰元数据管理平台EsPowerMeta就可以帮助你。
另外，元数据管理模块还提供了丰富的元数据分析功能，包括血缘分析、影响分析、全链分析、关联度分析、属性值差异分析等，分析出元数据的来龙去脉，快速识别元数据的价值，掌握元数据变更可能造成的影响，以便更有效的评估变化带来的风险，从而帮助用户高效准确的对数据资产进行清理、维护与使用！
血缘分析可以满足许多行业(包括医疗、金融、银行和制造业等)对所呈现数据的特殊监管及合规性要求。
最后，影响度分析，也是较为血缘关系应用的一部分，其用来分析数据的下游流向。当系统进行升级改造时，能动态数据结构变更、删除及时告知下游系统。通过依赖数据的影响性分析，可以快速定位出元数据修改会影响到哪些下游系统，哪些表和哪些字段。从而减少系统升级改造带来的风险。
驱动力
一线
分享嘉宾｜彭洪剑 字节跳动 DataLeap 研发工程师
编辑整理｜黄如飞 迅雷网心科技
出品社区｜DataFun
导读：DataLeap是火山引擎数智平台VeDI旗下的大数据研发治理套件产品，帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设，降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。
数据血缘是帮助用户找数据、理解数据以及使数据发挥价值的基础能力。本文将聚焦数据血缘存储和血缘导出，分享在存储和导出数据血缘的模型设计以及优化，并介绍字节跳动在数据血缘建设过程中所遇到的挑战和技术实现以及数据血缘的具体用例，具体包括数据血缘模型、数据血缘优化、数据血缘用例、未来展望四个部分。本文介绍的数据血缘能力和实践，目前大部分已通过火山引擎DataLeap对外提供服务，欢迎大家点击阅读原文体验。
字节跳动数据血缘技术实现与具体用例
转自知乎DataFunTalk账号
原文链接：
https://zhuanlan.zhihu.com/p/609364769
01/数据血缘模型
首先介绍一下字节内部数据血缘遇到的挑战。
随着公司业务扩张、用户数量持续增长以及数仓建设不断完善，元数据种类和数量也经历了非线性增长，并在此期间涌现出一些问题。
第一，扩展性。好的扩展性可以在面对新型元数据血缘时保证快速接入和迭代，而扩展性不佳则会导致在业务变化时需要不停地重构来适应业务，对业务造成很多影响。
第二，性能。一个模型本身的插入和更新效率会直接影响数据的导入导出的流程，这些都会带来更直观的业务上的感受，所以需要考虑如何保证环节高效性。
驱动力
一线
第三，时效性。很多应用场景对正确率格外敏感，如果血缘数据有延迟，其实就等于血缘的不准确，会对业务造成影响。
最后，赋能业务。技术服务于业务，业务增长会帮助技术升级迭代，技术创新也会促进业务发展。在字节内部，我们会根据业务特点，考虑业务需要，将技术成本与业务收益做平衡，最终做出数据模型决策。总而言之，数据模型没有完美的方案，只有最适合企业自身业务、适合当前阶段的数据血缘方案。
2. 数据血缘模型 – 展示层
字节内部有很多种元数据类型，包括线上传统的离线数仓Hive、OLAP分析引擎ClickHouse，以及实时侧元数据，如Kafka和ES以及Redis。这些元数据所对应的表/Topic都统一维护在元数据平台上，目前血缘展示层是以这些数据资产作为主视角。
如下图所示，中心数据资产包含普通字段和分区字段等信息，还可以从图中看到中心资产上下游资产信息，上游有哪些相关的表，下游有哪些相关的topic或者表。图中资产和资产之间连接的边，代表的是生产关系：1个任务读取了上游的资产，产生了下游的资产。
在图中，资产节点用圆形表示，任务节点用菱形表示。具体举个例子：
（1）一个 FlinkSQL 任务消费了 Kafka 的 topic，然后写入到一个 Hive 的表里，那么 Kafka 的 topic 和 hive 表就是表资产节点，而 FlinkSQL 消费任务就是中间的任务节点。（2）一个 Kafka 的 topic 里面可能会定义自己的 schema，包括多个字段，例如schema里包含字段 a、b、c，通过 FlinkSQL 任务，比如一个 SQL：insert into hiveTable select a，b，c from kafkaTopic，通过进行这样的处理，字段 a、b、c 和这个 hive 的字段 d 就产生了血缘关系。（3）创建子任务的节点，把几个字段节点连接起来，每个子任务节点会和子任务节点通过从属关系的边来进行连接，字段节点和每一个表资产节点也会通过从属关系的边进行连接。本身这个任务和资产之间会有消费生产关系的边连接。
以上就是整个血缘数据模型在抽象层的展现。
这样设计是有以下好处：
首先，任务资产的抽象是对生产平台上和在各种任务平台上广泛直接的任务关系的抽象，当再去接入新元数据或新任务类型时，我们只需要扩展当前抽象的资产节点和任务节点，即可把新加入进来的任务链路所对应的血缘接入到存储中。这种数据模型也能方便地更新和删除血缘链路，维持时效性。
其次，在字节内部的血缘建设中，还存在接入各种血缘链路的难点。基于目前设计可以减少开发成本，在更新血缘的时只需要更新中心任务节点，并且把中心任务节点所对应的子任务节点的边也做相应的更新和删除，就完成了血缘信息的插入和更新。
3. 数据血缘模型 – 抽象层
再来介绍，火山引擎DataLeap如何设计抽象层。
抽象层是整个数据血缘的数据模型，主要包含两种节点，一种是资产节点，另外一种是任务节点。
驱动力
一线
4. 数据血缘模型 – 实现层
在实现层，火山引擎 DataLeap 主要基于 Apache Atlas 来实现。Apache Atlas 本身也是一个数据治理的产品，它预定义了一些元数据的类型，整个类型系统有比较好的扩展性。在 Atlas 本身的 DataSet 和 Process 元数据定义上，我们引入了字节内部独有的业务元数据的属性和子任务定义，最终把任务相关的元数据存储起来。
Atlas 本身也支持血缘的查询能力，通过 Apache Atlas 暴露的接口来转换成图上查找某个节点对应血缘关系的边，以此实现血缘查询。
以上就是整个数据血缘模型的设计部分。通过这样的数据血缘模型，我们可以减少新的数据血缘链路接入开发成本，同时也很方便更新和删除血缘。
02/数据血缘优化
第二部分将主要介绍在火山引擎 DataLeap 中典型的数据血缘优化，包括实时数据血缘更新优化、血缘查询优化和血缘数据开放式导出。
5. 数据血缘模型 – 存储层
在存储层，目前主要基于 Apache Atlas 原生图数据库——JanusGraph。JanusGraph 底层支持 HBase。我们将每条边的关系作为两边的资产节点的属性，存入到对应 RowKey 的独立 cell 中。
另外，我们也对存储做了相关的改造，如字节内部自研的存算分离 key-value 存储。我们也在独立环境中会做轻量级部署，同时基于性能或成本，以及部署复杂度，把存储切换为 OLTP 数据库，比如 MYSQL 数据库。
驱动力
一线
1. 实时数据血缘优化
首先，实时数据血缘的更新。字节内部现在数据血缘的更新方式是通过 T+1 的链路和实时链路来更新。由于内部有很多场景对时效性的要求特别高，如果数据血缘更新不太及时，就是影响血缘准确率，甚至影响业务使用。
在数据血缘的架构设计之初就已经支持了 T+1 的导入，但是时效性始终是天级别的。
（1）数据血缘任务周期性的拉取所有在运行任务的配置信息，调用平台的 API 拉取对应任务相关的配置或者 SQL；
（2）对于 SQL 类型的任务会调用另外一个解析引擎服务提供的解析能力来去解析数据血缘的信息；
（3）再和元数据平台登记的资产信息相匹配，最后构建出一个任务资产节点的上下游，把这个任务资产节点和表资产节点之间的边更新到图数据库中去。
在实时更新的时候，我们有两种方案：
方案一：是在引擎侧，即在任务运行时，通过任务执行引擎把该任务在构建 DAG 后生成的血缘信息通过 Hook 送入。
（1）优点：在引擎侧的血缘采集是相对独立的，每个引擎在采集血缘的时候不会互相影响。
（2）缺点：
① 每个引擎都需要适配一个血缘采集的 Hook，一些中小企业在引擎侧都可能面临的一个问题是同一个引擎可能在线上运行会有多个版本，那么适配的成本就会比较高，需要每个版本都适配一次。
② Hook 还有一定的侵入性，会对本身的作业有一定的负担。
方案二：在任务开发的平台上把这个任务变更的消息送出，当任务的生命周期变化的时候，通过 Hook 消息把任务状态变更消息通过调用 API 进行登记或者发送到 MQ 进行解耦，血缘服务收到这份通知之后，再主动调用解析服务来更新这个任务血缘。
（1）优点：扩展性好，不会受到引擎侧限制，未来要接入新的引擎时，只需要在这个任务平台上去创建对应的任务，把这个任务变更
的消息送出，就可以得到这个血缘更新的通知，然后去更新血缘。
（2）缺点：对血缘解析服务平台会有一定的改造成本，任务间的消息可能会互相影响。
综合比较，我们采用了第二种方案，并且引入了MQ进一步的降低任务平台和血缘平台的耦合，这种做法可能牺牲了部分的延迟，但是会让整个链路变得更加可靠，最终减低了血缘这边整体的延迟，从天级别减低到了分钟级别。
以上就是我们在血缘时效性上的优化。
2. 数据查询优化
第二个优化点是查询。目前字节数据血缘查询依赖 Apache Atlas。在使用该血缘查询服务时，有一个很普遍的场景，就是多节点查询的场景。在影响分析的过程中，我们经常会查询一张表的全部字段血缘，会转化成查询多个节点的血缘上下游关系，需要解决查询效率的问题。
有两种基本的解决方案：
一种是直接在应用层进行封装，对 Apache Atlas 血缘服务的暴露层新增一个接口，比如通过循环遍历去执行单个查询，这样改造的内容是很少的，但是其实性能并没有提升，而且实现比较暴力。
驱动力
一线
另外一种方式是改造 Apache Atlas 血缘服务对图库查询的调用。因为 Atlas 使用 JanusGraph 作为底层的实现，提供了一部分的抽象，但是只暴露了单节点的查询，而没有批量查询的方法，我们只需要适配 JanusGraph 这边批量查询的接口，就可以达到提速的效果。
所以我们在图数据库的操作入口增加了一个新的批量查询的方法，通过这种方式对血缘节点进行批量查询，来进一步提升性能。同时 Atlas 在查询血缘节点回来之后，需要进行一个映射，映射到具体的实体上去拿回它的一些属性，在这个过程中我们也加入了异步批量的操作方式来进一步的提升性能。经过优化之后，我们在对一些引用热度比较高的表资产节点或者查询表资产或者对应列的时候，效率都可以得到明显提升。
03/数据血缘用例
接下来第三部分主要介绍数据血缘的具体用例，介绍字节内部是如何使用数据血缘的。在字节内部数据血缘用例的典型使用领域主要包括：资产领域、开发领域、治理领域和安全领域。
1. 数据血缘用例 – 资产领域
首先在资产领域，数据血缘主要应用在资产热度的计算。在资产热度计算时，有些资产会被频繁消费和广泛引用。某个资产被众多下游引用，是自身权威性的证明，而这种权威性的证明需要一种定量的度量，因此需要引入了“资产热度”的概念。资产热度本身是参考网页排名算法PageRank算法实现的，同时我们也提供了资产热度值，根据资产的下游血缘依赖的情况，定义了资产引用的热度值，如果某个资产引用热度值越高，就代表了这个资产更应该被信任，数据更可靠。
另外，血缘也可以帮助我们理解数据。比如用户在元数据平台或者血缘平台上查询数据资产节点的时候，可能是想要进行下一步的作业开发或者是排查一些问题，那么他就需要首先找到这个数据资产。用户不了解数据产生的过程，就无法了解数据的过去和未来。也就是哲学上经典的问题：这个表到底是怎么来的？它具体有哪些含义？我们就可以通过数据血缘来找到具体表的上下游信息。
3. 血缘数据开放式导出
第三个优化点是在血缘的导出上提供了多种方式，除了在页面上可视化的查询血缘的能力之上，我们也陆续提供了很多使用血缘的方式，包括下载到 Excel,或者查询这个血缘数据导出的数仓表，或者直接使用服务平台侧开放的 API，还可以订阅血缘变更的 topic，来直接监听血缘的变更，下游的用户可以根据自己的开发场景，以及业务对准确率、覆盖率的要求，来决定到底使用哪种方式来消费血缘数据。
驱动力
一线
2. 数据血缘用例 – 开发领域
数据血缘的第二个用例是开发领域。在开发领域中会有两个应用：影响分析和归因分析。
（1）影响分析应用
影响分析应用是事前分析。也就是当我们对表资产做一些变更的时候，在事前需要感知这个变更的影响，处于血缘上游的资产负责人在修改对应的生产任务的时候s，就需要通过血缘来查看自己资产的下游，来判断这个资产修改的影响，针对修改的兼容性或者某条链路的重要性，来对应的做一些通知的操作，否则会因为缺少通知而造成严重的生产事故。
（2）归因分析应用
归因分析应用是事后分析。比如当某个任务所产生的表出现了问题，我们就可以通过查询血缘的上游，逐级寻找到血缘上游改动的任务节点或者资产节点来排查出造成问题的根因是什么。在发现和定位出了问题之后，我们会去修复数据，在修复数据的时候，我们可以通过血缘来查找任务或者表的依赖关系，对于离线数仓可能就需要重跑某个分区的输出数据，我们需要根据血缘来划定范围，只需要回溯对应受影响的下游任务就可以了，减少一些不必要的资源浪费。
3. 数据血缘用例 – 治理领域
在治理领域应用中，血缘关系在字节内部也有典型的使用场景：链路状态追踪和数仓治理。
（1）链路状态追踪
比如在重要的节日或者活动的时候，我们需要事先挑选一些需要重要保障的任务，这时就需要通过血缘关系来梳理出链路的主干，即核心链路。然后去对应的做重点的治理和保障，比如签署 SLA。
（2）数仓治理
在数仓建设方面，也会使用血缘来辅助一些日常的工作，比如规范化治理。数仓规范化治理包括清理数仓中分层不合理的引用，或者是数仓分层整体不规范，存在一些冗余的表。比如，两个表来自同一个上游表，但是它们在不同层级，这些冗余的表就需要被清理掉的，这种场景就是使用血缘来辅助治理的一个典型用例。
驱动力
一线
4. 数据血缘用例 – 安全领域
安全相关问题在一些跨国或国际化产品企业会比较常见，每个国家地区的安全政策是不一样的。我们在做安全合规检查时，每个资产都有对应的资产安全等级，这个资产安全等级会有一定的规则，比如我们规定下游资产的安全等级一定高于上游的安全资产等级，否则就会有权限泄露问题或者是其他的安全问题。基于血缘，我们可以扫描到这些规则涉及的资产下游，来配置相应扫描规则，然后进行安全合规排查，以便做出对应的治理。
另外，血缘在标签传播方面也有所应用，可以通过血缘的传播链路来进行自动化工作，比如对资产进行安全标签打标的时候，人工的打标方式会相对比较繁琐而且需要关注链路的信息，那么就可以借助血缘信息来完成自动的打标，比如配置一些规则让安全标签明确场景、节点和终止规则。
04/未来展望
1. 血缘技术趋势
在业界，血缘的发展趋势主要关注以下几点：
（1）通用的血缘解析能力
血缘是元数据平台的核心能力，很多时候元数据平台会接入多样化元数据，这些业务元数据也会依赖血缘不同的血缘解析能力，现在的解析往往是依赖各个引擎团队来支持的，但是其实在更加广泛的场景，我们需要有一个兜底的方案来提供一个更通用的血缘解析能力，所以未来我们会提供标准 SQL 解析引擎，以达到通用解析的目的。
（2）非侵入式的非 SQL 类型血缘采集
除了可解析的 SQL 或可配置的任务，日常还会涉及到代码类型的任务，如 JAR 任务。JAR 任务现在的解析方式是根据一些埋点信息或者用户录入的上下游信息去完成血缘的收集，这部分未来会出现一种非侵入式的非 SQL 类型血缘采集的技术，比如 Flink 或者 Spark 的 JAR 任务，我们可以在任务运行时拿到这些血缘，来丰富平台侧血缘的数据。
（3）时序血缘
时序血缘也是字节内部的考虑点。目前血缘信息图数据库相当于是对当前血缘拓扑的一次快照，其实血缘是会变化的，比如用户在修
以上这些都是数据血缘在字节内部的一些典型用例，我们也在探索更多的使用场景。
根据其对血缘质量的要求，这些场景被分成了几个区域。根据血缘覆盖率、血缘准确率的要求，可以分为四个象限，比如其中一类是需要覆盖全链路且血缘准确率要求异常高的，例如开发项的两个用例，因为在开发项的用例中，血缘的延迟会严重影响决策上的判断，对血缘质量要求是最高的。
血缘建设过程也会划分不同的建设时期，我们可以根据现在要支持的业务场景和业务优先级来辅助制定血缘建设规划，决定血缘迭代的节奏和具体方向。
驱动力
一线
改一个任务的时候，上线任务变更或是修改表结构，然后对应的修改自己生产任务的时候，涉及到时序的概念，这个时序可以方便我们去追溯一些任务的变化，支持我们去做事前事后影响分析，所以时序血缘如何在图数据库中引入也是未来的一个趋势。
2. 数据血缘的应用趋势
（1）标准化
前文提到很多应用场景的底层能力都是通过接口来获得，获得接口的数据也涉及到应用的标准化，标准化的应用可以让我们移植到更多的业务上，提供更好的血缘数据分析帮助。
（2）端到端的血缘打通
另一个应用趋势是端到端的血缘能力，现在平台主要接入资产节点，端到端则会涉及到更上游，如 App 端和 Web 端采集的数据，或者是下游报表，以及 API 之后最终的节点。在血缘收集中，这部分信息目前缺失，端到端血缘打通将是未来应用上的趋势之一。
3. 云上的全链路血缘能力
在字节跳动内部，血缘能力会进行上云，云上涉及各类数据类型，因此血缘发展方向之一是把各类异构数据类型统一接入，并且支持云上用户来自定义接入新类型血缘。
同时，当数据应用标准化之后，也可以把血缘应用提供给云上用户，云上用户也可以反向加入到血缘应用的开发中，最后把数据血缘模型作为一种标准来推广，由此衍生出更好的血缘应用、血缘服务生态。
驱动力
热点
数据血缘关系，从概念来讲很好理解，即数据的全生命周期中，数据与数据之间会形成多种多样的关系，这些关系与人类的血缘关系类似，所以被称作数据的血缘关系。
数据治理：数据血缘关系
转自与数据同行微信公众号 作者歪老师
原文链接：
https://mp.weixin.qq.com/s/RhdAkq3f04KIi8tktZ_y5A
从技术角度来讲，数据a通过ETL处理生成了数据b，那么，我们会说，数据a与数据b具有血缘关系。不过与人类的血缘关系略有不同，数据血缘关系还具有一些个性化的特征。
归属性
数据是被特定组织或个人拥有所有权的，拥有数据的组织或个人具备数据的使用权，实现营销、风险控制等目的。
多源性
这个特性与人类的血缘关系有本质上的差异，同一个数据可以有多个来源（即多个父亲），来源包括，数据是由多个数据加工生成，或者由多种加工方式或加工步骤生成。
可追溯
数据的血缘关系体现了数据的全生命周期，从数据生成到废弃的整个过程，均可追溯。
层次性
数据的血缘关系是具备层级关系的，就如同传统关系型数据库中，用户是级别最高的，之后依次是数据库、表、字段，他们自上而下，一个用户拥有多个数据库，一个数据库中存储着多张表，而一张表中有多个字段。它们有机地结合在一起，形成完整的数据血缘关系。
如下图中某学校学生管理系统后台数据库的ER图示例，学生的学号、姓名、性别、出生日期、年级、班级等字段组成了学生信息表，学生信息表、教师信息表、选课表之间通过一个或多个关联字段组成了整个学生管理系统后台的数据库。
驱动力
热点
不管是结构化数据，还是非结构化数据，都具有数据血缘关系，他们的血缘关系或简单直接，或错综复杂，都是可以通过科学的方法追溯的。
以某银行财务指标为例，利息净收入的计算公式为利息收入减去利息支出，而利息收入又可以拆分为对客业务利息收入、资本市场业务利息收入和其他业务利息收入，对客业务利息收入又可以细分为信贷业务利息收入和其他业务利息收入，信贷业务利息收入还可以细分为多个业务条线和业务板块的利息收入。
如此细分下去，一直可以从财务指标追溯到原始业务数据，如，客户加权平均贷款利率和新发放贷款余额。如果利息净收入指标发现数据质量问题，其根因可以通过下图一目了然发现。
数据血缘追溯不只体现在指标计算上，同样可以应用到数据集的血缘分析上。不管是数据字段、数据表，还是数据库，都有可能与其他数据集存在着血缘关系，分析血缘关系对数据质量提升有帮助的同时，对数据价值评估、数据质量评估以及后续对数据生命周期管理也有较大的帮助和提高。
从数据价值评估角度来看，通过对数据血缘关系的梳理，我们不难发现，数据的拥有者和使用者，简单地来看，在数据拥有者较少且使用者（数据需求方）较多时，数据的价值较高。在数据流转中，对最终目标数据影响较大的数据源价值相对较高。同样，更新、变化频率较高的数据源，一般情况下，也在目标数据的计算、汇总中发挥着更高的作用，那可以判断为这部分数据源具有较高的价值。
从数据质量评估角度来看，清晰的数据源和加工处理方法，可以明确每个节点数据质量的好坏。
从数据生命周期管理角度来看，数据的血缘关系有助于我们判断数据的生命周期，是数据的归档和销毁操作的参考。
考虑到数据血缘的重要性和特性，以一般来讲，我们在血缘分析时，会关注应用（系统）级、程序级、字段级三个层次间数据间的关系。比较常见的是，数据通过系统间的接口进行交换和传输。
例如下图，银行业务系统中的数据，由统一数据交换平台进行流转分发给传统关系型数据库和非关系型大数据平台，数据仓库和大数据平台汇总后，交流各个应用集市分析使用。其中涉及大量的数据处理和数据交换工作：
驱动力
热点
在分析其中的血缘关系时，主要考虑以下几个方面：
1、全面性
如上图所示，数据处理过程实际上是程序对数据进行传递、运算演绎和归档的过程，即使归档的数据也有可能通过其他方式影响系统的结果或流转到其他系统中。为了确保数据流跟踪的连贯性，必须将整个系统集作为分析的对象。
2、静态分析法
本方法的优势是，避免受人为因素的影响，精度不受文档描述的详细程度、测试案例和抽样数据的影响，本方法基于编译原理，通过对源代码进行扫描和语法分析，以及对程序逻辑涉及的路径进行静态分析和罗列，实现对数据流转的客观反映。
3、接触感染式分析法
通过对数据传输和映射相关的程序命令进行筛选，获取关键信息，进行深度分析。
4、逻辑时序性分析法
为避免冗余信息的干扰，根据程序处理流程，将与数据库、文件、通信接口数据字段没有直接关系的传递和映射的间接过程和程序中间变量，转换为数据库、文件、通信接口数据字段之间的直接传递和映射。
5、及时性
为了确保数据字段关联关系信息的可用性和及时性，必须确保查询版本更新与数据字段关联信息的同步，在整个系统范围内做到“所见即所得”。
一般来说，数据血缘的用途主要体现以下几个方面：
1、合规需求，这是监管部门的需求，为了监管合规，数据流动的各点和来源，都是重点需要监管的。
2、影响分析和质量问题分析，这个数据开发部们的核心需求，随着数据应用越来越多，数据的流动链越来越长，一个源头的核心业务的改动，下游各分析应用必须保持同步，没有影响分析，就会各个数据服务造成异常访问的情况。
3、数据安全和隐私，这个是数据合规部门的需求，哪些数据是需要脱敏的，这个要保持全流通所有域的管控。
4、迁移项目，这个出现在特定老项目终止需要新项目接管的情况下，没有数据流动映射表，就会大量花时间去整理，也很难保证迁移的完整性和正确性。
5、自服务分析，数据分析团队为了确定数据可信程度，那么数据的来源是数据可信的重要依据。
数据血缘系统的构建和维护是一个较重的系统工程，笔者认为其是数据治理工作中的流沙之地，不小心会陷入这个坑之中，尤其是技术完美人格类型的负责人，这是因为数据血缘的工作需要考虑的因素很多。
为了最大程度降低项目失败的风险，我们需要考虑数据血缘的服务用户对象，确定业务方面和技术方面的血缘优先，需要考虑到细节程度，覆盖率，变化频率，同时还要考虑人员流动，组织部门，技术架构等情况，制定最适合我们自己的策略。
数据血缘的收集方法主要有以下几种：
1、自动解析
自动解析当前主要的收集方法，具体就是解析SQL语句，存储过程，ETL过程等文件。因为复杂代码和应用环境等原因，根据国际厂商的经验，自动解析可以覆盖到企业数据的70-95%，目前无法做到100%，因此患有技术洁癖的负责人容易犯下这个错误，即追求极高的覆盖率。
驱动力
热点
2、系统跟踪
这个方法就是通过数据加工流动过程中，加工主体工具负责发送数据映射，这样做的极大好处是收集精准，及时，细粒度可支持，不过限制就是不是每个工具都可以集成。这种方法一般鉴于统一的加工平台，比如Informatica可以管理自己的全数据血缘周期。
3、机器学习方法
这个方法是基于数据集之间的依赖关系，计算数据的相似度。这个方法的好处是对工具和业务没有依赖，缺点准确率需要人工确认，一般可以做到3-8的数据可以分析发现。
4、手工的收集
在整个项目中，一般有5%是需要手工来做的。
目前的数据血缘大多是基于技术的梳理，一般服务技术人员的需求。随着数据服务走向前台，服务业务分析和CDO的业务数据血缘，目前已经有相关产品，通过数据的语义分析，将技术元数据映射到业务元数据上，将血缘以业务流程方式发布共享出来，辅助商务决策，这是未来的发展方向之一。
--END--
北京市朝阳区朝外大街甲6号万通中心D座25层
联系电话：15801365057
投稿地址：kai.zhao@yeepay.com
--数据驱动变革--
增值电信业务经营许可证：陕B2-20210327 | 
陕公网安备 61102302611033号