乐趣区

关于数据库:火山引擎-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 理解更多

退出移动版