上節(jié)討論了如何保障數(shù)據(jù)中臺的數(shù)據(jù)質(zhì)量，讓數(shù)據(jù)“準”。除了“快”和“準”，數(shù)據(jù)中臺還離不開“省”。隨數(shù)據(jù)規(guī)模越來越大，成本越來越高，如不合理控制成本，還沒等你挖掘出數(shù)據(jù)應(yīng)用價值，企業(yè)利潤就被消耗完。

能否做到精細化成本管理，關(guān)乎數(shù)據(jù)中臺項目成敗。

某電商業(yè)務(wù)數(shù)據(jù)建設(shè)資源增長趨勢（CU= 1vcpu + 4G memory）：

某電商平臺的大數(shù)據(jù)資源消耗增長趨勢，2019全年資源規(guī)模25000CU，全年機器預算3500W。對創(chuàng)業(yè)企業(yè)顯然不小開支。

一天，數(shù)據(jù)團隊負責人李好看被CEO叫到了辦公室：

• 這3500W花在什么業(yè)務(wù)？
• 你們做了哪些成本優(yōu)化的舉措，效果如何？

把李問懵，他心想：團隊的成本是按機器又不是數(shù)據(jù)應(yīng)用核算。在數(shù)據(jù)中臺中，數(shù)據(jù)應(yīng)用之間的底層數(shù)據(jù)是復用的，那具體每個數(shù)據(jù)產(chǎn)品或者報表花了多少錢，自己沒有這樣的數(shù)據(jù)啊，咋可能知道。

可對CEO這些很重要，因為資源有限，他須確保資源都用在戰(zhàn)略目標的關(guān)鍵節(jié)點。如電商團隊今年核心KPI是提升單個注冊會員在平臺的消費額，老板角度，他須確保資源都投入與KPI相關(guān)業(yè)務(wù)，如基于數(shù)據(jù)對注冊會員精準化營銷，提升會員在平臺的消費額。

自己所在的團隊是否發(fā)生過類似的事情？ 數(shù)據(jù)部門是企業(yè)的成本中心，如要展現(xiàn)自己的價值：

• 支撐好業(yè)務(wù)，獲得業(yè)務(wù)的認可
• 精簡成本，為公司省錢

所以，今天重點在省錢，聊數(shù)據(jù)中臺的精細化成本管理。

1 成本陷阱

一開始建設(shè)數(shù)據(jù)中臺時，你往往會關(guān)注新業(yè)務(wù)的接入，數(shù)據(jù)的整合，數(shù)據(jù)價值的挖掘上，忽略成本管控的問題，從而落入陷阱中，造成成本爆炸式的增長。所以，有必要深入了解有哪些陷阱，盡量在日常開發(fā)中避免。

這里總結(jié)8種陷阱：

• 1~3廣泛存在，但易被忽略
• 4~8涉及數(shù)據(jù)開發(fā)中一些技能，開發(fā)時注意就可

“知其然，更要知其所以然”，才能發(fā)現(xiàn)問題本質(zhì)，深入掌握解決問題的方法。

1.1 數(shù)據(jù)上線容易，下線難

某數(shù)據(jù)中臺項目，表相關(guān)的使用統(tǒng)計。一半的表30d內(nèi)都沒有訪問，而這些表占26%存儲。如把這些表的產(chǎn)出任務(wù)單獨拎出，高峰期需消耗5000Core CPU計算資源，換算成服務(wù)器需125臺（按一臺服務(wù)器可分配CPU 40Core計算），成本一年近500W。自己竟然有這么多無用數(shù)據(jù)？我經(jīng)常把數(shù)據(jù)比作手機中的圖片，我們不斷拍照生圖，卻懶得清，最終手機存儲經(jīng)常不夠。

無法及時清數(shù)據(jù)，數(shù)據(jù)開發(fā)也有苦衷。他們不知道一個表：

• 還有哪些任務(wù)在引用
• 還有哪些人在查詢

自然不敢停止這個表的數(shù)據(jù)加工，導致數(shù)據(jù)上線易，下線難。

1.2 低價值的數(shù)據(jù)應(yīng)用消耗了大量的資源

數(shù)據(jù)看上去每天都被訪問，但究竟產(chǎn)出多少價值，ROI值得嗎？

有個寬表（擁有很多列的表，經(jīng)常出現(xiàn)在數(shù)據(jù)中臺下游的匯總層數(shù)據(jù)中），加上上游加工鏈路的任務(wù)，每天加工這張寬表要消耗6000塊錢，一年200W，可追查后我們發(fā)現(xiàn)，這張寬表實際每天只有一個人在使用，還是一個運營的實習生。顯然，投入和產(chǎn)出極不匹配。

