【51CTO.com原創(chuàng)稿件】隨著移動(dòng)互聯(lián)網(wǎng)和大數(shù)據(jù)的蓬勃發(fā)展，“數(shù)據(jù)即資產(chǎn)”的理念深入人心。大數(shù)據(jù)已發(fā)展成為具有戰(zhàn)略意義的生產(chǎn)資料，在各行各業(yè)發(fā)揮著極其重要的作用，而大數(shù)據(jù)也給很多企業(yè)帶來了前所未有的自豪感和自信感。

[[340696]]

圖片來自 Pexels

但是，大數(shù)據(jù)真的是越“大”越好嗎?大數(shù)據(jù)到達(dá)一定的規(guī)模，其所需承載的集群資源成本、數(shù)據(jù)開發(fā)維護(hù)成本和數(shù)據(jù)管理成本，將會(huì)呈幾何式增長，同樣也將會(huì)帶來一筆巨額的開銷。

[[340697]]

如果缺少科學(xué)有效的治理管控，就會(huì)出現(xiàn)大量的“負(fù)”數(shù)據(jù)資產(chǎn)，這不僅會(huì)吞噬公司的利潤，還會(huì)極大影響數(shù)據(jù)業(yè)務(wù)的發(fā)展以及平臺(tái)運(yùn)行的穩(wěn)定。

很多大數(shù)據(jù)公司都會(huì)面臨這樣一些窘境：

• 新開發(fā)的數(shù)據(jù)任務(wù)，趕緊上，卻發(fā)現(xiàn)集群資源不夠了。
• 早上要跑完的任務(wù)，上午還沒跑完，報(bào)表什么時(shí)候能看到?
• 上個(gè)月剛刪了很多數(shù)據(jù)，存儲(chǔ)又快滿了，每天還有大量的數(shù)據(jù)在增長。
• 小文件數(shù)量這么多，集群 NameNode 內(nèi)存快要爆了……

一個(gè)個(gè)頭疼的問題接踵而至，面對(duì)這些問題我們是不是得換一個(gè)視角，給大數(shù)據(jù)集群資源來一場(chǎng)瘦身，取其精華、去其糟粕，讓大數(shù)據(jù)集群資源環(huán)境更加健康，數(shù)據(jù)開發(fā)工作更加高效，公司投入產(chǎn)出比更加合理。

所以，大數(shù)據(jù)集群資源治理(以下簡(jiǎn)稱“治理”)的工作亟待開展。

治理為何難以推動(dòng)?

大多數(shù)公司在大數(shù)據(jù)發(fā)展初期都是野蠻生長的，它們更關(guān)注的是擁有更多的數(shù)據(jù)，更快速的完成數(shù)據(jù)業(yè)務(wù)開發(fā)，即使集群資源不夠了，增加機(jī)器遠(yuǎn)比開展治理來得更快。

治理工作涉及眾多的職能線與部門，角色不同，立場(chǎng)不同，治理投入度也不同。

即使集群資源達(dá)到一定規(guī)模，不得不治理時(shí)，各組織仍會(huì)以開發(fā)業(yè)務(wù)為核心，治理工作對(duì)他們來說優(yōu)先級(jí)并不高，這也直接影響著治理效果。

治理工作如何開展?

蘇寧認(rèn)為，治理工作需要從組織保障和治理工具兩方面協(xié)同推進(jìn)。公司的支持至關(guān)重要，有助于建設(shè)統(tǒng)一的數(shù)據(jù)文化，推進(jìn)成立數(shù)據(jù)治理委員會(huì)，明確各組織的職責(zé)，制定治理制度、標(biāo)準(zhǔn)和流程等，以專職的治理團(tuán)隊(duì)負(fù)責(zé)治理工具建設(shè)和整體運(yùn)營推進(jìn)。

不同于傳統(tǒng)數(shù)據(jù)資產(chǎn)管理，大數(shù)據(jù)集群資源治理聚焦計(jì)算資源和存儲(chǔ)資源的縮容，在保障平臺(tái)性能和穩(wěn)定性的同時(shí)，又需要考量數(shù)據(jù)資產(chǎn)管理的賦能。

