关于数据库:火山引擎-DataLeap-套件下构建数据目录Data-Catalog系统的实践

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

摘要

Data Catalog 产品，通过汇总技术和业务元数据，解决大数据生产者组织梳理数据、数据消费者找数和了解数的业务场景，并服务于数据开发和数据治理的产品体系。本文介绍了火山引擎 DataLeap 套件下 Data Catalog 零碎的构建和迭代过程，概要介绍外围设计以及局部要害实现。

背景

元数据与 Data Catalog

元数据，个别指形容数据的数据，对数据及信息资源的描述性信息。在以后大数据的上下文里，通常又可细分为技术元数据和业务元数据。
Data Catalog，是一种元数据管理的服务，会收集技术元数据，并在其根底上提供更丰盛的业务上下文与语义，通常反对元数据编目、查找、详情浏览等性能。
元数据是 Data Catalog 零碎的根底，而 Data Catalog 使元数据更好的施展业务价值。

Data Catalog 的业务价值

火山引擎 DataLeap 套件下 Data Catalog 零碎次要服务于两类用户的两种外围场景。
对于数据生产者来说，他们利用 Data Catalog 零碎来组织、梳理本人负责的各类元数据。生产者大部分是大数据开发的同学。通常，生产者会将某一批相干的元数据以目录等模式编排到一起，不便保护。另外，生产者会继续的在技术元数据的根底上，丰盛业务相干的属性，比方打业务标签，增加利用场景形容，字段解释等。
对于数据消费者来说，他们通过 Data Catalog 查找和了解他们须要的数据。在用户数量和角色上看，消费者远多于生产者，涵盖了数据分析师、产品、经营等多种角色的同学。通常，消费者会通过关键字检索，或者目录浏览，来查找解决本人业务场景的数据，并浏览详情介绍，字段形容，产出关系等，进一步的了解和信赖数据。
另外，Data Catalog 零碎中的各类元数据，也会向上服务于数据开发、数据治理两大类产品体系。
在大数据畛域，各类计算和存储系统百花齐放，概念和原理又千差万别，对于元数据的采集、组织、了解、信赖等，都带来了很大挑战。因而，做好一个 Data Catalog 产品，自身是一个门槛低、下限高的工作，须要有一个继续打磨晋升的过程。

旧版本痛点

字节跳动 Data Catalog 产品晚期为能较快解决 Hive 的元数据收集与检索工作，是基于 LinkedIn Wherehows 进行二次革新。Wherehows 架构绝对简略，采纳 Backend + ETL 的模式。初期版本，次要利用 Wherehows 的存储设计和 ETL 框架，自研实现前后端的功能模块。
随着字节跳动业务的疾速倒退，公司内各类存储引擎一直引入，数据生产者和消费者的痛点都日益显著。之前零碎的设计问题，也到了须要解决的阶段。具体来说：

• 用户层面痛点：

  • 数据生产者: 多引擎环境下，没有便捷、敌对的数据组织模式，来一站式的治理各类存储、计算引擎的技术与业务元数据
  • 数据消费者: 各种引擎之间找数难，元数据的业务解释零散造成了解数难，难以信赖

• 技术痛点：

  • 扩展性：新接入一类元数据时，整套零碎伤筋动骨，开发成本月级别
  • 可维护性：通过一段时间的修修补补，整个零碎显的很软弱，研发人员不敢轻易改变；存储依赖重，同时应用了 MySQL、ElasticSearch、图数据库等零碎存储元数据，保护老本很高；接入一种元数据会减少 2~3 个 ETL 工作，运维老本直线回升

