关于大数据:火山引擎-DataLeap-的-Data-Catalog-系统公有云实践

Data Catalog 通过汇总技术和业务元数据，解决大数据生产者组织梳理数据、数据消费者找数和了解数的业务场景。本篇内容源自于火山引擎大数据研发治理套件 DataLeap 中的 Data Catalog 功能模块的实际，次要介绍 Data Catalog 在私有云部署和公布中遇到挑战及解决方案。

背景

• Data Catalog 是一种元数据管理的服务，会收集技术元数据，并在其根底上提供更丰盛的业务上下文与语义，通常反对元数据编目、查找、详情浏览等性能。目前 Data Catalog 作为火山引擎大数据研发治理套件 DataLeap 产品的外围性能之一，通过多年打磨，服务于字节跳动外部简直所有外围业务线，解决了数据生产者和消费者对于元数据和资产治理的各项外围需要。
• DataLeap 作为一站式数据中台套件，会集了字节外部多年积攒的数据集成、开发、运维、治理、资产、平安等全套数据中台建设的教训，助力 ToB 市场客户晋升数据研发治理效率、升高治理老本。
• Data Catalog 作为 DataLeap 的外围性能之一，本文会集了 Data Catalog 团队在最近一年私有云从 0 到 1 实际的整体教训，次要解说遇到的各项挑战和对应的解决方案。

Data Catalog 私有云倒退历程

Data Catalog 曾经随着 DataLeap 一起作为私有云产品正式在火山引擎对外公布，上面是 Data Catalog 在性能演进上的一些重要工夫节点：

• 2021 年 9 月，Data Catalog 随着 DataLeap 实现在火山引擎私有云首个版本部署和公布，蕴含 60% 外部外围性能，反对 EMR Hive 数据源元数据管理。
• 2022 年 2 月，Data Catalog 随着 DataLeap 实现火山引擎私有云 Beta 版本公布，吸引了一批客户试用。
• 2022 年 5 月，Data Catalog 随着 DataLeap 实现火山引擎私有云 GA 版本公布，正式对外开放。
• 2021 年 9 月至 2022 年 5 月，Data Catalog 公布 10+ 版本，对齐 95% 外部外围性能以及公布新性能 20+，包含反对 LAS/ByteHouse 数据源、OpenAPI 和元数据采集等 ToB 场景新个性。

Data Catalog 私有云整体架构

Data Catalog 反对综合搜寻、血统剖析、库表治理、元数据采集、备注问答、专题治理、OpenAPI 等性能，和 DataLeap 其余功能模块（如数据开发、数据集成、数据品质、数据安全等）一起提供了大数据研发和治理场景的一站式解决方案。同时，Data Catalog 私有云产品是基于火山引擎提供的数据引擎和云基础设施来部署和服务的，上面会简略介绍下咱们所依赖和应用的产品和服务：

• 数据引擎： 是火山引擎提供的数据分析、数据仓库和数据湖相干产品，包含 ByteHouse/EMR/LAS 等产品。通常 Data Catalog 会从这类零碎内采集元并存储元数据，进行解决加工后，再提供搜寻、血统剖析等性能；另外，库表治理模块也会依赖这类零碎提供对应的接口来做建库建表等操作。
• 外部公共服务： 是火山引擎为反对公司外部产品上私有云提供的若干公共根底服务，次要作用是不便外部产品能疾速在私有云部署，提供和公司外部兼容性比拟高的公共服务，升高革新和迁徙老本。其中 Data Catalog 应用较多的包含：API 网关、网络代理、访问控制、平安认证、监控报警等。
• 根底服务： 这类服务或产品相较于下面说的外部公共服务次要区别是，他们是火山引擎对外售卖的规范云服务，内外部用户都可应用，且和业界支流云厂商能力是根本对齐的，不过会和公司外部一些相似的根底服务会有不少差别。Data Catalog 次要应用这类根底服务来进行本身服务的部署运维，并且进行较多的兼容性革新，包含容器部署、网络买通、内外部 CICD 和监控报警流程一致性等方面。
• 数据库和中间件： 是和业界支流云厂商对齐的存储和中间件畛域的规范云服务，和公司外部对应组件也会有若干差别，Data Catalog 为此也做了多版本的兼容。Data Catalog 在元数据存储上应用到了 Hbase/MySQL/ES/Redis，而后在元数据采集和同步场景应用了 Kafka，同时用到了日志服务来进步研发运维效率。

Data Catalog 私有云遇到的挑战

Data Catalog 经验了一个从 0 到 1 在火山引擎私有云部署并逐渐优化和迭代公布 10+ 版本的过程，在这个过程中经验不少挑战，上面将介绍其中比拟典型的问题以及咱们摸索并实际的一些解决方案。

网络和数据安全

为保障网络安全和多租户数据安全，火山引擎上私有云产品部署的环境划分为“公共服务区”和“售卖区”，同时售卖区又宰割为若干公有网络（即 VPC），而后公共服务区和售卖区以及售卖区的 VPC 之间都是网络隔离的。

