更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群
背景
-
DataLeap 作为一站式数据中台套件，汇集了字节内部多年积累的数据集成、开发、运维、治理、资产、安全等全套数据中台建设的经验，助力企业客户提升数据研发治理效率、降低管理成本。
-
Data Catalog 是一种元数据管理的服务，会收集技术元数据，并在其基础上提供更丰富的业务上下文与语义，通常支持元数据编目、查找、详情浏览等功能。目前 Data Catalog 作为火山引擎大数据研发治理套件 DataLeap 产品的核心功能之一，经过多年打磨，服务于字节跳动内部几乎所有核心业务线，解决了数据生产者和消费者对于元数据和资产管理的各项核心需求。
-
Data Catalog 系统的存储层，依赖 Apache Atlas，传递依赖 JanusGraph。JanusGraph 的存储后端，通常是一个 Key-Column-Value 模型的系统，本文主要讲述了使用 MySQL 作为 JanusGraph 存储后端时，在设计上面的思考，以及在实际过程中遇到的一些问题。
起因
实际生产环境，我们使用的存储系统维护成本较高，有一定的运维压力，于是想要寻求替代方案。在这个过程中，我们试验了很多存储系统，其中 MySQL 是重点投入调研和开发的备选之一。
另一方面，除了字节内部外，在 ToB 场景，MySQL 的运维成本也会明显小于其他大数据组件，如果 MySQL 的方案跑通，我们可以在 ToB 场景多一种选择。
基于以上两点，我们投入了一定的人力调研和实现基于 MySQL 的存储后端。
方案评估
在设计上，JanusGraph 的存储后端是可插拔的，只要做对应的适配即可，并且官方已经支持了一批存储系统。结合字节的技术栈以及我们的诉求，做了以下的评估。
各类存储系统比较