間接說明，數(shù)據(jù)部門比較關(guān)注新的數(shù)據(jù)產(chǎn)品帶給業(yè)務(wù)的價值，卻忽略已存產(chǎn)品或報表是否還存在價值，最終導致低價值的應(yīng)用仍大量耗資源。

1.3 煙囪式的開發(fā)模式

不僅研發(fā)效率低，因數(shù)據(jù)重復加工，還資源浪費。一張500T表，加工這表，計算任務(wù)需高峰期消耗300Core，折合7臺服務(wù)器（按一臺服務(wù)器可分配CPU 40Core計算），加上存儲盤成本(按照0.7 元/TB*天計算)，一年消耗40W。

而這張表每復用一次，就可節(jié)省40W。所以模型復用，還可實現(xiàn)省錢。

第四，數(shù)據(jù)傾斜。

數(shù)據(jù)傾斜會讓任務(wù)性能變差，也會浪費大量的資源，那什么是數(shù)據(jù)傾斜呢？

你肯定聽說過木桶效應(yīng)吧？一個木桶裝多少水，主要取決于最短的那塊板。對于一個分布式并行計算框架來說，這個效應(yīng)同樣存在。對于Spark計算引擎來說，它可以將海量的數(shù)據(jù)切分成不同的分片（Partition），分配到不同機器運行的任務(wù)中，進行并行計算，從而實現(xiàn)計算能力水平擴展。

但是整個任務(wù)的運行時長，其實取決于運行最長的那個任務(wù)。因為每個分片的數(shù)據(jù)量可能不同，每個任務(wù)需要的資源也不相同。由于不同的任務(wù)不能分配不同的資源，所以，總?cè)蝿?wù)消耗資源=max{單個任務(wù)消耗的資源} * 任務(wù)數(shù)量。這樣一來，數(shù)據(jù)量小的任務(wù)會消耗更多的資源，就會造成資源的浪費。

我們還是舉個電商場景的例子。

假設(shè)你需要按照商戶粒度統(tǒng)計每個商戶的交易金額，此時，我們需要對訂單流水表按照商戶進行g(shù)roup by計算。在平臺上，每個商戶的訂單交易量實際差距很大，有的訂單交易量很多，有的卻比較少。

我們利用Spark SQL完成計算過程。

在上圖中，任務(wù)A 讀取了左邊某個分片的數(shù)據(jù)，按照供應(yīng)商進行聚合，然后輸出給下一個Stage的B、C、D任務(wù)。

你可以看到，聚合后，B、C和D任務(wù)輸入的數(shù)據(jù)量有很大的不同，B處理的數(shù)據(jù)量比C和D多，消耗的內(nèi)存自然更多，假設(shè)單個Executor需要分配16G，而B、C、D不能設(shè)置不同的內(nèi)存大小，所以C和D也都設(shè)置了16G?？蓪嶋H上，按照C和D的數(shù)據(jù)量，只需要4G就夠了。這就造成了C和D 任務(wù)資源分配的浪費。

第五，數(shù)據(jù)未設(shè)置生命周期。

在06講中，我強調(diào)，一般原始數(shù)據(jù)和明細數(shù)據(jù)，會保留完整的歷史數(shù)據(jù)。而在匯總層、集市層或者應(yīng)用層，考慮到存儲成本，數(shù)據(jù)建議按照生命周期來管理，通常保留幾天的快照或者分區(qū)。如果存在大表沒有設(shè)置生命周期，就會浪費存儲資源。

第六，調(diào)度周期不合理。

通過這張圖你可以看到，大數(shù)據(jù)任務(wù)的資源消耗有很明顯的高峰和低谷效應(yīng)，一般晚上12點到第二天的9點是高峰期，9點到晚上12點，是低谷期。

雖然任務(wù)有明顯的高峰低谷效應(yīng)，但是服務(wù)器資源不是彈性的，所以就會出現(xiàn)服務(wù)器在低谷期比較空閑，在高峰期比較繁忙的情況，整個集群的資源配置取決于高峰期的任務(wù)消耗。所以，把一些不必要在高峰期內(nèi)運行任務(wù)遷移到低谷期運行，也可以節(jié)省資源的消耗。

第七，任務(wù)參數(shù)配置。

任務(wù)參數(shù)配置的不合理，往往也會浪費資源。比如在Spark中，Executor 內(nèi)存設(shè)置的過大；CPU設(shè)置的過多；還有Spark 沒有開啟動態(tài)資源分配策略，一些已經(jīng)運行完Task的Executor 不能釋放，持續(xù)占用資源，尤其是遇到數(shù)據(jù)傾斜的情況，資源浪費會更加明顯。

