上節(jié)討論了如何保障數(shù)據(jù)中臺的數(shù)據(jù)質(zhì)量蜕便，讓數(shù)據(jù)“準(zhǔn)”劫恒。除了“快”和“準(zhǔn)”，數(shù)據(jù)中臺還離不開“省”轿腺。隨數(shù)據(jù)規(guī)模越來越大两嘴，成本越來越高，如不合理控制成本族壳，還沒等你挖掘出數(shù)據(jù)應(yīng)用價值憔辫，企業(yè)利潤就被消耗完。
能否做到精細(xì)化成本管理仿荆，關(guān)乎數(shù)據(jù)中臺項目成敗贰您。
某電商業(yè)務(wù)數(shù)據(jù)建設(shè)資源增長趨勢（CU= 1vcpu + 4G memory）：
某電商平臺的大數(shù)據(jù)資源消耗增長趨勢坏平，2019全年資源規(guī)模25000CU，全年機器預(yù)算3500W锦亦。對創(chuàng)業(yè)企業(yè)顯然不小開支舶替。
一天，數(shù)據(jù)團隊負(fù)責(zé)人李好看被CEO叫到了辦公室：
- 這3500W花在什么業(yè)務(wù)杠园？
- 你們做了哪些成本優(yōu)化的舉措顾瞪，效果如何？
把李問懵抛蚁，他心想：團隊的成本是按機器又不是數(shù)據(jù)應(yīng)用核算陈醒。在數(shù)據(jù)中臺中，數(shù)據(jù)應(yīng)用之間的底層數(shù)據(jù)是復(fù)用的篮绿，那具體每個數(shù)據(jù)產(chǎn)品或者報表花了多少錢孵延，自己沒有這樣的數(shù)據(jù)啊，咋可能知道亲配。
可對CEO這些很重要尘应，因為資源有限，他須確保資源都用在戰(zhàn)略目標(biāo)的關(guān)鍵節(jié)點吼虎。如電商團隊今年核心KPI是提升單個注冊會員在平臺的消費額犬钢，老板角度，他須確保資源都投入與KPI相關(guān)業(yè)務(wù)思灰，如基于數(shù)據(jù)對注冊會員精準(zhǔn)化營銷玷犹，提升會員在平臺的消費額。
自己所在的團隊是否發(fā)生過類似的事情洒疚？ 數(shù)據(jù)部門是企業(yè)的成本中心歹颓，如要展現(xiàn)自己的價值：
- 支撐好業(yè)務(wù)，獲得業(yè)務(wù)的認(rèn)可
- 精簡成本油湖，為公司省錢
所以巍扛，今天重點在省錢，聊數(shù)據(jù)中臺的精細(xì)化成本管理乏德。
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ù)加工盲厌，導(dǎo)致數(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)，這張寬表實際每天只有一個人在使用炕倘，還是一個運營的實習(xí)生钧大。顯然，投入和產(chǎn)出極不匹配罩旋。
間接說明啊央，數(shù)據(jù)部門比較關(guān)注新的數(shù)據(jù)產(chǎn)品帶給業(yè)務(wù)的價值眶诈，卻忽略已存產(chǎn)品或報表是否還存在價值，最終導(dǎo)致低價值的應(yīng)用仍大量耗資源瓜饥。
1.3 煙囪式的開發(fā)模式
不僅研發(fā)效率低逝撬，因數(shù)據(jù)重復(fù)加工，還資源浪費乓土。一張500T表宪潮，加工這表，計算任務(wù)需高峰期消耗300Core趣苏，折合7臺服務(wù)器（按一臺服務(wù)器可分配CPU 40Core計算）狡相，加上存儲盤成本(按照0.7 元/TB*天計算)，一年消耗40W食磕。
而這張表每復(fù)用一次尽棕，就可節(jié)省40W。所以模型復(fù)用彬伦，還可實現(xiàn)省錢滔悉。
第四，數(shù)據(jù)傾斜媚朦。
數(shù)據(jù)傾斜會讓任務(wù)性能變差氧敢，也會浪費大量的資源，那什么是數(shù)據(jù)傾斜呢询张？
你肯定聽說過木桶效應(yīng)吧孙乖？一個木桶裝多少水，主要取決于最短的那塊板份氧。對于一個分布式并行計算框架來說唯袄，這個效應(yīng)同樣存在。對于Spark計算引擎來說蜗帜，它可以將海量的數(shù)據(jù)切分成不同的分片（Partition）恋拷，分配到不同機器運行的任務(wù)中，進(jìn)行并行計算厅缺，從而實現(xiàn)計算能力水平擴展蔬顾。
但是整個任務(wù)的運行時長，其實取決于運行最長的那個任務(wù)湘捎。因為每個分片的數(shù)據(jù)量可能不同诀豁，每個任務(wù)需要的資源也不相同。由于不同的任務(wù)不能分配不同的資源窥妇，所以舷胜，總?cè)蝿?wù)消耗資源=max{單個任務(wù)消耗的資源} * 任務(wù)數(shù)量。這樣一來活翩，數(shù)據(jù)量小的任務(wù)會消耗更多的資源烹骨，就會造成資源的浪費翻伺。
我們還是舉個電商場景的例子。
假設(shè)你需要按照商戶粒度統(tǒng)計每個商戶的交易金額沮焕，此時吨岭，我們需要對訂單流水表按照商戶進(jìn)行g(shù)roup by計算。在平臺上峦树，每個商戶的訂單交易量實際差距很大未妹，有的訂單交易量很多，有的卻比較少空入。
我們利用Spark SQL完成計算過程。
在上圖中族檬，任務(wù)A 讀取了左邊某個分片的數(shù)據(jù)歪赢，按照供應(yīng)商進(jìn)行聚合，然后輸出給下一個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钉蒲。可實際上彻坛，按照C和D的數(shù)據(jù)量顷啼，只需要4G就夠了。這就造成了C和D 任務(wù)資源分配的浪費昌屉。
第五钙蒙，數(shù)據(jù)未設(shè)置生命周期。
在06講中怠益，我強調(diào)仪搔，一般原始數(shù)據(jù)和明細(xì)數(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)高可用问词，默認(rèn)數(shù)據(jù)存儲3副本督函，所以大數(shù)據(jù)的物理存儲量消耗是比較大的。尤其是對于一些原始數(shù)據(jù)層和明細(xì)數(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)中招了，該怎么辦呢砸逊？ 別急璧南，接下來我們就看一看，如何進(jìn)行精細(xì)化的成本管理师逸。
2 如何實現(xiàn)精細(xì)化成本管理司倚？
成本治理應(yīng)遵循全局盤點、發(fā)現(xiàn)問題篓像、治理優(yōu)化和效果評估四步动知。
2.1 全局資產(chǎn)盤點
對數(shù)據(jù)中臺中，所有的數(shù)據(jù)進(jìn)行一次全面盤點员辩，基于元數(shù)據(jù)中心提供的數(shù)據(jù)血緣盒粮，建立全鏈路的數(shù)據(jù)資產(chǎn)視圖。
全鏈路數(shù)據(jù)資產(chǎn)視圖：
- 下游末端關(guān)聯(lián)到數(shù)據(jù)應(yīng)用（報表：財務(wù)分析）
- 上游起點是剛進(jìn)入數(shù)據(jù)中臺的原始數(shù)據(jù)
- 數(shù)據(jù)之間通過任務(wù)進(jìn)行連接
計算全鏈路數(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)用復(fù)用倍阐，那這個表的存儲資源成本以及產(chǎn)出任務(wù)消耗的成本，需分?jǐn)偨o多個應(yīng)用逗威。
那價值又該如何計算峰搪？
如末端數(shù)據(jù)是一張應(yīng)用層的表，它對接的是一個數(shù)據(jù)報表凯旭，那衡量這數(shù)據(jù)價值主要看報表的使用范圍和使用頻率概耻。
計算使用范圍時，通常用周活評估罐呼，同時還要考慮不同管理級別的人權(quán)重鞠柄，對老板，他一個人權(quán)重可相當(dāng)1000個普通員工嫉柴。所以這樣設(shè)計考慮到管理級別越高厌杜，做出商業(yè)決策影響越大，自然價值越大计螺。使用頻率一般使用單個用戶每周查看報表的次數(shù)來衡量期奔，次數(shù)越高，說明報表價值越大危尿。
如末端數(shù)據(jù)對接的不是一個數(shù)據(jù)報表呐萌，而是面向特定場景的數(shù)據(jù)應(yīng)用（比如我之前提到過的供應(yīng)鏈分析決策系統(tǒng)，它面向的人群主要是供應(yīng)鏈部門）谊娇。衡量這類產(chǎn)品的價值肺孤，主要考慮目標(biāo)人群的覆蓋率和直接業(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ù)下線要謹(jǐn)慎，參考數(shù)據(jù)下線的執(zhí)行過程圖：
末端數(shù)據(jù)刪除后缅叠，原先末端數(shù)據(jù)的上游數(shù)據(jù)會成為新的末端數(shù)據(jù)悄泥，同樣還要按發(fā)現(xiàn)問題到治理優(yōu)化進(jìn)行重復(fù)，直到所有的末端數(shù)據(jù)都不滿足下線策略為止肤粱。
對第二類問題弹囚，我們需要按照應(yīng)用粒度評估應(yīng)用是否還有存在的必要。對于報表领曼，可以按照30天內(nèi)沒有訪問的應(yīng)用自動下線的策略鸥鹉，先對報表進(jìn)行銷毀，然后對報表上游的表進(jìn)行下線庶骄，如果該表還被其他的應(yīng)用引用毁渗，就不能下線。下線步驟可以參考前面的下線步驟单刁。
第三類問題灸异，主要是針對高消耗的數(shù)據(jù)，又具體分為產(chǎn)出數(shù)據(jù)的任務(wù)高消耗和數(shù)據(jù)存儲高消耗。對于產(chǎn)出任務(wù)高消耗肺樟，首先要考慮是不是數(shù)據(jù)傾斜檐春。具體怎么判斷呢？其實你可以通過MR或者Spark日志中么伯，Shuffer的數(shù)據(jù)量進(jìn)行判斷疟暖。如果有某一個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進(jìn)行處理邻遏，然后對結(jié)果進(jìn)行并集
除數(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ù)集群負(fù)載情況，盡量將任務(wù)遷移到非高峰期執(zhí)行颠黎，“削峰填谷”另锋。
上面幾點是產(chǎn)出任務(wù)高消耗的情況。
對存儲消耗比較大的任務(wù)狭归，先考慮是否要壓縮夭坪，尤其對原始數(shù)據(jù)層和明細(xì)數(shù)據(jù)層，建議壓縮
壓縮方式
- 小文件的壓縮过椎，不考慮split室梅，gzip較合適
- 大文件，推薦lzo疚宇，支持split亡鼠，在保證壓縮效率前提下，有相對穩(wěn)定壓縮比
還要考慮生命周期是否設(shè)置：
- ODS原始數(shù)據(jù)層和DWD 明細(xì)數(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ù)費用買單
從常見成本陷阱入手决摧，分析可能造成成本浪費的原因，然后介紹精細(xì)化成本管理的方法凑兰，最后強調(diào)：
- 無用數(shù)據(jù)的下線應(yīng)該從全鏈路數(shù)據(jù)資產(chǎn)視圖的末端入手掌桩，然后抽絲剝繭，一層一層姑食，向數(shù)據(jù)加工鏈路的上游推進(jìn)波岛。
- 應(yīng)用層表的價值應(yīng)該以數(shù)據(jù)應(yīng)用的價值來衡量，對于低價值產(chǎn)出的應(yīng)用音半，應(yīng)該以應(yīng)用為粒度進(jìn)行下線则拷。
- 對高消耗任務(wù)的優(yōu)化只要關(guān)注集群高峰期的任務(wù)，項目的整體資源消耗只取決于高峰期的任務(wù)消耗祟剔，當(dāng)然隔躲，如果你使用的是公有云的資源，可以高峰和低谷實施差異化的成本結(jié)算物延，那低谷期的也是要關(guān)注的宣旱。
FAQ
在數(shù)據(jù)中臺的集市層，存在一些大寬表叛薯，幾百個字段浑吟，上游可能數(shù)十個表，如計算這個表的成本會非常高耗溜。這表中组力，字段訪問頻率不同，優(yōu)化這張寬表?
垂直切分：將寬表按照字段的訪問頻率劃分抖拴，將訪問頻率高的字段單獨劃分為一張表燎字，訪問頻率低的字段單獨劃分為一張表。這樣可以減少查詢時掃描的字段數(shù)阿宅，提高查詢效率
水平切分：將寬表按照行進(jìn)行切分候衍，將每個切分后的表中的字段數(shù)控制在可接受的范圍內(nèi)，這樣可以減少單個表的字段數(shù)洒放，提高查詢效率
建立索引：對于寬表中的訪問頻率高的字段蛉鹿，可以建立索引，這樣可以加快查詢速度
緩存機制：對于查詢頻率高的數(shù)據(jù)往湿，可以采用緩存機制妖异，將數(shù)據(jù)緩存在內(nèi)存中惋戏，這樣可以減少查詢時間
數(shù)據(jù)壓縮：對于寬表中的冷數(shù)據(jù)，可以采用數(shù)據(jù)壓縮技術(shù)他膳，減少存儲空間响逢，提高查詢效率
可根據(jù)實際情況選擇合適的優(yōu)化方式來提高查詢效率。
本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布矩乐！
