干货 | 字节跳动构建Data Catalog数据目录系统的实践(上)

作为数据目录产品,Data Catalog 通过汇总技术和业务元数据,解决大数据生产者组织梳理数据、数据消费者找数和理解数的业务场景,并服务于数据开发和数据治理的产品体系。本文介绍了字节跳动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 – 架构设计

    干货 | 字节跳动构建Data Catalog数据目录系统的实践(上)

    元数据的接入

    • 元数据接入支持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 – 产品功能升级

      干货 | 字节跳动构建Data Catalog数据目录系统的实践(上)

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

      • 基础能力建设(2017-2019):数据源主要是离线数仓Hive,支持了Hive相关库表创建、元数据搜索与详情展示、表之间血缘,以及将相关表组织成业务视角的数据专题等

      • 中阶能力建设(2019-2020年中):数据源扩展了Clickhouse与Kafka,支持了Hive列血缘,Q&A问答系统等

      • 架构升级(2020年中-2021年初):产品能力迭代放缓,基于新设计升级架构

      • 能力提升与快速迭代(2021年至今):数据源扩展为包含离线、近实时、业务等端到端系统,搜索和血缘能力有明显增强,探索机器学习能力,产品形态更成熟稳定。另外我们还具备了ToB售卖的能力。

      在下篇中,重点介绍Data Catalog关键技术和未来规划,敬请期待。

      – End –
      0 0 投票数
      文章评分

      本文转载自开发套件团队,原文链接:https://mp.weixin.qq.com/s/XoZvyU0ME6HS8VpT_1qv3A。

      (0)
      上一篇 2022-05-07 16:13
      下一篇 2022-05-08 15:09

      相关推荐

      订阅评论
      提醒
      guest
      1 评论
      最旧
      最新 最多投票
      内联反馈
      查看所有评论
      trackback
      4 月 前

      […] Catalog系统的构建和迭代过程,将分为上、下篇发布。上篇围绕Data Catalog调研思路及技术架构展开。下篇重点介绍Data […]

      1
      0
      希望看到您的想法,请您发表评论x