第八，數(shù)據(jù)未壓縮。

Hadoop 的HDFS 為了實現(xiàn)高可用，默認數(shù)據(jù)存儲3副本，所以大數(shù)據(jù)的物理存儲量消耗是比較大的。尤其是對于一些原始數(shù)據(jù)層和明細數(shù)據(jù)層的大表，動輒500多T，折合物理存儲需要1.5P（三副本，所以實際物理存儲5003），大約需要16臺物理服務(wù)器（一臺服務(wù)器可分配存儲按照128T計算），如果不啟用壓縮，存儲資源成本會很高。

另外，在Hive或者Spark 計算過程中，中間結(jié)果也需要壓縮，可以降低網(wǎng)絡(luò)傳輸量，提高Shuffer (在Hive或者Spark 計算過程中，數(shù)據(jù)在不同節(jié)點之間的傳輸過程)性能。

你看，我為你列舉了8個典型的成本陷阱，那你可能會問了，老師，我已經(jīng)中招了，該怎么辦呢？ 別急，接下來我們就看一看，如何進行精細化的成本管理。

2 如何實現(xiàn)精細化成本管理？

成本治理應(yīng)遵循全局盤點、發(fā)現(xiàn)問題、治理優(yōu)化和效果評估四步。

2.1 全局資產(chǎn)盤點

對數(shù)據(jù)中臺中，所有的數(shù)據(jù)進行一次全面盤點，基于元數(shù)據(jù)中心提供的數(shù)據(jù)血緣，建立全鏈路的數(shù)據(jù)資產(chǎn)視圖。

全鏈路數(shù)據(jù)資產(chǎn)視圖：

• 下游末端關(guān)聯(lián)到數(shù)據(jù)應(yīng)用（報表：財務(wù)分析）
• 上游起點是剛進入數(shù)據(jù)中臺的原始數(shù)據(jù)
• 數(shù)據(jù)之間通過任務(wù)進行連接

計算全鏈路數(shù)據(jù)資產(chǎn)視圖中，末端數(shù)據(jù)的成本和價值（末端數(shù)據(jù)就是加工鏈路最下游的表，例如圖中TableA，Table G）。

為什么一定要從末端開始？ 因為中間數(shù)據(jù)在計算價值時，還要考慮下游表被使用的情況，較難計算清楚，所以從末端數(shù)據(jù)開始。這與下線表的順序也一致，如數(shù)據(jù)的價值很低，成本很高，也從末端數(shù)據(jù)開始下線。

數(shù)據(jù)成本該如何計算？

對上圖中財務(wù)分析報表核算成本，這報表上游鏈路中涉及a，b，c，3個任務(wù)，A，B，C，D，E，F(xiàn)， 6張表：

這張報表的成本=3個任務(wù)加工消耗的計算資源成本+6張表消耗的存儲資源的成本。

如一個表被多個下游應(yīng)用復用，那這個表的存儲資源成本以及產(chǎn)出任務(wù)消耗的成本，需分攤給多個應(yīng)用。

那價值又該如何計算？

如末端數(shù)據(jù)是一張應(yīng)用層的表，它對接的是一個數(shù)據(jù)報表，那衡量這數(shù)據(jù)價值主要看報表的使用范圍和使用頻率。

計算使用范圍時，通常用周活評估，同時還要考慮不同管理級別的人權(quán)重，對老板，他一個人權(quán)重可相當1000個普通員工。所以這樣設(shè)計考慮到管理級別越高，做出商業(yè)決策影響越大，自然價值越大。使用頻率一般使用單個用戶每周查看報表的次數(shù)來衡量，次數(shù)越高，說明報表價值越大。

如末端數(shù)據(jù)對接的不是一個數(shù)據(jù)報表，而是面向特定場景的數(shù)據(jù)應(yīng)用（比如我之前提到過的供應(yīng)鏈分析決策系統(tǒng)，它面向的人群主要是供應(yīng)鏈部門）。衡量這類產(chǎn)品的價值，主要考慮目標人群的覆蓋率和直接業(yè)務(wù)價值產(chǎn)出。什么是直接業(yè)務(wù)價值產(chǎn)出呢？，在供應(yīng)鏈決策系統(tǒng)中，就是通過系統(tǒng)自動生成的采購訂單占所有采購訂單的比例。

末端數(shù)據(jù)可能還是一張集市層的表，主要用于提供給分析師做探索式查詢。這類表的價值看它被哪些分析師使用，使用頻率。使用范圍評估時，也要對分析師按級別加權(quán)。

