关于大数据:火山引擎DataLeap数据血缘技术建设实践

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群

DataLeap 是火山引擎数智平台 VeDI 旗下的大数据研发治理套件产品，帮忙用户疾速实现数据集成、开发、运维、治理、资产、平安等全套数据中台建设，升高工作老本和数据保护老本、开掘数据价值、为企业决策提供数据撑持。

数据血统是帮忙用户找数据、了解数据以及使数据施展价值的根底能力。本文将聚焦数据血统存储和血统导出，分享数据血统的模型设计以及优化，并 介绍字节跳动在数据血统建设过程中所遇到的挑战和技术实现以及数据血统的具体用例，具体包含数据血统模型、数据血统优化、数据血统用例、将来瞻望四个局部。 本文介绍的数据血统能力和实际，目前大部分已通过火山引擎 DataLeap 对外提供服务。

▌教训一：数据血统模型的分层架构

1. 挑战

首先介绍一下字节外部数据血统遇到的挑战。

随着公司业务扩张、用户数量持续增长以及数仓建设不断完善，元数据品种和数量也经验了非线性增长，并在此期间涌现出一些问题。

第一，扩展性。好的扩展性能够在面对新型元数据血统时保障疾速接入和迭代，而扩展性不佳则会导致在业务变动时须要不停地重构来适应业务，对业务造成很多影响。

第二，性能。一个模型自身的插入和更新效率会间接影响数据的导入导出的流程，这些都会带来更直观的业务上的感触，所以须要思考如何保障环节高效性。

第三，时效性。很多利用场景对正确率分外敏感，如果血统数据有提早，其实就等于血统的不精确，会对业务造成影响。

最初，赋能业务。技术服务于业务，业务增长会帮忙技术升级迭代，技术创新也会促成业务倒退。在字节外部，咱们会依据业务特点，思考业务须要，将技术老本与业务收益做均衡，最终做出数据模型决策。总而言之，数据模型没有完满的计划，只有最适宜企业本身业务、适宜以后阶段的数据血统计划。

2. 数据血统模型 - 展现层

字节外部有很多种元数据类型，包含线上传统的离线数仓 Hive、OLAP 剖析引擎 ClickHouse，以及实时侧元数据，如 Kafka 和 ES 以及 Redis。这些元数据所对应的表 /Topic 都对立保护在元数据平台上，目前血统展现层是以这些数据资产作为主视角。

如下图所示，核心数据资产蕴含一般字段和分区字段等信息，还能够从图中看到核心资产上下游资产信息。图中资产和资产之间连贯的边，代表的是生产关系：1 个工作读取了上游的资产，产生了上游的资产。

3. 数据血统模型 - 形象层

接下来介绍，火山引擎 DataLeap 如何设计形象层。

形象层是整个数据血统的数据模型，次要蕴含两种节点，一种是资产节点，另外一种是工作节点。

在图中，资产节点用圆形示意，工作节点用菱形示意。具体举个例子：

• 一个 FlinkSQL 工作生产了 Kafka 的 topic，而后写入到一个 Hive 的表里，那么 Kafka 的 topic 和 hive 表就是表资产节点，而 FlinkSQL 生产工作就是两头的工作节点。
• 一个 Kafka 的 topic 外面可能会定义本人的 schema，包含多个字段，例如 schema 里蕴含字段 a、b、c，通过 FlinkSQL 工作，比方一个 SQL：insert into hiveTable select a，b，c from kafka Topic，通过进行这样的解决，字段 a、b、c 和这个 hive 的字段 d 就产生了血缘关系。
• 创立子工作的节点，把几个字段节点连接起来，每个子工作节点会和子工作节点通过从属关系的边来进行连贯，字段节点和每一个表资产节点也会通过从属关系的边进行连贯。自身这个工作和资产之间会有生产生产关系的边连贯。

以上就是整个血统数据模型在形象层的展示。

这样设计有以下益处：

首先，工作资产的形象是对生产平台上和在各种工作平台上宽泛间接的工作关系的形象，当再去接入新元数据或新工作类型时，咱们只须要扩大以后形象的资产节点和工作节点，即可把新退出进来的工作链路所对应的血统接入到存储中。这种数据模型也能不便地更新和删除血统链路，维持时效性。

其次，在字节外部的血统建设中，还存在接入各种血统链路的难点。基于目前设计能够缩小开发成本，在更新血统的时只须要更新核心工作节点，并且把核心工作节点所对应的子工作节点的边也做相应的更新和删除，就实现了血统信息的插入和更新。

