【摘要】Akkio 從2014年進入Facebook ，管理著100PB的資料量。幫助Facebook 減少了高達50%的訪問延遲、高達50%的跨資料中心流量和高達40%的儲存佔用空間。本文對Akkio 架構、原理以及它如何實現它的目標進行了探索，希望大家能夠基於此類思路啟發，在今天的多雲分散式環境下找到更多適合的場景。

【作者】趙海

1. 背景介紹

偶爾讀到 OSDI 一篇關於 Akkio的文章，瞭解到這個工具的具體作用和它如何在臉書粉墨登場併發揮著巨大的作用，並幫助解決了臉書多資料中心架構下的資料區域性熱點問題，並且幫助臉書降低了 50%的使用者訪問延遲，減少了50%的跨資料中心流量，降低了40%的儲存空間等。既然這個工具有如此之巨大歷史貢獻，本人懷著濃厚的興趣翻閱了相關的資料，記錄了一些筆記，現在我想將其整理出來分享給大家。

2. Akkio是什麼

Akkio本身是一個介於分散式資料庫和應用客戶端之間的元件，它是用來幫助分散式資料庫實現何時、何處、如何遷移資料並且最終幫助資料庫實現使用者訪問低延遲的工具。關於它的細節認識，我們將從以下幾個部分來展開說明。

2.1 Akkio & Facebook

2014年，Akkio開始在Facebook的生產環境啟用，主要應用於ZippyDB, Cassandra以及其他三種分散式資料庫系統，管理著100PB數量級的資料。那麼為什麼Facebook會在2014年的時候選擇了這個工具呢，是什麼樣的背景呢？

首先，Facebook是以分散式資料庫為其基本的資料儲存架構，資料庫是以切片的形式存在於世界各個不同資料中心內。Facebook有很多重量級的資料訪問是以較高的更新比例（60%寫比例）為基礎的，這樣的話就會造成它的多個資料中心之間進行資料複製，從而消耗大量的頻寬和儲存資源，同時大量的跨資料中心的資料訪問成為必然，最終導致使用者訪問的延遲。

顯然，對於這個問題採取更多副本的策略固然可以降低使用者訪問延遲的問題，但是帶來更大的問題就是跨資料中心流量的暴增和儲存空間的暴增。因此，Facebook急需要一種工具可以根據資料訪問的熱點程度來選擇什麼樣的資料遷移到哪一個資料中心更適合大量熱點使用者的訪問。

於是，Facebook選擇了Akkio，那麼接下來我們看看Akkio在服役期間的表現如何？

從資料庫服務指標上來看，讀的延遲降低到原來的50%，寫的延遲降低到原來的50%以下，跨資料中心的橫向資料複製流量減少到原來的50%以下，用來存全量副本的儲存空間減少到原來的40%。從擴充套件性角度來看，Facebook業務系統整體的處理能力具備了十億級使用者併發處理能力，每秒處理能力達到數千萬。

2.2 Akkio的歷史使命及適合的場景

從 Akkio在Facebook服役的過程，我們基本可以看到Akkio的貢獻，也就明白了它的歷史使命。

其實，除了Facebook這樣的業務場景需要它，還有很多場景也需要它，總結來看我們可以認為有以下幾個場景非常適合Akkio的功能展示（前提是適合分散式資料庫的場景基礎之上）。

1、雲資料中心架構下的運營成本。減少資料副本數、儲存空間和跨資料中心的橫向資料通訊；

2、資料區域性熱點頻繁變化的場景。訪問請求會不斷發生變換，每個使用者訪問的資料也會不斷變化；

3、資料庫讀寫特點以讀寫均衡或者寫比例相對較高的場景，幫助減少大副本複製；

4、分散式快取效率低，無論讀寫，如果分散式快取的命中率很低，勢必產生大量的跨資料中心讀寫；

5、資料型別及大小更適合 Akkio的分散式資料庫（下文會講到Akkio對資料的管理）。

3. Akkio架構設計及原理

3.1 Akkio組成

Akkio是屬於客戶端和分散式資料庫之間的中間層，主要包括DPS（Data Placement Service）、Access DB、Location DB、Client SDK等幾個元件。具體如圖 3.1所示。

圖3.1 Akkio 架構原理圖

探索Facebook幕後神器：分散式資料庫切片佈局自動化管理工具 Akkio

結合圖3.1，我們來看Akkio架構組成當中的各個主要元件的功能：

