背景
存儲與計算資源是數倉建設的基礎,也是數倉建設中的重要成本支出。而随着數倉建設規模逐漸擴大、時間跨度逐漸拉長,将不可避免的出現資料表、任務、字段的備援。為了減輕資源負擔,降低數倉維護成本,需要對數倉建設成本進行治理與優化。
技術路線
針對數倉建設成本治理的粒度從大到小可以分為:資料表、資料任務、資料表字段。從粗到細的治理優化思路如下:
- 當發現低頻使用的資料表時,下線對應資料表的同時也删除對應資料任務;
- 當資料任務資源浪費嚴重,針對任務進行對應的代碼與資源優化;
- 當發現一張表中個别字段使用使用頻率很低,停止相關字段的計算與存儲。
根據以上的優化思路,首先要解決如何定位低頻使用資料表、高資源浪費率任務、低頻使用字段的問題,在此基礎上,針對不同的場景通過不同的手段進行優化。
「"數倉建設成本分析"看闆總覽」
技術方案
低頻使用資料表優化方案
定位低頻使用資料表
火山引擎Dataleap提供了Hive表的資源治理功能,包括Hive表的存儲與通路次數等基本資訊查詢,使用者可以根據該功能直接定位低頻使用資料表并進行優化。
- 但是以上的優化存在以下缺陷:
- 使用Hive表的直接查詢次數無法準确衡量使用者對于資料的實際使用次數:為了保障查詢速度,資料一般會由Hive表導入到ClickHouse等查詢速度較快的媒體中,而不會直接查詢Hive表。是以,一張Hive表的直接通路次數一般是由下遊的日常資料任務産生,而不是真正的使用者查詢。
- 缺少了對資料表生産過程中計算資源的統計:資料表在生産的過程中,除了占用存儲資源,計算資源是不可或缺的一部分:存在經過複雜計算過程後,産出很小資料量的資料表。是以,當希望對成本進行快速優化時需要瞄準高成本的資料表時,隻着眼于資料表占用的存儲資源是不夠全面的。
- Hive表成本分析看闆
為了解決以上兩個問題,火山引擎Dataleap研發人員進行了Hive表成本分析看闆的開發建設:
- 首先,對資料表進行血緣關系的梳理,從上(Hive表)至下(ClickHouse)建立資料表血緣關系樹
- 進一步将所有葉子節點的通路次數累加到相應根節點上,作為該根節點的使用次數(直接通路+間接通路)
- 再統計資料表計算資源,關聯資料表存儲資源,獲得該資料表的總生産成本
- 最後關聯資料表的總生産成本與總使用次數,評價該資料表實際的ROI
「資料表的生産成本vs使用次數」
優化手段與思路
- 優化手段
針對資料表的優化手段有:
① 下線資料表及對應任務
在火山引擎Dataleap下線相關任務,并删除對應資料表。
② 縮減資料表TTL
根據「表分區查詢熱度分布圖」在火山引擎Dataleap修改對應資料表TTL對應資料表。
「火山引擎DataLeap資料表生命周期配置」
③ 對曆史資料進行溫存配置
在火山引擎Dataleap配置曆史資料溫存天數。
- 優化思路
基于「Hive表成本分析看闆」,根據不同的使用成本與使用次數門檻值(如資料表的生産成本1000元/月,使用次數100次/月)将看闆分為四個象限,其中各個象限的資料表的含義及推薦的優化手段為:
象限 | 含義 | 優化手段 | 收益 |
第一象限 | 高成本高頻通路的資料表 | ② ③ | 存儲資源 |
第二象限 | 高成本低頻通路的資料表 | ① ② ③ | 計算資源+存儲資源 |
第三象限 | 低成本低頻通路的資料表 | ① ② ③ | 計算資源+存儲資源 |
第四象限 | 低成本高頻通路的資料表 | ② ③ | 存儲資源 |
根據優化收益進行治理的順序為:第二象限>第三象限>第一象限>第四象限。
低資源使用率任務優化方案
定位低資源使用率任務資料任務
計算資源分為CPU資源和記憶體資源,可以利用火山引擎Dataleap進行高浪費任務的定位與探查。
「任務資源使用監控」
「通過高浪費率任務監控看闆定位到的高資源浪費率任務」
優化手段與思路
- 對于新增任務
基于大資料研發治理套件火山引擎DataLeap,在建立資料任務與資料表時,要求需求方提供資料的服務時限,設定資料任務的壽命。當壽命到期,會提醒相關負責人确認是否可下線目前資料任務。
「資料任務壽命控制」
- 對于曆史任務
目前離線資料任務的主要計算引擎為Apache Spark。
低頻使用字段優化方案
相比于資料表與任務,針對資料表中的低頻使用的字段進行優化是一種更加細粒度的方式。
定位低頻使用字段
在離線數倉建設中,原始日志一般會從消息隊列中直接不加處理的存儲到原始資料層,再通過明細資料層對原始日志進行字段清洗與解析。在實踐中,火山引擎DataLeap研發人員發現處于明細資料層中的原始埋點明細表由于資料量巨大(單表PB量級):在某些資料庫中,僅三張表格就占據了所在資料庫75%的存儲大小,個别資料表的字段平均存儲大小約為150TB。是以,為了更加高效地完成資料表字段優化,研發人員從埋點明細表的埋點字段入手。
和Hive資料表類似,埋點字段也具有以下特點:
- 埋點字段一般也不會對外直接提供查詢,而是以清洗後的次元和名額的形式對外使用
- 衡量一個埋點字段的ROI具有也兩個方面:使用次數與生産成本(存儲+計算成本)。
是以,首先也需要建構埋點的血緣關系樹來統計其使用次數,再以存儲+計算資源消耗來衡量其生産成本,最終才能準确地評價埋點的價值。
為了解決以上兩個問題,研發人員進行了埋點成本分析看闆的開發建設:
- 首先,以原始埋點明細表的埋點字段為根節點,從上(埋點明細Hive表)至下(服務層提供次元、名額查詢的ClickHouse表)建立埋點字段的血緣關系樹
- 進一步将所有葉子節點的次元、名額字段的通路次數累加到相應根節點埋點字段上,作為該根節點埋點字段的使用次數
- 再統計埋點明細資料表的計算資源與存儲資源,獲得該埋點字段的的平均生産成本
- 最後關聯埋點字段的總生産成本與總使用次數,評價該埋點字段的實際的ROI
「埋點字段的生産成本vs使用次數」
優化手段與思路
- 優化手段
① 停止解析和存儲埋點字段
為了減少明細資料層字段的的計算與存儲成本,可以直接對一些低頻使用埋點停止解析與存儲。
但是低頻字段并不等于不使用字段,即如果要下線低頻使用字段,需要保證使用者在偶爾使用時仍然可以擷取。雖然使用頻次不同,但是同一張表中的埋點字段不能分别設定不同的存儲方式或者TTL,隻能選擇存儲或者不存儲。
是以,對于低頻使用埋點,結合使用者的實際使用情況與開發維護成本,可以通過搭建采樣鍊路、從原始資料層臨時擷取等方式滿足偶爾的少量使用場景,進而可以減少明細資料層的字段解析與存儲。
② 拆解埋點字段中常用的部分
還有一些被高頻使用的埋點常常以複雜的url、json的格式上報存儲。而實際在下遊的使用過程中隻會解析擷取部分屬性提供服務。是以,基于準确的擷取下遊的使用方式,将大字段拆解為小字段,不解析存儲不使用的部分。
- 優化思路
配合「埋點成本分析看闆」,根據不同的使用成本與使用次數門檻值将看闆分為四個象限,其中各個象限的資料表的含義及推薦的優化手段為:
象限 | 含義 | 優化手段 | 收益 |
第一象限 | 高成本高頻通路的字段 | ② | 計算資源+存儲資源 |
第二象限 | 高成本低頻通路的字段 | ① ② | 計算資源+存儲資源 |
第三象限 | 低成本低頻通路的字段 | ① ② | 計算資源+存儲資源 |
第四象限 | 低成本高頻通路的字段 | ② | 計算資源+存儲資源 |
根據優化收益進行治理的順序為:第二象限>第三象限>第一象限>第四象限。
總結
基于資料成本分析看闆,結合以上技術方案,如果是累計下線20+張資料表及對應任務,優化10+高成本任務,停止200+資料埋點解析,結合資料表溫存與TTL縮減,初步測算能節省數倉總成本的36%費用。
在梳理了資料表、字段的血緣樹的基礎上,建立了Hive表成本分析看闆、任務成本分析看闆、埋點成本分析看闆等看闆,結合大資料研發治理套件火山引擎DataLeap對數倉建設過程中的資料表、資料任務、埋點字段的成本的進行了由粗到細的梳理與優化,提升了現有資源的承載能力,降低了建設成本。