小米大資料儲存服務的資料治理實踐

　　導讀：資料治理是一個很大的話題，本文將主要介紹儲存服務相關工作，聚焦成本治理。文章主要分兩大部分，四個小節：第一部分：主要講述小米資料治理的演進過程，從高層視角來看小米的資料治理是如何開展的：1. 樸素資料治理；2. 用大資料治理大資料。第二部分：聚焦團隊的工作，如成本最佳化等具體內容：1. HDFS 的治理實踐；2. HBase 的治理實踐。

　　 01 樸素資料治理

　　資料治理的內涵是不斷豐富的，把時間倒回到 2018 年，小米剛開始做資料治理的時候，當時對資料治理的認識是很樸素的，資料治理就等於成本治理。

　　公司隨著業務發展、組織架構調整、交接不規範、商務談判等等，都會造成資源上的浪費。起初不多，治理的價值不高，大家更多的精力還是放在滿足業務需要上。到 2018 年這個時間點，治理已經可以有不錯的收益了，值得投入一些人力去治理了。　　

　　具體如何去做成本治理呢？簡單說就是“抓大放小”。先盤點哪些服務的成本最高，再找出哪些叢集的成本是最高的，然後每個負責人就各自領自己的治理任務，推進成本最佳化。　　

　　這麼做的好處在於：目標清晰、簡單高效。一方面，積累到 2018 年已經有不少浪費了，抓大放小的治理有很好的效果。另一方面，當時的工作重點仍在滿足業務需求上，不能讓治理動作消耗太多人力，目標是：投入有限的人力和時間快速取得結果。　　

　　這樣做也存在一些問題：

　　1. 不可觀測

　　成本、資源利用率不可觀測，看不到就不會有成本意識，沒有及時反饋，就會容易鬆懈，最終演變為運動式治理，每年年初搞一次。

　　2. 各自算帳

　　各個服務負責人要自己去算賬，算賬的口徑不統一，比如算節約了多少錢，有的用的是商務價格，有的用的是內部賬單價格，有的用的是過保價格，有的算的是相比去年同期節約了多少錢，有的算的是相比未來年底增長節約了多少錢。

　　3. 分工不合理

　　儲存平臺作為底層平臺，和業務中間還隔著好幾層，但是我們揹著治理的指標，就需要去找業務溝通，效率不是很高，成本最佳化技術研發工作也被 delay 了。

　　 02 用大資料治理大資料

　　隨著公司發展，大資料治理的內涵也在發生了變化，治理不再只是成本治理，同時相比運動式治理我們更需要長期生效的治理，於是治理髮展到了新階段，即用大資料治理大資料，做到資料資產化、可衡量。　　

　　新階段的資料治理要解決哪些問題呢？第一個還是成本問題，第二個是資料質量差問題，比如某個團隊產生的資料表，其他團隊正好需要，但他們不敢用，因為他們不知道資料質量怎麼樣，對方是不是還在維護這張表，是不是能按時產出，即可能存在時效性的問題。業務方只能自己產出和維護一份同樣的表，於是有引入了重複建設的問題。最後是安全隱私問題，平臺側的審查還不夠完善。

　　針對以上問題，我們希望能夠用一套通用的方法，把這些問題統一管控。

　　解決辦法就是用大資料治理大資料，簡單說就是三步走。　　

　　第一步，建元倉。

　　所有服務都要把自己的後設資料接入到元倉中，可以看到 Yarn、Hive、HBase、主機和叢集資訊等等，都接入到元倉中。這一步做到了統一口徑，服務節約多少錢都以元倉為準。另一點是有據可查，所有參與的人都能看到服務和叢集的成本以及資源利用率。

　　第二步，定特徵。

　　有了資料，就可以定特徵。特徵是一系列規則，用於篩選出不合理的使用，比如產出表未被讀取、表存在相似資料、儲存生命週期設定的不合理、表沒有 owner 沒有負責人等等。特徵是服務方和業務方一起溝通後定下來的，每天會帶著這些特徵掃描元倉，把有問題的表找出來。

　　第三步，產品化。

　　知道了哪些表有問題，下一步就是如何去觸達使用者。這裡我們設計了一個治理產品，把所有的資料都換算成健康分，然後透過一個網頁讓業務的負責人，包括他們的大老闆，可以直接看到健康度怎麼樣。同時要給一些治理建議，比如開啟自動冷備，治理完成後分數就漲上來了。

