字节跳动DataLeap数据血缘实践( 二 ) _大数据

（2）归因分析应用
归因分析应用是事后分析。比如当某个任务所产生的表出现了问题，我们就可以通过查询血缘的上游，逐级寻找到血缘上游改动的任务节点或者资产节点来排查出造成问题的根因是什么。在发现和定位出了问题之后，我们会去修复数据，在修复数据的时候，我们可以通过血缘来查找任务或者表的依赖关系，对于离线数仓可能就需要重跑某个分区的输出数据，我们需要根据血缘来划定范围，只需要回溯对应受影响的下游任务就可以了，减少一些不必要的资源浪费。
3. 数据血缘用例 – 治理领域
在治理领域应用中，血缘关系在字节内部也有典型的使用场景：链路状态追踪和数仓治理。
（1）链路状态追踪
比如在重要的节日或者活动的时候，我们需要事先挑选一些需要重要保障的任务，这时就需要通过血缘关系来梳理出链路的主干，即核心链路。然后去对应的做重点的治理和保障，比如签署 SLA 。
（2）数仓治理
在数仓建设方面，也会使用血缘来辅助一些日常的工作，比如规范化治理。数仓规范化治理包括清理数仓中分层不合理的引用，或者是数仓分层整体不规范，存在一些冗余的表。比如，两个表来自同一个上游表，但是它们在不同层级，这些冗余的表就需要被清理掉的，这种场景就是使用血缘来辅助治理的一个典型用例。
4. 数据血缘用例 – 安全领域
安全相关问题在一些跨国或国际化产品企业会比较常见，每个国家地区的安全政策是不一样的。我们在做安全合规检查时，每个资产都有对应的资产安全等级，这个资产安全等级会有一定的规则，比如我们规定下游资产的安全等级一定高于上游的安全资产等级，否则就会有权限泄露问题或者是其他的安全问题。基于血缘，我们可以扫描到这些规则涉及的资产下游，来配置相应扫描规则，然后进行安全合规排查，以便做出对应的治理。
另外，血缘在标签传播方面也有所应用，可以通过血缘的传播链路来进行自动化工作，比如对资产进行安全标签打标的时候，人工的打标方式会相对比较繁琐而且需要关注链路的信息，那么就可以借助血缘信息来完成自动的打标，比如配置一些规则让安全标签明确场景、节点和终止规则。
以上这些都是数据血缘在字节内部的一些典型用例，我们也在探索更多的使用场景。
根据其对血缘质量的要求，这些场景被分成了几个区域。根据血缘覆盖率、血缘准确率的要求，可以分为四个象限，比如其中一类是需要覆盖全链路且血缘准确率要求异常高的，例如开发项的两个用例，因为在开发项的用例中，血缘的延迟会严重影响决策上的判断，对血缘质量要求是最高的。
血缘建设过程也会划分不同的建设时期，我们可以根据现在要支持的业务场景和业务优先级来辅助制定血缘建设规划，决定血缘迭代的节奏和具体方向。
04
未来展望
1. 血缘技术趋势
在业界，血缘的发展趋势主要关注以下几点：
（1）通用的血缘解析能力
血缘是元数据平台的核心能力，很多时候元数据平台会接入多样化元数据，这些业务元数据也会依赖血缘不同的血缘解析能力，现在的解析往往是依赖各个引擎团队来支持的，但是其实在更加广泛的场景，我们需要有一个兜底的方案来提供一个更通用的血缘解析能力，所以未来我们会提供标准 SQL 解析引擎，以达到通用解析的目的。
（2）非侵入式的非 SQL 类型血缘采集
除了可解析的 SQL 或可配置的任务，日常还会涉及到代码类型的任务，如 JAR 任务。JAR 任务现在的解析方式是根据一些埋点信息或者用户录入的上下游信息去完成血缘的收集，这部分未来会出现一种非侵入式的非 SQL 类型血缘采集的技术，比如 Flink 或者 Spark 的 JAR 任务，我们可以在任务运行时拿到这些血缘，来丰富平台侧血缘的数据。