火山引擎 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系统,希望能达成如下目标:

  • 产品能力上,帮助数据生产者方便快捷组织元数据,数据消费者更好的找数和理解数
  • 系统能力上,将接入新型元数据的成本从月级别降低为星期甚至天级别,架构精简,单人业余时间可运维
调研与思路

业界产品调研

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

产品分类产品名称支持元数据种类重要产品功能机器学习能力获取信息途径特点分析
独角兽C**40+搜索、血缘、标签、评价与打分、认证、问答、Connector市场等demo和文档功能丰富,成熟度高,产品设计上有诸多可借鉴之处
A**60+搜索、血缘、标签、问答、Connector市场等demo和文档功能较丰富,成熟度较高,产品能力可做参考
开源A** A**10+搜索、血缘、标签等源码和文档离线相关数据源支持较好,类型系统和存储系统设计巧妙,但产品侧能力弱。近期迭代较缓慢
L** D**40+搜索、血缘、标签、统计大盘等源码和文档发展较快,背后商业化公司支持力度大,有在线demo环境可随时体验,功能简单直接
商业化A** P**30+搜索、血缘、标签、统计大盘等产品体验和文档功能较简单,与其公有云结合紧密,部分功能有借鉴意义

升级思路

根据调研结论,结合字节已有业务特点,火山引擎 DataLeap 研发人员敲定了以下发展思路:

  • 对于搜索、血缘这类核心能力,做深做强,对齐业界领先水平
  • 对于各产品间特色功能,挑选适合字节业务特点的做融合
  • 技术体系上,存储和模型能力基于Apache Atlas改造,应用层支持从旧版本平滑迁移
技术与产品概览

架构设计

picture.image

元数据的接入

  • 元数据接入支持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:以数仓表的形式呈现的全量元数据

产品功能升级

picture.image

