以一次 Data Catalog 架构升级为例聊业务系统的性能优化

动手点关注 干货不迷路 👆

摘要

字节的 DataCatalog 系统，在 2021 年进行过大规模重构，新版本的存储层基于 Apache Atlas 实现。迁移过程中，我们遇到了比较多的性能问题。本文以 Data Catalog 系统升级过程为例，与大家讨论业务系统性能优化方面的思考，也会介绍我们关于 Apache Atlas 相关的性能优化。

背景

字节跳动 Data Catalog 产品早期，是基于 LinkedIn Wherehows 进行二次改造，产品早期只支持 Hive 一种数据源。后续为了支持业务发展，做了很多修修补补的工作，系统的可维护性和扩展性变得不可忍受。比如为了支持数据血缘能力，引入了字节内部的图数据库 veGraph，写入时，需要业务层处理 MySQL、ElasticSearch 和 veGraph 三种存储，模型也需要同时理解关系型和图两种。更多的背景可以参照之前的文章。

新版本保留了原有版本全量的产品能力，将存储层替换成了 Apache Atlas。然而，当我们把存量数据导入到新系统时，许多接口的读写性能都有严重下降，服务器资源的使用也被拉伸到夸张的地步，比如：

• 写入一张超过 3000 列的 Hive 表元数据时，会持续将服务节点的 CPU 占用率提升到 100%，十几分钟后触发超时

• 一张几十列的埋点表，上下游很多，打开详情展示时需要等 1 分钟以上

为此，我们进行了一系列的性能调优，结合 Data Catlog 产品的特点，调整了 Apache Atlas 以及底层 Janusgraph 的实现或配置，并对优化性能的方法论做了一些总结。

业务系统优化的整体思路

在开始讨论更多细节之前，先概要介绍下我们做业务类系统优化的思路。本文中的业务系统，是相对于引擎系统的概念，特指解决某些业务场景，给用户直接暴露前端使用的 Web 类系统。

优化之前，首先应明确优化目标。与引擎类系统不同，业务类系统不会追求极致的性能体验，更多是以解决实际的业务场景和问题出发，做针对性的调优，需要格外注意避免过早优化与过度优化。

准确定位到瓶颈，才能事半功倍。一套业务系统中，可以优化的点通常有很多，从业务流程梳理到底层组件的性能提升，但是对瓶颈处优化，才是 ROI 最高的。

根据问题类型，挑性价比最高的解决方案。解决一个问题，通常会有很多种不同的方案，就像条条大路通罗马，但在实际工作中，我们通常不会追求最完美的方案，而是选用性价比最高的。

优化的效果得能快速得到验证。性能调优具有一定的不确定性，当我们做了某种优化策略后，通常不能上线观察效果，需要一种更敏捷的验证方式，才能确保及时发现策略的有效性，并及时做相应的调整。

业务系统优化的细节

优化目标的确定

在业务系统中做优化时，比较忌讳两件事情：

• 过早优化：在一些功能、实现、依赖系统、部署环境还没有稳定时，过早的投入优化代码或者设计，在后续系统发生变更时，可能会造成精力浪费。

• 过度优化：与引擎类系统不同，业务系统通常不需要跑分或者与其他系统产出性能对比报表，实际工作中更多的是贴合业务场景做优化。比如用户直接访问前端界面的系统，通常不需要将响应时间优化到 ms 以下，几十毫秒和几百毫秒，已经是满足要求的了。

优化范围选择

对于一个业务类 Web 服务来说，特别是重构阶段，优化范围比较容易圈定，主要是找出与之前系统相比，明显变慢的那部分 API，比如可以通过以下方式收集需要优化的部分：

• 通过前端的慢查询捕捉工具或者后端的监控系统，筛选出 P90 大于 2s 的 API

• 页面测试过程中，研发和测试同学陆续反馈的 API

• 数据导入过程中，研发发现的写入慢的 API 等

优化目标确立

针对不同的业务功能和场景，定义尽可能细致的优化目标，以 Data Catalog 系统为例：