大數(shù)據(jù)集群資源的治理工作應(yīng)結(jié)合公司現(xiàn)狀，集中精力解決當(dāng)前最大痛點(diǎn)，優(yōu)先治理緊急的、投入產(chǎn)出比高的治理項(xiàng)。

對(duì)于緊急的治理項(xiàng)，如果涉及的部門和用戶較少，能夠通過面對(duì)面、郵件、社交媒體進(jìn)行溝通，在短時(shí)間內(nèi)解決的，采用線下手工治理方式。

對(duì)于非緊急治理項(xiàng)，涉及的部門和用戶較廣，并且需要長期治理的，則采用線上工具輔助治理，以減少人力投入成本。

為此，蘇寧啟動(dòng)了“巡湖工程”、“千遷工程”等專項(xiàng)治理工程：

• 巡湖工程，主要任務(wù)是對(duì)大數(shù)據(jù)集群資源進(jìn)行全面的巡檢和治理。
• 千遷工程，是對(duì)高算力的 Hive 任務(wù)，進(jìn)行分批次遷移至 SparkSQL 計(jì)算平臺(tái)，同時(shí)保障治理工作的全面性和聚焦性。

在治理工作方式的演進(jìn)上，蘇寧采用了四個(gè)步驟：線下手工治理、半工具化治理、工具化治理和自驅(qū)動(dòng)治理，最終實(shí)現(xiàn)各組織自我驅(qū)動(dòng)型的治理常態(tài)。

典型治理場(chǎng)景和方案

大數(shù)據(jù)集群資源治理是一項(xiàng)龐大且復(fù)雜的工程，蘇寧結(jié)合自己的治理經(jīng)歷，從計(jì)算治理、存儲(chǔ)治理、性能和穩(wěn)定性治理三個(gè)方面，分享一下典型的治理場(chǎng)景和解決方案。

計(jì)算治理

毫無疑問，CPU 和內(nèi)存是集群的稀缺資源，保障集群資源算力是首要任務(wù)。

一旦計(jì)算資源缺乏，將面臨數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)加工、數(shù)據(jù)稽核等一系列數(shù)據(jù)作業(yè)的延誤，甚至崩潰。

如何降低計(jì)算資源的消耗，提高任務(wù)執(zhí)行的性能，縮短任務(wù)產(chǎn)出的時(shí)間，是計(jì)算治理的核心目標(biāo)。

以下主要從任務(wù)復(fù)算治理、任務(wù)異常治理、任務(wù)削峰平谷治理、任務(wù)資源配置治理、計(jì)算框架優(yōu)化幾個(gè)角度，分別介紹計(jì)算治理優(yōu)化。

①任務(wù)復(fù)算治理

數(shù)倉建設(shè)過程中，往往存在事實(shí)表與維度表多次關(guān)聯(lián)、事實(shí)表與事實(shí)表多次關(guān)聯(lián)的現(xiàn)象，造成數(shù)據(jù)的重復(fù)計(jì)算。

任務(wù)復(fù)算治理，是面向大數(shù)據(jù)離線任務(wù) Hive、SparkSQL 等 SQL 類的任務(wù)，通過對(duì)表與表關(guān)聯(lián)的 union、join、子查詢復(fù)雜關(guān)聯(lián)等語法進(jìn)行解析，識(shí)別重復(fù)計(jì)算的任務(wù)及其讀取的關(guān)聯(lián)表(源表)數(shù)據(jù)，并以此推動(dòng)公共模型建設(shè)，減少任務(wù)重復(fù)計(jì)算。

其中，表關(guān)聯(lián) union 方式識(shí)別比較簡(jiǎn)單，示例如下：

②任務(wù)異常治理

任務(wù)出錯(cuò)率是衡量任務(wù)是否需要治理的重要指標(biāo)，出錯(cuò)率過高意味著這個(gè)任務(wù)是沒有價(jià)值的，一般可以被清除。如果任務(wù)確實(shí)需要使用，則必須進(jìn)行優(yōu)化。

以下作為一個(gè)參考，閾值可根據(jù)實(shí)際情況進(jìn)行調(diào)整：

另外，當(dāng)任務(wù)的目標(biāo)表在一個(gè)或多個(gè)調(diào)度周期內(nèi)未作更新，可認(rèn)定為該任務(wù)未產(chǎn)出數(shù)據(jù)，任務(wù)清除下線的可能性很大。

