看到這個題目，我們會有很多疑問：什麼是分布式大資料系統中的全局資料管理？為什麼要從全局對資料進行管理？這種對資料從全局進行分布和排程的政策是在什麼樣的背景下産生的？如果我們不解決全局資料管理的問題，分布式大資料系統中将會面臨一些什麼樣的風險？
總的來說：基于大資料，雲計算的需求，加快了分布式系統的發展；開源分布式系統的發展，讓海量資料存儲和處理變的簡單；産生了很多為了解決特定問題，服務特定業務的專有叢集；叢集之間資料無法共享，存在備援甚至重複，遷移和複制代價高昂，同時還面臨資料校驗，驗證和生命周期等各種複雜問題；如何實作多叢集之間的資料共享，去重，邏輯上的規劃，實體上的分布成為一個無法回避又急需解決的問題。
在如今的很多大資料應用場景中，由于不同的業務線和資料來源，不同的資料可能分布在不同的大資料系統中。這些資料彼此之間有着關聯，卻無法從大資料系統層面實作共享。不同的系統中，如果要通路到其他叢集的資料，需要将資料進行來回的拷貝和傳輸，即資料搬遷。即使有了資料搬遷，資料在全局上仍然存在重複備援、一緻性、資料校驗、生命周期等等一系列的問題。怎麼樣解決在不同系統之間資料和計算在全局上的優化、管理和排程？
全局資料管理要解決的是存儲的問題，而目前所有大資料系統的底層解決存儲問題無一例外都是使用分布式檔案系統（以下簡稱為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進行計算的機器當機的時候，由于這塊資料在其他節點上仍然有完好的副本，分布式計算系統完全可以将終端的任務重新發送到另外一台機器上進行計算。某些個别機器的當機就不會影響到計算本身的完整性。
考慮一種最極端的情況，那就是資料不僅分布在不同的叢集上，而且叢集還分布在不同的資料中心甚至不同的地域的情況。在這樣的情況下，我們通過什麼樣的方式來規劃叢集，達到資料共享并減少備援和重複、高效通路的目的？
在實踐中，阿裡使用過兩種叢集規劃的形式，分别如上圖所示。如左圖，在多個資料中心之間架設統一的分布式檔案系統和分布式計算系統，讓這些資料中心裡的所有機器像一個整體一樣，組成一個統一的分布式系統，讓系統屏蔽掉内部跨資料中心的實體細節，并通過智能的資料、分布政策和計算排程政策來規避由于跨資料中心的實體網絡限制。如右圖所示，其方案是分别在每一個資料中心上架設獨立的分布式檔案系統和分布式計算系統，組成多個獨立的分布式系統組合。但在這些系統的上層架設一個屏蔽掉下面多系統環境的排程層來達到跨資料中心的系統統一提供給使用者層服務的目的。
雲梯叢集使用的是上述第一種叢集規劃方案。下圖就是雲梯跨叢集方案的架構圖。
從架構圖中可以看出，雲梯叢集跨越了兩個資料中心，也就是機房一和機房二。機房一和機房二的所有機器構成了一個統一的分布式檔案系統。其中一部分檔案系統的name space在機房一的master上，另外一部分的name space在機房二的master上。機房二中運作的計算作業如果需要通路資料就在機房二，那麼就直接從機房二的master上進行通路，不需要跨越機房間的帶寬。而如果機房二中的計算作業要通路的是機房一中的資料，則有兩種選擇：第一是直接通過機房間的獨享網絡帶寬來直讀，這種方式對資料的通路次數很少的情況下是可行的，但如果對同一份資料要跨機房的通路資料很多就會産生多次通路的帶寬疊加，代價下就會成倍地上升；第二則是讓機房一中需要被機房二中通路到的資料将其中一個或多個副本放置在機房二，這樣當機房二中的計算任務需要通路機房一中的資料時會發現這份資料在機房二上也有副本，于是計算會發送到機房二中的計算節點上進行計算，大大節約了資料跨機房直讀的帶寬和效率。
odps叢集使用的是上述第二種叢集規劃方案。
在odps中資料并不一定是以最原始的分布式檔案的方式呈現給使用者，而是以一種更加抽象的方式提供資料視角，用這種方式将使用者從簡單的檔案操作中解放出來，隻需要關心自己業務邏輯相關的資料視圖。其中最常用的兩種資料視圖分别是：table，适用于使用者是sql使用者，使用者運作分布式作業的方式是通過送出sql語句來執行，這樣使用者通常來說并不關心資料的實體存儲而是以表這樣的視圖來看自己的資料；volume，也就是原始檔案資料，這樣使用者能夠通過volume看到自己需要處理的原始檔案并通過自己寫mypreduce或者其他類型的分布式作業來對資料進行處理。
對于一些sql作業，可能需要讀到不同表裡的資料，而這些表的資料又不屬于同樣的業務部門，将這些表進行關聯計算能夠挖掘出一些更加有價值的商業資料，也是以這些表之間就産生了關系，稱之為資料表之間的血緣關系。對于這種場景，如果這些表剛好又分布在不同的實體叢集或者不同的資料中心，于是就産生了資料的跨叢集依賴問題。
如果這種跨叢集資料依賴的資料量非常大，勢必會對兩個資料中心之間的帶寬造成很大的壓力，進而拖慢很多跨叢集讀取作業的計算速度。如果對同一個表的資料進行反複地讀取，那麼造成的網絡流量就會成倍地增加。有沒有一種降低網絡帶寬消耗的同時又能滿足跨叢集資料依賴需求的解決方案呢？
odps中引入了跨叢集複制系統，也就是剛剛提到的odps架構中最右邊的replication worker所做的工作，其運作的本質就是當發現某一份資料被跨叢集的其他資料依賴，并且依賴程度非常高的時候，replication system會發現這種依賴并在這份資料被跨叢集使用之前将這份資料跨叢集地拷貝到其依賴的其他叢集上，并設定這份資料在其他叢集上的生命周期。通過這種智能的方式就解決了資料被跨叢集依賴同時又被多次跨叢集讀取造成了網絡帶寬過度消耗的問題。也因為生命周期的引入也不會對資料造成過多的副本而造成存儲空間的浪費。odps replication system就是用來做上述這種動态跨叢集的複制和生命周期回收的系統，其内部系統結構如下圖所示。
從架構圖中可以看到，下面不管有多少獨立的叢集，replication system能夠在他們之間自動地進行資料的拷貝。replication
worker能夠智能地掃描所有的表和volume。當發現其中一些表或者volume中的部分資料被跨叢集的其他資料依賴的時候，就會發起一個replication
task，每一個replication task就會送出一系列的replication job到cluster中，進行這些資料從源叢集到目的叢集的拷貝。同時在每一次掃描中，當發現一些已經跨叢集拷貝的資料超過了其生命周期，則表示這份資料已經不再被其他叢集的資料依賴，這個時候就回收這部分資料，也就是将些已經跨叢集拷貝到其他叢集的資料進行删除，以回收存儲空間。