2.2 發(fā)現(xiàn)問題

全局盤點為發(fā)現(xiàn)問題提供數(shù)據(jù)支撐，關(guān)注：

• 持續(xù)產(chǎn)生成本，但已沒有使用的末端數(shù)據(jù)（一般指30天內(nèi)無訪問）

  沒有使用，但一直在消耗成本的表，對應(yīng)的就是我提到的陷阱1

• 數(shù)據(jù)應(yīng)用價值很低，成本卻很高，這些數(shù)據(jù)應(yīng)用上游鏈路上的所有相關(guān)數(shù)據(jù)

  低價值產(chǎn)出，高成本的數(shù)據(jù)應(yīng)用，對應(yīng)的是陷阱2

• 高峰期高消耗的數(shù)據(jù)

  高成本的數(shù)據(jù)，對應(yīng)陷阱4～8

陷阱3實際是在第6節(jié)模型設(shè)計中解決的。

2.3 治理優(yōu)化

針對這三類問題制訂相應(yīng)策略。

第一類，應(yīng)對表下線。 數(shù)據(jù)下線要謹慎，參考數(shù)據(jù)下線的執(zhí)行過程圖：

末端數(shù)據(jù)刪除后，原先末端數(shù)據(jù)的上游數(shù)據(jù)會成為新的末端數(shù)據(jù)，同樣還要按發(fā)現(xiàn)問題到治理優(yōu)化進行重復，直到所有的末端數(shù)據(jù)都不滿足下線策略為止。

對第二類問題，我們需要按照應(yīng)用粒度評估應(yīng)用是否還有存在的必要。對于報表，可以按照30天內(nèi)沒有訪問的應(yīng)用自動下線的策略，先對報表進行銷毀，然后對報表上游的表進行下線，如果該表還被其他的應(yīng)用引用，就不能下線。下線步驟可以參考前面的下線步驟。

第三類問題，主要是針對高消耗的數(shù)據(jù)，又具體分為產(chǎn)出數(shù)據(jù)的任務(wù)高消耗和數(shù)據(jù)存儲高消耗。對于產(chǎn)出任務(wù)高消耗，首先要考慮是不是數(shù)據(jù)傾斜。具體怎么判斷呢？其實你可以通過MR或者Spark日志中，Shuffer的數(shù)據(jù)量進行判斷。如果有某一個Task 數(shù)據(jù)量非常大，其他的很少，就可以判定出現(xiàn)了數(shù)據(jù)傾斜。

圖 Spark task shuffer records：

圖 MR reduce task records：

數(shù)據(jù)傾斜處理？

不同的場景有一些適用的解決方案：

• 如一些大表和小表關(guān)聯(lián)時，Key分布不均造成數(shù)據(jù)傾斜，可使用mapjoin
• 較通用的處理方式，如把熱點Key單獨處理，然后對剩下的Key進行處理，然后對結(jié)果進行并集

推薦閱讀

除數(shù)據(jù)傾斜，還應(yīng)該查任務(wù)的配置參數(shù)。如Spark執(zhí)行引擎：

• Executor個數(shù)是否過大
• executor-cores和executor-memory是否過多，利用率較低

一般executors-memorty 設(shè)4G-8G，executor-cores設(shè)2-4個（實踐過利用率最高的配置項）。

還要考慮任務(wù)是否真有必要在高峰期執(zhí)行，可根據(jù)集群負載情況，盡量將任務(wù)遷移到非高峰期執(zhí)行，“削峰填谷”。

上面幾點是產(chǎn)出任務(wù)高消耗的情況。

對存儲消耗比較大的任務(wù)，先考慮是否要壓縮，尤其對原始數(shù)據(jù)層和明細數(shù)據(jù)層，建議壓縮

壓縮方式

• 小文件的壓縮，不考慮split，gzip較合適
• 大文件，推薦lzo，支持split，在保證壓縮效率前提下，有相對穩(wěn)定壓縮比

還要考慮生命周期是否設(shè)置：

• ODS原始數(shù)據(jù)層和DWD 明細數(shù)據(jù)層，適合用永久保留策略
• 一些商品、用戶維表，可考慮3、5年保留策略

整體上，底層表都是長期保留。關(guān)注重點應(yīng)是匯總層以上的表（包括匯總層），一般可根據(jù)數(shù)據(jù)的重要性，制訂7天，1個月保留策略。

治理效果評估

量化治理成果 - 省了多少錢