4. 数据血统模型 - 实现层

在实现层，火山引擎 DataLeap 次要基于 Apache Atlas 来实现。Apache Atlas 自身也是一个数据治理的产品，它预约义了一些元数据的类型，整个类型零碎有比拟好的扩展性。在 Atlas 自身的 DataSet 和 Process 元数据定义上，咱们引入了字节外部独有的业务元数据的属性和子工作定义，最终把工作相干的元数据存储起来。

Atlas 自身也反对血统的查问能力，通过 Apache Atlas 裸露的接口来转换成图上查找某个节点对应血缘关系的边，以此实现血统查问。

5. 数据血统模型 - 存储层

在存储层，目前次要基于 Apache Atlas 原生图数据库——JanusGraph。JanusGraph 底层反对 HBase。咱们将每条边的关系作为两边的资产节点的属性，存入到对应 RowKey 的独立 cell 中。

另外，咱们也对存储做了相干的革新，如字节外部自研的存算拆散 key-value 存储。咱们也在独立环境中会做轻量级部署，同时基于性能或老本，以及部署复杂度，把存储切换为 OLTP 数据库，比方 MYSQL 数据库。

以上就是整个数据血统模型的设计局部。通过这样的数据血统模型，咱们能够缩小新的数据血统链路接入开发成本，同时也很不便更新和删除血统。

▌教训二：三个数据血统优化方向

第二局部将次要介绍在火山引擎 DataLeap 中典型的数据血统优化，包含实时数据血统更新优化、血统查问优化和血统数据开放式导出。

1. 实时数据血统优化

首先，实时数据血统的更新。字节外部当初数据血统的更新形式是通过 T + 1 的链路和实时链路来更新。因为外部有很多场景对时效性的要求特地高，如果数据血统更新不太及时，就会影响血统准确率，甚至影响业务应用。

在数据血统的架构设计之初就曾经反对了 T + 1 的导入，不过时效性始终是按天为周期的。

• 数据血统工作周期性的拉取所有在运行工作的配置信息，调用平台的 API 拉取对应工作相干的配置或者 SQL
• 对于 SQL 类型的工作会调用另外一个解析引擎服务提供的解析能力来去解析数据血统的信息
• 再和元数据平台注销的资产信息相匹配，最初构建出一个工作资产节点的上下游，把这个工作资产节点和表资产节点之间的边更新到图数据库中去。

在实时更新的时候，咱们有两种计划：

计划一：是在引擎侧，即在工作运行时，通过工作执行引擎把该工作在构建 DAG 后生成的血统信息通过 Hook 送入。

• 长处：在引擎侧的血统采集是绝对独立的，每个引擎在采集血统的时候不会相互影响。

• 毛病：

  • 每个引擎都须要适配一个血统采集的 Hook，一些中小企业在引擎侧都可能面临的一个问题是同一个引擎可能在线上运行会有多个版本，那么适配的老本就会比拟高，须要每个版本都适配一次。
  • Hook 还有肯定的侵入性，会对自身的作业有肯定的累赘。

计划二：在工作开发的平台上把这个工作变更的音讯送出，当工作的生命周期变动的时候，通过 Hook 音讯把工作状态变更音讯通过调用 API 进行注销或者发送到 MQ 进行解耦，血统服务收到这份告诉之后，再被动调用解析服务来更新这个工作血统。

• 长处：扩展性好，不会受到引擎侧限度，将来要接入新的引擎时，只须要在这个工作平台下来创立对应的工作，把这个工作变更的音讯送出，就能够失去这个血统更新的告诉，而后去更新血统。
• 毛病：对血统解析服务平台会有肯定的革新老本，工作间的音讯可能会相互影响

综合比拟，咱们采纳了第二种计划，并且引入了 MQ 进一步的升高工作平台和血统平台的耦合，这种做法可能就义了局部的提早，然而会让整个链路变得更加牢靠，最终减低了血统这边整体的提早，工夫周期从天减低到了分钟级别。

以上就是咱们在血统时效性上的优化。

2. 数据查问优化

第二个优化点是查问。目前字节数据血统查问依赖 Apache Atlas。在应用该血统查问服务时，有一个很广泛的场景，就是多节点查问的场景。在影响剖析的过程中，咱们常常会查问一张表的全副字段血统，会转化成查问多个节点的血统上下游关系，须要解决查问效率的问题。

有两种根本的解决方案：

