企業降本增效是越來越熱門的話題，2022年大數據平臺面臨容量增長快，成本壓力大，在二十多個部門緊密合作下，通過建設大數據平臺容量管控體系，全方位應對容量挑戰，最終完成2022年容量控制目標。在此回顧一下大家是如何實現降本增效的。
一
大數據平臺簡介
首先簡單介紹一下微衆銀行大數據平臺架構體系，是一套一站式、金融級、全連通、開源開放的大數據平臺套件，從建設之初就確立了開源+自研的研發路徑，依託開源社區力量共建金融級大數據平臺能力。當前已具備了數據開發應用管理的完備能力，形成了一個“434”陣型：
1. 前場，是數據分析、數據治理、機器學習和運營管理 4 大功能工具工場，提供完整的數據+AI應用開發管理能力。
2. 中場，是計算中間件、元數據中間件和微前端中間件；做到承上啓下，提供連通、管控、擴展、複用等獨有的中間件能力。簡化平臺整體架構，降低開發運維成本。
3. 後場，是批量計算、交互式計算、流式計算和複雜計算 4 大基礎計算存儲模塊。提供面向各場景的基礎計算存儲能力。
整個大數據架構是自上往下、相互依賴的體系，承載的業務應用也是豐富多樣，各應用之前相互依賴，由此引發的容量管控也會比較複雜。
二
爲什麼要做容量管控
在平臺規模還比較小的時候，業務對大數據處理能力需求豐富，平臺建設優先完善平臺功能建設。提供完整、豐富的數據處理分析能力，未對各業務應用的存儲容量和計算資源強加限制，以滿足業務需求。各業務應用的快速上線，大量數據重複全量抽取、多次拷貝，在數倉架構上未統一規劃，數據存儲容量快速增長。同時一些計算量大的任務較少考慮性能優化，主要靠增加計算資源來滿足任務時效。
近年來，隨着業務的發展，各種數據存儲和分析的需求快速增加，到2022年初，集羣機器數已達幾千臺的規模，其中批量集羣存儲幾十PB 數據，日增上百TB，每天離線計算任務有近百萬級。根據近年的統計數據，差不多每年有50%左右的機器規模增長，帶來了較大的成本壓力，容量管控迫在眉睫。
三
面臨的問題與挑戰
我們如何才能在保障平臺和應用穩定，保障數據任務準點執行完成的要求下，將成本降下來。這驅使我們必須建立一套容量管控體系，在資源使用方和資源管理方緊密合作下，通過升級技術，完善工具，並在此過程中控制風險來達成。
2022年大數據平臺的容量管控主要是批量集羣的存儲容量管控。面臨的問題和挑戰主要體現在爲四方面：
指標體系：基礎運營數據指標體系不完善，管控前的指標粒度粗。
流程機制：預算和容量預警等流程機制不健全，大數據成本未能透明到業務側。
平臺工具：工具功能缺失，風險控制能力、性能等均需大幅提升。
業務應用：涉及幾十萬張表，關聯業務和子系統多，數據上下游依賴複雜，需充分評估影響，溝通成本大。改造和清理需確保業務穩定和數據正確，改造成本大。
四
如何做容量管控
我們批量集羣容量管控的思路如下：
首先是對數據資產梳理，完善指標體系和流程機制。業務方根據業務價值做每年的預算，並以此預算建立每月預算限額和對應的容量限額，通過報表形式透明各業務方容量使用及成本分攤情況。
其次是由平臺從基礎引擎和功能工具上進行技術優化，爲業務提供成本治理的方法和工具，比如說數據壓縮能力，表刪除能力、生命週期能力、歸檔能力等能力。
最後是業務方的基於數據價值、管控目標，利用基礎引擎和功能工具提供的輔助能力，優化數倉模型架構，實現容量控制，從而降低成本。
通過對指標體系、流程機制、平臺工具和業務應用四方面的多輪迭代，不斷完善容量管控體系，總體如下：
下面針對指標體系、流程機制、平臺工具和業務應用，詳細介紹具體如何落地。
1、指標體系建設
整個平臺的運營指標，通過統一的數倉架構進行構建，分爲ODS數據採集層、DM數倉層和ADS應用層。對批量計算、交互式、流式計算、複雜計算，進行統一採集運營數據到Hive容量報表數倉，各層級不同組件之間的加工依賴通過調度系統信息串聯，各個組件的採集指標都拆解並關聯到部門/科室、業務產品、子系統維度。以批量集羣存儲容量爲例，直接管控指標包括：總存儲量、總存儲限額，日增存儲、日增限額、剩餘可支撐天數、評價指標（壓縮佔比、歸檔佔比、冷數據佔比、全量切片佔比、ODS佔比，疑似重複數據佔比等）。
2、流程機制建設
主要建立了兩套管控流程：預算跟蹤和容量預警。提供涵蓋大數據平臺所有組件、統一的預算評估計算公式模板，供各業務應用方結合業務需求、業務價值、合理性維度進行評估，並將預算提交部門領導審覈後統一上報，最終根據確定的預算額度制定每月預算限額，每月容量限額。每月統計各部門容量和預算使用情況進行跟蹤，結合管控指標進行分析，對預算/容量預測會超限的部門預警或升級，提供優化措施和優化完成時間。
3、平臺工具完善
對於存量容量的控制，要實現控增量，降存量，需要對底層基礎引擎和功能工具進行開發，以支撐最終降本的目標。
在批量計算基礎引擎上，Hive、Spark統一推薦使用ORC+Snappy進行壓縮存儲，通過開發修復各種數據精度和兼容性問題，通過多輪測試，根據不同應用場景、不同租戶逐步灰度開啓了BDP（Big Data Platform, Hadoop批量集羣，承載核心批量）和BDAP（Big Data Analytical Platform, Hadoop批量集羣，用於探索分析）的默認壓縮功能。
通過分析，批量集羣上的大部分歷史數據很少訪問，因此引入Hadoop的分層存儲技術，開發相關功能，讓我們的Hadoop聯邦集羣支持歸檔能力。通過採購更高存儲密度的專用歸檔機型，壓測通過後，用於將不能通過下線無用表、數據生命週期來節省成本的數據，進行歸檔存儲。實現方式是對存儲介質加上標籤，然後將需要歸檔數據設置成Cold (默認爲Hot)，然後執行HDFS的Mover命令，將歸檔數據從計算機型移動到歸檔機型上。該歸檔機型不具有計算能力，只提供數據存儲，單機存儲容量是計算機型的9倍，單機價格只是計算機型的1.7倍。整個歸檔過程對用戶無感，無需恢復即可訪問歷史冷數據。
Hadoop引入歸檔後，計算機型的擴容將會變少，對於計算資源的消耗需求還在，因此還對YARN調度性能進行優化，通過優化排序比較函數、優化作業跳過時間、隊列並行排序優化等技術升級。同時提供基於規則的動態隊列功能，定時調整同部門下多個隊列的計算資源配置，實現計算資源的充分利用。
在功能工具上，通過開發運營門戶系統(Portalis), 元數據中間件(DataShapis)和數據操作管理系統(DOPS)輔助進行容量管控的落地。其中Portalis提供預算管理和成本分攤功能；DMS提供元數據管理，數據血緣分析，生命週期規則管理功能，降低操作風險，提升管理效率；DOPS串聯DataShapis、計算中間件Linkis和數據質量校驗Qualitis，提供數據壓縮，數據清理與恢復，數據歸檔和小文件合併功能，在確保數據準確和可恢復前提下，完成管控措施的真正落地。DOPS系統架構如下：
4、業務應用優化
整個批量集羣容量控制，最終都需要由各業務應用方通過制定相關規則和進行數倉架構優化才能真實落地。各業務應用方利用平臺提供的運營數據，進行數據資產梳理，進一步將表歸屬及目標分解到對應具體的負責人，識別依賴，評估操作風險，提單申請進行數據壓縮、無用表下線、數據生命週期清理和數據歸檔。同時通過優化數倉架構和業務邏輯，制定數倉開發規範，開發拉鍊表改造工具，逐步實施每日全量切片改增量切片或改造成成拉鍊表，降低日增存儲。
五
容量管控效果
通過各部門的緊密合作，容量管控效果顯著。2022年管控後，總存儲量較管控前增長預估節省幾十PB,日增降幅30%+，預估節省成本（包含增量收益）在千萬以上。
同時DOPS數據清理性能從提升到百萬分區/天，提升10倍；數據壓縮性能也提升到上百TB/天，提升17倍；數據歸檔性能提升到近百TB/天，提升73倍。相關工具的逐步完善爲長效容量管控夯實基礎。
六
總結與展望
回顧2022年的整個容量管控過程，容量管控體系分爲指標體系、流程機制、平臺工具和業務應用。通過指標體系建設，讓業務方瞭解各業務產品在大數據平臺上的資源及成本使用情況，更好地評價數據的業務價值；通過預算和容量預警機制，確保預算和容量使用情況得到有效跟蹤；通過對基礎引擎和功能工具的建設，幫助業務方在風險可控條件下進行容量控制，提升容量管控的效率，實現降本增效；通過業務應用側深入優化，從根源上實現批量計算存儲增長更可控，與業務增長曲線更吻合。
最後分享一些成本管控的思考與展望：
首先，成本管控需要依靠於體系化的建設，相關指標、流程機制和平臺工具的完善是整個管控過程能夠有效運轉的基礎。這樣才能實現業務的自助式治理從而達到持續控本目標，這樣做大數據團隊可以釋放更多精力進行一些技術相關的成本優化探索。
其次，大數據場景多樣性且有個性化特徵，成本優化需要持續精進不斷地探索。2023年將繼續在現有基礎上完善數據生命週期管理，同時覆蓋交互式計算、流式計算和複雜計算等基礎引擎。如ES/KAFKA/HBASE等小集羣合併；批量集羣減少不必要的容量同步，優化容災；細粒度的行列授權支持，用權限控制替代行列拆表，減少數據拷貝；BDP和BDAP計算資源打通，提升資源利用率；以及對批量Job進行任務診斷，基於健康度的方式進行運營，持續優化。
第三，大數據計算存儲技術快速更新，存算分離、容器化調度、湖倉一體、流批一體等技術是大數據發展的趨勢，我們也將探索計算存儲成本更低的技術，進一步實現成本優化。
如何成爲社區貢獻者
1 ► 官方文檔貢獻。發現文檔的不足、優化文檔，持續更新文檔等方式參與社區貢獻。通過文檔貢獻，讓開發者熟悉如何提交PR和真正參與到社區的建設。參考攻略：保姆級教程：如何成爲Apache Linkis文檔貢獻者
2 ► 代碼貢獻。我們梳理了社區中簡單並且容易入門的的任務，非常適合新人做代碼貢獻。請查閱新手任務列表：https://github.com/apache/incubator-linkis/issues/1161
3 ► 內容貢獻：發佈WeDataSphere開源組件相關的內容，包括但不限於安裝部署教程、使用經驗、案例實踐等，形式不限，請投稿給小助手。例如：
4 ► 社區答疑：積極在社區中進行答疑、分享技術、幫助開發者解決問題等；
5 ► 其他：積極參與社區活動、成爲社區志願者、幫助社區宣傳、爲社區發展提供有效建議等；
本文分享自微信公衆號 - WeDataSphere（gh_273e85fce73b）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。