火山引擎Dataleap治理實踐：如何降低數倉建設成本
背景
存儲與計算資源是數倉建設的基礎，也是數倉建設中的重要成本支出。而隨著數倉建設規模逐漸擴大、時間跨度逐漸拉長，將不可避免的出現數據表、任務、字段的冗余。
技術路線
針對數倉建設成本治理的粒度從大到小可以分為：數據表、數據任務、數據表字段。從粗到細的治理優化思路如下：
- 當發現低頻使用的數據表時，下線對應數據表的同時也刪除對應數據任務；
- 當數據任務資源浪費嚴重，針對任務進行對應的代碼與資源優化；
- 當發現一張表中個別字段使用使用頻率很低，停止相關字段的計算與存儲。
根據以上的優化思路，首先要解決如何定位低頻使用數據表、高資源浪費率任務、低頻使用字段的問題，在此基礎上，針對不同的場景通過不同的手段進行優化。
"數倉建設成本分析"看板總覽
技術方案
低頻使用數據表優化方案
定位低頻使用數據表
火山引擎DataLeap提供了Hive表的資源治理功能，包括Hive表的存儲與訪問次數等基本信息查詢，用戶可以根據該功能直接定位低頻使用數據表并進行優化。
- 但是以上的優化存在以下缺陷：
- 使用 Hive 表的直接查詢次數無法準確衡量用戶對于數據的實際使用次數：為了保障查詢速度，數據一般會由Hive表導入到ClickHouse等查詢速度較快的介質中，而不會直接查詢Hive表。因此，一張Hive表的直接訪問次數一般是由下游的日常數據任務產生，而不是真正的用戶查詢。
- 缺少了對數據表生產過程中計算資源的統計：數據表在生產的過程中，除了占用存儲資源，計算資源是不可或缺的一部分：存在經過復雜計算過程后，產出很小數據量的數據表。因此，當希望對成本進行快速優化時需要瞄準高成本的數據表時，只著眼于數據表占用的存儲資源是不夠全面的。
Hive表成本分析看板
https://data.bytedance.net/aeolus/#/dashboard/437272?appId=555186&sheetId=440345
為了解決以上兩個問題，火山引擎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對數倉建設過程中的數據表、數據任務、埋點字段的成本的進行了由粗到細的梳理與優化，提升了現有資源的承載能力，降低了建設成本。
