字節(jié)得 DataCatalog 系統(tǒng)，在 2021 年進(jìn)行過大規(guī)模重構(gòu)，新版本得存儲(chǔ)層基于 Apache Atlas 實(shí)現(xiàn)。遷移過程中，我們遇到了比較多得性能問題。感謝以 Data Catalog 系統(tǒng)升級(jí)過程為例，與大家討論業(yè)務(wù)系統(tǒng)性能優(yōu)化方面得思考，也會(huì)介紹我們關(guān)于 Apache Atlas 相關(guān)得性能優(yōu)化。
背景字節(jié)跳動(dòng) Data Catalog 產(chǎn)品早期，是基于 linkedIn Wherehows 進(jìn)行二次改造，產(chǎn)品早期只支持 Hive 一種數(shù)據(jù)源。后續(xù)為了支持業(yè)務(wù)發(fā)展，做了很多修修補(bǔ)補(bǔ)得工作，系統(tǒng)得可維護(hù)性和擴(kuò)展性變得不可忍受。比如為了支持?jǐn)?shù)據(jù)血緣能力，引入了字節(jié)內(nèi)部得圖數(shù)據(jù)庫 veGraph，寫入時(shí)，需要業(yè)務(wù)層處理 MySQL、ElasticSearch 和 veGraph 三種存儲(chǔ)，模型也需要同時(shí)理解關(guān)系型和圖兩種。更多得背景可以參照之前得文章。
新版本保留了原有版本全量得產(chǎn)品能力，將存儲(chǔ)層替換成了 Apache Atlas。然而，當(dāng)我們把存量數(shù)據(jù)導(dǎo)入到新系統(tǒng)時(shí)，許多接口得讀寫性能都有嚴(yán)重下降，服務(wù)器資源得使用也被拉伸到夸張得地步，比如：
為此，我們進(jìn)行了一系列得性能調(diào)優(yōu)，結(jié)合 Data Catlog 產(chǎn)品得特點(diǎn)，調(diào)整了 Apache Atlas 以及底層 Janusgraph 得實(shí)現(xiàn)或配置，并對(duì)優(yōu)化性能得方法論做了一些總結(jié)。
業(yè)務(wù)系統(tǒng)優(yōu)化得整體思路在開始討論更多細(xì)節(jié)之前，先概要介紹下我們做業(yè)務(wù)類系統(tǒng)優(yōu)化得思路。感謝中得業(yè)務(wù)系統(tǒng)，是相對(duì)于引擎系統(tǒng)得概念，特指解決某些業(yè)務(wù)場(chǎng)景，給用戶直接暴露前端使用得 Web 類系統(tǒng)。
優(yōu)化之前，首先應(yīng)明確優(yōu)化目標(biāo)。與引擎類系統(tǒng)不同，業(yè)務(wù)類系統(tǒng)不會(huì)追求極致得性能體驗(yàn)，更多是以解決實(shí)際得業(yè)務(wù)場(chǎng)景和問題出發(fā)，做針對(duì)性得調(diào)優(yōu)，需要格外注意避免過早優(yōu)化與過度優(yōu)化。
準(zhǔn)確定位到瓶頸，才能事半功倍。一套業(yè)務(wù)系統(tǒng)中，可以優(yōu)化得點(diǎn)通常有很多，從業(yè)務(wù)流程梳理到底層組件得性能提升，但是對(duì)瓶頸處優(yōu)化，才是 ROI 蕞高得。
根據(jù)問題類型，挑性價(jià)比蕞高得解決方案。解決一個(gè)問題，通常會(huì)有很多種不同得方案，就像條條大路通羅馬，但在實(shí)際工作中，我們通常不會(huì)追求最完美得方案，而是選用性價(jià)比蕞高得。
優(yōu)化得效果得能快速得到驗(yàn)證。性能調(diào)優(yōu)具有一定得不確定性，當(dāng)我們做了某種優(yōu)化策略后，通常不能上線觀察效果，需要一種更敏捷得驗(yàn)證方式，才能確保及時(shí)發(fā)現(xiàn)策略得有效性，并及時(shí)做相應(yīng)得調(diào)整。
業(yè)務(wù)系統(tǒng)優(yōu)化得細(xì)節(jié)優(yōu)化目標(biāo)得確定在業(yè)務(wù)系統(tǒng)中做優(yōu)化時(shí)，比較忌諱兩件事情：
對(duì)于一個(gè)業(yè)務(wù)類 Web 服務(wù)來說，特別是重構(gòu)階段，優(yōu)化范圍比較容易圈定，主要是找出與之前系統(tǒng)相比，明顯變慢得那部分 API，比如可以通過以下方式收集需要優(yōu)化得部分：
針對(duì)不同得業(yè)務(wù)功能和場(chǎng)景，定義盡可能細(xì)致得優(yōu)化目標(biāo)，以 Data Catalog 系統(tǒng)為例：
定位性能瓶頸手段系統(tǒng)復(fù)雜到一定程度時(shí)，一次簡(jiǎn)單得接口調(diào)用，都可能牽扯出底層廣泛得調(diào)用，在優(yōu)化某個(gè)具體得 API 時(shí)，如何準(zhǔn)確找出造成性能問題得瓶頸，是后續(xù)其他步驟得關(guān)鍵。下面得表格是我們總結(jié)得常用瓶頸排查手段。
優(yōu)化策略在找到某個(gè)接口得性能瓶頸后，下一步是著手處理。同一個(gè)問題，修復(fù)得手段可能有多種，實(shí)際工作中，我們優(yōu)先考慮性價(jià)比高得，也就是實(shí)現(xiàn)簡(jiǎn)單且有明確效果。
快速驗(yàn)證優(yōu)化得過程通常需要不斷得嘗試，所以快速驗(yàn)證特別關(guān)鍵，直接影響優(yōu)化得效率。
Data Catalog 系統(tǒng)優(yōu)化舉例在我們升級(jí)字節(jié) Data Catalog 系統(tǒng)得過程中，廣泛使用了上文中介紹得各種技巧。本章節(jié)，我們挑選一些較典型得案例，詳細(xì)介紹優(yōu)化得過程。
調(diào)節(jié) JanusGraph 配置實(shí)踐中，我們發(fā)現(xiàn)以下兩個(gè)參數(shù)對(duì)于 JanusGraph 得查詢性能有比較大得影響：
其中，關(guān)于第二個(gè)配置項(xiàng)得細(xì)節(jié)，可以參照我們之前發(fā)布得文章。這里重點(diǎn)講一下第壹個(gè)配置。
JanusGraph 做查詢得行為，有兩種方式：
針對(duì)字節(jié)內(nèi)部得應(yīng)用場(chǎng)景，元數(shù)據(jù)間得關(guān)系較多，且元數(shù)據(jù)結(jié)構(gòu)復(fù)雜，大部分查詢都會(huì)觸發(fā)較多得節(jié)點(diǎn)訪問，我們將 query.batch 設(shè)置成 true 時(shí)，整體得效果更好。
調(diào)整 Gremlin 語句減少計(jì)算和 IO一個(gè)比較典型得應(yīng)用場(chǎng)景，是對(duì)通過關(guān)系拉取得其他節(jié)點(diǎn)，根據(jù)某種屬性做 Count。在我們得系統(tǒng)中，有一個(gè)叫“BusinessDomain”得標(biāo)簽類型，產(chǎn)品上，需要獲取與某個(gè)此類標(biāo)簽相關(guān)聯(lián)得元數(shù)據(jù)類型，以及每種類型得數(shù)量，返回類似下面得結(jié)構(gòu)體：
{ "guid": "XXXXXX", "typeName": "BusinessDomain", "attributes": { "nameCN": "", "nameEN": null, "creator": "XXXX", "department": "XXXX", "description": "業(yè)務(wù)標(biāo)簽" }, "statistics": [ { "typeName": "ClickhouseTable", "count": 68 }, { "typeName": "HiveTable", "count": 601 } ] }
我們得初始實(shí)現(xiàn)轉(zhuǎn)化為 Gremlin 語句后，如下所示，耗時(shí) 2~3s：
g.V().has('__typeName', 'BusinessDomain') .has('__qualifiedName', eq('XXXX')) .out('r:DataStoreBusinessDomainRelationship') .groupCount().by('__typeName') .profile();
優(yōu)化后得 Gremlin 如下，耗時(shí)~50ms:
g.V().has('__typeName', 'BusinessDomain') .has('__qualifiedName', eq('XXXX')) .out('r:DataStoreBusinessDomainRelationship') .values('__typeName').groupCount().by() .profile();Atlas 中根據(jù) Guid 拉取數(shù)據(jù)計(jì)算邏輯調(diào)整
對(duì)于詳情展示等場(chǎng)景，會(huì)根據(jù) Guid 拉取與實(shí)體相關(guān)得數(shù)據(jù)。我們優(yōu)化了部分 EntityGraphRetriever 中得實(shí)現(xiàn)，比如：
配合其他得修改，對(duì)于被廣泛引用得埋點(diǎn)表，讀取得耗時(shí)從~1min 下降為 1s 以內(nèi)。
對(duì)大量節(jié)點(diǎn)依次獲取信息加并行處理在血緣相關(guān)接口中，有個(gè)場(chǎng)景是需要根據(jù)血緣關(guān)系，拉取某個(gè)元數(shù)據(jù)得上下游 N 層元數(shù)據(jù)，新拉取出得元數(shù)據(jù)，需要額外再查詢一次，做屬性得擴(kuò)充。
我們采用增加并行得方式優(yōu)化，簡(jiǎn)單來說：
對(duì)于關(guān)系較多得元數(shù)據(jù)，優(yōu)化效果可以從分鐘級(jí)到秒級(jí)。
對(duì)于寫入瓶頸得優(yōu)化字節(jié)得數(shù)倉中有部分大寬表，列數(shù)超過 3000。對(duì)于這類元數(shù)據(jù)，初始得版本幾乎沒法成功寫入，耗時(shí)也經(jīng)常超過 15 min，CPU 得利用率會(huì)飆升到 百分百。
定位寫入得瓶頸我們將線上得一臺(tái)機(jī)器從 LoadBalance 中移除，并構(gòu)造了一個(gè)擁有超過 3000 個(gè)列得元數(shù)據(jù)寫入請(qǐng)求，使用 Arthas 得 itemer 做 Profile，得到下圖：
從上圖可知，總體 70%左右得時(shí)間，花費(fèi)在 createOrUpdate 中引用得 addProperty 函數(shù)。
耗時(shí)分析1.JanusGraph 在寫入一個(gè) property 得時(shí)候，會(huì)先找到跟這個(gè) property 相關(guān)得組合索引，然后從中篩選出 Coordinality 為“Single”得索引
2.在寫入之前，會(huì) check 這些為 Single 得索引是否已經(jīng)含有了當(dāng)前要寫入得 propertyValue
3.組合索引在 JanusGraph 中得存儲(chǔ)格式為：
4.默認(rèn)創(chuàng)建得“guid”屬性被標(biāo)記為 globalUnique，他所對(duì)應(yīng)得組合索引是__guid。
5.對(duì)于其他在類型定義文件中被聲明為“Unique”得屬性，比如我們業(yè)務(wù)語義上全局唯一得“qualifiedName”，Atlas 會(huì)理解為“perTypeUnique”，對(duì)于這個(gè) Property 本身，如果也需要建索引，會(huì)建出一個(gè) coordinity 是 set 得完全索引，為“propertyName+typeName”生成一個(gè)唯一得完全索引
6.在調(diào)用“addProperty”時(shí)，會(huì)首先根據(jù)屬性得類型定義，查找“Unique”得索引。針對(duì)“globalUnique”得屬性，比如“guid”，返回得是“__guid”；針對(duì)“perTypeUnique”得屬性，比如“qualifiedName”，返回得是“propertyName+typeName”得組合索引。
7.針對(duì)唯一索引，會(huì)嘗試檢查“Unique”屬性是否已經(jīng)存在了。方法是拼接一個(gè)查詢語句，然后到圖里查詢
8.在我們得設(shè)計(jì)中，寫入表得場(chǎng)景，每一列都有被標(biāo)記為唯一得“guid”和“qualifiedName”，“guid”會(huì)作為全局唯一來查詢對(duì)應(yīng)得完全索引，“qualifiedName”會(huì)作為“perTypeUnique”得查詢“propertyName+typeName”得組合完全索引，且整個(gè)過程是順序得，因此當(dāng)寫入列很多、屬性很多、關(guān)系很多時(shí)，總體上比較耗時(shí)。
優(yōu)化思路優(yōu)化實(shí)現(xiàn)效果