　　儲存平臺作為資料治理的一環，承接成本治理工作，對應到 3 步裡是：後設資料接入、提供特徵、提供治理技術方案。

　　今年上半年我們用了 2 個多月的時間把這套方法落地了，主機數減少了23.8%，主機成本降低了 38.9%，主機成本降的比主機多是因為下的是比較貴的機器。　　

　　以上介紹了小米在資料治理方面的演進過程，接下來介紹儲存平臺在成本治理中具體做了哪些工作，我們做的成本治理的技術對應到前端最佳化都有哪些治理建議。

　　 03 HDFS 的治理實踐

　　首先介紹一下 HDFS 的治理實踐。　　

　　HDFS 治理策略是冷熱分層，低成本儲存技術有很多，包括：高密度、Hadoop 3 EC、在高密度機器上做 EC 等等，選型時要結合小米自身業務特點。小米的特點是叢集全球部署，海外都是直接部署在公有云上。公有云不提供高密度機器，公有云上最便宜的儲存是物件儲存，所以海外成本治理一定要圍繞物件來做。又考慮到全球統一架構，集中開發人力，我們最終選擇了 Tiering 方案，把冷資料儲存到物件儲存裡，在國內和海外是同一套方案。　　

　　具體做法：

　　（1）Tiering 在 HDFS 中引入了物件檔案，它沒有塊，只是記錄了一系列物件 uri。

　　（2）所有檔案在剛寫入的時候都是基於塊的檔案，儲存在 DN 上。

　　（3）治理服務會週期地掃描特徵，發現要治理的檔案後，傳送給 NN，NN在 INode 上打一個標記。我們部署了一個服務定期解析 image，把這些檔案找出來，轉為物件檔案。

　　（3）轉物件的過程是透過 spark 任務完成的，它先把檔案讀出來拆成物件寫入，並在檔案寫完後傳送 RPC 給 NN。NN 會新建一個物件 INode 把原來的 INode 替換掉，原來的 INode 會在 safeBox 中儲存一段時間。　　

　　下面是讀的過程：

　　（1）左側是正常使用者讀，先從 NN 獲取地址，再去 DN 讀資料。

　　（2）Tiering 的讀流程是一樣的，右側小人也是先去 NN 拿地址，不過這次拿到的是一個假的塊 id，和隨機選擇的 proxy dn 地址，之後 client 去 proxy dn 讀資料。Proxy dn 是一組沒有盤的 DN，只負責讀 Tiering 檔案。收到請求後，它會解析出 object uri，並去物件儲存把內容讀出來，返回給使用者。Proxy DN 上要做頻寬控制，一是限制單個 DN 的流量，二是限制專線流量。因為在國內我們的部署方式是物理機房+公有云，Client 和物件儲存一個在 IDC 一個在公有云，透過專線相連，是要做限速的。海外沒有這個問題，海外的 client 和物件儲存在同一個 az。

　　（3）有一些特殊情況要處理，比如 transform 成功後，原檔案要被刪掉。如果有一些 client 快取了地址或是正在讀，就會失敗。對於失敗處理的邏輯要修改下，否則會報 blkId 不匹配。另一點是短路讀，HDFS 短路讀是透過 Domain Socket 在程式間傳遞fd，從而直接讀塊檔案。但是 proxy dn 是沒有 fd 的，和 client 在一起也不能短路讀。最好是關掉，不關閉也沒關係，短路讀失敗會自動重試，走網路讀。　　

　　下面介紹 HDFS 的治理策略，如何自動化地做冷熱分層。因為 HDFS 上大部分儲存的是結構化的表，所以自動化治理完全是基於結構化資料。對於非結構化資料，我們先看其能否被當作一張表來治理，如果不能的話就先不治理了。