产品能力上的升级迭代,大致分为以下几个阶段:

  • 基础能力建设(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之间的关联模式。

在实际应用这套类型系统时,我们有两个方面比较有特点:

  1. 继承与组合的广泛使用

picture.image

字节的业务场景十分复杂,为了充分复用各种元数据类型之间的相似能力,又获得足够的定制灵活性,火山引擎 DataLeap 研发人员为每类元数据设计了父Type。比如,Hive Table和Clickhouse Table,都含有名称、描述、字段等属性,他们都继承自DataStore这个父Type。

另外一种情况,有些类型的实体可以作用于多种其他的实体,比如一张Hive表和一堆被组织在一起的业务报表,都可以被用户收藏或点赞。我们将收藏、点赞这些行为也抽象为实体,并通过关系与Hive表、业务报表集合等相关联。这种思想,类似编程中的组合或者是切面的概念。

  1. 调整类型加载机制

在实践中我们意识到,跟某种数据源相关联的能力,应该尽可能收敛到一起,这可以极大的降低后续的维护成本。对于一种元数据类型定义,也在这种考虑的范围之内。火山引擎 DataLeap 研发人员调整了Apache Atlas加载类型文件的机制,使其可以从多个package,以我们定义过的目录结构和先后顺序加载。这也为后面的标准化奠定了基础。

数据接入标准化

为了最终达成降低接入和维护成本的目标,统一了类型系统之后,第二步就是接入流程的标准化。

火山引擎 DataLeap 研发人员将某一种元数据类型的接入逻辑封装为一个connector,并通过提供SDK的方式简化connector的编写成本。

以使用最广泛的T+1 bridge接入的connector SDK为例,我们参照时下流行的Flink流式处理框架,结合T+1 bridge的业务特点,实现了如下模型:

picture.image

  • 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,给了我们针对性优化的机会。
  • 行为数据规模有限:公司内部的元数据搜索用户,通常是千级别,而每天搜索的点击次数是万级别,这个规模远远小于对外的通用搜索引擎,也造成很多模型没法及时收敛,但也一定程度上给与我们简化问题的机会。

picture.image

火山引擎 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、离线数仓消费。

picture.image

最后,在血缘质量衡量上,火山引擎 DataLeap 研发人员通过定义有效的血缘准确率、覆盖率和时效性,来确保血缘信息的准确、全面和实时性。

当前,我们的血缘能力已经广泛应用于字节的数据资产、数据开发和数据治理等领域。

存储层优化

如前面介绍,在存储层,火山引擎 DataLeap 研发人员借用了Atlas的设计与实现。Atlas的底层使用JanusGraph做图引擎。JanusGraph 是基于Gremlin 图查询语义实现的计算引擎,其底层存储支持HBase/Cassadra/BerkeleyDB等KCV结构的存储,同时,使用ElasticSearch作为索引查询支持。

当火山引擎 DataLeap 研发人员将越来越多的元数据接入系统,图存储中的点和边分别到达百万和千万量级,读写性能都遇到了比较大的问题。我们做了部分源码的修改,这边介绍其中比较重要的两个,更多细节请参照后续的文章。

读优化:开启MutilPreFetch 能力

在我们的图库中,存在很多超级点,也就是关系十分庞大的元数据。举两种情况,一是列十分多的大宽表,对于一些机器学习的表,甚至会超过1万列;另外一种情况是被广泛引用的底表,比如埋点底表的一级血缘下游就超过了1万。在读取这类数据时,我们发现性能极差。

与关系型数据库慢查询优化类似,我们通过监控埋点收集到慢查询语句,借助gremlin的profile函数,分析query plan中的问题,并通过构建索引或者改写语句与配置等,做相应的优化。

开启JanusGraph的MutilPreFetch查询开关,是其中一种情况。该特性的大致实现原理是,在属性过滤的时候, 批量并行获取所有关联顶点的属性,再在内存做属性过滤,而未开启该特性时,则会找到对端的顶点后,每个顶点单独去获取属性再做过滤条件。

picture.image

需要注意的是,该机制在触发优化时的前置条件

Janusgraph 0.4版本以上且配置打开

语句中不包含limit

语句中包含has

查询结果行数不超过cache.tx-cache-size值

写优化:去除Guid全局唯一性检查

对于超大元数据的写入请求,也有比较严重的性能问题。比如超过3000列的写入,火山引擎 DataLeap 研发人员发现需要消耗接近15分钟。

通过模拟单个超大表写入,并使用arthas火焰图跟踪相关代码, 火山引擎 DataLeap 研发人员发现在每个JanusGraph图顶点写入时,都会做guid的全局唯一性校验,这里十分耗时。

picture.image

通过分析,火山引擎 DataLeap 研发人员发现guid在全局上默认是唯一的,没有必要做这个唯一性检查,同时,我们定义了业务语义上全局唯一的qualifiedName,以此减少不必要的唯一性重复检查。

配合其他的优化,我们在一次写入大量节点时,节省不少开销,最终性能大致如下:

优化前优化后
小表(10列以内)1~2s<100ms
中表(100-500列)3-5min2~5s
超大表(3000列以上)15min以上,经常写入失败0.5~1min,可写入
未来工作

文中阐述的部分Data Catalog技术和产品功能已经通过 火山引擎 大数据研发治理 套件 DataLeap 对外开放

接下来,火山引擎 DataLeap 研发人员提升Data Catalog系统,会主要集中在以下几个方面:

首先,是将元数据往数据资产转化。当前,团队收集了丰富的技术类元数据和一部分业务类元数据,如何将各类元数据,与真实的业务场景关联,将没有直接业务价值的元数据转化为有直接业务价值的数据资产,是团队正在探索的方向。

其次,是更广泛的应用智能能力。Data Catalog中有很多可以落地的智能化场景,比如搜索推荐,自动打标等,团队已经做了一些基础的尝试,接下来会进行更广泛的推广。

最后,开放能力的搭建。在元数据接入方面,团队准备将其封装成产品能力,提供类似connector市场的功能,便于在ToB市场做更敏捷的合作与推广;另外计划与开源和商用的敏捷报表等做更好的打通,可以将系统能力展现在各类报表系统里。

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

224
0
0
0
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论