作为数据目录产品，Data Catalog 通过汇总技术和业务元数据，解决大数据生产者组织梳理数据、数据消费者找数和理解数的业务场景，并服务于数据开发和数据治理的产品体系。 本文介绍了字节跳动Data Catalog系统的构建和迭代过程，将分为上、下篇发布。 上篇主要围绕Data Catalog调研思路及技术架构展开。
文 | 邱艺朴、 大滨 来自字节跳动数据平台开发套件团队
DataLeap
背景
01 - 元数据与Data Catalog
元数据，一般指描述数据的数据，对数据及信息资源的描述性信息。在当前大数据的上下文里，通常又可细分为技术元数据和业务元数据。
Data Catalog，是一种元数据管理的服务，会收集技术元数据，并在其基础上提供更丰富的业务上下文与语义，通常支持元数据编目、查找、详情浏览等功能。
元数据是Data Catalog系统的基础，而Data Catalog使元数据更好的发挥业务价值。
02 - Data Catalog的业务价值
Data Catalog系统主要服务于两类用户的两种核心场景。
对于数据生产者来说，他们利用Data Catalog系统来组织、梳理自己负责的各类元数据。生产者大部分是大数据开发的同学。通常，生产者会将某一批相关的元数据以目录等形式编排到一起，方便维护。另外，生产者会持续在技术元数据的基础上，丰富业务相关的属性，比如打业务标签，添加应用场景描述，字段解释等。
对于数据消费者来说，他们通过Data Catalog查找和理解他们需要的数据。在用户数量和角色上看，消费者远多于生产者，涵盖了数据分析师、产品、运营等多种角色的同学。通常，消费者会通过关键字检索，或者目录浏览，来查找解决自己业务场景的数据，并浏览详情介绍，字段描述，产出关系等，进一步的理解和信任数据。
另外，Data Catalog系统中的各类元数据，也会向上服务于数据开发、数据治理两大类产品体系。
在大数据领域，各类计算和存储系统百花齐放，概念和原理又千差万别，对于元数据的采集、组织、理解、信任等，都带来了很大挑战。因此，做好一个Data Catalog产品，本身是一个门槛低、上限高的工作，需要有一个持续打磨提升的过程。
03 - 旧版本痛点
字节跳动Data Catalog产品早期为了能较快解决Hive的元数据收集与检索工作，是基于LinkedIn Wherehows进行二次改造 。Wherehows架构相对简单，采用Backend + ETL的模式。初期版本，主要利用Wherehows的存储设计和ETL框架，自研实现前后端的功能模块。
随着字节跳动业务的快速发展， 公司内各类存储引擎不断引入，数据生产者和消费者的痛点都日益明显。之前系统的设计问题，也到了需要解决的阶段。具体来说：
- 用户层面痛点：
- 数据生产者: 多引擎环境下，没有便捷、友好的数据组织形式，来一站式的管理各类存储、计算引擎的技术与业务元数据。
- 数据消费者: 各种引擎之间找数难，元数据的业务解释零散造成理解数难，难以信任。
- 技术痛点：
- 扩展性：新接入一类元数据时，整套系统伤筋动骨，开发成本月级别。
- 可维护性：经过一段时间的修修补补，整个系统显得很脆弱，研发人员不敢随便改动；存储依赖重，同时使用了MySQL、ElasticSearch、图数据库等系统存储元数据，维护成本很高；接入一种元数据会增加2~3个ETL任务，运维成本直线上升。
04 - 新版本目标
基于上述痛点，我们重新设计实现Data Catalog系统，希望能达成如下目标：
- 产品能力上，帮助数据生产者方便快捷组织元数据，数据消费者更好的找数和理解数。
- 系统能力上，将接入新型元数据的成本从月级别降低为星期甚至天级别，架构精简，单人业余时间可运维。
DataLeap
01 - 业界产品调研
站在巨人的肩膀上，动手之前我们针对业界主流DataCatalog产品做了产品功能和技术调研。因各个系统都在频繁迭代，数据仅供参考。
| 产品分类 | 产品名称 | 支持元数据种类 | 重要产品功能 | 机器学习能力 | | 独角兽 | C** | 40+ | 搜索、血缘、标签、评价与打分、认证、问答、Connector市场等 | 有 | | A** | 60+ | 搜索、血缘、标签、问答、Connector市场等 | 有 | | 开源 | A** A** | 10+ | 搜索、血缘、标签等 | 无 | | L** D** | 40+ | 搜索、血缘、标签、统计大盘等 | 无 | | 商业化 | A** P** | 30+ | 搜索、血缘、标签、统计大盘等 | 无 |
02 - 升级思路
根据调研结论，结合字节已有业务特点，我们敲定了以下发展思路：
- 对于搜索、血缘这类核心能力，做深做强，对齐业界领先水平。
- 对于各产品间特色功能，挑选适合字节业务特点的做融合。
- 技术体系上，存储和模型能力基于Apache Atlas改造，应用层支持从旧版本平滑迁移。
DataLeap
01 - 架构设计
元数据的接入
- 元数据接入支持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：以数仓表的形式呈现的全量元数据
02 - 产品功能升级
产品能力上的升级迭代，大致分为以下几个阶段：
- 基础能力建设（2017-2019）：数据源主要是离线数仓Hive，支持了Hive相关库表创建、元数据搜索与详情展示、表之间血缘，以及将相关表组织成业务视角的数据专题等
- 中阶能力建设（2019-2020年中）：数据源扩展了Clickhouse与Kafka，支持了Hive列血缘，Q&A问答系统等
- 架构升级（2020年中-2021年初）：产品能力迭代放缓，基于新设计升级架构
- 能力提升与快速迭代（2021年至今）：数据源扩展为包含离线、近实时、业务等端到端系统，搜索和血缘能力有明显增强，探索机器学习能力，产品形态更成熟稳定。另外我们还具备了ToB售卖的能力。
在下篇中，重点介绍Data Catalog关键技术和未来规划，敬请期待。
开发套件团队正在招人，
点击 阅读原文
了解
产品介绍
火山引擎大数据研发治理套件DataLeap
一站式数据中台套件，帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设，帮助数据团队有效的降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。 后台回复数字“2”了解产品
- End -