Data Catalog 会依赖一些外部公共服务，这类服务通常都部署在公共服务区，而依照网络和数据安全标准，Data Catalog 作为独立云产品须要部署在售卖区独立 VPC 内，相似的状况 Data Catalog 依赖的数据中台产品也需部署在独立 VPC 内，例如 EMR、LAS 和 Bytehouse。另外，Data Catalog 对外会提供 OpenAPI，内部客户能够通过火山引擎的 API 网关来拜访这些 API，但 API 网关服务是在公共服务区，无奈间接拜访到 Data Catalog 服务，基于以上状况，为了失常对外提供服务，咱们须要解决网络隔离问题同时还要保障安全性。

解决方案：

服务部署： 为了可能在售卖区部署，通过调研咱们抉择火山引擎提供的容器服务（VKE）和负载平衡（CLB）来进行根底服务部署和构建，其中 CLB 提供四层负载平衡能力，容器服务是高性能 Kubernetes 容器集群治理服务。Data Catalog 基于容器服务提供的无状态负载（Deployment）、定时工作（CronJob）、服务（Service）等云原生容器治理性能进行根本服务和调度工作部署，同时也应用火山引擎的存储和中间件，以上组件均在同一个 VPC 内，可能保障网络连通以及数据安全。

• 网络买通： 为解决上文所说的网络隔离问题，通过调研咱们应用了公司通用的网络代理服务（PLB/Shuttle），该网络代理可做到网络买通的同时保障四层网络流量的平安，从而达到咱们和各依赖方如公共服务（API 网关、IAM 等、独立部署的云服务（EMR/LAS 等）的网络连通指标。
• 数据安全： 火山引擎部署环境做网络隔离，次要是保障安全性，咱们尽管应用网络代理买通网络，然而仍需保障各个环节的安全性，思考到服务间交互都是通过 HTTP 申请，咱们对和内部交互的接口都减少了 SSL 和双向认证的机制，同时在平安认证方面，咱们没有应用 Nginx 或 Java 原生的计划，而是借助于火山引擎外部平安服务中的 ZTI 团队的 envoy 组件来实现，同时应用 sidecar 模式和咱们后端服务容器集成部署，既升高了服务端部署革新老本，也解耦了服务端业务逻辑和平安认证逻辑。

多租户适配

这里先对多租户相干概念做一些解释：
* 租户： 一个客户、公司、集体开明或购买了火山引擎的云产品，火山引擎就会告诉对应的服务提供者，对应云产品会感知到他的开明，这个客户就是这个云产品的一个租户，理论场景能够类比于一个公司是一个租户，不同的公司是不同的租户。

• 多租户服务： 云服务要为多个租户提供服务，须要做到租户隔离，保障各租户的访问控制、数据、服务响应等各方面的应用都是隔离的，彼此互不感知互不影响的。要做到租户隔离，就须要云服务能通过逻辑或物理隔离的形式来将各租户对应数据和拜访隔离开来，防止相互影响。

此前，在字节跳动外部实际中不存在多租户场景，所以面向私有云用户服务时，Data Catalog 针对反对多租户服务的能力，须要进行专门适配。

解决方案：Data Catalog 在元数据存储层借用了 Apache Atlas 的设计与实现。Atlas 的底层应用 JanusGraph 做图引擎，JanusGraph 是基于 Gremlin 图查问语义实现的计算引擎，而社区版 Atlas 不反对多租户场景。咱们通过在 Atlas 上减少 JanusGraph Partition Strategy 适配，实现存储层租户逻辑隔离。

参考以上示例，JanusGraph 的 Partition Strategy 能够反对设置的 read/write Partition 的 value，并保障只读 / 写指定 Partition 的数据，从而达到数据隔离，咱们将租户信息和 Partition Strategy 相结合，实现了多租户场景下读写数据的逻辑隔离，保障了数据安全性。

内外部性能统一

Data Catalog 在字节跳动外部已打磨多年，产品状态和技术架构比拟成熟，但随着私有云部署和 ToB 产品迭代，因外部外根底服务差别和 ToB 引入新的应用场景和上下游组件导致内外部产品性能和技术实现的差别也越来越多。

在前几个版本中，咱们尝试应用独立的代码分支和版本来反对 ToB 性能，防止外部新性能对 ToB 产生影响，但咱们发现随着版本差别越来越大，代码和性能的合并和兼容就变得十分艰难，在其中一次整体代码合并时，呈现了好几千的文件 diff 和上百处 merge conflict，咱们破费了一周工夫多的工夫合并代码和进行多环境测试回归验证，最终实现了合并。性能和代码的不统一曾经成为影响研发效率和需要交付进度的很重要因素，必须要进行优化。

解决方案：
咱们次要从产品性能和代码版本两方面来解决内外部一致性问题：
产品性能

