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