一种是间接在应用层进行封装，对 Apache Atlas 血统服务的裸露层新增一个接口，比方通过循环遍历去执行单个查问，这样革新的内容是很少的，然而其实性能并没有晋升，而且实现比拟暴力。

另外一种形式是革新 Apache Atlas 血统服务对图库查问的调用。因为 Atlas 应用 JanusGraph 作为底层的实现，提供了一部分的形象，然而只裸露了单节点的查问，而没有批量查问的办法，咱们还须要适配 JanusGraph 这边批量查问的接口，才能够达到提速的成果。

所以咱们在图数据库的操作入口减少了一个新的批量查问的办法，通过这种形式对血统节点进行批量查问，来进一步晋升性能。同时 Atlas 在查问血统节点回来之后，须要进行一个映射，映射到具体的实体下来拿回它的一些属性，在这个过程中咱们也退出了异步批量的操作形式来进一步的晋升性能。通过优化之后，咱们在对一些援用热度比拟高的表资产节点或者查问表资产或者对应列的时候，效率都能够失去显著晋升。

3. 血统数据开放式导出

第三个优化点是在血统的导出上提供了多种形式，除了在页面上可视化的查问血统的能力之上，咱们也陆续提供了很多应用血统的形式，包含下载到 Excel 或者查问这个血统数据导出的数仓表，或者间接应用服务平台侧凋谢的 API，还能够订阅血统变更的 topic，来间接监听血统的变更，上游的用户能够依据本人的开发场景，以及业务对准确率、覆盖率的要求，来决定到底应用哪种形式来生产血统数据。

▌教训三：四大数据血统用例解析

接下来第三局部次要介绍数据血统的具体用例，介绍字节外部是如何应用数据血统的。在字节外部数据血统用例的典型应用畛域次要包含：资产畛域、开发畛域、治理畛域和平安畛域。

1. 数据血统用例 – 资产畛域

首先在资产畛域，数据血统次要利用在资产热度的计算。在资产热度计算时，有些资产会被频繁生产和宽泛援用。某个资产被泛滥上游援用，是其本身权威性的体现，而这种权威性的证实须要一种定量的度量，因而须要引入“资产热度”的概念。资产热度自身是参考网页排名算法 PageRank 算法实现的，同时咱们也提供了资产热度值，依据资产的上游血统依赖的状况，定义了资产援用的热度值，如果某个资产援用热度值越高，就代表了这个资产更应该被信赖，数据更牢靠。

另外，血统也能够帮忙咱们了解数据。比方用户在元数据平台或者血统平台上查问数据资产节点的时候，可能是想要进行下一步的作业开发或者是排查一些问题，那么他就须要首先找到这个数据资产。用户不理解数据产生的过程，就无奈理解数据的过来和将来。也就是哲学上经典的问题：这个表到底是怎么来的？它具体有哪些含意？咱们就能够通过数据血统来找到具体表的上下游信息。

2. 数据血统用例 – 开发畛域

数据血统的第二个用例是开发畛域。在开发畛域中会有两个利用：影响剖析 和归因剖析。

1. 影响剖析利用

影响剖析即事先剖析，指当表资产产生变更时，可能事先感知影响。血统上游的资产负责人在批改对应的生产工作时，须要通过血统查看资产上游，由此判断资产批改产生的影响，从而针对批改的兼容性或者某条链路的重要性，实现告诉等操作，否则会因为短少告诉而造成重大的生产事变。

2. 归因剖析利用

归因剖析利用是预先剖析。比方当某个工作所产生的表呈现了问题，咱们就能够通过查问血统的上游，逐级寻找到血统上游改变的工作节点或者资产节点来排查出造成问题的根因是什么。在发现和定位出了问题之后，咱们会去修复数据，在修复数据的时候，咱们能够通过血统来查找工作或者表的依赖关系，对于离线数仓可能就须要重跑某个分区的输入数据，咱们须要依据血统来划定范畴，只须要回溯对应受影响的上游工作就能够了，缩小一些不必要的资源节约。

3. 数据血统用例 – 治理畛域

在治理畛域利用中，血缘关系在字节外部也有典型的应用场景：链路状态追踪 和数仓治理。

1. 链路状态追踪

比方在重要的节日或者流动的时候，咱们须要当时筛选一些须要重要保障的工作，这时就须要通过血缘关系来梳理出链路的骨干，即外围链路。而后去对应的做重点的治理和保障，比方签订 SLA。

2. 数仓治理

