中生代技術

鏈接技術大咖，分享技術干貨

全文：4700字

“

隨著移動互聯網和大數據的蓬勃發展，“數據即資產”的理念深入人心。大數據已發展成為具有戰略意義的生產資料，在各行各業發揮著極其重要的作用，而大數據也給很多企業帶來了前所未有的自豪感和自信感。

圖片來自 Pexels

但是，大數據真的是越“大”越好嗎？大數據到達一定的規模，其所需承載的集群資源成本、數據開發維護成本和數據管理成本，將會呈幾何式增長，同樣也將會帶來一筆巨額的開銷。

如果缺少科學有效的治理管控，就會出現大量的“負”數據資產，這不僅會吞噬公司的利潤，還會極大影響數據業務的發展以及平臺運行的穩定。

很多大數據公司都會面臨這樣一些窘境：

• 新開發的數據任務，趕緊上，卻發現集群資源不夠了。

• 早上要跑完的任務，上午還沒跑完，報表什么時候能看到？

• 上個月剛刪了很多數據，存儲又快滿了，每天還有大量的數據在增長。

• 小文件數量這么多，集群 NameNode 內存快要爆了……

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

所以，大數據集群資源治理（以下簡稱“治理”）的工作亟待開展。

治理為何難以推動？

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

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

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

治理工作如何開展？

蘇寧認為，治理工作需要從組織保障和治理工具兩方面協同推進。公司的支持至關重要，有助于建設統一的數據文化，推進成立數據治理委員會，明確各組織的職責，制定治理制度、標準和流程等，以專職的治理團隊負責治理工具建設和整體運營推進。

不同于傳統數據資產管理，大數據集群資源治理聚焦計算資源和存儲資源的縮容，在保障平臺性能和穩定性的同時，又需要考量數據資產管理的賦能。

大數據集群資源的治理工作應結合公司現狀，集中精力解決當前最大痛點，優先治理緊急的、投入產出比高的治理項。

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

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

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

• 巡湖工程，主要任務是對大數據集群資源進行全面的巡檢和治理。
  

• 千遷工程，是對高算力的 Hive 任務，進行分批次遷移至 SparkSQL 計算平臺，同時保障治理工作的全面性和聚焦性。

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

典型治理場景和方案

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

計算治理

毫無疑問，CPU 和內存是集群的稀缺資源，保障集群資源算力是首要任務。

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

如何降低計算資源的消耗，提高任務執行的性能，縮短任務產出的時間，是計算治理的核心目標。

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

①任務復算治理

數倉建設過程中，往往存在事實表與維度表多次關聯、事實表與事實表多次關聯的現象，造成數據的重復計算。

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

其中，表關聯 union 方式識別比較簡單，示例如下：

②任務異常治理

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

以下作為一個參考，閾值可根據實際情況進行調整：

另外，當任務的目標表在一個或多個調度周期內未作更新，可認定為該任務未產出數據，任務清除下線的可能性很大。

③任務削峰平谷治理

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

大家都想在早上 8 點前跑完任務，但是不是每個忙時任務都有這個必要呢？通過對忙時任務產出表的被讀時間進行分析，可以識別出不合理調度執行的任務。

比如，如果任務在早上 8 點跑完，其寫入的目標表在中午 12 點才被讀取，是否可以將該任務避開忙時執行？

④任務資源配置治理

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

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

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

當出現 batch_time>>total_delay 時，當前任務占用的資源會浪費 wait_time。

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

雖然 total_delay 會加長，只要整體處理時間還在原定計劃內，即可滿足業務需求。

⑤計算框架優化

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

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

存儲治理

在數據爆發式增長的今天，存儲資源的有效使用也面臨著一系列的挑戰。如何降低存儲資源的消耗，節省存儲成本，是存儲治理的目標。

以下主要從生命周期管理、數據壓縮治理、數據復存治理、數據價值治理幾個角度介紹存儲治理優化。

①生命周期管理

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

如果表的生命周期設置不合理（過長），也可以根據表的類型、業務情況進行稽核整改。