若直接拿服務(wù)器數(shù)量來衡量，不能真實反應(yīng)治理效果，因為還要考慮業(yè)務(wù)增長原因，可圍繞任務(wù)和數(shù)據(jù)的成本考慮：

• 下線了多少任務(wù)和數(shù)據(jù)
• 這些任務(wù)每日消耗了多少資源
• 數(shù)據(jù)占用了多少存儲空間

拿這些資源來計算成本，就能算出省了多少錢。如開頭案例，任務(wù)A運行3h，在運行過程中，共消耗5384503 cpu*s，37007892 GB *s, 假設(shè)我們1個CU （1 cpu， 4g memeory）一年是1300元成本，折合每天為3.5元（計算公式為1300/365）。

不論是優(yōu)化或下線任務(wù)，只統(tǒng)計高峰時間段內(nèi)，因為優(yōu)化低峰時間無法實際節(jié)省資源。

高峰時間段為8h，那折合每s費用0.00012153，則該任的費用為max{5384503*0.00012153, 37007892/4 * 0.00012153} = max{654, 1124} = 1124 。下線這任務(wù)后節(jié)省1124元，再加上表A占用的存儲空間大小乘以每GB的成本，可得數(shù)據(jù)表A下線節(jié)省費用。

成本治理中心

成本治理不是一勞永逸的工作，需要持之以恒，不斷發(fā)現(xiàn)問題，然后治理優(yōu)化，建立長久運行機制的前提是必須降低成本治理的門檻，接下來，看一下網(wǎng)易的一個成本治理的平臺，EasyCost。

系統(tǒng)提供了數(shù)據(jù)診斷的功能，可以按照訪問時間、訪問頻率、關(guān)聯(lián)的應(yīng)用，設(shè)置下線策略，支持一鍵灰度下線，大幅提高了管理的效率。

可通過系統(tǒng)化方式沉淀到產(chǎn)品，然后通過產(chǎn)品提高管理效率，實現(xiàn)治理機制的長久落地。

總結(jié)

通過數(shù)據(jù)中臺：

• 可獲得大數(shù)據(jù)作為資產(chǎn)中心帶來的紅利
• 也可能陷入成本的深淵，為野蠻增長的大數(shù)據(jù)費用買單

從常見成本陷阱入手，分析可能造成成本浪費的原因，然后介紹精細化成本管理的方法，最后強調(diào)：

• 無用數(shù)據(jù)的下線應(yīng)該從全鏈路數(shù)據(jù)資產(chǎn)視圖的末端入手，然后抽絲剝繭，一層一層，向數(shù)據(jù)加工鏈路的上游推進。
• 應(yīng)用層表的價值應(yīng)該以數(shù)據(jù)應(yīng)用的價值來衡量，對于低價值產(chǎn)出的應(yīng)用，應(yīng)該以應(yīng)用為粒度進行下線。
• 對高消耗任務(wù)的優(yōu)化只要關(guān)注集群高峰期的任務(wù)，項目的整體資源消耗只取決于高峰期的任務(wù)消耗，當然，如果你使用的是公有云的資源，可以高峰和低谷實施差異化的成本結(jié)算，那低谷期的也是要關(guān)注的。

FAQ

在數(shù)據(jù)中臺的集市層，存在一些大寬表，幾百個字段，上游可能數(shù)十個表，如計算這個表的成本會非常高。這表中，字段訪問頻率不同，優(yōu)化這張寬表?

1. 垂直切分：將寬表按照字段的訪問頻率劃分，將訪問頻率高的字段單獨劃分為一張表，訪問頻率低的字段單獨劃分為一張表。這樣可以減少查詢時掃描的字段數(shù)，提高查詢效率

2. 水平切分：將寬表按照行進行切分，將每個切分后的表中的字段數(shù)控制在可接受的范圍內(nèi)，這樣可以減少單個表的字段數(shù)，提高查詢效率

3. 建立索引：對于寬表中的訪問頻率高的字段，可以建立索引，這樣可以加快查詢速度

4. 緩存機制：對于查詢頻率高的數(shù)據(jù)，可以采用緩存機制，將數(shù)據(jù)緩存在內(nèi)存中，這樣可以減少查詢時間

5. 數(shù)據(jù)壓縮：對于寬表中的冷數(shù)據(jù)，可以采用數(shù)據(jù)壓縮技術(shù)，減少存儲空間，提高查詢效率

可根據(jù)實際情況選擇合適的優(yōu)化方式來提高查詢效率。

本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布！文章來源地址http://www.zghlxwxcb.cn/news/detail-607807.html

到了這里，關(guān)于如何在數(shù)據(jù)中臺中提高效率并節(jié)省成本？的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！