更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【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 产品做了产品功能和技术调研。因各个系统都在频繁迭代，数据仅供参考。

升级思路

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

• 对于搜索、血缘这类核心能力，做深做强，对齐业界领先水平

• 对于各产品间特色功能，挑选适合字节业务特点的做融合

• 技术体系上，存储和模型能力基于 Apache Atlas 改造，应用层支持从旧版本平滑迁移

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