更多技术交流、求职机会,欢迎关注字节跳动数据平台微信公众号,回复【1】进入官方交流群

关键技术

构建一个好的Data Catalog系统,需要考虑的核心产品设计和技术设计有很多。篇幅所限,本文只概要介绍技术设计中最核心重要的部分,更多细节展开可参照后续的文章。

数据模型统一

将不同元数据的数据模型统一,是降低接入成本和维护成本的重要前提。系统的数据模型,火山引擎 DataLeap 研发人员基本参照了Apache Atlas的设计与实现。一些基本概念简单介绍如下:
  • 类型(Type):描述一类元数据,由多个属性组成。例如,hive table是一类元数据,hive_db也是一类元数据。Type可具备继承关系。按面向对象的编程思想,可以理解type为一个Class。
  • 实例(Entity):代表一个type的具体事例。一个entity可能作为一个属性存在于另一个entity中,例如hive_table中的db属性,db本身也是一个entity。在面向对象的编程思想中,一个entity可以认为是一个class的instance。
  • 属性(Attribute):属性的集合组合而成为一个Type。属性本身的类型(typeName)可能是一个自定义的type,也可能是一种基础类型,包括date,string等。例如,db是hive_table的一个属性,column也是hive_table的一个属性。
  • 关系(Relationship):一种特殊的Entity,用以描述两个Entity之间的关联模式。
在实际应用这套类型系统时,我们有两个方面比较有特点:
  1. 继承与组合的广泛使用

字节的业务场景十分复杂,为了充分复用各种元数据类型之间的相似能力,又获得足够的定制灵活性,火山引擎 DataLeap 研发人员为每类元数据设计了父Type。比如,Hive Table和Clickhouse Table,都含有名称、描述、字段等属性,他们都继承自DataStore这个父Type。
另外一种情况,有些类型的实体可以作用于多种其他的实体,比如一张Hive表和一堆被组织在一起的业务报表,都可以被用户收藏或点赞。我们将收藏、点赞这些行为也抽象为实体,并通过关系与Hive表、业务报表集合等相关联。这种思想,类似编程中的组合或者是切面的概念。
  1. 调整类型加载机制
在实践中我们意识到,跟某种数据源相关联的能力,应该尽可能收敛到一起,这可以极大的降低后续的维护成本。对于一种元数据类型定义,也在这种考虑的范围之内。火山引擎 DataLeap 研发人员调整了Apache Atlas加载类型文件的机制,使其可以从多个package,以我们定义过的目录结构和先后顺序加载。这也为后面的标准化奠定了基础。

数据接入标准化

为了最终达成降低接入和维护成本的目标,统一了类型系统之后,第二步就是接入流程的标准化。
火山引擎 DataLeap 研发人员将某一种元数据类型的接入逻辑封装为一个connector,并通过提供SDK的方式简化connector的编写成本。
以使用最广泛的T+1 bridge接入的connector SDK为例,我们参照时下流行的Flink流式处理框架,结合T+1 bridge的业务特点,实现了如下模型:

  • Source:从外部存储计算系统等批量拉取最新的全量元数据。数据结构和字段通常由外部系统决定。概念上可对齐Flink的source operator。
  • Diff Operator:接收source的输出,并从Catalog Service拉取当前系统中的全量元数据,做差异对比,产出差异的部分。概念上对齐Flink中的某一种自定义的ProcessFunction。
  • Event Generate Operator:接收Diff Operator的输出,根据Catalog系统定义好的格式,将差异的metadata转化成event格式,比如对于新建的metadata,转换成CreateEvent。概念上对齐Flink中的某一种自定义的ProcessFunction。
  • Sink:接收Event Generate Operator的输出,将差异的metadata写入Ingestion Service。概念上对齐Flink的sink operator。
  • Bridge Job:组装pipeline,做运行时控制。概念上对齐Flink的Job。
当需要接入新的元数据时,通常只需要重新编写Source和Diff Operator,其他组件都是可直接复用的。标准化的connector极大的节省接入和运维成本。

搜索优化

