背景

存儲(chǔ)與計(jì)算資源是數(shù)倉(cāng)建設(shè)的基礎(chǔ)，也是數(shù)倉(cāng)建設(shè)中的重要成本支出。而隨著數(shù)倉(cāng)建設(shè)規(guī)模逐漸擴(kuò)大、時(shí)間跨度逐漸拉長(zhǎng)，將不可避免的出現(xiàn)數(shù)據(jù)表、任務(wù)、字段的冗余。

技術(shù)路線

針對(duì)數(shù)倉(cāng)建設(shè)成本治理的粒度從大到小可以分為：數(shù)據(jù)表、數(shù)據(jù)任務(wù)、數(shù)據(jù)表字段。從粗到細(xì)的治理優(yōu)化思路如下：

當(dāng)發(fā)現(xiàn)低頻使用的數(shù)據(jù)表時(shí)，下線對(duì)應(yīng)數(shù)據(jù)表的同時(shí)也刪除對(duì)應(yīng)數(shù)據(jù)任務(wù)；當(dāng)數(shù)據(jù)任務(wù)資源浪費(fèi)嚴(yán)重，針對(duì)任務(wù)進(jìn)行對(duì)應(yīng)的代碼與資源優(yōu)化；當(dāng)發(fā)現(xiàn)一張表中個(gè)別字段使用使用頻率很低，停止相關(guān)字段的計(jì)算與存儲(chǔ)。

根據(jù)以上的優(yōu)化思路，首先要解決如何定位低頻使用數(shù)據(jù)表、高資源浪費(fèi)率任務(wù)、低頻使用字段的問(wèn)題，在此基礎(chǔ)上，針對(duì)不同的場(chǎng)景通過(guò)不同的手段進(jìn)行優(yōu)化。

(資料圖片僅供參考)

"數(shù)倉(cāng)建設(shè)成本分析"看板總覽

技術(shù)方案低頻使用數(shù)據(jù)表優(yōu)化方案定位低頻使用數(shù)據(jù)表

火山引擎DataLeap提供了Hive表的資源治理功能，包括Hive表的存儲(chǔ)與訪問(wèn)次數(shù)等基本信息查詢，用戶可以根據(jù)該功能直接定位低頻使用數(shù)據(jù)表并進(jìn)行優(yōu)化。

但是以上的優(yōu)化存在以下缺陷：使用Hive表的直接查詢次數(shù)無(wú)法準(zhǔn)確衡量用戶對(duì)于數(shù)據(jù)的實(shí)際使用次數(shù)：為了保障查詢速度，數(shù)據(jù)一般會(huì)由Hive表導(dǎo)入到ClickHouse等查詢速度較快的介質(zhì)中，而不會(huì)直接查詢Hive表。因此，一張Hive表的直接訪問(wèn)次數(shù)一般是由下游的日常數(shù)據(jù)任務(wù)產(chǎn)生，而不是真正的用戶查詢。缺少了對(duì)數(shù)據(jù)表生產(chǎn)過(guò)程中計(jì)算資源的統(tǒng)計(jì)：數(shù)據(jù)表在生產(chǎn)的過(guò)程中，除了占用存儲(chǔ)資源，計(jì)算資源是不可或缺的一部分：存在經(jīng)過(guò)復(fù)雜計(jì)算過(guò)程后，產(chǎn)出很小數(shù)據(jù)量的數(shù)據(jù)表。因此，當(dāng)希望對(duì)成本進(jìn)行快速優(yōu)化時(shí)需要瞄準(zhǔn)高成本的數(shù)據(jù)表時(shí)，只著眼于數(shù)據(jù)表占用的存儲(chǔ)資源是不夠全面的。Hive表成本分析看板

https://data.bytedance.net/aeolus/#/dashboard/437272?appId=555186&sheetId=440345

為了解決以上兩個(gè)問(wèn)題，火山引擎DataLeap研發(fā)人員進(jìn)行了Hive表成本分析看板的開(kāi)發(fā)建設(shè)：

首先，對(duì)數(shù)據(jù)表進(jìn)行血緣關(guān)系的梳理，從上（Hive表）至下（ClickHouse）建立數(shù)據(jù)表血緣關(guān)系樹(shù)進(jìn)一步將所有葉子節(jié)點(diǎn)的訪問(wèn)次數(shù)累加到相應(yīng)根節(jié)點(diǎn)上，作為該根節(jié)點(diǎn)的使用次數(shù)（直接訪問(wèn)+間接訪問(wèn)）再統(tǒng)計(jì)數(shù)據(jù)表計(jì)算資源，關(guān)聯(lián)數(shù)據(jù)表存儲(chǔ)資源，獲得該數(shù)據(jù)表的總生產(chǎn)成本最后關(guān)聯(lián)數(shù)據(jù)表的總生產(chǎn)成本與總使用次數(shù)，評(píng)價(jià)該數(shù)據(jù)表實(shí)際的ROI

