【51CTO.com原創(chuà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ù)到達一定的規(guī)模，其所需承載的集群資源成本、數(shù)據(jù)開發(fā)維護成本和數(shù)據(jù)管理成本，將會呈幾何式增長，同樣也將會帶來一筆巨額的開銷。

[[340697]]

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

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

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

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

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

治理為何難以推動?

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

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

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

治理工作如何開展?

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

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

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

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

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

為此，蘇寧啟動了“巡湖工程”、“千遷工程”等專項治理工程：

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

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

典型治理場景和方案

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

計算治理

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

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

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

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

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

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

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

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

②任務(wù)異常治理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

存儲治理

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

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

①生命周期管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

①小文件治理

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

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

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

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

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

很多時候，我們在用 Hive 或 Spark 任務(wù)取數(shù)，只是跑了一個簡單的 join 語句，卻跑了很長時間，往往會覺得這是集群資源不夠?qū)е碌?，但是很大情況下，是出現(xiàn)了“數(shù)據(jù)傾斜”的情況。

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

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

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

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

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

后記

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

并且，隨著治理工作的推進，各組織也更主動的開展源頭治理，大大減輕了事后治理的工作量。

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

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

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

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

--韋真

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

缺管理，實難控。若不治，隨可崩。

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

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

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

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

始源頭，理價值。視場景，擇平臺。

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

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

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

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

存儲易，算力難。若有方，皆可成。

作者：韋真

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

編輯：陶家龍

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

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