字節(jié)跳動技術(shù)團隊 2023-06-28 12:01 發(fā)表于北京

干貨不迷路

背景

存儲與計算資源是數(shù)倉建設的基礎，也是數(shù)倉建設中的重要成本支出。而隨著數(shù)倉建設規(guī)模逐漸擴大、時間跨度逐漸拉長，將不可避免的出現(xiàn)數(shù)據(jù)表、任務、字段的冗余。為了減輕資源負擔，降低數(shù)倉維護成本，需要對數(shù)倉建設成本進行治理與優(yōu)化。

(資料圖)

技術(shù)路線

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

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

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

\"數(shù)倉建設成本分析\"看板總覽

技術(shù)方案

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

定位低頻使用數(shù)據(jù)表

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

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

Hive表成本分析看板

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

為了解決以上兩個問題，火山引擎Dataleap研發(fā)人員進行了Hive表成本分析看板的開發(fā)建設：

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

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

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

優(yōu)化手段

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

① 下線 數(shù)據(jù)表及對應任務

在火山引擎Dataleap下線相關任務，并刪除對應數(shù)據(jù)表。

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

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

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

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

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

優(yōu)化思路

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

根據(jù)優(yōu)化收益進行治理的順序為：第二象限>第三象限>第一象限>第四象限。

低資源利用率任務優(yōu)化方案

定位低資源利用率任務數(shù)據(jù)任務

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

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

通過高浪費率任務監(jiān)控看板定位到的高資源浪費率任務

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

對于新增任務

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

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

對于歷史任務

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

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

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

定位低頻使用字段

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

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

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

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

為了解決以上兩個問題，研發(fā)人員進行了埋點成本分析看板的開發(fā)建設：

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

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

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

優(yōu)化手段

① 停止解析和存儲 埋點 字段

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

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

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

② 拆解 埋點 字段中常用的部分

還有一些被高頻使用的埋點常常以復雜的url、json的格式上報存儲。而實際在下游的使用過程中只會解析獲取部分屬性提供服務。因此，基于準確的獲取下游的使用方式，將大字段拆解為小字段，不解析存儲不使用的部分。

優(yōu)化思路

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

根據(jù)優(yōu)化收益進行治理的順序為：第二象限>第三象限>第一象限>第四象限。

總結(jié)

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

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

Hive表成本分析看板

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

任務成本分析看板

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

埋點成本分析看板

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

關鍵詞：