搜索是Data Catalog中,除了详情浏览外,最广泛使用的功能,也是数据消费者找数最主要的手段。在火山引擎 DataLeap 系统中,每天有70%以上的用户都会使用搜索功能。
搜索是一个相对成熟的技术领域,针对元数据的检索可以看作是垂直领域的搜索引擎。本节概要介绍在设计实现元数据搜索引擎时的收获,更多的细节展开,会有后续的文章。
在实际场景中,火山引擎 DataLeap 研发人员发现公司内的元数据搜索,与通用搜索引擎相比,有两个十分显著的特点:
  • 搜索中存在部分很强的Pattern:用户搜索元数据时,有一些隐式的习惯,通过挖掘埋点中的固定pattern,给了我们针对性优化的机会。
  • 行为数据规模有限:公司内部的元数据搜索用户,通常是千级别,而每天搜索的点击次数是万级别,这个规模远远小于对外的通用搜索引擎,也造成很多模型没法及时收敛,但也一定程度上给与我们简化问题的机会。
火山引擎 DataLeap 研发人员设计的元数据搜索,架构如上图所示。粗略来看,可以划分为两大部分:
  • 离线部分:负责汇集各类与搜索相关的数据,做数据清洗或者模型训练,根据不同的用途,写入不同的存储,供给在线搜索模块使用。
  • 在线部分:分为搜索理解、召回、精排三个主要阶段,步骤和概念上与通用搜索引擎对齐。
针对上面分析的特点,火山引擎 DataLeap 研发人员在搜索优化时,有两个对应的策略:
  • 对于强Pattern,广泛使用Rule-Based的优化手段:比如,火山引擎 DataLeap 研发人员发现很大一部分用户在搜索Hive时,会使用“库名.表名”的pattern,在识别到query语句中有“.”时,火山引擎 DataLeap 研发人员会优先尝试根据库名和表名检索
  • 激进的个性化:因用户规模可控,且某位用户通常会频繁使用某个领域的元数据,火山引擎 DataLeap 研发人员记录了很多用户的历史行为细节,当query语句与过去浏览过元数据有一定文本相关性时,个性化相关的得分会有较大提升

血缘能力

血缘能力是Data Catalog系统的另外一个核心能力。自动化的,端到端的血缘能力,是很多业界系统宣称的亮点功能。构建完备的血缘能力,既可以帮助生产者梳理、组织他们负责的元数据,也可以帮助数据消费者找数和理解数据的上下文。
字节非常关注数据价值,业务也复杂,对我们数据血缘链路的建设也提出了很高的要求。本节只概要介绍火山引擎 DataLeap 研发人员搭建血缘链路时考虑的核心问题,更多细节可以参照之前的文章:字节跳动内部的数据血缘用例与设计
首先,数据血缘的系统边界是:从RDS和MQ开始,一路途径各种计算和存储,最终汇入指标、报表和数据服务系统。
其次,在设计系统时,火山引擎 DataLeap 研发人员充分考虑了血缘链路的多样性和复杂性。如下图所示,火山引擎 DataLeap 研发人员通过T+1和近实时的方式,获取各类任务系统中的信息,根据任务类型,调用不同的解析服务,将格式化过的血缘数据写入Data Catalog系统,供给下游的API调用或者MQ、离线数仓消费。

最后,在血缘质量衡量上,火山引擎 DataLeap 研发人员通过定义有效的血缘准确率、覆盖率和时效性,来确保血缘信息的准确、全面和实时性。
当前,我们的血缘能力已经广泛应用于字节的数据资产、数据开发和数据治理等领域。

存储层优化

如前面介绍,在存储层,火山引擎 DataLeap 研发人员借用了Atlas的设计与实现。Atlas的底层使用JanusGraph做图引擎。JanusGraph 是基于Gremlin 图查询语义实现的计算引擎,其底层存储支持HBase/Cassadra/BerkeleyDB等KCV结构的存储,同时,使用ElasticSearch作为索引查询支持。
当火山引擎 DataLeap 研发人员将越来越多的元数据接入系统,图存储中的点和边分别到达百万和千万量级,读写性能都遇到了比较大的问题。我们做了部分源码的修改,这边介绍其中比较重要的两个,更多细节请参照后续的文章。

读优化:开启MutilPreFetch 能力

