共计 5890 个字符，预计需要花费 15 分钟才能阅读完成。
更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群
DataLeap 是火山引擎数智平台 VeDI 旗下的大数据研发治理套件产品，帮忙用户疾速实现数据集成、开发、运维、治理、资产、平安等全套数据中台建设，升高工作老本和数据保护老本、开掘数据价值、为企业决策提供数据撑持。
数据血统是帮忙用户找数据、了解数据以及使数据施展价值的根底能力。基于字节跳动外部积淀的数据治理教训，火山引擎 DataLeap 具备齐备的数据血统能力，本文将从数据血统利用背景、倒退详情、架构演讲以及将来瞻望四局部，为大家介绍数据血统在字节跳动进化史。
背景介绍
1. 数据血统是数据资产平台的重要能力之一
在火山引擎 DataLeap 中，数据资产平台次要提供元数据搜寻、展现、资产治理以及常识发现能力。在数据资产平台中，数据血统是帮忙用户找数据、了解数据以及使数据施展价值的重要根底能力。
2. 字节跳动的数据链路状况
数据起源
在字节跳动，数据次要来源于以下两局部：
第一，埋点数据：次要来自 APP 端和 Web 端。
通过日志采集后，这类数据最终进入到音讯队列中。
第二，业务数据：该类数据个别以在线模式存储，如 RDS 等。
两头局部是以 Hive 为代表的离线数仓：该类数据次要来自音讯队列或者在线存储，通过数据集成服务把数据导入离线数仓。通过离线数仓的数据加工逻辑，流转到以 ClickHouse 为代表的 OLAP 引擎。
另外，在音讯队列局部，还会通过 Flink 工作或者其余工作对 Topic 分流，因而上图也展示了一个回指的箭头。
数据去向
次要以指标零碎和报表零碎为代表。指标零碎蕴含重要且罕用的业务指标，如抖音的日活等。报表零碎是把指标以可视化模式展示进去。
数据服务
次要通过 API 提供数据，具体而言，从音讯队列、在线存储、上游生产以及上图右侧所示的数据流转，都涵盖在数据血统范畴内。
血统倒退详情
接下来介绍血统在字节跳动的三个倒退阶段。
第一阶段：2019 年左右开始第一阶段次要提供数据血统根底能力，以 Hive 和 ClickHouse 为代表，反对表级血统、字段血统，波及 10+ 元数据。
第二阶段：从 2020 年初开始第二阶段引入了工作血统，同时反对的元数据类型进行裁减，达到 15+。
第三阶段：从 2021 年上半年至今在这一阶段，咱们对整个元数据系统（即前文提到的资产平台）进行了 GMA 革新，同步对血统架构进行全面降级，由此反对了更丰盛的性能，具体包含：
首先，元数据品种裁减到近 30 种且时效性晋升。之前以离线形式更新血统数据，导致数据加工逻辑变动的第二天，血统才会产生变动。目前，基于近实时的更新形式，数据加工逻辑在 1 分钟内即在血统中体现。
其次，新增血统生产形式的变更告诉。因为该版本反对实时血统，业务方产生及时理解血统变动的需要，变动告诉性能就是把血统变动状况以音讯队列的模式告知业务方。
再次，反对评估血统品质。新增一条链路，专门服务于血统数据品质。
最初，引入标准化接入形式。为了缩小反复工作、升高血统接入老本，咱们制订了具体的血统接入规范，业务方数据均以标准化形式接入。以上就是整体的倒退状况，目前处于第三个版本当中。
数据血统架构的演进
接下来介绍血统架构的演进。第一版血统架构：建设血统根本能力，初探应用场景血统架构
- 在数据起源方面，目前血统次要包含两个数据起源（见上图左上角）：
第一，数据开发平台：用户在开发平台写工作，并对数据加工，由此产生血统数据。
第二，追踪数据：第三方平台（即工作平台）对用户埋点等数据进行计算，也会产生血统信息。 - 在血统加工工作方面（见上图两头局部）：
这部分会对工作进行血统解析，产生血统快照文件。因为第一版采纳离线形式运行，每天该血统工作均会生成对应的血统快照文件。咱们通过比照前后两天的血统快照文件，来获取血统的变更状况，而后把这些变更加载到图中。除此之外，血统中波及的元数据会冗余一份，并存储到图里。 - 在血统存储方面（见上图左边局部），除了图数据库之外，血统自身也会依赖元数据的存储，如 Mysql 以及索引类存储。
- 在血统生产层面，第一版只反对通过 API 进行生产。
最初总结该版本的三个关键点：
- 血统数据每天以离线形式全量更新。
- 通过比照血统快照来判断血统更新操作，前面将为大家具体解答为什么要通过比照的形式。
- 冗余一份元数据存储到图数据库中。
存储模型
图中上半部分为表级血统，只包含一种类型节点，即表节点，比方 Hive 表、ClickHouse 表等。
图中下半部分为字段血统，第一版次要是提供构建血统的根本能力，因而用彼此拆散的两张图来实现。因为血统中元数据进行了冗余，每个图外面的每个节点外面都存储表相干的元数据，包含业务信息以及其余信息。
除此之外，咱们会事后计算一些统计信息，保留到图的节点中，如以后节点上游总节点数量、上游层级数量等。
采纳事后计算的目标是为了“用空间换工夫”，在产品对外展现的性能上可能要露出数据信息，如果从图里实时查问可能影响性能，因而采纳空间换工夫的形式来反对产品的展现。
2. 第二版血统架构：血统价值逐渐体现，应用场景拓宽
血统架构
通过 1 年的应用，血统在数据资产中的价值逐渐体现，且一直有利用场景落地，由此咱们进行了第二版本升级。降级点具体包含：
第一，去除第一版本中元数据冗余。元数据冗余在图晋升了性能，然而可能导致 Metadata Store 的元数据不统一，给用户带来困扰。
第二，去掉了预计算的统计信息。随着血统的数据量增多，预计算的信息透出不能给很好辅助用户实现业务判断，且导致工作负担重。比方，即便晓得某一节点的上游数据量，还是要拉出所有节点能力进一步剖析或决策。
第三，反对一条全新链路，在新增链路上，咱们把血统快照文件导入离线数仓，次要利用于两个场景：离线剖析场景或全量分析场景。基于离线数仓的血统数据实现数据监控，尽早发现血统异常情况。
因而，从第二版开始，数据血统新增了很多离线生产形式。
存储模型
第二个版本引入了全新血统存储模型（如上图所示），并将第一个版本两张图交融成一张图，解决了无奈通过表遍历字段血统的问题。
除此之外，第二个版本还引入了工作类型节点，服务于以下三种遍历场景：
- 单纯遍历数据血统，即从数据节点到数据节点。
- 数据血统和工作血统混合形式。
- 单纯工作之间血缘关系。
3. 第三版血统架构：血统成为数据施展价值的重要根底能力
血统架构
2021 年初，火山引擎 DataLeap 数据血统迭代到第三版，也成为公司外部数据施展价值的重要根底能力。
服务于业务方对数据高质量要求，第三版降级点如下：
- 血统数据起源：除了反对两个平台之外，还反对包含报表、第三方用户画像等其余平台。
- 血统工作：之前版本只反对每天定时运行的离线调度形式，第三版引入实时生产形式，反对实时解析血统，并提取通用逻辑，复用离线血统工作和实时血统工作。
- 血统解析：不同类型工作须要应用不同解析逻辑。在之前版本中，Hive SQL 工作和 Flink SQL 工作的解析逻辑是集成到血统工作中。从第三版开始，咱们把解析服务拆解成可配置的插件，实现了插件化。当某一种工作类型的血统解析逻辑须要调整的时候，只用改变其中一个解析服务，其余解析服务不受影响，同时也让血统工作更好保护。
- 元数据存储对立：只依赖图数据库和索引存储，同时反对从零碎中把所有相干的数据导出离线数仓。
- 实时生产：血统产生变更的信息会被同步到音讯队列。
- 血统的验证模块：应用方对血统数据品质有高要求，因而第三版引入新的血统的验证模块。验证的前提是要有引擎埋点数据，该埋点数据能分明晓得某一个工作具体读取数据状况、写入数据状况在离线数仓中，通过埋点数据与血统数据中比照，生成血统数据品质报表。数据品质报表对血统消费者凋谢，消费者可能清晰理解每个血统链路准确性和笼罩状况。
- 血统标准化接入：即让用户疾速接入数据，不必每一种血统接入都反复写逻辑。
存储模型
第三版血统存储模型绝对于前两版的降级点如下：
- 以工作为核心。黄色圆圈为工作节点，数据加工逻辑产生血统，因而咱们把数据加工逻辑形象为工作节点，血统的建设则以工作为媒介，工作成为血统核心。也就是说，表 1、表 2、表 3 之间的血统，是通过工作 a 实现构建。假如没有工作 a，则三个表之间的血统也不存在。
- 表血统和字段血统模型对立，在字段血统之间没有具体任务的状况下，咱们会形象出虚构的工作来对立模型。由此，工作和工作之间的血统采纳新的边来示意依赖关系。
重要个性
增量更新
在实时血统根底上，咱们还反对增量更新能力，即当某一个工作的加工逻辑发生变化时，只须要更新图中一小部分。
- 血统创立：数据加工逻辑上线或开始失效，将被形象为图数据库的操作，即创立一个工作节点和对应的数据节点，并创立两者之间的边。上图例子为表 1、表 2 和工作的边，以及工作和表 3 之间的边。
- 血统删除：数据的加工逻辑产生了下线、删除或不失效。先在图外面查问该工作节点，把工作节点以及关联血统相干的边删除。血统存储模型以工作为核心，因而表 1、表 2 和表 3 之间的血缘关系也同步隐没，这部分血统即被删除。
- 血统更新：工作自身没有产生上线或下线，但计算逻辑发生变化。例如，本来血缘关系是表 1、表 2 生成表 3，当初变成了表 2、表 4 生成表 3。咱们须要做的如下：
解析出最新血统状态，即表 2、表 4 到表 3 的血缘关系，与以后血统状态做比照（次要比照该工作 a 相干的边），上图例子是入边发生变化，那么删除其中一条边，构建另外一条边，即可实现该工作节点的血统更新。
如果面临以上血缘关系变动，然而没有该工作节点，应该执行哪些操作来更新血统？因为只有血统最新状态和以后状态，没有工作节点去获取最小单位的血缘关系，所以只能进行全量血统或全图比照，能力得出边的变动状况，再更新到图数据库中。如果不进行全量血统或全图比照，无奈通晓如何删除条和创立条，导致血统无奈更新。这也是前两个版本须要进行血统快照比照的起因。
血统标准化
在火山引擎 DataLeap 中，通常把血统数据接入形象成一个 ETL。
首先，血统数据起源，即第三方平台血统相干的数据，通常是一个数据加工逻辑或者称为工作。接着，对这些工作实现 KeyBy 操作，并与数据资产平台的工作信息做比照，确定如何进行任何创立、删除和更新。
在再实现过滤操作之后，由 Lineage Parser 对创立、更新等工作进行血统解析，得出血统后果之后会生成示意图相干操作的 Event，最终通过 Sink 把数据写入到数据资产平台中。
上图绿色和蓝色别离示意：
- 蓝色：对不同血统接入过程的逻辑统一，可形象进去并复用。
- 绿色：不同血统的实现状况不一样。例如，某一个平台为拉取数据，另外一个平台通过其余形式获取数据，导致三个局部不一样，因而咱们抽取非凡局部，复用独特局部。除此之外，咱们还提供通用 SDK，串联整个血统接入流程，使得接入新的血统时，只须要实现绿色组件。
目前，字节跳动外部业务曾经能够应用 SDK 轻松接入血统。
数据血统品质 - 覆盖率
当血统倒退到肯定阶段，业务方不止关怀血统笼罩状况、反对状况，还关怀血统数据品质状况。因而，第三版本透出血统品质相干指标——覆盖率和准确率。
覆盖率：血统笼罩的数据资产数占关注的资产数量占比。
关注的数据资产个别指，有生产工作或有生产行为的资产。上图虚线圆圈，如 Table 9，用户创立该表后没有生产行为，因而也不会产生血统，在计算中将被剔除掉。上图实线圆圈，示意有生产行为或有工作读取，则被认为是关注的资产。关注的数据资产被血统笼罩的占比，即覆盖率。
以上图为例，在 10 张表中，因为有工作与 Table 1 ~ 8 关联，因而断定有血统。Table 10，它与 Task-D 之间的连线是虚线，示意原本它应该有血统，然而实际上血统工作没把这个血缘关系解析进去，那么咱们就认为这个 Table 10 是没有被血统笼罩的。整体上被血统笼罩的资产就是表 1 ~ 8。除了 Table 9 之外，其余的都是关注的资产，那么血统笼罩的资产占比就是 8/9。也就是图上蓝色的这第 8 个除以蓝色的 8 个加上 Table 10，就是 9 个，所以这个覆盖率就是 88%。
数据血统品质 - 准确率
笼罩血统不肯定是正确的，所以咱们还定义了准确率指标，即血统精确的工作数 / 同类型的工作数。
举个例子，假如工作 c 的血统应该是 Table 5、Table6 生成 Table 7，但实际上被脱漏，没有被解析（虚线示意），导致工作 c 的血统不精确。
也存在其余状况缺失或多余状况，导致血统不精确。在上图中，同类型工作蕴含 4 个，即 a、b、c、d。那么，精确的血统解析只有 a、b，因而准确率占比为 2/4 = 50%。
在火山引擎 DataLeap 中，因为血统起源是工作，因而咱们以工作的视角来对待血统准确率。
血统品质 - 字节现状
在覆盖率局部，目前 Hive 和 ClickHouse 元数据覆盖度较高，别离达到 98%、96%。对于实时元数据，如 Kafka，相干 Topic 笼罩 70%，其余元数据则稍低。
在准确率局部，咱们辨别工作类型做准确性解析。如 DTS 数据集成工作达到 99% 以上，Hive SQL 工作、Flink SQL 工作是 97%、81% 左右。
血统架构比照
上图为三个版本比照状况：
- 血统的生产形式：第一版只反对 API 的形式，用户须要在数据资产平台上查看血统信息；第二版反对离线数仓，让用户能够全量分析血统；第三版反对音讯队列，使用户能够获取血统增量的变动。
- 增量更新：第三版开始反对增量更新。
- 血统工作：第二个版本开始反对工作血统，第三个版本反对数据品质。
- 元数据存储对立：第三版进行了元数据架构降级，使得元数据和血统存储在同一个中央。
- 新血统接入耗时：前两个版本大略须要破费 7-10 天左右。第三版本引入标准化，内部业务方或字节外部用标准化流程，实现 3、4 天左右实现开发、测试、上线。
将来瞻望
第一，继续对架构和流程进行精简。目前，血统工作分为离线和实时两局部，但没有齐全对立。在插件化、横向扩大等方面也须要增强。
第二，生态化反对。目前反对公司外部的元数据，将来打算拓展对开源或内部元数据的反对。在血统标准化方面，提供一站式数据血统能力，作为根底能力平台为业务方提供服务。
第三，晋升数据品质。除了血统数量，还须要继续晋升品质。同时因为数据链路简单，导致链路问题排查异样艰难，将来咱们也会反对疾速诊断。
最初，反对智能化场景。联合元数仓等数据，提供蕴含要害链路梳理在内的智能化能力。目前，当业务方发现数据有问题之后，次要通过依照血统数据一个一个排查形式解决，导致效率低下。将来，咱们将思考透出血统要害链路，晋升排查效率。
以上介绍的数据血统能力和实际，目前大部分已通过火山引擎 DataLeap 对外提供服务。
点击跳转 大数据研发治理套件 DataLeap 理解更多