火山引擎 DataLeap 套件下构建数据目录（Data Catalog）零碎的实际
摘要
Data Catalog 产品，通过汇总技术和业务元数据，解决大数据生产者组织梳理数据、数据消费者找数和了解数的业务场景，并服务于数据开发和数据治理的产品体系。本文介绍了火山引擎 DataLeap 套件下 Data Catalog 零碎的构建和迭代过程，概要介绍外围设计以及局部要害实现。
背景
元数据与 Data Catalog
元数据，个别指形容数据的数据，对数据及信息资源的描述性信息。在以后大数据的上下文里，通常又可细分为技术元数据和业务元数据。
Data Catalog，是一种元数据管理的服务，会收集技术元数据，并在其根底上提供更丰盛的业务上下文与语义，通常反对元数据编目、查找、详情浏览等性能。
元数据是 Data Catalog 零碎的根底，而 Data Catalog 使元数据更好的施展业务价值。
Data Catalog 的业务价值
火山引擎 DataLeap 套件下 Data Catalog 零碎次要服务于两类用户的两种外围场景。
对于数据生产者来说，他们利用 Data Catalog 零碎来组织、梳理本人负责的各类元数据。生产者大部分是大数据开发的同学。通常，生产者会将某一批相干的元数据以目录等模式编排到一起，不便保护。另外，生产者会继续的在技术元数据的根底上，丰盛业务相干的属性，比方打业务标签，增加利用场景形容，字段解释等。
对于数据消费者来说，他们通过 Data Catalog 查找和了解他们须要的数据。在用户数量和角色上看，消费者远多于生产者，涵盖了数据分析师、产品、经营等多种角色的同学。通常，消费者会通过关键字检索，或者目录浏览，来查找解决本人业务场景的数据，并浏览详情介绍，字段形容，产出关系等，进一步的了解和信赖数据。
另外，Data Catalog 零碎中的各类元数据，也会向上服务于数据开发、数据治理两大类产品体系。
在大数据畛域，各类计算和存储系统百花齐放，概念和原理又千差万别，对于元数据的采集、组织、了解、信赖等，都带来了很大挑战。因而，做好一个 Data Catalog 产品，自身是一个门槛低、下限高的工作，须要有一个继续打磨晋升的过程。
旧版本痛点
字节跳动 Data Catalog 产品晚期为能较快解决 Hive 的元数据收集与检索工作，是基于 LinkedIn Wherehows 进行二次革新。Wherehows 架构绝对简略，采纳 Backend + ETL 的模式。初期版本，次要利用 Wherehows 的存储设计和 ETL 框架，自研实现前后端的功能模块。
随着字节跳动业务的疾速倒退，公司内各类存储引擎一直引入，数据生产者和消费者的痛点都日益显著。之前零碎的设计问题，也到了须要解决的阶段。具体来说：

• 用户层面痛点：

  • 数据生产者: 多引擎环境下，没有便捷、敌对的数据组织模式，来一站式的治理各类存储、计算引擎的技术与业务元数据
  • 数据消费者: 各种引擎之间找数难，元数据的业务解释零散造成了解数难，难以信赖

• 技术痛点：

  • 扩展性：新接入一类元数据时，整套零碎伤筋动骨，开发成本月级别

  • 可维护性：通过一段时间的修修补补，整个零碎显的很软弱，研发人员不敢轻易改变；存储依赖重，同时应用了 MySQL、ElasticSearch、图数据库等零碎存储元数据，保护老本很高；接入一种元数据会减少 2~3 个 ETL 工作，运维老本直线回升

    新版本指标

    基于上述痛点，火山引擎 DataLeap 研发人员从新设计实现 Data Catalog 零碎，心愿能达成如下指标：

• 产品能力上，帮忙数据生产者方便快捷组织元数据，数据消费者更好的找数和了解数

• 零碎能力上，将接入新型元数据的老本从月级别升高为星期甚至天级别，架构精简，单人业余时间可运维

  调研与思路

  业界产品调研

  站在伟人的肩膀上，入手之前火山引擎 DataLeap 研发人员针对业界支流 DataCatalog 产品做了产品性能和技术调研。因各个系统都在频繁迭代，数据仅供参考。

  降级思路

  依据调研论断，联合字节已有业务特点，火山引擎 DataLeap 研发人员敲定了以下倒退思路：

• 对于搜寻、血统这类外围能力，做深做强，对齐业界领先水平
• 对于各产品间特色性能，筛选适宜字节业务特点的做交融
• 技术体系上，存储和模型能力基于 Apache Atlas 革新，应用层反对从旧版本平滑迁徙

技术与产品概览

架构设计

元数据的接入

• 元数据接入反对 T + 1 和近实时两种形式
• 上游零碎：包含各类存储系统（比方 Hive、Clickhouse 等）和业务零碎（比方数据开发平台、数据品质平台等）

• 中间层：

  • ETL Bridge：T+ 1 形式运行，通常是从内部零碎拉取最新元数据，与以后 Catalog 零碎的元数据做比照，并更新差别的局部
  • MQ：用于暂存各类元数据增量音讯，供 Catalog 零碎近实时生产

  • 与上游零碎打交道的各类 Clients，封装了操作底层资源的能力

    外围服务层

    零碎的外围服务，依据职责的不同，细拆为以下子服务：

