首页 > 分享 > 火山引擎DataLeap数据目录系统公有云实践（下）

火山引擎DataLeap数据目录系统公有云实践（下）

花匠小妙招
2025-01-08 14:35

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

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）等云原生容器管理功能来部署基础服务和调度任务，同时也使用了Volcano的存储和中间件引擎。以上组件均位于同一个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可以支持设置的读/写Partition的值，保证只有指定Partition的数据被读/写，从而实现数据隔离。我们将租户信息与分区策略相结合，实现多租户场景下数据读写的逻辑隔离，保证数据安全。

内外部功能一致

数据目录在字节跳动经过多年打磨，产品形态和技术架构都比较成熟。但随着公有云的部署和ToB产品的迭代，由于内外基础服务和ToB的差异，引入了新的使用场景和上下游组件，内外实现的差异也越来越大。产品功能和技术。

在之前的版本中，我们尝试使用独立的代码分支和版本来支持ToB功能，以避免内部新功能对ToB的影响，但我们发现随着版本差异越来越大，代码和功能的合并和兼容变得越来越困难。这变得非常困难。在一次整体代码合并期间，存在数千个文件差异和数百个合并冲突。我们花了一周多的时间合并代码并进行多环境测试回归验证，最终完成了合并。功能和代码的不一致已经成为影响研发效率和需求交付进度的一个非常重要的因素，必须进行优化。

解决方案：

我们主要从产品功能和代码版本两个方面处理内外部一致性问题：

解决方案：

产品功能原则上所有功能应内外一致，仅允许部分功能点的实现存在差异。我们希望标准化所有功能。原则上，基础模块和通用能力（如元数据模型、搜索、沿袭）必须内外一致。将内外依赖或需求场景差异较大的功能（如元数据访问与获取、库表管理）纳入标准化流程，将差异最小化，使其仅通过配置、插件、版本控制工具即可适配等，降低研发和运维成本。产品功能的标准化：从模块到功能点逐一比较内部和外部实现，制定长期路线图，明确差异的支持时间表，并增加内部功能对齐的优先级，逐步减少差异。明确的一致性规划：新功能的设计需要考虑内部和外部的一致性，包括产品交互和研发技术方案，需要考虑外部场景并明确兼容的解决方案。原则上，特殊场景的自定义功能需要考虑通用场景的适配。保持多环境兼容性。新功能的兼容性：

技术实现原则上内外代码一致，即统一分支机构。具体来说，内部和外部功能都需要兼容多种环境，并在多种环境中进行验证，然后才能合并代码。公有云等外部源会在发布周期中根据内部主分支代码（如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。下面介绍一下主要流程和关注点：

解决方案：

Data Catalog 借助API Gateway 来管理OpenAPI，包括注册激活、访问控制、限流等。 API 规范：Volcano Engine OpenAPI 有明确的参数规范，Data Catalog 也需要符合这个规范，但由于不同的内部OpenAPI参数格式，需要兼容。考虑到新API的支持成本，借助Spring的Interceptor和Advice以及自定义的JSON序列化和反序列化逻辑，实现参数格式自动转换，降低API格式兼容的开发成本。访问控制：Volcano Engine作为云服务提供商，采用行业标准的AKSK密钥管理规范。 API用户需要创建AKSK并使用该信息访问API才能通过访问控制，API网关将通过IAM进行身份验证。通过后，用户的身份（如租户ID、用户ID）将透明传输给服务提供者，即API注册者，以方便API提供者使用。安全认证：为了应对API网关提供的基本认证，Data Catalog还增加了更多的机制来保证安全，包括双向认证、租户激活状态检测等。 API文档：针对每个OpenAPI，都写有详细的参数说明根据火山引擎规范，总结成官方API文档，方便用户参考和使用。API管理

用户或服务通过AKSK 或通过前端控制台间接访问API。 API网关通过IAM进行认证，并将识别出的用户身份通过HTTP header透传给服务提供商。服务提供者接收请求并通过HTTP header获取用户身份以进行下一步处理。

总结

火山引擎数据目录产品基于字节跳动内部平台。经过多年打磨业务场景和产品能力，部署并发布在公有云上，希望帮助更多外部客户创造数据价值。目前公有云产品已包含内部成熟的产品功能，并扩展了多项ToB核心功能，并逐步与业界领先的数据目录云产品能力接轨。文中提到的内容其实还有进一步优化的空间，而且随着客户的使用，还出现了一些新的问题，包括多租户性能优化、服务稳定性保障等，火山引擎DataLeap研发团队正在不断探索和探索期望在提供优质稳定的服务和丰富的扩展能力的同时，更好地支持ToB客户的业务需求，实现商业价值。

点击跳转至大数据研发治理套件DataLeap了解更多