上節(jié)討論了如何保障數(shù)據(jù)中臺(tái)的數(shù)據(jù)質(zhì)量，讓數(shù)據(jù)“準(zhǔn)”。除了“快”和“準(zhǔn)”，數(shù)據(jù)中臺(tái)還離不開(kāi)“省”。隨數(shù)據(jù)規(guī)模越來(lái)越大，成本越來(lái)越高，如不合理控制成本，還沒(méi)等你挖掘出數(shù)據(jù)應(yīng)用價(jià)值，企業(yè)利潤(rùn)就被消耗完。
能否做到精細(xì)化成本管理，關(guān)乎數(shù)據(jù)中臺(tái)項(xiàng)目成敗。
某電商業(yè)務(wù)數(shù)據(jù)建設(shè)資源增長(zhǎng)趨勢(shì)（CU= 1vcpu + 4G memory）：
某電商平臺(tái)的大數(shù)據(jù)資源消耗增長(zhǎng)趨勢(shì)，2019全年資源規(guī)模25000CU，全年機(jī)器預(yù)算3500W。對(duì)創(chuàng)業(yè)企業(yè)顯然不小開(kāi)支。
一天，數(shù)據(jù)團(tuán)隊(duì)負(fù)責(zé)人李好看被CEO叫到了辦公室：
- 這3500W花在什么業(yè)務(wù)？
- 你們做了哪些成本優(yōu)化的舉措，效果如何？
把李問(wèn)懵，他心想：團(tuán)隊(duì)的成本是按機(jī)器又不是數(shù)據(jù)應(yīng)用核算。在數(shù)據(jù)中臺(tái)中，數(shù)據(jù)應(yīng)用之間的底層數(shù)據(jù)是復(fù)用的，那具體每個(gè)數(shù)據(jù)產(chǎn)品或者報(bào)表花了多少錢，自己沒(méi)有這樣的數(shù)據(jù)啊，咋可能知道。
可對(duì)CEO這些很重要，因?yàn)橘Y源有限，他須確保資源都用在戰(zhàn)略目標(biāo)的關(guān)鍵節(jié)點(diǎn)。如電商團(tuán)隊(duì)今年核心KPI是提升單個(gè)注冊(cè)會(huì)員在平臺(tái)的消費(fèi)額，老板角度，他須確保資源都投入與KPI相關(guān)業(yè)務(wù)，如基于數(shù)據(jù)對(duì)注冊(cè)會(huì)員精準(zhǔn)化營(yíng)銷，提升會(huì)員在平臺(tái)的消費(fèi)額。
自己所在的團(tuán)隊(duì)是否發(fā)生過(guò)類似的事情？ 數(shù)據(jù)部門是企業(yè)的成本中心，如要展現(xiàn)自己的價(jià)值：
- 支撐好業(yè)務(wù)，獲得業(yè)務(wù)的認(rèn)可
- 精簡(jiǎn)成本，為公司省錢
所以，今天重點(diǎn)在省錢，聊數(shù)據(jù)中臺(tái)的精細(xì)化成本管理。
1 成本陷阱
一開(kāi)始建設(shè)數(shù)據(jù)中臺(tái)時(shí)，你往往會(huì)關(guān)注新業(yè)務(wù)的接入，數(shù)據(jù)的整合，數(shù)據(jù)價(jià)值的挖掘上，忽略成本管控的問(wèn)題，從而落入陷阱中，造成成本爆炸式的增長(zhǎng)。所以，有必要深入了解有哪些陷阱，盡量在日常開(kāi)發(fā)中避免。
這里總結(jié)8種陷阱：
- 1~3廣泛存在，但易被忽略
- 4~8涉及數(shù)據(jù)開(kāi)發(fā)中一些技能，開(kāi)發(fā)時(shí)注意就可
“知其然，更要知其所以然”，才能發(fā)現(xiàn)問(wèn)題本質(zhì)，深入掌握解決問(wèn)題的方法。
1.1 數(shù)據(jù)上線容易，下線難
某數(shù)據(jù)中臺(tái)項(xiàng)目，表相關(guān)的使用統(tǒng)計(jì)。一半的表30d內(nèi)都沒(méi)有訪問(wèn)，而這些表占26%存儲(chǔ)。如把這些表的產(chǎn)出任務(wù)單獨(dú)拎出，高峰期需消耗5000Core CPU計(jì)算資源，換算成服務(wù)器需125臺(tái)（按一臺(tái)服務(wù)器可分配CPU 40Core計(jì)算），成本一年近500W。自己竟然有這么多無(wú)用數(shù)據(jù)？我經(jīng)常把數(shù)據(jù)比作手機(jī)中的圖片，我們不斷拍照生圖，卻懶得清，最終手機(jī)存儲(chǔ)經(jīng)常不夠。
無(wú)法及時(shí)清數(shù)據(jù)，數(shù)據(jù)開(kāi)發(fā)也有苦衷。他們不知道一個(gè)表：
- 還有哪些任務(wù)在引用
- 還有哪些人在查詢
自然不敢停止這個(gè)表的數(shù)據(jù)加工，導(dǎo)致數(shù)據(jù)上線易，下線難。
1.2 低價(jià)值的數(shù)據(jù)應(yīng)用消耗了大量的資源
數(shù)據(jù)看上去每天都被訪問(wèn)，但究竟產(chǎn)出多少價(jià)值，ROI值得嗎？
有個(gè)寬表（擁有很多列的表，經(jīng)常出現(xiàn)在數(shù)據(jù)中臺(tái)下游的匯總層數(shù)據(jù)中），加上上游加工鏈路的任務(wù)，每天加工這張寬表要消耗6000塊錢，一年200W，可追查后我們發(fā)現(xiàn)，這張寬表實(shí)際每天只有一個(gè)人在使用，還是一個(gè)運(yùn)營(yíng)的實(shí)習(xí)生。顯然，投入和產(chǎn)出極不匹配。
間接說(shuō)明，數(shù)據(jù)部門比較關(guān)注新的數(shù)據(jù)產(chǎn)品帶給業(yè)務(wù)的價(jià)值，卻忽略已存產(chǎn)品或報(bào)表是否還存在價(jià)值，最終導(dǎo)致低價(jià)值的應(yīng)用仍大量耗資源。
1.3 煙囪式的開(kāi)發(fā)模式
不僅研發(fā)效率低，因數(shù)據(jù)重復(fù)加工，還資源浪費(fèi)。一張500T表，加工這表，計(jì)算任務(wù)需高峰期消耗300Core，折合7臺(tái)服務(wù)器（按一臺(tái)服務(wù)器可分配CPU 40Core計(jì)算），加上存儲(chǔ)盤成本(按照0.7 元/TB*天計(jì)算)，一年消耗40W。
而這張表每復(fù)用一次，就可節(jié)省40W。所以模型復(fù)用，還可實(shí)現(xiàn)省錢。
第四，數(shù)據(jù)傾斜。
數(shù)據(jù)傾斜會(huì)讓任務(wù)性能變差，也會(huì)浪費(fèi)大量的資源，那什么是數(shù)據(jù)傾斜呢？
你肯定聽(tīng)說(shuō)過(guò)木桶效應(yīng)吧？一個(gè)木桶裝多少水，主要取決于最短的那塊板。對(duì)于一個(gè)分布式并行計(jì)算框架來(lái)說(shuō)，這個(gè)效應(yīng)同樣存在。對(duì)于Spark計(jì)算引擎來(lái)說(shuō)，它可以將海量的數(shù)據(jù)切分成不同的分片（Partition），分配到不同機(jī)器運(yùn)行的任務(wù)中，進(jìn)行并行計(jì)算，從而實(shí)現(xiàn)計(jì)算能力水平擴(kuò)展。
但是整個(gè)任務(wù)的運(yùn)行時(shí)長(zhǎng)，其實(shí)取決于運(yùn)行最長(zhǎng)的那個(gè)任務(wù)。因?yàn)槊總€(gè)分片的數(shù)據(jù)量可能不同，每個(gè)任務(wù)需要的資源也不相同。由于不同的任務(wù)不能分配不同的資源，所以，總?cè)蝿?wù)消耗資源=max{單個(gè)任務(wù)消耗的資源} * 任務(wù)數(shù)量。這樣一來(lái)，數(shù)據(jù)量小的任務(wù)會(huì)消耗更多的資源，就會(huì)造成資源的浪費(fèi)。
我們還是舉個(gè)電商場(chǎng)景的例子。
假設(shè)你需要按照商戶粒度統(tǒng)計(jì)每個(gè)商戶的交易金額，此時(shí)，我們需要對(duì)訂單流水表按照商戶進(jìn)行g(shù)roup by計(jì)算。在平臺(tái)上，每個(gè)商戶的訂單交易量實(shí)際差距很大，有的訂單交易量很多，有的卻比較少。
我們利用Spark SQL完成計(jì)算過(guò)程。
在上圖中，任務(wù)A 讀取了左邊某個(gè)分片的數(shù)據(jù)，按照供應(yīng)商進(jìn)行聚合，然后輸出給下一個(gè)Stage的B、C、D任務(wù)。
你可以看到，聚合后，B、C和D任務(wù)輸入的數(shù)據(jù)量有很大的不同，B處理的數(shù)據(jù)量比C和D多，消耗的內(nèi)存自然更多，假設(shè)單個(gè)Executor需要分配16G，而B(niǎo)、C、D不能設(shè)置不同的內(nèi)存大小，所以C和D也都設(shè)置了16G?？蓪?shí)際上，按照C和D的數(shù)據(jù)量，只需要4G就夠了。這就造成了C和D 任務(wù)資源分配的浪費(fèi)。
第五，數(shù)據(jù)未設(shè)置生命周期。
在06講中，我強(qiáng)調(diào)，一般原始數(shù)據(jù)和明細(xì)數(shù)據(jù)，會(huì)保留完整的歷史數(shù)據(jù)。而在匯總層、集市層或者應(yīng)用層，考慮到存儲(chǔ)成本，數(shù)據(jù)建議按照生命周期來(lái)管理，通常保留幾天的快照或者分區(qū)。如果存在大表沒(méi)有設(shè)置生命周期，就會(huì)浪費(fèi)存儲(chǔ)資源。
第六，調(diào)度周期不合理。
通過(guò)這張圖你可以看到，大數(shù)據(jù)任務(wù)的資源消耗有很明顯的高峰和低谷效應(yīng)，一般晚上12點(diǎn)到第二天的9點(diǎn)是高峰期，9點(diǎn)到晚上12點(diǎn)，是低谷期。
雖然任務(wù)有明顯的高峰低谷效應(yīng)，但是服務(wù)器資源不是彈性的，所以就會(huì)出現(xiàn)服務(wù)器在低谷期比較空閑，在高峰期比較繁忙的情況，整個(gè)集群的資源配置取決于高峰期的任務(wù)消耗。所以，把一些不必要在高峰期內(nèi)運(yùn)行任務(wù)遷移到低谷期運(yùn)行，也可以節(jié)省資源的消耗。
第七，任務(wù)參數(shù)配置。
任務(wù)參數(shù)配置的不合理，往往也會(huì)浪費(fèi)資源。比如在Spark中，Executor 內(nèi)存設(shè)置的過(guò)大；CPU設(shè)置的過(guò)多；還有Spark 沒(méi)有開(kāi)啟動(dòng)態(tài)資源分配策略，一些已經(jīng)運(yùn)行完Task的Executor 不能釋放，持續(xù)占用資源，尤其是遇到數(shù)據(jù)傾斜的情況，資源浪費(fèi)會(huì)更加明顯。
第八，數(shù)據(jù)未壓縮。
Hadoop 的HDFS 為了實(shí)現(xiàn)高可用，默認(rèn)數(shù)據(jù)存儲(chǔ)3副本，所以大數(shù)據(jù)的物理存儲(chǔ)量消耗是比較大的。尤其是對(duì)于一些原始數(shù)據(jù)層和明細(xì)數(shù)據(jù)層的大表，動(dòng)輒500多T，折合物理存儲(chǔ)需要1.5P（三副本，所以實(shí)際物理存儲(chǔ)5003），大約需要16臺(tái)物理服務(wù)器（一臺(tái)服務(wù)器可分配存儲(chǔ)按照128T計(jì)算），如果不啟用壓縮，存儲(chǔ)資源成本會(huì)很高。
另外，在Hive或者Spark 計(jì)算過(guò)程中，中間結(jié)果也需要壓縮，可以降低網(wǎng)絡(luò)傳輸量，提高Shuffer (在Hive或者Spark 計(jì)算過(guò)程中，數(shù)據(jù)在不同節(jié)點(diǎn)之間的傳輸過(guò)程)性能。
你看，我為你列舉了8個(gè)典型的成本陷阱，那你可能會(huì)問(wèn)了，老師，我已經(jīng)中招了，該怎么辦呢？ 別急，接下來(lái)我們就看一看，如何進(jìn)行精細(xì)化的成本管理。
2 如何實(shí)現(xiàn)精細(xì)化成本管理？
成本治理應(yīng)遵循全局盤點(diǎn)、發(fā)現(xiàn)問(wèn)題、治理優(yōu)化和效果評(píng)估四步。
2.1 全局資產(chǎn)盤點(diǎn)
對(duì)數(shù)據(jù)中臺(tái)中，所有的數(shù)據(jù)進(jìn)行一次全面盤點(diǎn)，基于元數(shù)據(jù)中心提供的數(shù)據(jù)血緣，建立全鏈路的數(shù)據(jù)資產(chǎn)視圖。
全鏈路數(shù)據(jù)資產(chǎn)視圖：
- 下游末端關(guān)聯(lián)到數(shù)據(jù)應(yīng)用（報(bào)表：財(cái)務(wù)分析）
- 上游起點(diǎn)是剛進(jìn)入數(shù)據(jù)中臺(tái)的原始數(shù)據(jù)
- 數(shù)據(jù)之間通過(guò)任務(wù)進(jìn)行連接
計(jì)算全鏈路數(shù)據(jù)資產(chǎn)視圖中，末端數(shù)據(jù)的成本和價(jià)值（末端數(shù)據(jù)就是加工鏈路最下游的表，例如圖中TableA，Table G）。
為什么一定要從末端開(kāi)始？ 因?yàn)橹虚g數(shù)據(jù)在計(jì)算價(jià)值時(shí)，還要考慮下游表被使用的情況，較難計(jì)算清楚，所以從末端數(shù)據(jù)開(kāi)始。這與下線表的順序也一致，如數(shù)據(jù)的價(jià)值很低，成本很高，也從末端數(shù)據(jù)開(kāi)始下線。
數(shù)據(jù)成本該如何計(jì)算？
對(duì)上圖中財(cái)務(wù)分析報(bào)表核算成本，這報(bào)表上游鏈路中涉及a，b，c，3個(gè)任務(wù)，A，B，C，D，E，F(xiàn)， 6張表：
這張報(bào)表的成本=3個(gè)任務(wù)加工消耗的計(jì)算資源成本+6張表消耗的存儲(chǔ)資源的成本。
如一個(gè)表被多個(gè)下游應(yīng)用復(fù)用，那這個(gè)表的存儲(chǔ)資源成本以及產(chǎn)出任務(wù)消耗的成本，需分?jǐn)偨o多個(gè)應(yīng)用。
那價(jià)值又該如何計(jì)算？
如末端數(shù)據(jù)是一張應(yīng)用層的表，它對(duì)接的是一個(gè)數(shù)據(jù)報(bào)表，那衡量這數(shù)據(jù)價(jià)值主要看報(bào)表的使用范圍和使用頻率。
計(jì)算使用范圍時(shí)，通常用周活評(píng)估，同時(shí)還要考慮不同管理級(jí)別的人權(quán)重，對(duì)老板，他一個(gè)人權(quán)重可相當(dāng)1000個(gè)普通員工。所以這樣設(shè)計(jì)考慮到管理級(jí)別越高，做出商業(yè)決策影響越大，自然價(jià)值越大。使用頻率一般使用單個(gè)用戶每周查看報(bào)表的次數(shù)來(lái)衡量，次數(shù)越高，說(shuō)明報(bào)表價(jià)值越大。
如末端數(shù)據(jù)對(duì)接的不是一個(gè)數(shù)據(jù)報(bào)表，而是面向特定場(chǎng)景的數(shù)據(jù)應(yīng)用（比如我之前提到過(guò)的供應(yīng)鏈分析決策系統(tǒng)，它面向的人群主要是供應(yīng)鏈部門）。衡量這類產(chǎn)品的價(jià)值，主要考慮目標(biāo)人群的覆蓋率和直接業(yè)務(wù)價(jià)值產(chǎn)出。什么是直接業(yè)務(wù)價(jià)值產(chǎn)出呢？，在供應(yīng)鏈決策系統(tǒng)中，就是通過(guò)系統(tǒng)自動(dòng)生成的采購(gòu)訂單占所有采購(gòu)訂單的比例。
末端數(shù)據(jù)可能還是一張集市層的表，主要用于提供給分析師做探索式查詢。這類表的價(jià)值看它被哪些分析師使用，使用頻率。使用范圍評(píng)估時(shí)，也要對(duì)分析師按級(jí)別加權(quán)。
2.2 發(fā)現(xiàn)問(wèn)題
全局盤點(diǎn)為發(fā)現(xiàn)問(wèn)題提供數(shù)據(jù)支撐，關(guān)注：
-
持續(xù)產(chǎn)生成本，但已沒(méi)有使用的末端數(shù)據(jù)（一般指30天內(nèi)無(wú)訪問(wèn)）
沒(méi)有使用，但一直在消耗成本的表，對(duì)應(yīng)的就是我提到的陷阱1
-
數(shù)據(jù)應(yīng)用價(jià)值很低，成本卻很高，這些數(shù)據(jù)應(yīng)用上游鏈路上的所有相關(guān)數(shù)據(jù)
低價(jià)值產(chǎn)出，高成本的數(shù)據(jù)應(yīng)用，對(duì)應(yīng)的是陷阱2
-
高峰期高消耗的數(shù)據(jù)
高成本的數(shù)據(jù)，對(duì)應(yīng)陷阱4～8
陷阱3實(shí)際是在第6節(jié)模型設(shè)計(jì)中解決的。
2.3 治理優(yōu)化
針對(duì)這三類問(wèn)題制訂相應(yīng)策略。
第一類，應(yīng)對(duì)表下線。 數(shù)據(jù)下線要謹(jǐn)慎，參考數(shù)據(jù)下線的執(zhí)行過(guò)程圖：
末端數(shù)據(jù)刪除后，原先末端數(shù)據(jù)的上游數(shù)據(jù)會(huì)成為新的末端數(shù)據(jù)，同樣還要按發(fā)現(xiàn)問(wèn)題到治理優(yōu)化進(jìn)行重復(fù)，直到所有的末端數(shù)據(jù)都不滿足下線策略為止。
對(duì)第二類問(wèn)題，我們需要按照應(yīng)用粒度評(píng)估應(yīng)用是否還有存在的必要。對(duì)于報(bào)表，可以按照30天內(nèi)沒(méi)有訪問(wèn)的應(yīng)用自動(dòng)下線的策略，先對(duì)報(bào)表進(jìn)行銷毀，然后對(duì)報(bào)表上游的表進(jìn)行下線，如果該表還被其他的應(yīng)用引用，就不能下線。下線步驟可以參考前面的下線步驟。
第三類問(wèn)題，主要是針對(duì)高消耗的數(shù)據(jù)，又具體分為產(chǎn)出數(shù)據(jù)的任務(wù)高消耗和數(shù)據(jù)存儲(chǔ)高消耗。對(duì)于產(chǎn)出任務(wù)高消耗，首先要考慮是不是數(shù)據(jù)傾斜。具體怎么判斷呢？其實(shí)你可以通過(guò)MR或者Spark日志中，Shuffer的數(shù)據(jù)量進(jìn)行判斷。如果有某一個(gè)Task 數(shù)據(jù)量非常大，其他的很少，就可以判定出現(xiàn)了數(shù)據(jù)傾斜。
圖 Spark task shuffer records：
圖 MR reduce task records：
數(shù)據(jù)傾斜處理？
不同的場(chǎng)景有一些適用的解決方案：
- 如一些大表和小表關(guān)聯(lián)時(shí)，Key分布不均造成數(shù)據(jù)傾斜，可使用mapjoin
- 較通用的處理方式，如把熱點(diǎn)Key單獨(dú)處理，然后對(duì)剩下的Key進(jìn)行處理，然后對(duì)結(jié)果進(jìn)行并集
除數(shù)據(jù)傾斜，還應(yīng)該查任務(wù)的配置參數(shù)。如Spark執(zhí)行引擎：
- Executor個(gè)數(shù)是否過(guò)大
- executor-cores和executor-memory是否過(guò)多，利用率較低
一般executors-memorty 設(shè)4G-8G，executor-cores設(shè)2-4個(gè)（實(shí)踐過(guò)利用率最高的配置項(xiàng)）。
還要考慮任務(wù)是否真有必要在高峰期執(zhí)行，可根據(jù)集群負(fù)載情況，盡量將任務(wù)遷移到非高峰期執(zhí)行，“削峰填谷”。
上面幾點(diǎn)是產(chǎn)出任務(wù)高消耗的情況。
對(duì)存儲(chǔ)消耗比較大的任務(wù)，先考慮是否要壓縮，尤其對(duì)原始數(shù)據(jù)層和明細(xì)數(shù)據(jù)層，建議壓縮
壓縮方式
- 小文件的壓縮，不考慮split，gzip較合適
- 大文件，推薦lzo，支持split，在保證壓縮效率前提下，有相對(duì)穩(wěn)定壓縮比
還要考慮生命周期是否設(shè)置：
- ODS原始數(shù)據(jù)層和DWD 明細(xì)數(shù)據(jù)層，適合用永久保留策略
- 一些商品、用戶維表，可考慮3、5年保留策略
整體上，底層表都是長(zhǎng)期保留。關(guān)注重點(diǎn)應(yīng)是匯總層以上的表（包括匯總層），一般可根據(jù)數(shù)據(jù)的重要性，制訂7天，1個(gè)月保留策略。
治理效果評(píng)估
量化治理成果 - 省了多少錢
若直接拿服務(wù)器數(shù)量來(lái)衡量，不能真實(shí)反應(yīng)治理效果，因?yàn)檫€要考慮業(yè)務(wù)增長(zhǎng)原因，可圍繞任務(wù)和數(shù)據(jù)的成本考慮：
- 下線了多少任務(wù)和數(shù)據(jù)
- 這些任務(wù)每日消耗了多少資源
- 數(shù)據(jù)占用了多少存儲(chǔ)空間
拿這些資源來(lái)計(jì)算成本，就能算出省了多少錢。如開(kāi)頭案例，任務(wù)A運(yùn)行3h，在運(yùn)行過(guò)程中，共消耗5384503 cpu*s，37007892 GB *s, 假設(shè)我們1個(gè)CU （1 cpu， 4g memeory）一年是1300元成本，折合每天為3.5元（計(jì)算公式為1300/365）。
不論是優(yōu)化或下線任務(wù)，只統(tǒng)計(jì)高峰時(shí)間段內(nèi)，因?yàn)閮?yōu)化低峰時(shí)間無(wú)法實(shí)際節(jié)省資源。
高峰時(shí)間段為8h，那折合每s費(fèi)用0.00012153，則該任的費(fèi)用為max{5384503*0.00012153, 37007892/4 * 0.00012153} = max{654, 1124} = 1124 。下線這任務(wù)后節(jié)省1124元，再加上表A占用的存儲(chǔ)空間大小乘以每GB的成本，可得數(shù)據(jù)表A下線節(jié)省費(fèi)用。
成本治理中心
成本治理不是一勞永逸的工作，需要持之以恒，不斷發(fā)現(xiàn)問(wèn)題，然后治理優(yōu)化，建立長(zhǎng)久運(yùn)行機(jī)制的前提是必須降低成本治理的門檻，接下來(lái)，看一下網(wǎng)易的一個(gè)成本治理的平臺(tái)，EasyCost。
系統(tǒng)提供了數(shù)據(jù)診斷的功能，可以按照訪問(wèn)時(shí)間、訪問(wèn)頻率、關(guān)聯(lián)的應(yīng)用，設(shè)置下線策略，支持一鍵灰度下線，大幅提高了管理的效率。
可通過(guò)系統(tǒng)化方式沉淀到產(chǎn)品，然后通過(guò)產(chǎn)品提高管理效率，實(shí)現(xiàn)治理機(jī)制的長(zhǎng)久落地。
總結(jié)
通過(guò)數(shù)據(jù)中臺(tái)：
- 可獲得大數(shù)據(jù)作為資產(chǎn)中心帶來(lái)的紅利
- 也可能陷入成本的深淵，為野蠻增長(zhǎng)的大數(shù)據(jù)費(fèi)用買單
從常見(jiàn)成本陷阱入手，分析可能造成成本浪費(fèi)的原因，然后介紹精細(xì)化成本管理的方法，最后強(qiáng)調(diào)：
- 無(wú)用數(shù)據(jù)的下線應(yīng)該從全鏈路數(shù)據(jù)資產(chǎn)視圖的末端入手，然后抽絲剝繭，一層一層，向數(shù)據(jù)加工鏈路的上游推進(jìn)。
- 應(yīng)用層表的價(jià)值應(yīng)該以數(shù)據(jù)應(yīng)用的價(jià)值來(lái)衡量，對(duì)于低價(jià)值產(chǎn)出的應(yīng)用，應(yīng)該以應(yīng)用為粒度進(jìn)行下線。
- 對(duì)高消耗任務(wù)的優(yōu)化只要關(guān)注集群高峰期的任務(wù)，項(xiàng)目的整體資源消耗只取決于高峰期的任務(wù)消耗，當(dāng)然，如果你使用的是公有云的資源，可以高峰和低谷實(shí)施差異化的成本結(jié)算，那低谷期的也是要關(guān)注的。
FAQ
在數(shù)據(jù)中臺(tái)的集市層，存在一些大寬表，幾百個(gè)字段，上游可能數(shù)十個(gè)表，如計(jì)算這個(gè)表的成本會(huì)非常高。這表中，字段訪問(wèn)頻率不同，優(yōu)化這張寬表?
垂直切分：將寬表按照字段的訪問(wèn)頻率劃分，將訪問(wèn)頻率高的字段單獨(dú)劃分為一張表，訪問(wèn)頻率低的字段單獨(dú)劃分為一張表。這樣可以減少查詢時(shí)掃描的字段數(shù)，提高查詢效率
水平切分：將寬表按照行進(jìn)行切分，將每個(gè)切分后的表中的字段數(shù)控制在可接受的范圍內(nèi)，這樣可以減少單個(gè)表的字段數(shù)，提高查詢效率
建立索引：對(duì)于寬表中的訪問(wèn)頻率高的字段，可以建立索引，這樣可以加快查詢速度
緩存機(jī)制：對(duì)于查詢頻率高的數(shù)據(jù)，可以采用緩存機(jī)制，將數(shù)據(jù)緩存在內(nèi)存中，這樣可以減少查詢時(shí)間
數(shù)據(jù)壓縮：對(duì)于寬表中的冷數(shù)據(jù)，可以采用數(shù)據(jù)壓縮技術(shù)，減少存儲(chǔ)空間，提高查詢效率
可根據(jù)實(shí)際情況選擇合適的優(yōu)化方式來(lái)提高查詢效率。
本文由博客一文多發(fā)平臺(tái) OpenWrite 發(fā)布！