• Catalog Service：反对元数据的搜寻、详情、批改等外围服务
• Ingestion Service：承受内部零碎调用，写入元数据，或被动从 MQ 中生产增量元数据
• Resource Control Plane：通过各类 Clients，与底层的存储或业务零碎交互，操作底层资源，比方建库建表，能力可插拔
• Q&A Service：问答零碎相干能力，反对对元数据的字段含意、应用场景等发问和答复，能力可插拔
• ML Service：负责封装与机器学习相干的能力，能力可插拔

• API Layer：以 RESTful API 的模式整合系统中的各类能力

  存储层

  针对不同场景，选用的不同的存储：

• Meta Store：寄存全量元数据和血缘关系，以后应用的是 HBase
• Index Store：寄存用于减速查问，反对全文索引等场景的索引，以后应用的是 ElasticSearch

• Model Store：寄存举荐、打标等的算法模型信息，应用 HDFS，当 ML Service 启用时应用

  元数据的生产

• 数据的生产者和消费者，通过 Data Catalog 的前端与零碎交互
• 上游在线服务可通过 OpenAPI 拜访元数据，与零碎交互

• Metadata Outputs Layer：提供除了 API 之外的另外一种上游生产形式

  • MQ：用于暂存各类元数据变更音讯，格局由 Catalog 零碎官网定义
  • Data warehouse：以数仓表的模式出现的全量元数据

产品性能降级

产品能力上的降级迭代，大抵分为以下几个阶段：

• 根底能力建设（2017-2019）：数据源次要是离线数仓 Hive，反对了 Hive 相干库表创立、元数据搜寻与详情展现、表之间血统，以及将相干表组织成业务视角的数据专题等
• 中阶能力建设（2019-2020 年中）：数据源扩大了 Clickhouse 与 Kafka，反对了 Hive 列血统，Q&A 问答零碎等
• 架构降级（2020 年中 -2021 年初）：产品能力迭代放缓，基于新设计降级架构

• 能力晋升与疾速迭代（2021 年至今）：数据源扩大为蕴含离线、近实时、业务等端到端系统，搜寻和血统能力有明显增强，摸索机器学习能力，产品状态更成熟稳固。另外咱们还具备了 ToB 售卖的能力。

  关键技术

  构建一个好的 Data Catalog 零碎，须要思考的外围产品设计和技术设计有很多。篇幅所限，本文只概要介绍技术设计中最外围重要的局部，更多细节开展可参照后续的文章。

  数据模型对立

  将不同元数据的数据模型对立，是升高接入老本和保护老本的重要前提。零碎的数据模型，火山引擎 DataLeap 研发人员根本参照了 Apache Atlas 的设计与实现。一些基本概念简略介绍如下：

• 类型（Type）：形容一类元数据，由多个属性组成。例如，hive table 是一类元数据，hive_db 也是一类元数据。Type 可具备继承关系。按面向对象的编程思维，能够了解 type 为一个 Class。
• 实例（Entity）：代表一个 type 的具体事例。一个 entity 可能作为一个属性存在于另一个 entity 中，例如 hive_table 中的 db 属性，db 自身也是一个 entity。在面向对象的编程思维中，一个 entity 能够认为是一个 class 的 instance。
• 属性（Attribute）：属性的汇合组合而成为一个 Type。属性自身的类型（typeName）可能是一个自定义的 type，也可能是一种根底类型，包含 date，string 等。例如，db 是 hive_table 的一个属性，column 也是 hive_table 的一个属性。
• 关系（Relationship）：一种非凡的 Entity，用以形容两个 Entity 之间的关联模式。
  在理论利用这套类型零碎时，咱们有两个方面比拟有特点：
• 继承与组合的宽泛应用

  字节的业务场景十分复杂，为了充沛复用各种元数据类型之间的类似能力，又取得足够的定制灵活性，火山引擎 DataLeap 研发人员为每类元数据设计了父 Type。比方，Hive Table 和 Clickhouse Table，都含有名称、形容、字段等属性，他们都继承自 DataStore 这个父 Type。
  另外一种状况，有些类型的实体能够作用于多种其余的实体，比方一张 Hive 表和一堆被组织在一起的业务报表，都能够被用户珍藏或点赞。咱们将珍藏、点赞这些行为也形象为实体，并通过关系与 Hive 表、业务报表汇合等相关联。这种思维，相似编程中的组合或者是切面的概念。