Client SDK：它是被安裝整合在分散式資料庫客戶端元件當中的外掛，負責與Akkio其他核心元件模組進行控制資訊以及資料資訊的互動。
Location DB：它是分散式資料庫在Akkio邏輯檢視上的後設資料，主要記錄資料切片的位置資訊。
Access DB：它是資料訪問的一個統計資訊資料庫，根據它來決定資料如何遷移。
DPS：它是Akkio的核心元件，主要負責資料的遷移以及遷移之後的位置資訊更新。

在瞭解了以上各個核心元件的基礎之上，我們來看在這個架構下的資料的訪問獲取流程：

1.應用客戶端發起資料訪問請求getdataBy(key,Value)。

2.Akkio Client SDK 將資料訪問請求getdataBy(key,Value)轉化為getdataBy(µ-shard-id,key,Value)。這個µ-shard-id就是真正的資料所在的切片位置資訊，只不過這個切片µ-shard是經過Akkio根據自己的檢視邏輯劃分的更小的資料庫切片。

3.Akkio Client SDK 首先訪問Location DB Service，以獲取µ-shard-id。① 如果獲取到µ-shard-id，那麼返回並執行第4步。② 如果沒有獲取到µ-shard-id，那麼它會通知DPS進行切片的資訊更新，然後重複執行。

4.Akkio Client SDK 告訴分散式資料庫客戶端去哪個DB Shard當中去獲取資料。

3.2 Akkio & µ-shards

Akkio的歷史使命就是最佳化資料的佈局以降低使用者訪問延遲、減少跨資料中心流量、降低儲存空間等。那麼如何達到對資料佈局的最佳化呢？這就一定會涉及到資料的邏輯檢視問題，也就是它對資料如何定義、劃分、組織等一系列問題。這就涉及到一個非常重要的概念μ-shard。

Akkio 將原來分散式資料庫非常大的切片（Shard），分割為非常小的切片單元（ μ-shard ）。
Akkio Client SDK來決定 μ-shard的建立，不是分散式資料庫。
μ-shard的大小通常為幾十K到幾百K，不超過M。
Akkio 將 μ-shard與分散式資料庫切片的對映關係儲存在Location DB當中。
Akkio Client 資料訪問統計資訊是以對 μ-shard的訪問頻度進行統計的，並記錄在AccessDB。
當新的 μ-shard 分片被 Akkio Client 建立時，通常情況下會在距離請求的客戶端最近的資料中心選擇副本儲存資料並在相鄰的資料中心中選擇負載較輕的作為備份。也可以直接使用簡單的雜湊函式來決定資料儲存的資料中心。

3.3 Akkio工作原理

關於Akkio的工作原理，其實主要要搞清楚3個關鍵問題：Akkio何時決定要遷移資料？Akkio如何決定資料的遷移方式？Akkio如何保障遷移過程當中的資料一致性？

1.Akkio何時決定要遷移資料？

當Akkio Client 訪問資料的時候，如果它發現獲取到的μ-shard-id是在遠方資料中心的DB-Shard當中，那麼它會通知到DPS，這個時候DPS會檢查是否需要進行μ-shard的遷移。這是主動的觸發，另外一種就是Akkio DPS在後臺的非同步檢查被動觸發。

2.Akkio如何決定資料的遷移方式？

很顯然在這個問題當中，我們首先需要找到要遷移的物件，然後需要找到遷移的目的地。如何找到這兩個核心引數，Akkio主要是要依靠Access DB當中的統計資訊以及分散式資料庫的例項統計資訊，在Access DB當中記錄著客戶端發起的對不同的μ-shard的訪問資訊。

Akkio以每一個μ-shard為單位，也就是說在主動觸發的場景當中，Akkio通知DPS的那個沒有從就近獲取到的μ-shard資料就是我們可能要遷移的資料物件。針對這個資料物件μ-shard，Akkio會計算不同的資料中心針對這個μ-shard可以得到的加權分，得分最高的資料中心就是這個μ-shard資料的遷移目標，同等得分情況下，Akkio會根據資料中心資源的情況再進行篩選，例如CPU、Memory、IO等統計資訊。

關於資料中心的得分情況，主要是參考兩個指標：資料被訪問的次數、請求的遠近程度。訪問的次數越多得分越多，訪問距離本資料中心越近權重越高。