數(shù)據(jù)表的生產(chǎn)成本vs使用次數(shù)

優(yōu)化手段與思路優(yōu)化手段

針對(duì)數(shù)據(jù)表的優(yōu)化手段有：

①下線數(shù)據(jù)表及對(duì)應(yīng)任務(wù)

在火山引擎DataLeap下線相關(guān)任務(wù)，并刪除對(duì)應(yīng)數(shù)據(jù)表。

② 縮減數(shù)據(jù)表TTL

根據(jù)「表分區(qū)查詢熱度分布圖」在火山引擎DataLeap修改對(duì)應(yīng)數(shù)據(jù)表TTL對(duì)應(yīng)數(shù)據(jù)表。

火山引擎DataLeap數(shù)據(jù)表生命周期配置

③ 對(duì)歷史數(shù)據(jù)進(jìn)行溫存配置

在火山引擎DataLeap配置歷史數(shù)據(jù)溫存天數(shù)。

優(yōu)化思路

基于「Hive表成本分析看板」，根據(jù)不同的使用成本與使用次數(shù)閾值（如數(shù)據(jù)表的生產(chǎn)成本1000元/月，使用次數(shù)100次/月）將看板分為四個(gè)象限，其中各個(gè)象限的數(shù)據(jù)表的含義及推薦的優(yōu)化手段為：

根據(jù)優(yōu)化收益進(jìn)行治理的順序?yàn)椋旱诙笙?第三象限>第一象限>第四象限。

低資源利用率任務(wù)優(yōu)化方案定位低資源利用率任務(wù)數(shù)據(jù)任務(wù)

計(jì)算資源分為CPU資源和內(nèi)存資源，可以利用火山引擎DataLeap進(jìn)行高浪費(fèi)任務(wù)的定位與探查。

任務(wù)資源使用監(jiān)控

通過(guò)高浪費(fèi)率任務(wù)監(jiān)控看板定位到的高資源浪費(fèi)率任務(wù)

優(yōu)化手段與思路對(duì)于新增任務(wù)

基于大數(shù)據(jù)研發(fā)治理套件火山引擎DataLeap，在新建數(shù)據(jù)任務(wù)與數(shù)據(jù)表時(shí)，要求需求方提供數(shù)據(jù)的服務(wù)時(shí)限，設(shè)置數(shù)據(jù)任務(wù)的壽命。當(dāng)壽命到期，會(huì)提醒相關(guān)負(fù)責(zé)人確認(rèn)是否可下線當(dāng)前數(shù)據(jù)任務(wù)。

數(shù)據(jù)任務(wù)壽命控制

對(duì)于歷史任務(wù)

目前離線數(shù)據(jù)任務(wù)的主要計(jì)算引擎為Apache Spark。

低頻使用字段優(yōu)化方案

相比于數(shù)據(jù)表與任務(wù)，針對(duì)數(shù)據(jù)表中的低頻使用的字段進(jìn)行優(yōu)化是一種更加細(xì)粒度的方式。

定位低頻使用字段

在離線數(shù)倉(cāng)建設(shè)中，原始日志一般會(huì)從消息隊(duì)列中直接不加處理的存儲(chǔ)到原始數(shù)據(jù)層，再通過(guò)明細(xì)數(shù)據(jù)層對(duì)原始日志進(jìn)行字段清洗與解析。在實(shí)踐中，火山引擎DataLeap研發(fā)人員發(fā)現(xiàn)處于明細(xì)數(shù)據(jù)層中的原始埋點(diǎn)明細(xì)表由于數(shù)據(jù)量巨大(單表PB量級(jí))：在某些數(shù)據(jù)庫(kù)中，僅三張表格就占據(jù)了所在數(shù)據(jù)庫(kù)75%的存儲(chǔ)大小，個(gè)別數(shù)據(jù)表的字段平均存儲(chǔ)大小約為150TB。因此，為了更加高效地完成數(shù)據(jù)表字段優(yōu)化，研發(fā)人員從埋點(diǎn)明細(xì)表的埋點(diǎn)字段入手。

和Hive數(shù)據(jù)表類似，埋點(diǎn)字段也具有以下特點(diǎn)：

埋點(diǎn)字段一般也不會(huì)對(duì)外直接提供查詢，而是以清洗后的維度和指標(biāo)的形式對(duì)外使用。衡量一個(gè)埋點(diǎn)字段的ROI具有也兩個(gè)方面：使用次數(shù)與生產(chǎn)成本（存儲(chǔ)+計(jì)算成本）。