③任務(wù)削峰平谷治理

從全天來看，任務(wù)執(zhí)行會(huì)有明顯的忙閑時(shí)之分。大部分公司的忙時(shí)主要集中在凌晨 0 點(diǎn)至 8 點(diǎn)，其余時(shí)間段相對(duì)為閑時(shí)，這就造成了忙時(shí)計(jì)算資源嚴(yán)重緊缺。

大家都想在早上 8 點(diǎn)前跑完任務(wù)，但是不是每個(gè)忙時(shí)任務(wù)都有這個(gè)必要呢?通過對(duì)忙時(shí)任務(wù)產(chǎn)出表的被讀時(shí)間進(jìn)行分析，可以識(shí)別出不合理調(diào)度執(zhí)行的任務(wù)。

比如，如果任務(wù)在早上 8 點(diǎn)跑完，其寫入的目標(biāo)表在中午 12 點(diǎn)才被讀取，是否可以將該任務(wù)避開忙時(shí)執(zhí)行?

④任務(wù)資源配置治理

這里主要談一下 Spark Streaming 實(shí)時(shí)任務(wù)資源治理。Spark Streaming 和 Spark 處理邏輯是相同的，都是收到外部數(shù)據(jù)流之后按照時(shí)間切分。

“微批”處理一個(gè)個(gè)切分后的文件，往往會(huì)存在資源分配過多的現(xiàn)象，這很容易被識(shí)別。

由上圖可見，將數(shù)據(jù)按照時(shí)間劃分成 N 等分。假設(shè)每批次 A 的間隔時(shí)長：batch_time;處理 B 的時(shí)長：total_delay;等待 C 的時(shí)長：wait_time。

當(dāng)出現(xiàn) batch_time>>total_delay 時(shí)，當(dāng)前任務(wù)占用的資源會(huì)浪費(fèi) wait_time。

通過縮減任務(wù)資源或多個(gè)任務(wù)合并成一個(gè)任務(wù)的方式來治理，都可以提升資源利用率。

雖然 total_delay 會(huì)加長，只要整體處理時(shí)間還在原定計(jì)劃內(nèi)，即可滿足業(yè)務(wù)需求。

⑤計(jì)算框架優(yōu)化

計(jì)算框架越來越多，也越來越成熟完善，選擇適合自己的計(jì)算框架是關(guān)鍵。比如，由 Hive 任務(wù)遷移至 SparkSQL 任務(wù)、Storm 任務(wù)遷移至 Flink 任務(wù)，會(huì)帶來性能上的明顯提升。

但是，在海量數(shù)據(jù)任務(wù)的前提下，任務(wù)遷移絕非易事，需要綜合考慮遷移的方案以及涉及的成本和風(fēng)險(xiǎn)。

存儲(chǔ)治理

在數(shù)據(jù)爆發(fā)式增長的今天，存儲(chǔ)資源的有效使用也面臨著一系列的挑戰(zhàn)。如何降低存儲(chǔ)資源的消耗，節(jié)省存儲(chǔ)成本，是存儲(chǔ)治理的目標(biāo)。

以下主要從生命周期管理、數(shù)據(jù)壓縮治理、數(shù)據(jù)復(fù)存治理、數(shù)據(jù)價(jià)值治理幾個(gè)角度介紹存儲(chǔ)治理優(yōu)化。

①生命周期管理

根據(jù)表生命周期對(duì)表進(jìn)行清理刪除，是最常見有效的存儲(chǔ)治理方式。為降低數(shù)據(jù)丟失風(fēng)險(xiǎn)，可以先對(duì)表進(jìn)行 rename 或通過 ranger 禁止表讀寫權(quán)限(相當(dāng)于邏輯刪除)，7 天觀察期過后刪除至回收站，回收站默認(rèn)保留 3 天后進(jìn)行最終刪除。

如果表的生命周期設(shè)置不合理(過長)，也可以根據(jù)表的類型、業(yè)務(wù)情況進(jìn)行稽核整改。

②數(shù)據(jù)壓縮治理

