数据目录

数据目录功能

• 与各种数据源相连接： 连接公司拥有的多种数据源（如：HDFS\MySQL\Hbase…），并且可以定时的监测新生成的数据。

• 检索筛选能力：数据集名称、标签、描述、字段相关信息、问答内容、数据规格详情等。

• 数据描述：据集的名称、标签、负责人以及存储详情的变动趋势；以及数据的条数空值等统计信息

• 协作能力：主要体现在数据集相关问题的处理上面。使用数据集时遇到的问题可以在系统中提问，问题会自动转向数据集负责人，数据集负责人需要在系统中答复。所有问题和回答应该以时间线的方式组织，方便其他数据集使用人员的查阅和检索。

• 简化合规、权限管理工作： 数据目录应通过分析数据资产、推断它们与特定规则的相关性、以及自动分类和标记它们以供将来参考来简化合规工作。

• 支持可以确保可信数据的质量和治理： 数据目录应与您现有的任何质量和治理程序和工具无缝集成，包括数据质量规则、业务术语表和工作流。

字节数据目录架构

1）元数据的接入：T+1和近实时两种方式

• 上游系统：包括各类存储系统（比如Hive、 Clickhouse等）和业务系统（比如数据开发平台、数据质量平台等）

• 中间层：
• ETL Bridge：T+1方式运行，通常是从外部系统拉取最新元数据，与当前Catalog系统的元数据做对比，并更新差异的部分
ETL 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。
• MQ：用于暂存各类元数据增量消息，供Catalog系统近实时消费与上游系统打交道的各类Clients，封装了操作底层资源的能力

2）核心服务层系统的核心服务

• Catalog Service：支持元数据的搜索、详情、修改等核心服务
搜索优化
在实际场景中，元数据搜索与通用搜索引擎相比，有两个十分显著的特点：
• 搜索中存在部分很强的Pattern：用户搜索元数据时，有一些隐式的习惯，通过挖掘埋点中的固定pattern，给了我们针对性优化的机会。
• 行为数据规模有限：公司内部的元数据搜索用户，通常是千级别，而每天搜索的点击次数是万级别，这个规模远远小于对外的通用搜索引擎，也造成很多模型没法及时收敛，

• 离线部分：负责汇集各类与搜索相关的数据，做数据清洗或者模型训练，根据不同的用途，写入不同的存储，供给在线搜索模块使用。
• 在线部分：分为搜索理解、召回、精排三个主要阶段，步骤和概念上与通用搜索引擎对齐。针对上面分析的特点，我们在搜索优化时，有两个对应的策略：
• 对于强Pattern，广泛使用Rule-Based的优化手段：比如，我们发现很大一部分用户在搜索Hive时，会使用“库名.表名”的pattern，在识别到query语句中有“.”时，我们会优先尝试根据库名和表名检索
• 激进的个性化：因用户规模可控，且某位用户通常会频繁使用某个领域的元数据，我们记录了很多用户的历史行为细节，当query语句与过去浏览过元数据有一定文本相关性时，个性化相关的得分会有较大提升

• Ingestion Service：接受外部系统调用，写入元数据，或主动从MQ中消费增量元数据

• Resource Control Plane：通过各类Clients，与底层的存储或业务系统交互，操作底层资源，比如建库建表，能力可插拔。

• Q&A Service：问答系统相关能力，支持对元数据的字段含义、使用场景等提问和回答，能力可插拔

• ML Service：负责封装与机器学习相关的能力，能力可插拔

• API Layer：以RESTful API的形式整合系统中的各类能力

3）存储层针对不同场景，选用的不同的存储：

• Meta Store：存放全量元数据和血缘关系，当前使用的是HBase
血缘能力
我们通过T+1和近实时的方式，获取各类任务系统中的信息，根据任务类型，调用不同的解析服务，将格式化过的血缘数据写入Data Catalog系统，供给下游的API调用或者MQ、离线数仓消费。

最后，在血缘质量衡量上，我们通过定义有效的血缘准确率、覆盖率和时效性
存储优化
在存储层，我们借用了Atlas的设计与实现。Atlas的底层使用JanusGraph做图引擎。当我们将越来越多的元数据接入系统，图存储中的点和边分别到达百万和千万量级，读写性能都遇到了比较大的问题。我们做了部分源码的修改，这边介绍其中比较重要的两个
1. 读优化：开启MutilPreFetch 能力在我们的图库中，存在很多超级点，也就是关系十分庞大的元数据。在读取这类数据时，我们发现性能极差，我们通过监控埋点收集到慢查询语句，借助gremlin的profile函数，分析query plan中的问题，并通过构建索引或者改写语句与配置等，做相应的优化。
2. 写优化：去除Guid全局唯一性检查对于超大元数据的写入请求，也有比较严重的性能问题。比如超过3000列的写入，我们发现需要消耗接近15分钟。通过模拟单个超大表写入，并使用arthas火焰图跟踪相关代码， 我们发现在每个JanusGraph图顶点写入时，都会做guid的全局唯一性校验，这里十分耗时。然而，没有必要做这个唯一性检查。

• Index Store：存放用于加速查询，支持全文索引等场景的索引，当前使用的是ElasticSearch

• Model Store：存放推荐、打标等的算法模型信息，使用HDFS，当ML Service启用时使用（4）元数据的消费

• 数据的生产者和消费者，通过Data Catalog的前端与系统交互

• 下游在线服务可通过OpenAPI访问元数据，与系统交互

• Metadata Outputs Layer：提供除了API之外的另外一种下游消费方式
• MQ：用于暂存各类元数据变更消息，格式由Catalog系统官方定义
• Data warehouse：以数仓表的形式呈现的全量元数据