数据血统也会用来辅助数仓建设，如规范化治理。数仓规范化治理包含清理数仓分层不合理的援用、数仓分层不标准、冗余表等。例如，来自同一个上游表，但属于不同层级的两个表，属于冗余，将通过数据血统辅助清理。

4. 数据血统用例 – 平安畛域

平安相干问题在一些跨国企业或国际化产品会比拟常见，每个国家地区的平安政策是不一样的。咱们在做平安合规查看时，每个资产都有对应的资产安全等级，这个资产安全等级会有肯定的规定，比方咱们规定上游资产的安全等级肯定要高于上游的平安资产等级，否则就会有权限泄露问题或者是其余的平安问题。基于血统，咱们能够扫描到这些规定波及的资产上游，来配置相应扫描规定，而后进行平安合规排查，以便做出对应的治理。

另外，血统在标签流传方面也有所利用，能够通过血统的流传链路来进行自动化工作，比方对资产进行平安标签打标的时候，人工的打标形式会绝对比拟繁琐而且须要关注链路的信息，那么就能够借助血统信息来实现主动的打标，比方配置一些规定让平安标签明确场景、节点和终止规定。

以上这些都是数据血统在字节外部的一些典型用例，咱们也在摸索更多的应用场景。

依据其对血统品质的要求，这些场景被分成了几个区域。依据血统覆盖率、血统准确率的要求，能够分为四个象限，比方其中一类是须要笼罩全链路且血统准确率要求异样高的，例如开发项的两个用例，因为在开发项的用例中，血统的提早会重大影响决策上的判断，对血统品质要求是最高的。

血统建设过程也会划分不同的建设期间，咱们能够依据当初要反对的业务场景和业务优先级来辅助制订血统建设布局，决定血统迭代的节奏和具体方向。

▌将来瞻望

1. 数据血统技术趋势

在业界，血统的发展趋势次要关注以下几点：

通用的血统解析能力

血统是元数据平台的外围能力，很多时候元数据平台会接入多样化元数据，这些业务元数据也会依赖血统不同的血统解析能力，当初的解析往往是依赖各个引擎团队来反对的，然而其实在更加宽泛的场景，咱们须要有一个兜底的计划来提供一个更通用的血统解析能力，所以将来咱们会提供规范 SQL 解析引擎，以达到通用解析的目标。

非侵入式的非 SQL 类型血统采集

除了可解析的 SQL 或可配置的工作，日常还会波及到代码类型的工作，如 JAR 工作。JAR 工作当初的解析形式是依据一些埋点信息或者用户录入的上下游信息去实现血统的收集，这部分将来会呈现一种非侵入式的非 SQL 类型血统采集的技术，比方 Flink 或者 Spark 的 JAR 工作，咱们能够在工作运行时拿到这些血统，来丰盛平台侧血统的数据。

时序血统

时序血统也是字节外部的思考点。目前血统信息图数据库相当于是对以后血统拓扑的一次快照，其实血统是会变动的，比方用户在批改一个工作的时候，上线工作变更或是批改表构造，而后对应的批改本人生产工作，这里波及到时序的概念，这个时序能够不便咱们去追溯一些工作的变动，反对咱们去做事前事后影响剖析，所以时序血统如何在图数据库中引入也是将来的一个趋势。

2. 数据血统的利用趋势

标准化

前文提到很多利用场景的底层能力都是通过接口来取得，取得接口的数据也波及到利用的标准化，标准化的利用能够让咱们移植到更多的业务上，提供更好的血统数据分析帮忙。

端到端的血统买通

另一个利用趋势是端到端的血统能力，当初平台次要接入资产节点，端到端则会波及到更上游，如 App 端和 Web 端采集的数据，或者是上游报表，以及 API 之后最终的节点。在血统收集中，这部分信息目前缺失，端到端血统买通将是将来利用上的趋势之一。

3. 云上的全链路血统能力

在字节跳动外部，血统能力会进行上云，云上波及各类数据类型，因而血统倒退方向之一是把各类异构数据类型对立接入，并且反对云上用户来自定义接入新类型血统。

同时，当数据利用标准化之后，也能够把血统利用提供给云上用户，云上用户也能够反向退出到血统利用的开发中，最初把数据血统模型作为一种规范来推广，由此衍生出更好的血统利用、血统服务生态。

本文介绍的数据血统能力和实际，目前大部分已通过火山引擎 DataLeap 对外提供服务，欢送大家点击浏览原文体验。

点击跳转大数据研发治理套件 DataLeap 理解更多