數(shù)據(jù)壓縮治理是最簡(jiǎn)單有效的存儲(chǔ)治理方式。數(shù)據(jù)壓縮的好處顯而易見，可以直接節(jié)省磁盤空間，提升磁盤利用率，并且加速網(wǎng)絡(luò)傳輸。

但同時(shí)數(shù)據(jù)的壓縮和解壓，需要消耗計(jì)算資源。如果集群計(jì)算資源緊缺，并且數(shù)據(jù)經(jīng)常被讀，則建議根據(jù)實(shí)際場(chǎng)景選擇合適的數(shù)據(jù)壓縮方式。

在不同的存儲(chǔ)格式和壓縮算法下，簡(jiǎn)單查詢、大寬表查詢和復(fù)雜查詢的執(zhí)行表現(xiàn)均有差異，具體需結(jié)合實(shí)際場(chǎng)景選擇使用。

③數(shù)據(jù)復(fù)存治理

比較簡(jiǎn)單的方式是通過解析 Hive 任務(wù)、SparkSQL 任務(wù)的代碼邏輯，分析代碼中的讀表、寫表、條件、字段函數(shù)，識(shí)別讀表和寫表是否重復(fù)存儲(chǔ)。

另外，也可以通過表名、字段名的相似度進(jìn)行識(shí)別，并結(jié)合某些周期產(chǎn)出數(shù)據(jù)，抽樣進(jìn)行相似度對(duì)比分析和識(shí)別。

如果表數(shù)據(jù)出現(xiàn)重復(fù)存儲(chǔ)，還需要根據(jù)鏈路血緣關(guān)系找出上游任務(wù)，對(duì)整個(gè)鏈路上的表及上游任務(wù)實(shí)施“一鍋端”治理。

④數(shù)據(jù)價(jià)值治理

梳理當(dāng)前業(yè)務(wù)價(jià)值，從數(shù)據(jù)應(yīng)用層(包括報(bào)表、指標(biāo)、標(biāo)簽)源頭分析投入產(chǎn)出比，對(duì)整體鏈路資源進(jìn)行“從上至下”的價(jià)值治理。

如果表長時(shí)間未作更新(如 32 天)或未被讀取，往往表明這張表價(jià)值很低，甚至沒有價(jià)值，則可對(duì)表進(jìn)行清理刪除，這時(shí)可以優(yōu)先考慮治理大表、分區(qū)表、高成本表。

性能和穩(wěn)定性治理

集群的性能和穩(wěn)定性治理涉及眾多方面，這里重點(diǎn)談一下小文件治理和數(shù)據(jù)傾斜治理。

①小文件治理

HDFS 雖然支持水平擴(kuò)展，但是不適合大量小文件的存儲(chǔ)。因?yàn)?NameNode 將文件系統(tǒng)的元數(shù)據(jù)存放在內(nèi)存中，導(dǎo)致存儲(chǔ)的文件數(shù)目受限于 NameNode 內(nèi)存大小。當(dāng)集群到了一定規(guī)模，NameNode 內(nèi)存就會(huì)成為瓶頸。

小文件治理需要根據(jù)當(dāng)前集群的文件數(shù)量，定義合適的小文件大小，比如小于 1M。

治理方式需要考慮從源頭控制，在任務(wù)中配置文件合并參數(shù)，在 HDFS 存儲(chǔ)之前進(jìn)行小文件合并，但這又會(huì)延長任務(wù)執(zhí)行時(shí)間。

所以，可選擇在閑時(shí)進(jìn)行周期性的小文件合并。另外，也可以設(shè)置小文件占比閾值，根據(jù)閾值觸發(fā)小文件合并。

②數(shù)據(jù)傾斜治理

很多時(shí)候，我們?cè)谟?Hive 或 Spark 任務(wù)取數(shù)，只是跑了一個(gè)簡(jiǎn)單的 join 語句，卻跑了很長時(shí)間，往往會(huì)覺得這是集群資源不夠?qū)е碌模呛艽笄闆r下，是出現(xiàn)了“數(shù)據(jù)傾斜”的情況。

數(shù)據(jù)傾斜，在 MapReduce 編程模型中十分常見，大量的相同 key 被 partition 分配到一個(gè)分區(qū)里，造成了“某些任務(wù)累死，還拖了后腿，其他任務(wù)閑死”的情況，這并不利于資源最大化的有效利用。

