作为数据目录产品，Data Catalog 通过汇总技术和业务元数据，解决大数据生产者组织梳理数据、数据消费者找数和了解数的业务场景，并服务于数据开发和数据治理的产品体系。本文介绍了字节跳动Data Catalog零碎的构建和迭代过程，将分为上、下篇公布。上篇次要围绕Data Catalog调研思路及技术架构开展。

一、背景

1. 元数据与Data Catalog
元数据，个别指形容数据的数据，对数据及信息资源的描述性信息。在以后大数据的上下文里，通常又可细分为技术元数据和业务元数据。
Data Catalog，是一种元数据管理的服务，会收集技术元数据，并在其根底上提供更丰盛的业务上下文与语义，通常反对元数据编目、查找、详情浏览等性能。
元数据是Data Catalog零碎的根底，而Data Catalog使元数据更好的施展业务价值。
2. Data Catalog的业务价值
Data Catalog零碎次要服务于两类用户的两种外围场景。
对于数据生产者来说，他们利用Data Catalog零碎来组织、梳理本人负责的各类元数据。生产者大部分是大数据开发的同学。通常，生产者会将某一批相干的元数据以目录等模式编排到一起，不便保护。另外，生产者会继续的在技术元数据的根底上，丰盛业务相干的属性，比方打业务标签，增加利用场景形容，字段解释等。
对于数据消费者来说，他们通过Data Catalog查找和了解他们须要的数据。在用户数量和角色上看，消费者远多于生产者，涵盖了数据分析师、产品、经营等多种角色的同学。通常，消费者会通过关键字检索，或者目录浏览，来查找解决本人业务场景的数据，并浏览详情介绍，字段形容，产出关系等，进一步的了解和信赖数据。
另外，Data Catalog零碎中的各类元数据，也会向上服务于数据开发、数据治理两大类产品体系。
在大数据畛域，各类计算和存储系统百花齐放，概念和原理又千差万别，对于元数据的采集、组织、了解、信赖等，都带来了很大挑战。因而，做好一个Data Catalog产品，自身是一个门槛低、下限高的工作，须要有一个继续打磨晋升的过程。
3. 旧版本痛点
字节跳动Data Catalog产品晚期为能较快解决Hive的元数据收集与检索工作，是基于LinkedIn Wherehows进行二次革新 。Wherehows架构绝对简略，采纳Backend + ETL的模式。初期版本，次要利用Wherehows的存储设计和ETL框架，自研实现前后端的功能模块。
随着字节跳动业务的疾速倒退， 公司内各类存储引擎一直引入，数据生产者和消费者的痛点都日益显著。之前零碎的设计问题，也到了须要解决的阶段。具体来说：

  • 用户层面痛点：
    数据生产者: 多引擎环境下，没有便捷、敌对的数据组织模式，来一站式的治理各类存储、计算引擎的技术与业务元数据。
    数据消费者: 各种引擎之间找数难，元数据的业务解释零散造成了解数难，难以信赖。
  • 技术痛点：
    扩展性：新接入一类元数据时，整套零碎伤筋动骨，开发成本月级别。
    可维护性：通过一段时间的修修补补，整个零碎显的很软弱，研发人员不敢轻易改变；存储依赖重，同时应用了MySQL、ElasticSearch、图数据库等零碎存储元数据，保护老本很高；接入一种元数据会减少2~3个ETL工作，运维老本直线回升。
    4. 新版本指标
    基于上述痛点，咱们从新设计实现Data Catalog零碎，心愿能达成如下指标：
  • 产品能力上，帮忙数据生产者方便快捷组织元数据，数据消费者更好的找数和了解数。
  • 零碎能力上，将接入新型元数据的老本从月级别升高为星期甚至天级别，架构精简，单人业余时间可运维。

二、 调研与思路

1. 业界产品调研
站在伟人的肩膀上，入手之前咱们针对业界支流DataCatalog产品做了产品性能和技术调研。因各个系统都在频繁迭代，数据仅供参考。

2. 降级思路
依据调研论断，联合字节已有业务特点，咱们敲定了以下倒退思路：
对于搜寻、血统这类外围能力，做深做强，对齐业界领先水平。
对于各产品间特色性能，筛选适宜字节业务特点的做交融。
技术体系上，存储和模型能力基于Apache Atlas革新，应用层反对从旧版本平滑迁徙。

三、技术与产品概览

1. 架构设计

（1）元数据的接入

  • 元数据接入反对T+1和近实时两种形式
  • 上游零碎：包含各类存储系统（比方Hive、 Clickhouse等）和业务零碎（比方数据开发平台、数据品质平台等）
  • 中间层：
    ETL Bridge：T+1形式运行，通常是从内部零碎拉取最新元数据，与以后Catalog零碎的元数据做比照，并更新差别的局部
    MQ：用于暂存各类元数据增量音讯，供Catalog零碎近实时生产
    与上游零碎打交道的各类Clients，封装了操作底层资源的能力
    （2）外围服务层
    零碎的外围服务，依据职责的不同，细拆为以下子服务：
  • Catalog Service：反对元数据的搜寻、详情、批改等外围服务
  • Ingestion Service：承受内部零碎调用，写入元数据，或被动从MQ中生产增量元数据
  • Resource Control Plane：通过各类Clients，与底层的存储或业务零碎交互，操作底层资源，比方建库建表，能力可插拔
  • Q&A Service：问答零碎相干能力，反对对元数据的字段含意、应用场景等发问和答复，能力可插拔
  • ML Service：负责封装与机器学习相干的能力，能力可插拔
  • API Layer：以RESTful API的模式整合系统中的各类能力
    （3）存储层
    针对不同场景，选用的不同的存储：
  • Meta Store：寄存全量元数据和血缘关系，以后应用的是HBase
  • Index Store：寄存用于减速查问，反对全文索引等场景的索引，以后应用的是ElasticSearch
  • Model Store：寄存举荐、打标等的算法模型信息，应用HDFS，当ML Service启用时应用
    （4）元数据的生产
  • 数据的生产者和消费者，通过Data Catalog的前端与零碎交互
  • 上游在线服务可通过OpenAPI拜访元数据，与零碎交互
  • Metadata Outputs Layer：提供除了API之外的另外一种上游生产形式
    MQ：用于暂存各类元数据变更音讯，格局由Catalog零碎官网定义
    Data warehouse：以数仓表的模式出现的全量元数据
    2. 产品性能降级

    产品能力上的降级迭代，大抵分为以下几个阶段：
  • 根底能力建设（2017-2019）：数据源次要是离线数仓Hive，反对了Hive相干库表创立、元数据搜寻与详情展现、表之间血统，以及将相干表组织成业务视角的数据专题等
  • 中阶能力建设（2019-2020年中）：数据源扩大了Clickhouse与Kafka，反对了Hive列血统，Q&A问答零碎等
  • 架构降级（2020年中-2021年初）：产品能力迭代放缓，基于新设计降级架构
  • 能力晋升与疾速迭代（2021年至今）：数据源扩大为蕴含离线、近实时、业务等端到端系统，搜寻和血统能力有明显增强，摸索机器学习能力，产品状态更成熟稳固。另外咱们还具备了ToB售卖的能力。

四、关联产品

火山引擎大数据研发治理套件DataLeap
一站式数据中台套件，帮忙用户疾速实现数据集成、开发、运维、治理、资产、平安等全套数据中台建设，帮忙数据团队无效的升高工作老本和数据保护老本、开掘数据价值、为企业决策提供数据撑持。

欢送关注字节跳动数据平台同名公众号获取更多技术干货