在我们的图库中,存在很多超级点,也就是关系十分庞大的元数据。举两种情况,一是列十分多的大宽表,对于一些机器学习的表,甚至会超过1万列;另外一种情况是被广泛引用的底表,比如埋点底表的一级血缘下游就超过了1万。在读取这类数据时,我们发现性能极差。
与关系型数据库慢查询优化类似,我们通过监控埋点收集到慢查询语句,借助gremlin的profile函数,分析query plan中的问题,并通过构建索引或者改写语句与配置等,做相应的优化。
开启JanusGraph的MutilPreFetch查询开关,是其中一种情况。该特性的大致实现原理是,在属性过滤的时候, 批量并行获取所有关联顶点的属性,再在内存做属性过滤,而未开启该特性时,则会找到对端的顶点后,每个顶点单独去获取属性再做过滤条件。
需要注意的是,该机制在触发优化时的前置条件
Janusgraph 0.4版本以上且配置打开
语句中不包含limit
语句中包含has
查询结果行数不超过cache.tx-cache-size值

写优化:去除Guid全局唯一性检查

对于超大元数据的写入请求,也有比较严重的性能问题。比如超过3000列的写入,火山引擎 DataLeap 研发人员发现需要消耗接近15分钟。
通过模拟单个超大表写入,并使用arthas火焰图跟踪相关代码, 火山引擎 DataLeap 研发人员发现在每个JanusGraph图顶点写入时,都会做guid的全局唯一性校验,这里十分耗时。
通过分析,火山引擎 DataLeap 研发人员发现guid在全局上默认是唯一的,没有必要做这个唯一性检查,同时,我们定义了业务语义上全局唯一的qualifiedName,以此减少不必要的唯一性重复检查。
配合其他的优化,我们在一次写入大量节点时,节省不少开销,最终性能大致如下:
 
优化前
优化后
小表(10列以内)
1~2s
<100ms
中表(100-500列)
3-5min
2~5s
超大表(3000列以上)
15min以上,经常写入失败
0.5~1min,可写入

未来工作

文中阐述的部分Data Catalog技术和产品功能已经通过火山引擎大数据研发治理套件 DataLeap 对外开放
接下来,火山引擎 DataLeap 研发人员提升Data Catalog系统,会主要集中在以下几个方面:
首先,是将元数据往数据资产转化。当前,我们收集了丰富的技术类元数据和一部分业务类元数据,如何将各类元数据,与真实的业务场景关联,将没有直接业务价值的元数据转化为有直接业务价值的数据资产,是我们正在探索的方向。
其次,是更广泛的应用智能能力。Data Catalog中有很多可以落地的智能化场景,比如搜索推荐,自动打标等,我们已经做了一些基础的尝试,接下来会进行更广泛的推广。
最后,开放能力的搭建。在元数据接入方面,我们准备将其封装成产品能力,提供类似connector市场的功能,便于在ToB市场做更敏捷的合作与推广;另外计划与开源和商用的敏捷报表等做更好的打通,可以将系统能力展现在各类报表系统里。
 
点击跳转大数据研发治理套件 DataLeap了解更多

火山引擎 DataLeap 构建Data Catalog系统的实践(三):关键技术与总结的更多相关文章

  1. 火山引擎 DataLeap 的 Data Catalog 系统公有云实践

      Data Catalog 通过汇总技术和业务元数据,解决大数据生产者组织梳理数据.数据消费者找数和理解数的业务场景.本篇内容源自于火山引擎大数据研发治理套件 DataLeap 中的 Data Ca ...

  2. 如何又快又好实现 Catalog 系统搜索能力?火山引擎 DataLeap 这样做

      摘要 DataLeap 是火山引擎数智平台 VeDI 旗下的大数据研发治理套件产品,帮助用户快速完成数据集成.开发.运维.治理.资产.安全等全套数据中台建设,降低工作成本和数据维护成本.挖掘数据价 ...

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

    作为数据目录产品,Data Catalog 通过汇总技术和业务元数据,解决大数据生产者组织梳理数据.数据消费者找数和理解数的业务场景,并服务于数据开发和数据治理的产品体系.本文介绍了字节跳动 Data ...

  4. 火山引擎 DataLeap:3 个关键步骤,复制字节跳动一站式数据治理经验

    更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,并进入官方交流群 DataLeap 是火山引擎数智平台 VeDI 旗下的大数据研发治理套件产品,帮助用户快速完成数据集成.开发.运维.治理. ...

  5. 火山引擎 DataLeap:揭秘字节跳动数据血缘架构演进之路

    更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群 DataLeap 是火山引擎数智平台 VeDI 旗下的大数据研发治理套件产品,帮助用户快速完成数据集成.开发.运维 ...

  6. 火山引擎 DataLeap:一家企业,数据体系要怎么搭建?

    更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群 导读:经过十多年的发展,数据治理在传统行业以及新兴互联网公司都已经产生落地实践.字节跳动也在探索一种分布式的数据治 ...

  7. 火山引擎DataLeap数据调度实例的 DAG 优化方案

    更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,并进入官方交流群 实例 DAG 介绍 DataLeap 是火山引擎自研的一站式大数据中台解决方案,集数据集成.开发.运维.治理.资产管理能力 ...

  8. 以字节跳动内部 Data Catalog 架构升级为例聊业务系统的性能优化

    背景 字节跳动 Data Catalog 产品早期,是基于 LinkedIn Wherehows 进行二次改造,产品早期只支持 Hive 一种数据源.后续为了支持业务发展,做了很多修修补补的工作,系统 ...

  9. 使用 Kafka 和 Spark Streaming 构建实时数据处理系统

    使用 Kafka 和 Spark Streaming 构建实时数据处理系统 来源:https://www.ibm.com/developerworks,这篇文章转载自微信里文章,正好解决了我项目中的技 ...

  10. 基于MRS-ClickHouse构建用户画像系统方案介绍

    业务场景 用户画像是对用户信息的标签化.用户画像系统通过对收集的各维度数据,进行深度的分析和挖掘,给不同的用户打上不同的标签,从而刻画出客户的全貌.通过用户画像系统,可以对各个用户进行精准定位,从而将 ...