3.Akkio如何保障遷移過程中的資料一致性？

資料遷移的過程當中可能會遇到兩種情況，一種就是在遷移的過程當中，μ-shard同時獲得了更新的請求處理。另外一種就是在遷移的過程當中獲得了其他讀的請求。對於Facebook的ZippyDB的解決方案來講，它是透過鎖許可權控制來實現的。

(1). 獲取 μ-shard上的鎖許可權，並標記為遷移列表中的元素；

(2). 將遷移原資料μ-shard以及遷移目標μ-shard都設定為只讀許可權；

(3). 從源資料中心將μ-shard遷移到目標資料中心；

(4). 更新Location DB資訊；

(5). 刪除源資料中心當中的μ-shard，將μ-shard從遷移列表釋放，並且釋放鎖資訊；

當然，這裡也可以透過源資料μ-shard和目標資料μ-shard同步接受更新的方式來保持資料的一致性。

4. Akkio如何完成其使命

4.1 使用者訪問延遲

我們透過對Facebook的資料瞭解到：Akkio的應用使得Facebook的使用者訪問延遲降到了原來的50%。那麼從理論上來講，增加了Akkio之後，資料訪問的深度加了一層，資料對映增加了（ μ-shard-DB Shard ）維度，而且增加了資料定址的複雜度，資料訪問的延遲應該是增加了啊。

但是我們透過DPS的遷移，將熱點的 μ-shard資料遷移到客戶訪問相對最近的資料中心，那麼資料在從分散式資料庫儲存系統到客戶端這個過程卻是避免很多的遠距離傳輸，將大部分的跨資料中心遠距離傳輸轉化為大部分的就近訪問，這部分節省下來的時間相對於定址複雜化來講要可觀的多，尤其是在海量資料多資料中心的雲架構當中。

另外，資料中心之間的資料流量減少必然會改善通道傳輸質量，少數跨中心訪問也會比原來好很多。

4.2 跨資料中心橫向流量

我們知道分散式資料庫的副本數是根據資料庫的整體策略制定的，使用者資料是一定的，資料副本的絕對數量也是一定的，為什麼在Facebook的資料當中會減少50%的跨資料中心橫向流量呢？

其實分散式資料庫進行資料副本的複製的時候，一般都是日誌回溯的模式，也就是說在資料中心之間傳遞的應該是一些事務日誌，並不是大量的使用者資料。所以真正佔用跨資料中心頻寬的還是客戶端請求的使用者資料，正因為Akkio具備將資料以 μ-shard為單元進行最佳化佈局的能力，才減少了大量的跨資料中心請求，最終導致跨資料中心橫向流量的減少。

因此，這個問題與4.1當中的問題其實是一個問題。

4.3 儲存空間

假定我們把分散式資料庫的副本數看成是一個固定的數字，比如是3。那麼在這個前提條件下，大家可能無論如何都不覺得Akkio能帶來儲存空間的節約。因為無論如何去切分資料，資料副本數都是3，怎麼可能節約儲存空間呢？

但是我們從另外一個角度來看，Facebook的業務橫跨全世界的很多資料中心，如果僅僅是基於高可用或者容災角度的三副本機制，那麼隨著業務的不斷擴充套件，使用者訪問體驗必然越來越差。因此提高資料的副本數是在沒有Akkio的場景下，提升使用者訪問體驗的一種手段，副本數越多，意味著使用者訪問的平均路徑會短，延遲就會低。但是這樣解決問題意味著要以倍數的程度投入儲存資源。

所以從這個意義上來講，原來10個副本才能實現的使用者體驗，用了Akkio之後，可以以5個副本的策略達到同樣的使用者訪問延遲，那麼儲存空間是不是節約了一半？

5. 總結展望

Akkio 從2014年進入Facebook ，管理著100PB的資料量。幫助Facebook 減少了高達50%的訪問延遲、高達50%的跨資料中心流量和高達40%的儲存佔用空間。本文透過對Akkio 架構、原理以及它如何實現它的目標的探索，可以知道 Akkio 透過合理利用使用者的訪問統計資訊，最佳化資料動態佈局，使得資料更加貼近使用者，不僅提高使用者體驗，而且節約IT運營成本。看起來，這是一個非常有意義的工具。但是 Akkio並不適用於所有的場景。因此，基於此類思路的啟發，在今天的多雲分散式環境下找到更多適合的場景，那將是非常有意義的事情。