因此，首先也需要構(gòu)建埋點(diǎn)的血緣關(guān)系樹(shù)來(lái)統(tǒng)計(jì)其使用次數(shù)，再以存儲(chǔ)+計(jì)算資源消耗來(lái)衡量其生產(chǎn)成本，最終才能準(zhǔn)確地評(píng)價(jià)埋點(diǎn)的價(jià)值。

為了解決以上兩個(gè)問(wèn)題，研發(fā)人員進(jìn)行了埋點(diǎn)成本分析看板的開(kāi)發(fā)建設(shè)：

首先，以原始埋點(diǎn)明細(xì)表的埋點(diǎn)字段為根節(jié)點(diǎn)，從上（埋點(diǎn)明細(xì)Hive表）至下（服務(wù)層提供維度、指標(biāo)查詢的ClickHouse表）建立埋點(diǎn)字段的血緣關(guān)系樹(shù)進(jìn)一步將所有葉子節(jié)點(diǎn)的維度、指標(biāo)字段的訪問(wèn)次數(shù)累加到相應(yīng)根節(jié)點(diǎn)埋點(diǎn)字段上，作為該根節(jié)點(diǎn)埋點(diǎn)字段的使用次數(shù)再統(tǒng)計(jì)埋點(diǎn)明細(xì)數(shù)據(jù)表的計(jì)算資源與存儲(chǔ)資源，獲得該埋點(diǎn)字段的的平均生產(chǎn)成本最后關(guān)聯(lián)埋點(diǎn)字段的總生產(chǎn)成本與總使用次數(shù)，評(píng)價(jià)該埋點(diǎn)字段的實(shí)際的ROI

埋點(diǎn)字段的生產(chǎn)成本vs使用次數(shù)

優(yōu)化手段與思路優(yōu)化手段

① 停止解析和存儲(chǔ)埋點(diǎn)字段

為了減少明細(xì)數(shù)據(jù)層字段的的計(jì)算與存儲(chǔ)成本，可以直接對(duì)一些低頻使用埋點(diǎn)停止解析與存儲(chǔ)。

但是低頻字段并不等于不使用字段，即如果要下線低頻使用字段，需要保證用戶在偶爾使用時(shí)仍然可以獲取。雖然使用頻次不同，但是同一張表中的埋點(diǎn)字段不能分別設(shè)置不同的存儲(chǔ)方式或者TTL，只能選擇存儲(chǔ)或者不存儲(chǔ)。

因此，對(duì)于低頻使用埋點(diǎn)，結(jié)合用戶的實(shí)際使用情況與開(kāi)發(fā)維護(hù)成本，可以通過(guò)搭建采樣鏈路、從原始數(shù)據(jù)層臨時(shí)獲取等方式滿足偶爾的少量使用場(chǎng)景，從而可以減少明細(xì)數(shù)據(jù)層的字段解析與存儲(chǔ)。

② 拆解埋點(diǎn)字段中常用的部分

還有一些被高頻使用的埋點(diǎn)常常以復(fù)雜的url、json的格式上報(bào)存儲(chǔ)。而實(shí)際在下游的使用過(guò)程中只會(huì)解析獲取部分屬性提供服務(wù)。因此，基于準(zhǔn)確的獲取下游的使用方式，將大字段拆解為小字段，不解析存儲(chǔ)不使用的部分。

優(yōu)化思路

配合「埋點(diǎn)成本分析看板」，根據(jù)不同的使用成本與使用次數(shù)閾值將看板分為四個(gè)象限，其中各個(gè)象限的數(shù)據(jù)表的含義及推薦的優(yōu)化手段為：

根據(jù)優(yōu)化收益進(jìn)行治理的順序?yàn)椋旱诙笙?第三象限>第一象限>第四象限。

總結(jié)

基于數(shù)據(jù)成本分析看板，結(jié)合以上技術(shù)方案，如果是累計(jì)下線20+張數(shù)據(jù)表及對(duì)應(yīng)任務(wù)，優(yōu)化10+高成本任務(wù)，停止200+數(shù)據(jù)埋點(diǎn)解析，結(jié)合數(shù)據(jù)表溫存與TTL縮減，初步測(cè)算能節(jié)省數(shù)倉(cāng)總成本的36%費(fèi)用。

在梳理了數(shù)據(jù)表、字段的血緣樹(shù)的基礎(chǔ)上，建立了Hive表成本分析看板、任務(wù)成本分析看板、埋點(diǎn)成本分析看板等看板，結(jié)合大數(shù)據(jù)研發(fā)治理套件火山引擎DataLeap對(duì)數(shù)倉(cāng)建設(shè)過(guò)程中的數(shù)據(jù)表、數(shù)據(jù)任務(wù)、埋點(diǎn)字段的成本的進(jìn)行了由粗到細(xì)的梳理與優(yōu)化，提升了現(xiàn)有資源的承載能力，降低了建設(shè)成本。

關(guān)鍵詞：