背景

• DataLeap 作為一站式數(shù)據(jù)中臺(tái)套件，匯集了字節(jié)內(nèi)部多年積累的數(shù)據(jù)集成、開發(fā)、運(yùn)維、治理、資產(chǎn)、安全等全套數(shù)據(jù)中臺(tái)建設(shè)的經(jīng)驗(yàn)，助力企業(yè)客戶提升數(shù)據(jù)研發(fā)治理效率、降低管理成本。

• Data Catalog 是一種元數(shù)據(jù)管理的服務(wù)，會(huì)收集技術(shù)元數(shù)據(jù)，并在其基礎(chǔ)上提供更豐富的業(yè)務(wù)上下文與語義，通常支持元數(shù)據(jù)編目、查找、詳情瀏覽等功能。目前 Data Catalog 作為火山引擎大數(shù)據(jù)研發(fā)治理套件 DataLeap 產(chǎn)品的核心功能之一，經(jīng)過多年打磨，服務(wù)于字節(jié)跳動(dòng)內(nèi)部幾乎所有核心業(yè)務(wù)線，解決了數(shù)據(jù)生產(chǎn)者和消費(fèi)者對(duì)于元數(shù)據(jù)和資產(chǎn)管理的各項(xiàng)核心需求。

• Data Catalog 系統(tǒng)的存儲(chǔ)層，依賴 Apache Atlas，傳遞依賴 JanusGraph。JanusGraph 的存儲(chǔ)后端，通常是一個(gè) Key-Column-Value 模型的系統(tǒng)，本文主要講述了使用 MySQL 作為 JanusGraph 存儲(chǔ)后端時(shí)，在設(shè)計(jì)上面的思考，以及在實(shí)際過程中遇到的一些問題。

起因

實(shí)際生產(chǎn)環(huán)境，我們使用的存儲(chǔ)系統(tǒng)維護(hù)成本較高，有一定的運(yùn)維壓力，于是想要尋求替代方案。在這個(gè)過程中，我們?cè)囼?yàn)了很多存儲(chǔ)系統(tǒng)，其中 MySQL 是重點(diǎn)投入調(diào)研和開發(fā)的備選之一。

另一方面，除了字節(jié)內(nèi)部外，在 ToB 場景，MySQL 的運(yùn)維成本也會(huì)明顯小于其他大數(shù)據(jù)組件，如果 MySQL 的方案跑通，我們可以在 ToB 場景多一種選擇。

基于以上兩點(diǎn)，我們投入了一定的人力調(diào)研和實(shí)現(xiàn)基于 MySQL 的存儲(chǔ)后端。

方案評(píng)估

在設(shè)計(jì)上，JanusGraph 的存儲(chǔ)后端是可插拔的，只要做對(duì)應(yīng)的適配即可，并且官方已經(jīng)支持了一批存儲(chǔ)系統(tǒng)。結(jié)合字節(jié)的技術(shù)棧以及我們的訴求，做了以下的評(píng)估。

各類存儲(chǔ)系統(tǒng)比較

• 因投入成本過高，我們不接受自己運(yùn)維有狀態(tài)集群，排除了 HBase 和 Cassandra；

• 從當(dāng)前數(shù)據(jù)量與將來的可擴(kuò)展性考慮，單機(jī)方案不可選，排除了 BerkeleyDB；

• 同樣因?yàn)槿肆Τ杀?，需要做極大量開發(fā)改造的方案暫時(shí)不考慮，排除了 Redis。

?

最終我們挑選了 MySQL 來推進(jìn)到下一步。