共计 4227 个字符，预计需要花费 11 分钟才能阅读完成。
数据血统形容了数据的起源和去向，以及数据在多个处理过程中的转换。数据血统是组织内使数据施展价值的重要根底能力。本文从字节的数据链路详情开始，介绍了数据血统在字节的利用场景，总体设计，数据模型以及掂量指标。
文 | 罗小亮、拾捌、大滨来自字节跳动数据平台开发套件团队
字节跳动数据链路介绍
为了明确问题的探讨范畴，咱们首先介绍一下字节的数据链路。
字节的数据的起源分为两种：
- 端数据：APP 和 Web 端通过埋点 SDK 发送的，通过 LogService，最终落入 MQ；
- 业务数据：APP，Web 和第三方服务所进行的业务操作，通过各种利用的服务，最终落入 RDS，RDS 中的数据，通过 Binlog 的形式，汇入 MQ；
MQ 中的数据，在 MQ 之间有分流的过程，做转换格局，流量拆分等。
离线数仓的外围是 Hive，数据通过各种伎俩最终汇入其中，应用支流的 HiveSQL 或 SparkJob 做业务解决，流入上游 Clickhouse 等其余存储。
实时数仓的外围是 MQ，应用支流的 FlinkSQL 或通用 FlinkJob 做解决，期间与各种存储做 SideJoin 丰盛数据，最终写入各种存储。
典型的数据进口有三类：
- 指标零碎：业务属性强烈的一组数据，比方“抖音日活”
- 报表零碎：以可视化的模式，各种维度展现加工前或加工后的数据
- 数据服务：以 API 调用的模式进一步加工和获取数据
在字节，数据血统的零碎边界是：从 RDS 和 MQ 开始，一路路径各种计算和存储，最终汇入指标、报表和数据服务零碎。
血统的利用场景
在探讨技术细节之前，须要先讲清楚血统的利用场景与业务价值，进一步明确数据血统须要解决的问题。不同的利用场景，对于血统数据的生产形式，血统的覆盖范围，血统的品质诉求，都会有所差异。
数据血统零碎的整体设计
01 – 概览
通过对字节血统链路和利用场景的探讨，能够总结出血统整体设计时须要思考的两个关键点：
- 可扩展性：在字节，业务简单而宏大，整条数据链路中，应用到的各种存储有几十种，细分的工作类型也是几十种，血统零碎须要能够灵便的反对各种存储和工作类型
- 凋谢的集成形式：生产血统时，有实时查问的场景，也有离线生产的场景，还有可能上游零碎会基于以后数据做扩大
字节数据血统零碎的整体架构能够分为三局部：
- 工作接入：以某种形式，从工作管理系统中获取工作信息
- 血统解析：通过解析工作中的信息，获取到血统数据
- 数据导出：负责将血统数据存储到 Data Catalog 零碎中，并供上游零碎生产
02 – 工作接入
有两个要害的设计思考：
提供两种可选的链路，以应答不同上游零碎对于数据实时性的不同要求：
- 近实时链路：工作管理系统将工作的批改的音讯写入 MQ，供血统模块生产
- 离线链路：血统模块周期性的调用工作管理系统的 API 接口，拉取全量（或增量）工作信息，进行解决
定义对立的 Task 模型，并通过 TaskType 来辨别不同类型工作，确保后续解决的可扩展性：
- 不同工作管理系统，可能治理雷同类型的工作，比方都反对 FlinkSQL 类型的工作；同一工作管理系统，有时会反对不同类型的工作，比方同时反对编写 FlinkSQL 和 HiveSQL
- 新增工作管理系统或者工作类型，能够增加 TaskType
03 – 血统解析
有两个要害的设计思考：
定义对立的血统数据模型 LineageInfo
针对不同的 TaskType，灵便定制不同的解析实现，也反对不同 TaskType 可服用的兜底解析策略。比方：
- SQL 类工作：比方 HiveSQL 与 FlinkSQL，会调用 SQL 类的解析服务
- Data Transfer Service（DTS）类：解析工作中的配置，建设源与指标之间的血缘关系
- 其余类工作：比方一些通用工作会注销依赖和产出，报表类零碎的管制面会提供报表起源的库表信息等
04 – 数据导出
血统解析所产出的 LineageInfo，会首先送入 DataCatalog 零碎，反对三种集成形式：
- 对于 Data Catalog 中血统相干 API 调用，实时拉取须要的血统数据
- 生产 MQ 中的血统批改增量音讯，以近实时能力结构其余周边零碎
- 生产数仓中的离线血统导出数据，做剖析梳理等业务
血统的数据模型
血统数据模型的定义，是确保零碎可扩展性和不便上游生产集成的要害设计之一。
01 - 概览
咱们以图的数据模型来建模整套血统零碎。图中蕴含两类节点和两类边：
- 数据节点：对于存储数据的介质的形象，比方一张 Hive 表，或者是 Hive 表的一列
- 工作节点：对于工作（或链路）的形象，比方一个 HiveSQL 脚本
- 从数据节点指向工作节点的边：代表一种生产关系，工作读取了这个数据节点的数据
- 从工作节点指向数据节点的边：代表一种生产关系，工作生产了这个数据节点的数据
将工作节点和数据节点对立到一张图上的 2 点劣势：
- 将血统的生命周期与工作的生命周期对立，通过更新工作关联的边来更新血缘关系
- 能够灵便的反对从工作切入和从数据节点切入的不同场景。比方数据资产畛域从数据节点切入的居多，而数据开发畛域从工作切入的场景居多，不同的利用场景能够在一张大图上灵便遍历
02 – 字段（Column）级血统
字段血统是血统模型中的边界状况，独自拿进去简略探讨。在实现时，有两种可供选择的思路：
咱们最终采纳了第 2 种计划。
血统掂量指标
理论推广血统时，最常被用户问到的问题就是，血统品质怎么样，他们的场景能不能用。面对这种灵魂拷问，每个用户都独自评估一遍的开销过大，所以咱们花了很多精力探讨摸索出了最罕用的三个技术指标，以佐证血统品质。用户能够依据这些指标，判断本人的场景是否实用。
01 – 准确率
定义：假如一个工作理论的输出和产出与血统中该工作的上游和上游相符，既不缺失也不多余，则认为这个工作的血统是精确的，血统精确的工作占全量工作的比例即为血统准确率。
准确率是用户最关注的指标，像数据开发的影响剖析场景，血统的缺失有可能会造成重要工作没有被告诉，造成线上事变。
不同类型的工作，血统解析的逻辑不同，计算准确率的逻辑也有区别：
- SQL 类工作：比方 HiveSQL 和 FlinkSQL 工作，血统来源于 SQL 的解析，当 SQL 解析服务给出的质量保证是，胜利解析的 SQL 工作，产生的血缘关系就肯定是精确的，那么这类工作的血统准确率，就能够转化成 SQL 解析的成功率。
- 数据集成（DTS）类工作：比方 MySQL->Hive 这类通道工作，血统来源于对用户注销上下游映射关系的配置，这类血统的准确率，能够转化成对于工作配置解析的成功率。
- 脚本类工作：比方 shell，python 工作等，这些血统来源于用户注销的工作产出，这类血统的准确率，能够转化成注销产出中正确的比例。
留神一个问题，下面所讲的准确率计算，转化的时候都有一个前提假如，是程序依照咱们假设的形式运行，理论状况并不一定总是这样。其实这件事件没必要特地纠结，血统就像咱们在运行的其余程序一样，都可能因程序 bug，环境配置，边界输出等，产生不合乎预期的后果。
作为准确率的补充，咱们在实践中通过三种路径，尽早发现有问题的血统：
- 人工校验：通过结构测试用例来验证其余零碎一样，血统的准确性问题也能够通过结构用例来验证。实际操作时，咱们会从线上运行的工作中采样出一部分，人工校验解析后果是否正确，有必要的时候，会 mock 掉输入，继续运行校验。
- 埋点数据验证：字节中的局部存储会产生拜访埋点数据，通过荡涤这些埋点数据，能够剖析出局部场景的血统链路，以此来校验程序中血统产出的正确性。比方，HDFS 的埋点数据能够用来校验很多 Hive 相干链路的血统产出。
- 用户反馈：全量血统汇合的准确性验证是个浩瀚的过程，然而具体到某个用户的某个业务场景，问题就简化多了。实际操作中，咱们会与一些业务方深刻的单干，一起校验血统准确性，并修复问题。
02 – 覆盖率
定义：当至多有一条血统链路与资产相干时，称为资产被血统笼罩到了。被血统笼罩到的资产占关注资产的比例即为血统覆盖率。
血统覆盖率是比拟粗粒度的指标。作为准确率的补充，用户通过覆盖率能够晓得以后曾经反对的资产类型和工作类型，以及每种笼罩的范畴。
在外部，咱们定义覆盖率指标的目标有两个，一是圈定出咱们比拟关注的资产汇合，二是寻找零碎中缺失的整块的工作类型。
以 Hive 表为例，字节生产环境的 Hive 表曾经达到了几十万级别，其中有很大一部分，是不会被长期应用与关注的。计算血统覆盖率时，咱们会依据规定圈选出其中的局部，比方，过来 7 天有数据写入的，作为分母，在这之上，看血统覆盖率是多少。
当血统覆盖率低时，通常阐明咱们漏掉了某种工作类型或者圈选的资产范畴不合理。举个例子，在初期时，咱们发现 MQ 的血统覆盖率只有个位数，剖析后发现，咱们漏掉了以另外一种格局定义的流式数据集成工作。
03 – 时效性
定义：从工作产生批改，到最终反馈到血统存储系统的端到端延时。
对于一些用户场景来说，血统的时效性并没有特地重要，属于加分项，然而有一些场景是强依赖。不同工作类型的时效性会有差别。
数据开发畛域的影响剖析场景，是对血统实时性要求很高的场景之一。用户在圈定批改的影响范畴时，如果只能拉取到昨天为止的状态，是会产生重大业务事变的。
晋升时效性的瓶颈，通常不在血统服务方，而是工作管理系统是否能够近实时的将工作相干的批改，以告诉模式发送进去。
将来
文中论述的局部数据血统技术曾经通过火山引擎大数据研发治理套件 DataLeap 对外开放。
接下来，字节跳动数据平台在数据血统方面的工作，会次要集中在三个方向：
- 首先，是继续晋升血统的准确性。以后咱们的血统准确性曾经晋升到了可用的状态，然而仍然须要人工的校验与修复。如何继续稳固的晋升准确性，是摸索的重要方向。
- 其次，是血统的标准化建设。除了数据血统之外，利用级别的血统其实也很重要，在解决方案上，咱们心愿做到通用与规范。以后业务方会基于数据血统拼接一些本人业务畛域的链路，实现标准化后，这部分用例能够复用整套基础设施，定制产品层面的展示就好了。
- 最初，是增强对外部生态的反对。细分下来有两个方向，一是摸索通用的 SQL 类血统解析引擎，以后，新接入一种 SQL 类的引擎血统，老本是比拟高的；二是反对开源或私有云上产品的端到端血统。
相干产品
[火山引擎大数据研发治理套件 DataLeap
](https://www.volcengine.com/pr…)
一站式数据中台套件，帮忙用户疾速实现数据集成、开发、运维、治理、资产、平安等全套数据中台建设，帮忙数据团队无效的升高工作老本和数据保护老本、开掘数据价值、为企业决策提供数据撑持。
欢送关注字节跳动数据平台同名公众号
