共计 1768 个字符，预计需要花费 5 分钟才能阅读完成。
更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【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 理解更多