背景

看到這個題目，我們會有很多疑問：什麽是分布式大數據系統中的全局數據管理？為什麽要從全局對數據進行管理？這種對數據從全局進行分布和調度的策略是在什麽樣的背景下產生的？如果我們不解決全局數據管理的問題，分布式大數據系統中將會面臨一些什麽樣的風險？

總的來說：基於大數據，雲計算的需求，加快了分布式系統的發展；開源分布式系統的發展，讓海量數據存儲和處理變的簡單；產生了很多為了解決特定問題，服務特定業務的專有集群；集群之間數據無法共享，存在冗余甚至重復，遷移和復制代價高昂，同時還面臨數據校驗，驗證和生命周期等各種復雜問題；如何實現多集群之間的數據共享，去重，邏輯上的規劃，物理上的分布成為一個無法回避又急需解決的問題。

在如今的很多大數據應用場景中，由於不同的業務線和數據來源，不同的數據可能分布在不同的大數據系統中。這些數據彼此之間有著關聯，卻無法從大數據系統層面實現共享。不同的系統中，如果要訪問到其他集群的數據，需要將數據進行來回的拷貝和傳輸，即數據搬遷。即使有了數據搬遷，數據在全局上仍然存在重復冗余、一致性、數據校驗、生命周期等等一系列的問題。怎麽樣解決在不同系統之間數據和計算在全局上的優化、管理和調度？

前序知識

分布式文件系統

全局數據管理要解決的是存儲的問題，而目前所有大數據系統的底層解決存儲問題無一例外都是使用分布式文件系統（以下簡稱為DFS）計數。

傳統分布式系統的系統架構

一個典型的DFS通常分為三個大的組件：

最左邊是Client，即客戶端，用來提供用戶訪問DFS的組件，通過Client用戶可以在DFS中創建目錄；

中間是DFS的Master組件，通常一個DFS中肯定會有一個Master節點， DFS中必然會有很多的目錄、子目錄、文件等等，且通常都是按照樹型的結構一層一層地向子目錄和最終的葉子節點（文件）延伸，所以DFS的Master中緩存了DFS的整個目錄數；

如圖中中間方框所示，log1.txt這個文件就是在根——淘寶——man這個目錄下。由於DFS中文件的存儲是分塊存儲，所以Master節點還保存了所有文件的分塊信息以及這些分塊都是存在哪些slave節點的位置信息。如圖，log1.txt這個文件有三個分塊數據，分別叫做block1、block2、block3，並且這幾個block實際的數據塊是分別存儲在slave1、slave2 和slave4這三個slave節點上。

圖中的右邊就是DFS中的slave節點。通常一個DFS中至少會有一臺到多臺（不固定，兩臺甚至成千上萬臺）的slave節點。slave節點就是DFS中文件的數據存儲的最終地點，即屬於某些文件的分塊。這些分塊跟其他機器上的某些分塊按照一定的順序組合起來就能拼湊成一個完整的數據文件。另外在DFS中數據塊的存儲副本是可以進行控制的。比如圖中的log2.txt文件只有一個block4，但是這個block被分別存儲在slave1、slave3、slave4這三臺slave機器上。那麽這個log2.txt文件的副本數就是三。也就是說DFS中有這個文件所有block的三個副本。

分布式系統中的容錯機制

由於DFS通常都是在多機的環境下，而機器越多，某一時間有機器發生故障的概率就越高。當集群規模達到一定的程度的時候，比如幾千上萬臺磁盤或機器每天發生故障甚至宕機幾乎就成了常態。即使在這種情況，DFS通常也是能夠保證任何一個文件的完整性的。

數據冗余策略就是將一份數據分別在不同的機器上進行多份的冗余存儲。數據丟失的時候並不會造成數據的根本丟失。而一旦DFS發現某個文件的某個block在整個集群中的副本數小於其期望的數字的時候（比如剛才的例子中三），那麽DFS就會自動地將剩余的副本重新拷貝到其他的slave節點上直到其冗余數達到期望的副本數。

如上圖，log1.txt文件被切成三個block，每個block都只有一個副本，分別存儲在三臺slave機器上。此時當slave2這臺機器宕機的時候，我們就會發現集群中所有其他機器都已經沒有block2這個數據塊的數據。此時如果用戶來讀取log1文件，就會發現讀完block1以後無法再獲取block2的數據。相當於log1.txt中出現了一個數據斷層，這個文件的數據完整性就遭到了破壞，除非按圖中所示，slave2這臺機器恢復並且數據沒有丟失，此時用戶在讀取數據的時候就會從slave2上找到block2數據塊。在很多情況下，機器宕機很也可能無法像這裏所說的slave2恢復。在這種情況下，如log1.txt這樣block副本只有1，並且block在slave2這臺機器上的文件就可能用戶無法恢復，集群出現丟失數據的情況。