由上圖可見，通過對(duì)任務(wù)執(zhí)行的監(jiān)控日志分析，可以很方便的找出數(shù)據(jù)傾斜任務(wù)。

結(jié)合具體產(chǎn)生原因、數(shù)據(jù)分布和業(yè)務(wù)變化，有針對(duì)性的優(yōu)化任務(wù)，任務(wù)執(zhí)行時(shí)間能縮短幾十倍以上，效果非常明顯。

治理工具需要具備哪些能力?

面向治理責(zé)任人、項(xiàng)目主管、公司領(lǐng)導(dǎo)及治理運(yùn)營人員，蘇寧構(gòu)建了統(tǒng)一的集群資源治理平臺(tái)，全局把控集群計(jì)算資源、存儲(chǔ)資源、性能和穩(wěn)定性的整體情況，通過平臺(tái)“識(shí)別通知、治理優(yōu)化、監(jiān)督考核”的支撐能力，實(shí)現(xiàn)一站式治理服務(wù)和閉環(huán)流程，降低治理投入的工作量，提升治理成效。

后記

蘇寧建設(shè)了較為成熟的數(shù)據(jù)治理體系和標(biāo)準(zhǔn)流程，多項(xiàng)治理工作同步推進(jìn)，均取得了顯著的成果，為公司節(jié)約了可觀的服務(wù)器資源投入成本。

并且，隨著治理工作的推進(jìn)，各組織也更主動(dòng)的開展源頭治理，大大減輕了事后治理的工作量。

治理工作不會(huì)一蹴而就，也不如前端業(yè)務(wù)那么容易出彩，顯得“樸實(shí)無華”。每一位治理工作者都在背后默默的堅(jiān)守付出，孜孜不倦地保障著大數(shù)據(jù)集群資源的最大化有效利用。

未來，蘇寧大數(shù)據(jù)治理團(tuán)隊(duì)仍將持續(xù)推進(jìn)治理工作，進(jìn)一步提升治理工具產(chǎn)品支撐能力，賦能治理工作常態(tài)化、工具化和智能化。

我們崇尚科技與藝術(shù)的結(jié)合，最后賦詩一首，希望能幫助有需要的同仁更好的理解這項(xiàng)工作，更快的實(shí)現(xiàn)治理目標(biāo)。

《蘇寧數(shù)據(jù)治理 三字經(jīng)》

--韋真

數(shù)之初，量本小。猛增長，遇瓶頸。

缺管理，實(shí)難控。若不治，隨可崩。

若廣治，懼其繁。治之道，貴以專。

高層挺，強(qiáng)執(zhí)行。定職責(zé)，齊協(xié)作。

察現(xiàn)狀，診問題。能識(shí)別，準(zhǔn)定位。

控增量，降存量。攤成本，明方向。

始源頭，理價(jià)值。視場(chǎng)景，擇平臺(tái)。

宜壓縮，需清理。去冗余，平峰谷。

治理急，線下先。累經(jīng)驗(yàn)，建工具。

能優(yōu)化，可評(píng)估。須考核，納監(jiān)督。

體系化，智能化。一站式，閉環(huán)式。

存儲(chǔ)易，算力難。若有方，皆可成。

作者：韋真

簡(jiǎn)介：蘇寧科技集團(tuán)蘇寧智能 BU 大數(shù)據(jù)中心數(shù)據(jù)治理團(tuán)隊(duì)負(fù)責(zé)人，全面負(fù)責(zé)蘇寧數(shù)據(jù)資產(chǎn)管理和大數(shù)據(jù)集群資源治理工作。長期致力于數(shù)據(jù)治理領(lǐng)域的研究與實(shí)踐，曾服務(wù)于運(yùn)營商、政府、公安等多類行業(yè)客戶，在數(shù)據(jù)治理領(lǐng)域有著豐富的產(chǎn)品規(guī)劃、產(chǎn)品建設(shè)和運(yùn)營實(shí)踐經(jīng)驗(yàn)。

編輯：陶家龍

征稿：有投稿、尋求報(bào)道意向技術(shù)人請(qǐng)聯(lián)絡(luò) editor@51cto.com

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】