以字节跳动内部DataCatalog架构升级为例聊业务系统的性能优化.pdfVIP

背景 字节跳动 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 系统为例： 定位性能瓶颈手段 系统复杂到一定程度时，一次简单的接口调用，都可能牵扯出底层广泛的调用，在优化某个具体 的 API 时，如何准确找出造成性能问题的瓶颈，是后续其他步骤的关键。下面的表格是我们总结 的常用瓶颈排查手段。 优化策略 在找到某个接口的性能瓶颈后，下一步是着手处理。同一个问题，修复的手段可能有多种，实际 工作中，我们优先考虑性价比高的，也就是实现简单且有明确效果。 快速验证 优化的过程通常需要不断的尝试，所以快速验证特别关键，直接影响优化的效率。 Data Catalog 系统优化举例 在我们升级字节 Data Catalog 系统的过程中，广泛使用了上文中介绍的各种技巧。本章节，我 们挑选一些较典型的案例，详细介绍优化的过程。 调节 JanusGraph 配置 实践中，我们发现以下两个参数对于 JanusGraph 的查询性能有比较大的影响： query.batch = ture query.batch-property-prefetch=true 其中