數據冗余策略能夠很大程度緩解這個問題。圖中的log2.txt文件，由於它的副本數是3，所以假設當slave3這臺機器宕機，此時block4這個數據塊的副本數變成了2，但是並不影響這個數據的完整，因為slave1和slave4上分別都含有這份數據的block副本。此時DFS發現block4只有兩個副本，小於其期望的三個副本，於是DFS會從其他擁有這個block的機器上將這份數據進行一次拷貝，拷貝到另外的一臺機器上。這樣 block4這個數據塊的冗余度重新達到三，數據的完整性沒有遭到破壞，同時數據的可靠性也跟宕機前是一樣的。

分布式節點距離計算法則

在分布式系統中，分布式節點間的距離反映了兩臺機器之間在某個層面上的遠近程度。比如，兩臺機器之間的網絡帶寬越寬，可以理解為距離越近，反之則越遠。這個距離對於數據本身的分布策略起著非常重要的指導作用。在DFS中最簡單的距離計算法則是步長計算法則。其原理就是在網絡拓撲圖中從當前節點走到指定的節點需要在拓撲圖上走幾步即為這兩個節點之間的步長。在實際的環境中，會在步長的計算法則的基礎上根據實際的物理集群環境來調整一些權重，才能形成能夠描述整個集群環境下的距離抽象模型。分布式節點間的距離計算法則對數據分布起著非常重要的指導作用，是決定數據分布的一個非常重要的決定因素。

分布式文件系統中的數據分布策略

在DFS中，數據並不是像普通的單機文件系統那樣整塊地進行文件全部數據的存儲，而是將文件數據進行切塊然後分別存儲。比如一個193MB的文件，如果按照64MB進行劃分，那麽這個文件就會被切成四個block，前三個64MB，最後一個1MB。冗余存儲策略導致每個block就會有多個副本，分布在集群的各個機器上。常見的分布式策略通常遵循如下的一些原則：讓同一個block的多個副本盡量分布在不同的磁盤、不同的機器、不同的機架以及不同的數據中心。

分布式計算調度

分布式計算的就近原則（既計算調度的localization）：將計算發送到數據所在的節點上運行；將計算發送到離數據最近的節點上運行；將計算發送到數據所在的IDC運行。

分布式環境中，機器宕機可能是常態，當某些正在運行的計算任務的機器宕機的時候，分布式計算系統是怎麽進行容錯的？分布式計算作業中，每一個計算任務只處理整個計算作業中某一部分數據，而這一部分數據通常就是分布在某些slave節點上的block塊。而由於DFS中的block都是冗余的，也因此對某個block進行計算的機器宕機的時候，由於這塊數據在其他節點上仍然有完好的副本，分布式計算系統完全可以將終端的任務重新發送到另外一臺機器上進行計算。某些個別機器的宕機就不會影響到計算本身的完整性。

跨IDC集群規劃

考慮一種最極端的情況，那就是數據不僅分布在不同的集群上，而且集群還分布在不同的數據中心甚至不同的地域的情況。在這樣的情況下，我們通過什麽樣的方式來規劃集群，達到數據共享並減少冗余和重復、高效訪問的目的？

在實踐中，阿裏使用過兩種集群規劃的形式，分別如上圖所示。如左圖，在多個數據中心之間架設統一的分布式文件系統和分布式計算系統，讓這些數據中心裏的所有機器像一個整體一樣，組成一個統一的分布式系統，讓系統屏蔽掉內部跨數據中心的物理細節，並通過智能的數據、分布策略和計算調度策略來規避由於跨數據中心的物理網絡限制。如右圖所示，其方案是分別在每一個數據中心上架設獨立的分布式文件系統和分布式計算系統，組成多個獨立的分布式系統組合。但在這些系統的上層架設一個屏蔽掉下面多系統環境的調度層來達到跨數據中心的系統統一提供給用戶層服務的目的。

雲梯

雲梯集群使用的是上述第一種集群規劃方案。下圖就是雲梯跨集群方案的架構圖。