②數據壓縮治理

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

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

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

③數據復存治理

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

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

如果表數據出現重復存儲，還需要根據鏈路血緣關系找出上游任務，對整個鏈路上的表及上游任務實施“一鍋端”治理。

④數據價值治理

梳理當前業務價值，從數據應用層（包括報表、指標、標簽）源頭分析投入產出比，對整體鏈路資源進行“從上至下”的價值治理。

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

性能和穩定性治理

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

①小文件治理

HDFS 雖然支持水平擴展，但是不適合大量小文件的存儲。因為 NameNode 將文件系統的元數據存放在內存中，導致存儲的文件數目受限于 NameNode 內存大小。當集群到了一定規模，NameNode 內存就會成為瓶頸。

小文件治理需要根據當前集群的文件數量，定義合適的小文件大小，比如小于 1M。

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

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

②數據傾斜治理

很多時候，我們在用 Hive 或 Spark 任務取數，只是跑了一個簡單的 join 語句，卻跑了很長時間，往往會覺得這是集群資源不夠導致的，但是很大情況下，是出現了“數據傾斜”的情況。

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

由上圖可見，通過對任務執行的監控日志分析，可以很方便的找出數據傾斜任務。

結合具體產生原因、數據分布和業務變化，有針對性的優化任務，任務執行時間能縮短幾十倍以上，效果非常明顯。

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

面向治理責任人、項目主管、公司領導及治理運營人員，蘇寧構建了統一的集群資源治理平臺，全局把控集群計算資源、存儲資源、性能和穩定性的整體情況，通過平臺“識別通知、治理優化、監督考核”的支撐能力，實現一站式治理服務和閉環流程，降低治理投入的工作量，提升治理成效。

后記

蘇寧建設了較為成熟的數據治理體系和標準流程，多項治理工作同步推進，均取得了顯著的成果，為公司節約了可觀的服務器資源投入成本。

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

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

未來，蘇寧大數據治理團隊仍將持續推進治理工作，進一步提升治理工具產品支撐能力，賦能治理工作常態化、工具化和智能化。

我們崇尚科技與藝術的結合，最后賦詩一首，希望能幫助有需要的同仁更好的理解這項工作，更快的實現治理目標。

《蘇寧數據治理 三字經》

--韋真

數之初，量本小。猛增長，遇瓶頸。

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

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

高層挺，強執行。定職責，齊協作。

察現狀，診問題。能識別，準定位。

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

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

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

治理急，線下先。累經驗，建工具。

能優化，可評估。須考核，納監督。

體系化，智能化。一站式，閉環式。

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

作者：韋真

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

編輯：陶家龍

來源：本文首發于51CTO技術棧，公眾號51CTOblog

END

推薦閱讀

?

螞蟻資深算法專家周俊：從原理到落地，支付寶如何打造保護隱私的共享智能？

?

阿里高級技術專家簫逸：如何畫好一張架構圖？

?

阿里巴巴閑魚架構負責人王樹彬：萬億交易規模技術架構實踐

?

58轉轉技術總監駱俊武：監控系統選型？必讀本篇！

?

螞蟻集團高級架構師郭援非：分布式數據庫是金融機構數字化轉型的最佳路徑

?

工行高級經理林承軍：工行基于 MySQL 構建分布式架構的轉型之路

?

平安銀行吳建峰：RocketMQ 在銀行的應用和實踐

?

阿里高級技術專家張建飛：應用架構分離業務邏輯和技術細節之道

?

知道創宇總監姚昌林：敏捷開發-如何打破研發交付過程中的“墻”

?

微博技術專家陳波：百億級訪問量的應用如何做緩存架構設計

?

天弘基金首席架構師李鑫：微服務接口限流的算法及架構實現

?

阿里P9專家右軍：大話軟件質量穩定性

? ?END ? ?? #接力技術，鏈接價值#

點分享點點贊點在看

總結

以上是生活随笔為你收集整理的苏宁智能 BU大数据中心数据治理团队负责人韦真：数据治理“三字经”，超实用！...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。