Data Catalog 通过汇总技能和事务元数据，处理大数据生产者安排梳理数据、数据顾客找数和理解数的事务场景。本篇内容源自于火山引擎大数据研制办理套件DataLeap中的Data Catalog 功用模块的实践，首要介绍Data Catalog在公有云布置和发布中遇到应战及处理计划。
布景
- Data Catalog是一种元数据办理的服务，会搜集技能元数据，并在其根底上供给更丰厚的事务上下文与语义，一般支撑元数据编目、查找、概况浏览等功用。现在Data Catalog作为火山引擎大数据研制办理套件DataLeap产品的中心功用之一，通过多年打磨，服务于字节跳动内部简直一切中心事务线，处理了数据生产者和顾客对于元数据和财物办理的各项中心需求。
- 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 恳求流程
- 用户或服务通过AKSK拜访API，或者通过前端操控台直接拜访API。
- API网关通过IAM进行鉴权，将识别到的用户身份通过HTTP header透传给服务供给者。
- 服务供给者接收到恳求并通过HTTP header获取用户身份，进行下一步处理。
总结
火山引擎Data Catalog产品是根据字节跳动内部渠道，通过多年打磨事务场景和产品才干，在公有云进行布置和发布，希望帮忙更多外部客户发明数据价值。现在公有云产品已包含内部老练的产品功用一起扩展若干ToB中心功用，正在逐渐对齐业界抢先Data Catalog云产品各项才干。
文中提及的内容其实还有继续优化的空间，以及跟着客户的运用，还有面对一些新的问题，包含多租户功能优化、服务稳定性保证等，咱们都在继续探究和处理，希望能更好的支撑ToB客户的事务诉求并完成商业价值的一起，供给优质稳定的服务和丰厚的扩展才干。
跳转 大数据研制办理套件 DataLeap 了解概况！