随机推荐

  1. JavsScript对密码进行Base64加密和Base64解密

    const password = "hello"; // 进行Base64加密 let pwd64 = window.btoa(password); console.log(pwd ...

  2. 微信支付:wxpay.unifiedOrder(data)返回appid 与 openId 不配

    原因:小程序和APP.公众号等支付方式夸端口调用支付,后台配置多个appId时 A程序中的openid 在B程序中支付.即使用A程序的openid和B程序的appIdy去调用wxpay.unified ...

  3. 龙芯发布 .NET 8 SDK 8.0.100-rc2 LoongArch64

    随着.NET 8的发布的临近,国内的社区朋友们也很关心龙芯.NET 团队对于Loongarch .NET 8的发布时间,目前从龙芯.NET编译器团队的可靠信息,Loongarch .NET 8的发布会 ...

  4. Miniconda安装及搭建

    Miniconda安装配置 下载Miniconda Miniconda下载地址 最新版 Miniconda For Windows 下载链接 Windows 安装配置 修改Powershell执行策略 ...

  5. Ubuntu环境下C++使用onnxruntime和Opencv进行YOLOv8模型部署

    目录 环境配置 系统环境 项目文件路径 文件环境 config.txt CMakeLists.txt type.names 读取config.txt配置文件 修改图片尺寸格式 读取缺陷标志文件 生成缺 ...

  6. C/C++ 运用Npcap发送UDP数据包

    Npcap 是一个功能强大的开源网络抓包库,它是 WinPcap 的一个分支,并提供了一些增强和改进.特别适用于在 Windows 环境下进行网络流量捕获和分析.除了支持通常的网络抓包功能外,Npca ...

  7. 三菱PLC 轻松数采

    目前市面上数采的软件有很多,但是用的最为省力最为简单的就是kepserver了,在kepserver的应用中,有对应的三菱驱动针对于三菱PLC,三菱驱动支持多个Mitsubishi 协议,包括 MEL ...

  8. cookie和session的区别?一文讲透

    一.问题 cookie和session的区别? 二.回答 1.总结如下- cookie: - cookie存储于客户端本地,即浏览器缓存 - cookie存储着sessionId,作为后台sessio ...

  9. MCU看门狗使用注意事项

    前言 最近因为项目产品硬件设计有问题,导致设计的一款产品把硬件电源开关以及硬件系统复位功能去掉了.更严重的是,这产品已经开始生产了,硬件已经无法修改,所以软件必须上看门狗,否则设备死机或是异常后就只能 ...

  10. 企业ERP和泛微OA集成场景分析

    轻易云数据集成平台(qeasy.cloud)为企业ERP和泛微OA系统提供了强大的互通解决方案,特别在销售.采购和库存领域的单据审批场景中表现出色.这些场景涉及到多个业务单据的创建和审批,以下是一些具 ...