從架構圖中可以看出，雲梯集群跨越了兩個數據中心，也就是機房一和機房二。機房一和機房二的所有機器構成了一個統一的分布式文件系統。其中一部分文件系統的Name space在機房一的Master上，另外一部分的Name space在機房二的Master上。機房二中運行的計算作業如果需要訪問數據就在機房二，那麽就直接從機房二的Master上進行訪問，不需要跨越機房間的帶寬。而如果機房二中的計算作業要訪問的是機房一中的數據，則有兩種選擇：第一是直接通過機房間的獨享網絡帶寬來直讀，這種方式對數據的訪問次數很少的情況下是可行的，但如果對同一份數據要跨機房的訪問數據很多就會產生多次訪問的帶寬疊加，代價下就會成倍地上升；第二則是讓機房一中需要被機房二中訪問到的數據將其中一個或多個副本放置在機房二，這樣當機房二中的計算任務需要訪問機房一中的數據時會發現這份數據在機房二上也有副本，於是計算會發送到機房二中的計算節點上進行計算，大大節約了數據跨機房直讀的帶寬和效率。

ODPS

ODPS集群使用的是上述第二種集群規劃方案。

如上圖中所示，下面是分別叫做伏羲的分布式計算系統和叫做盤古的分布式文件系統。在機制上提供了多種分布式計算模型如SQL、流式計算、內存計算等多種計算模型的ODPS集群。ODPS提供多種計算模型如分布式的SQL、MyProduce等。所有這些計算任務都在這套架構中進行調度和管理並最終提交到底層的伏羲調度系統，處理存儲在盤古分布式文件系統上的數據。在ODPS的下方是多個獨立的分布式集群，分別叫做Cluster1和Cluster2等等。這些系統都是一些獨立的分布式文件系統和分布式計算系統的組合，但他們都是為ODPS服務。中間方框最右邊的Replication worker組件就是用來管理ODPS中跨集群數據分布和管理策略的組件

在ODPS中數據並不一定是以最原始的分布式文件的方式呈現給用戶，而是以一種更加抽象的方式提供數據視角，用這種方式將用戶從簡單的文件操作中解放出來，只需要關心自己業務邏輯相關的數據視圖。其中最常用的兩種數據視圖分別是：Table，適用於用戶是SQL用戶，用戶運行分布式作業的方式是通過提交SQL語句來執行，這樣用戶通常來說並不關心數據的物理存儲而是以表這樣的視圖來看自己的數據；Volume，也就是原始文件數據，這樣用戶能夠通過Volume看到自己需要處理的原始文件並通過自己寫MyPreduce或者其他類型的分布式作業來對數據進行處理。

ODPS跨集群數據依賴

對於一些SQL作業，可能需要讀到不同表裏的數據，而這些表的數據又不屬於同樣的業務部門，將這些表進行關聯計算能夠挖掘出一些更加有價值的商業數據，也因此這些表之間就產生了關系，稱之為數據表之間的血緣關系。對於這種場景，如果這些表剛好又分布在不同的物理集群或者不同的數據中心，於是就產生了數據的跨集群依賴問題。

如果這種跨集群數據依賴的數據量非常大，勢必會對兩個數據中心之間的帶寬造成很大的壓力，進而拖慢很多跨集群讀取作業的計算速度。如果對同一個表的數據進行反復地讀取，那麽造成的網絡流量就會成倍地增加。有沒有一種降低網絡帶寬消耗的同時又能滿足跨集群數據依賴需求的解決方案呢？

ODPS中引入了跨集群復制系統，也就是剛剛提到的ODPS架構中最右邊的Replication worker所做的工作，其運行的本質就是當發現某一份數據被跨集群的其他數據依賴，並且依賴程度非常高的時候，Replication system會發現這種依賴並在這份數據被跨集群使用之前將這份數據跨集群地拷貝到其依賴的其他集群上，並設置這份數據在其他集群上的生命周期。通過這種智能的方式就解決了數據被跨集群依賴同時又被多次跨集群讀取造成了網絡帶寬過度消耗的問題。也因為生命周期的引入也不會對數據造成過多的副本而造成存儲空間的浪費。ODPS Replication system就是用來做上述這種動態跨集群的復制和生命周期回收的系統，其內部系統結構如下圖所示。

從架構圖中可以看到，下面不管有多少獨立的集群，Replication system能夠在他們之間自動地進行數據的拷貝。Replication worker能夠智能地掃描所有的表和Volume。當發現其中一些表或者Volume中的部分數據被跨集群的其他數據依賴的時候，就會發起一個Replication task，每一個Replication task就會提交一系列的Replication job到cluster中，進行這些數據從源集群到目的集群的拷貝。同時在每一次掃描中，當發現一些已經跨集群拷貝的數據超過了其生命周期，則表示這份數據已經不再被其他集群的數據依賴，這個時候就回收這部分數據，也就是將些已經跨集群拷貝到其他集群的數據進行刪除，以回收存儲空間。

分布式大數據系統巧實現，全局數據調度管理不再難