• 调整类型加载机制
  在实践中咱们意识到，跟某种数据源相关联的能力，应该尽可能收敛到一起，这能够极大的升高后续的保护老本。对于一种元数据类型定义，也在这种思考的范畴之内。火山引擎 DataLeap 研发人员调整了 Apache Atlas 加载类型文件的机制，使其能够从多个 package，以咱们定义过的目录构造和先后顺序加载。这也为前面的标准化奠定了根底。

  数据接入标准化

  为了最终达成升高接入和保护老本的指标，对立了类型零碎之后，第二步就是接入流程的标准化。
  火山引擎 DataLeap 研发人员将某一种元数据类型的接入逻辑封装为一个 connector，并通过提供 SDK 的形式简化 connector 的编写老本。
  以应用最宽泛的 T +1 bridge 接入的 connector SDK 为例，咱们参照时下风行的 Flink 流式解决框架，联合 T +1 bridge 的业务特点，实现了如下模型：

• Source：从内部存储计算零碎等批量拉取最新的全量元数据。数据结构和字段通常由内部零碎决定。概念上可对齐 Flink 的 source operator。
• Diff Operator：接管 source 的输入，并从 Catalog Service 拉取以后零碎中的全量元数据，做差别比照，产出差别的局部。概念上对齐 Flink 中的某一种自定义的 ProcessFunction。
• Event Generate Operator：接管 Diff Operator 的输入，依据 Catalog 零碎定义好的格局，将差别的 metadata 转化成 event 格局，比方对于新建的 metadata，转换成 CreateEvent。概念上对齐 Flink 中的某一种自定义的 ProcessFunction。
• Sink：接管 Event Generate Operator 的输入，将差别的 metadata 写入 Ingestion Service。概念上对齐 Flink 的 sink operator。

• Bridge Job：组装 pipeline，做运行时管制。概念上对齐 Flink 的 Job。
  当须要接入新的元数据时，通常只须要从新编写 Source 和 Diff Operator，其余组件都是可间接复用的。标准化的 connector 极大的节俭接入和运维老本。

  搜寻优化

  搜寻是 Data Catalog 中，除了详情浏览外，最宽泛应用的性能，也是数据消费者找数最次要的伎俩。在火山引擎 DataLeap 零碎中，每天有 70% 以上的用户都会应用搜寻性能。
  搜寻是一个绝对成熟的技术畛域，针对元数据的检索能够看作是垂直畛域的搜索引擎。本节概要介绍在设计实现元数据搜索引擎时的播种，更多的细节开展，会有后续的文章。
  在理论场景中，火山引擎 DataLeap 研发人员发现公司内的元数据搜寻，与通用搜索引擎相比，有两个非常显著的特点：

• 搜寻中存在局部很强的 Pattern：用户搜寻元数据时，有一些隐式的习惯，通过开掘埋点中的固定 pattern，给了咱们针对性优化的机会。
• 行为数据规模无限：公司外部的元数据搜寻用户，通常是千级别，而每天搜寻的点击次数是万级别，这个规模远远小于对外的通用搜索引擎，也造成很多模型没法及时收敛，但也肯定水平上给与咱们简化问题的机会。

火山引擎 DataLeap 研发人员设计的元数据搜寻，架构如上图所示。粗略来看，能够划分为两大部分：

• 离线局部：负责会集各类与搜寻相干的数据，做数据荡涤或者模型训练，依据不同的用处，写入不同的存储，供应在线搜寻模块应用。
• 在线局部：分为搜寻了解、召回、精排三个次要阶段，步骤和概念上与通用搜索引擎对齐。
  针对下面剖析的特点，火山引擎 DataLeap 研发人员在搜寻优化时，有两个对应的策略：
• 对于强 Pattern，宽泛应用 Rule-Based 的优化伎俩：比方，火山引擎 DataLeap 研发人员发现很大一部分用户在搜寻 Hive 时，会应用“库名. 表名”的 pattern，在辨认到 query 语句中有“.”时，火山引擎 DataLeap 研发人员会优先尝试依据库名和表名检索
• 激进的个性化：因用户规模可控，且某位用户通常会频繁应用某个畛域的元数据，火山引擎 DataLeap 研发人员记录了很多用户的历史行为细节，当 query 语句与过来浏览过元数据有肯定文本相关性时，个性化相干的得分会有较大晋升

血统能力