　　對於結構化的表要怎麼治理呢？我們先判斷表的建立時間，如果是 93 天以內建立的，那這個表還很新，先不治理它，給它打個 80 分。如果超過了 93 天，我們要治理它，先看看這張表有沒有分割槽。如果沒有分割槽，那就只能整表來看最近 93 天有沒有訪問，沒有訪問的話推給使用者建議他治理。如果有分割槽，情況會好一些，我們逐個分割槽去看最近訪問情況。這是我們要把表分為兩類，一類是不可再生的表，比如原始日誌，原始日誌我們是可以從血緣關係裡找出來的，或是計算起來極其麻煩資源耗費很大的表，這些表被列為不可再生表。除此之外都是可再生表，出了問題我們可以重新計算。我們要求使用者必須給自己的表設定 ttv 和 ttl，ttv 就是建議訪問週期，ttl是生命週期。對於不可再生表，如果超過 ttv 沒超過 ttl，就是溫資料，儲存到物件裡，如果超過 ttl 就直接刪掉。對於可再生表，如果超過 ttv 沒超過 2 倍 ttv 就是溫資料，超過 2 倍 ttv 就是冷資料，都儲存到物件裡，區別是一旦資料轉冷，就要用物件的歸檔型別，不支援直接訪問，讀之前需要先恢復。

　　 04 HBase 的治理實踐

　　接下來介紹 HBase 的治理。

　　HBase 在小米應用很廣泛，主要是用在線上場景，作為線上的資料庫，儲存索引、IOT 指令、訊息等等。線上場景對延遲有要求，所以我們大部分叢集使用的都是 SSD。HBase 的治理思路也是冷熱分離，比 SSD 便宜的儲存方式包括：HDD、Tiering、HDFS EC、高密度機器。　　

　　不同儲存方式要服務不同的場景，HBase 的場景比 HDFS 要複雜，下面介紹不同場景如何選擇冷儲存方案。

　　場景1：一致性要求高的備叢集和離線叢集　　

　　小米主備叢集用 replication 同步，資料存在不一致。備叢集分兩種，一種是容災用的，即一致性要求高的備叢集。另一種是解決可用性問題的，即可用性要求高的備叢集。

　　對一致性要求高的業務僅在主叢集徹底無法訪問時，比如機房網路全都斷掉了，或是機房起火了，才會切換到備叢集，切換後業務方允許大部分有一定恢復時間，因此我們可以用比較便宜的儲存來儲存備叢集資料，只要能在一定時間恢復到 SSD 上就行。

　　離線叢集指用來跑 Spark、Hive 作業的叢集，都是離線作業效能要求不高。

　　針對這兩種情況，我們都採用 Tiering 儲存 HFile。WAL 仍使用三副本方式寫入，不會因為寫得慢阻塞同步。Tiering的效能在做全表 scan 時和 HDD 一致，Get 時比HDD 慢 22 倍，高延遲高吞吐，用在這裡是合適的。

　　場景2：可用性要求高的備叢集　　

　　對於可用性要求高的備叢集，當主叢集發生故障，使用者需要馬上切到備叢集繼續提供服務。這時用 Tiering 就不合適了，我們採用 EC 的方式，提供和主叢集相近的效能，同時犧牲一些毛刺。

　　場景3：HBase 中的線上表　　

　　第三類場景是一些線上表儲存了時序資料。我們可以透過時間戳對資料冷熱進行劃分，以 HFile 為粒度進行冷備。在國內我們採用 HDD 儲存，海外採用 Tiering。

　　其實這裡國內的選擇不止 HDD，也可以選擇 Tiering、EC+ 高密度等等。

　　場景4&5：遷移到離線，歸檔刪除　　

　　還有兩個小的場景，對於只寫不讀的線上表，我們會建議使用者把表遷移到離線叢集去，使用 Tiering 儲存 HFile。對於 7 天無讀無寫的線上表，或是 1 年無讀無寫的離線表，我們建議使用者直接把表刪掉。因為我們面對的是線上業務，且沒有血緣能統計出表是不是可再生，刪除資料需要很謹慎，我們一般是先歸檔儲存一份，再刪除。　　

　　Hbase 的治理思路如上圖所示。首先 HBase 這裡我們沒有統計血緣，沒辦法看出來表是不是可再生，首先我們判斷表是不是無用表。長期無讀無寫的，建議歸檔後刪掉。無讀有寫的線上表，建議保留但是遷移到離線叢集。對於所有需要長期儲存的表，如果是離線叢集就全部 Tiering 轉存到物件，如果是可用性要求高備叢集就 EC，如果是一致性要求高備叢集就 Tiering，如果是時序表就在表內做冷熱分離。

　　HBase 的例項節約了 16.6% 的機器。