• 产品性能的标准化：原则上所有性能都应做到内外部统一，只容许局部性能点的实现区别。咱们冀望能将各性能都进行标准化，根底模块和通用能力（如元数据模型、搜寻、血统）原则上需放弃内外统一，内外部依赖或需要场景差别较大的性能（如元数据接入和采集、库表治理）革新为标准化流程，将差别局部尽量减小，做到只通过配置、插件、版本控制工具等形式就能适配，缩小研发和运维老本。
• 明确的一致性布局：从模块到性能点一一比照外部外实现状况，制订长期 roadmap，明确差别点的反对排期，并进步对齐外部性能的工作优先级，逐渐缩小差别。
• 新性能的兼容性：新性能的设计需思考内外部一致性，包含产品的交互和研发的技术计划都需思考内部场景并明确兼容计划，原则上对非凡场景定制化性能都需思考通用场景适配，尽量放弃多环境的兼容性。
  技术实现
• 对立的代码分支治理标准：原则上内外部的代码是统一的即对立的分支。具体来说，不论域内外性能都需兼容多环境并在多环境验证能力合并代码，内部如私有云在发版周期中会基于外部主分支代码（如 master 分支）创立一个新的 release-x.x.x 分支，进行回归验证和私有云上线，同时线上继续应用 release-x.x.x 分支以保障线上环境稳固，release-x.x.x 分支需定期合回主分支。新的版本会持续基于主分支开发，并持续保持该标准。
• 明确的发版布局：依据理论状况，外部通常迭代比拟麻利发版频率较快，而内部通常要求稳定性，会定期发版（如每月一个版本），思考到发版周期的差别，咱们会以内部固定周期为规范，细粒度管制需要评估、性能开发、QA 测试、回归测试等各环节所在时间段，明确封板工夫，升高内外部相互影响。
• 一致性意识和自动化多环境验证：通过多轮分享和培训在技术团队外部对齐一致性意识，分明内外部差别点 FAQ 等，另外，如上所说新性能技术设计方案需明确多环境兼容性。同时，引入自动化的多环境验证环节，尽早发现不兼容或不统一的问题，缩小人工判断和测试的老本。

OpenAPI

在 DataLeap Beta 版本公布之后，有内外部客户在试用，过后就有客户提出 OpenAPI 的需要，但在 Beta 版本咱们还未反对 OpenAPI。公司外部有 OpenAPI 标准和平台，Data Catalog 也借助相干平台实现了外部的 OpenAPI，然而 ToB 场景的公共平台不同且会遇到 ToB 场景特定的问题（如平安认证、多租户、API 开明计费等），须要综合思考来对外提供解决方案。

解决方案：
如前文介绍，火山引擎外部公共服务有 API 网关的通用服务（TOP），并有若干 API 公布标准，Data Catalog 调研了该 API 网关并解决以上外围问题来反对 ToB OpenAPI。以下介绍一下次要流程和关注点：

API 治理

• Data Catalog 借助于 API 网关治理 OpenAPI，包含注册和开明、访问控制、限流等。
• API 标准：火山引擎 OpenAPI 有明确的参数标准，Data Catalog 也需合乎该标准，但因外部 OpenAPI 参数格局不同，需做兼容，思考到新 API 的反对老本，借助于 Spring 的 Interceptor 和 Advice 以及定制 JSON 序列化和反序列化逻辑，实现了主动的参数格局转化，升高 API 格局兼容的开发成本。
• 访问控制：火山引擎作为云服务提供商，应用业界标准的 AKSK 密钥治理标准，API 使用者需创立 AKSK 并通过该信息来拜访 API 才可通过访问控制，而 API 网关会通过 IAM 进行鉴权，通过后会给服务提供者也就是 API 注册者透传用户的身份（如租户 ID，用户 ID），不便 API 提供者应用。
• 平安认证：解决 API 网关提供的根底鉴权，Data Catalog 也减少了更多机制来保障安全性，包含双向认证、租户开明状态检测等。
• API 文档：对于每一个 OpenAPI 都依据火山引擎标准编写了具体的参数阐明，汇总为一个正式 API 文档，不便用户查阅应用。

API 申请流程
1. 用户或服务通过 AKSK 拜访 API，或者通过前端控制台间接拜访 API。
2.API 网关通过 IAM 进行鉴权，将辨认到的用户身份通过 HTTP header 透传给服务提供者。
3. 服务提供者接管到申请并通过 HTTP header 获取用户身份，进行下一步解决。

总结

火山引擎 Data Catalog 产品是基于字节跳动外部平台，通过多年打磨业务场景和产品能力，在私有云进行部署和公布，冀望帮忙更多内部客户发明数据价值。目前私有云产品已蕴含外部成熟的产品性能同时扩大若干 ToB 外围性能，正在逐渐对齐业界当先 Data Catalog 云产品各项能力。

文中提及的内容其实还有持续优化的空间，以及随着客户的应用，还有面临一些新的问题，包含多租户性能优化、服务稳定性保障等，咱们都在继续摸索和解决，冀望能更好的反对 ToB 客户的业务诉求并实现商业价值的同时，提供优质稳固的服务和丰盛的扩大能力。

点击跳转火山引擎大数据研发治理套件 DataLeap 理解更多