血统能力是 Data Catalog 零碎的另外一个外围能力。自动化的，端到端的血统能力，是很多业界零碎声称的亮点性能。构建齐备的血统能力，既能够帮忙生产者梳理、组织他们负责的元数据，也能够帮忙数据消费者找数和了解数据的上下文。
字节十分关注数据价值，业务也简单，对咱们数据血统链路的建设也提出了很高的要求。本节只概要介绍火山引擎 DataLeap 研发人员搭建血统链路时思考的外围问题，更多细节能够参照之前的文章：字节跳动外部的数据血统用例与设计。
首先，数据血统的零碎边界是：从 RDS 和 MQ 开始，一路路径各种计算和存储，最终汇入指标、报表和数据服务零碎。
其次，在设计零碎时，火山引擎 DataLeap 研发人员充分考虑了血统链路的多样性和复杂性。如下图所示，火山引擎 DataLeap 研发人员通过 T + 1 和近实时的形式，获取各类工作零碎中的信息，依据工作类型，调用不同的解析服务，将格式化过的血统数据写入 Data Catalog 零碎，供应上游的 API 调用或者 MQ、离线数仓生产。

最初，在血统品质掂量上，火山引擎 DataLeap 研发人员通过定义无效的血统准确率、覆盖率和时效性，来确保血统信息的精确、全面和实时性。
以后，咱们的血统能力曾经广泛应用于字节的数据资产、数据开发和数据治理等畛域。

存储层优化

最初，在血统品质掂量上，火山引擎 DataLeap 研发人员通过定义无效的血统准确率、覆盖率和时效性，来确保血统信息的精确、全面和实时性。
以后，咱们的血统能力曾经广泛应用于字节的数据资产、数据开发和数据治理等畛域。
存储层优化

读优化：开启 MutilPreFetch 能力

在咱们的图库中，存在很多超级点，也就是关系非常宏大的元数据。举两种状况，一是列非常多的大宽表，对于一些机器学习的表，甚至会超过 1 万列；另外一种状况是被宽泛援用的底表，比方埋点底表的一级血统上游就超过了 1 万。在读取这类数据时，咱们发现性能极差。
与关系型数据库慢查问优化相似，咱们通过监控埋点收集到慢查问语句，借助 gremlin 的 profile 函数，剖析 query plan 中的问题，并通过构建索引或者改写语句与配置等，做相应的优化。
开启 JanusGraph 的 MutilPreFetch 查问开关，是其中一种状况。该个性的大抵实现原理是，在属性过滤的时候, 批量并行获取所有关联顶点的属性，再在内存做属性过滤，而未开启该个性时，则会找到对端的顶点后, 每个顶点独自去获取属性再做过滤条件。

须要留神的是，该机制在触发优化时的前置条件

Janusgraph 0.4 版本以上且配置关上
语句中不蕴含 limit
语句中蕴含 has
查问后果行数不超过 cache.tx-cache-size 值

写优化：去除 Guid 全局唯一性查看

对于超大元数据的写入申请，也有比较严重的性能问题。比方超过 3000 列的写入，火山引擎 DataLeap 研发人员发现须要耗费靠近 15 分钟。通过模仿单个超大表写入，并应用 arthas 火焰图跟踪相干代码，火山引擎 DataLeap 研发人员发现在每个 JanusGraph 图顶点写入时，都会做 guid 的全局唯一性校验，这里非常耗时。

通过剖析，火山引擎 DataLeap 研发人员发现 guid 在全局上默认是惟一的，没有必要做这个唯一性查看，同时，咱们定义了业务语义上全局惟一的 qualifiedName，以此缩小不必要的唯一性反复查看。配合其余的优化，咱们在一次写入大量节点时，节俭不少开销，最终性能大抵如下:

将来工作

文中论述的局部 Data Catalog 技术和产品性能曾经通过火山引擎大数据研发治理套件 DataLeap 对外开放。
接下来，火山引擎 DataLeap 研发人员晋升 Data Catalog 零碎，会次要集中在以下几个方面：
首先，是将元数据往数据资产转化。以后，团队收集了丰盛的技术类元数据和一部分业务类元数据，如何将各类元数据，与实在的业务场景关联，将没有间接业务价值的元数据转化为有间接业务价值的数据资产，是团队正在摸索的方向。
其次，是更宽泛的利用智能能力。Data Catalog 中有很多能够落地的智能化场景，比方搜寻举荐，主动打标等，团队曾经做了一些根底的尝试，接下来会进行更宽泛的推广。
最初，凋谢能力的搭建。在元数据接入方面，团队筹备将其封装成产品能力，提供相似 connector 市场的性能，便于在 ToB 市场做更麻利的单干与推广；另外打算与开源和商用的麻利报表等做更好的买通，能够将零碎能力展示在各类报表零碎里。

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