分析：阿里巴巴的海量數據技術架構設計

阿里巴巴網站目前來講分為中文站、國際站，還有一些國際交易和日本站之類的一些站點。我們核心表的數據量大概都是在億和十億級別，在這樣的一個數量級下面，都會涉及到一些容量方面、性能方面，以及分布式方面的一些問題。整個網站發展到現在已經11年到12年的時間。我們的數據量也從最開始的很少一點，擴大到現在的規模，尤其是近幾年更是呈爆發式的增長。數據庫層面來講，關鍵點是兩個，一個是之前我們一直采用的Oracle數據庫，不管是中文站還是國際站，Oracle數據庫有非常多的優點，但是隨著數據量的飛速增長，無論是用小機也好，還是更高端的存儲也好，都會帶來瓶頸的問題。我們在07年末，08年初的時候意識到了問題，因為那時候，我們的數據量呈現急劇上升的趨勢。當時我們考慮的是將數據庫進行拆分，拆分現在對于大家來說都已經耳熟能詳了，包括水平拆分和垂直拆分。如果從數據庫角度來講，就兩個階段，是99年到08年，然后08年到現在的這個階段。08年相當于是我們從單一的Oracle數據源跨越到多數據源支持的一個關鍵時間點。從08年開始，我們經歷了大概一到兩年的時間，將中文站最核心的表，以及和它關聯的一些表拆分到了MySQL上，這時我們已經通過數據庫的水平拆分，將數據均勻的拆分到了MySQL集群上面。不管是TPS(TransactionPerSecond)也好，容量也好，都極大的緩解了之前Oracle遇到過的問題，包括它的邏輯讀寫非常大，CPU也一度飆升到三四十之類的問題等。從目前來講，阿里巴巴的數據庫，相對于其它互聯網的一些網站，比如說淘寶，比如說Twitter之類的，本身還是有一些特點的，目前來講，還是會員服務的性質為主。對于會員來講，數據的一致性以及可用性要求都是非常高。與傳統互聯網企業相比，現在大多數新型的互聯網企業在數據存儲方面的要求可能有細微的差別。所以另外一點，數據要從集中式走向分布式。還有一點就是阿里巴巴網站相對于其他的站點而言，是少有的跨多個IDC，具備容災備份的站點。不管是中文站還是國際站都有多個站點分布在不同的國內，甚至是國外的一些機房里面，這樣的話，在包括數據一致性以及數據同步這一塊，都會有一些特有的解決方案，大致就是這些特性。應對策略：分攤與存儲數據從數據庫層面或者數據訪問層面來講無非就是兩點，第一點，是壓力如何分攤，分攤的目的就是為了把集中式變為分布式，這是其一。另外，采用多種的存儲方案，不同的業務數據，它必然會有不同的特點，針對不同的特點，我們會采用例如Oracle來存儲，或是MySQL來存，使用集中式的存儲，還是分布式的存儲，是采用傳統的RDBMS，還是采用KVStore，或者是其他的一些存儲方案。綜合以上兩點，從數據拆分來講，我們目前在B2B更多的是水平拆分，我們把一張數據量非常大的表，上億級別數據量的表，把它從Oracle里邊搬出來，拆分到MySQL里邊，這是一種水平拆分的方式。我們偶爾會采用一些垂直拆分的方案，但是垂直拆分方案相對而言，是一種過渡方案，最終還是為了達到水平拆分的目的。其實水平拆分主要為了解決兩個問題，一個是，底層存儲的無關性。另外一個就是隨著數據量以及訪問請求包括TPS、QPS(QueryPerSecond)的壓力增長，我們能夠通過線性的去增加機器就能夠滿足要求。此外還可以利用線性的這種增長方式，去支持壓力和數據量的增長。至于多存儲方案而言，其實這跟我們的業務是有緊密關系的，比如說我們非常核心的數據，目前還是選擇存儲在Oracle里面。像一些大數據量的，壓力非常大的這種表，我們就選擇把它拆分到MySQL數據庫里面去。還有一種，其實就是簡單的，比如說KVStore，跟目前的NoSQL的這種選型類似，就相當于把一些關系型不是特別明顯的，例如網站的一些用戶屬性以及一些Property之類的數據，我們都把它放到KVStore里邊去，大致，就是用這些技術手段來解決，應該說，最關鍵的一些技術解決方案，大致就是這些。數據中心處理就目前來講，其實有三個產品來密切配合解決這樣的一些問題，這三個產品分別是Erosa、Eromanga和Otter。可能聽上去會讓人感覺有點摸不著頭腦，不知道是干什么的，Erosa簡單的說就是做MySQL的Bin-Log時時解析，會對MySQL也好，還是一些其他的KVStore也好，他的BIN-LOG進行時時解析，解析完了之后，會放到Eromanga，Eromanga是什么東西？其實就是增量數據的發布訂閱的產品，Erosa產生了時時變更的數據發布到Eromanga。然后，這時候，不管是搜索引擎也好，還是數據倉庫也好，還是一些關聯的業務方也好，他就可以通過訂閱的方式，把這些時時變更的數據時時的通過Push或者是Pull的方式拉到他的業務端，然后進行一些業務處理。還有一塊是Otter，其實更多的是它的定位，就是跨IDC的數據同步，之前是國際站，現在是中文站，中文站我們也有容災站點，應該不光是說容災站點，應該是AA站點，這時候，我們要求我們的數據能夠及時的反映到兩邊去，我們是通過Otter來解決這方面的問題。Otter，其實就是類似于業界，比如說現在SharePlex的這種方式的數據同步的方式，雙向同步的數據解決方案，相比而言，不管是數據庫的同步，還是說SharePlex的同步也好，我們做了一些定制化，包括對業務數據關聯的一些文件系統同步，我們是按照事務的方式來將數據通過Otter重組應用到另外站點的數據庫里面去，這是相對于目前業界的一些商業產品不同的地方。另外一個，數據同步沖突這一塊，其實阿里巴巴站點，雖然我們現在新的一些架構都極力避免同一條數據在兩IDC機房里面的數據庫中同時被修改，但是由于一些歷史原因，的確存在有一些業務既在這個機房里變更，與此同時，他也會在另一個機房里面被變更，這時候怎么解決同步沖突。這時候我們其實這是這一塊我們目前來講，是最難解決，但是目前又還急需解決的，我們目前，當然現有的版本，暫時是一種比較簡單的方式去解決問題的。其實就是以那個站點數據為優先，站點A，比如說A機房的站點的數據是優先的，不管怎么樣，它就覆蓋到B的，今后我們會有一些包括業務相關的策略，包括變更的時間，及沖突合并之類的方式來解決到這種雙向同步，以及變更沖突這方面的一些問題。從時時效果來看，目前來講，Erosa和Otter，目前承擔了幾乎B2B所有的，不管是跨IDC的還是說從跨站點的，比如說我們從中文站同步到DW，還是從國際站同步到DW，同步到其他的一些數據源。那目前來講，基本上現在已經是遍地插滿旗幟，大致情況是這樣的。系統緩存結構設計緩存這個東西，首先在阿里巴巴來講，它其實是分為幾個級別的，從前到后，比如說從用戶最開始發起HTTP請求，到最后訪問數據庫，目前來講，是分了三級緩存的，包括圖片，包括頁面的緩存。然后直到最后面的包括數據的緩存、圖片的緩存，以及靜態頁面的緩存，相對而言，都是采用熱點數據方式，包括提高他的命中率，基本上我們的命中率都非常高，前端相對而言都比較高。對于后端比如說數據緩存這一塊，目前來講，分為LocalCache和RemoteCache，應該叫DistributeCache。就相當于說，我們會把一些不怎么變化的比如說屬性數據，用戶屬性，或是一些其他的屬性數據，會在Server啟動的時候，將其加載到LocalCache，這時，就不需要關心一致性的問題，反正就是啟動之后就加載到LocalCache，這是一種緩存。還有一種，就是RemoteCache，相當于是分布式的Cache。就B2B來講，目前Cache的實現策略非常多，實現的底層不管是包括BerkeleyDB也好，還是MemcacheDB也好，實際有很多的。同時我們在前端也做了一層封裝，無論底層的Cache是用哪一種存儲實現，都能根據業務場景需要，提供出一些最優推薦。對于如何提高緩存命中率，如何進行緩存的設計，我說下B2B的一些選擇。就前端圖片和頁面來講，我們會把一些動態頁面靜態化。靜態化這塊我們有相應的產品來支持動態頁面靜態化。數據緩存這塊，我們更多的是從對象緩存的角度來看，緩存命中率更關鍵的是把緩存力度劃分的越細，命中率相對會越高。另外一塊，緩存跟業務是具有相關性的，在做架構設計時，需要確定哪些是需要緩存到里面的，因為緩存并不是無限大的。另外，緩存是有有效期的，不可能無限的讓他存在那兒，要真是如此的話，他就不叫Cache，叫Store了，所以這塊，大致就是這樣一些機制。第一個是注意切分力度，什么樣的業務需要保證什么樣的力度，有些細力度，有些粗力度。還有一塊，如何保證緩存的生命周期，他的有效期是多久，因為不可能把所有東西都緩存到Cache里面去。技術部=拆遷大隊？其實在阿里巴巴，特別是在技術部，這邊的團隊有一個比較有意思的稱謂，叫做拆遷大隊。三國殺游戲里有個人物叫甘寧，就是專門負責拆牌的，這個團隊其實就是把目前Oracle中大數據量的表拆成MySQL的。目前來講，我們拆分，其實是有幾個拆分策略的，第一個是按字段拆分，這是最細力度的。比如說一張表我按某個字段Company拆掉，我就按COMPANY_ID來拆，這是一種方式，還有一種是按表來拆，我把這張表拆到MySQL，那張表拆到MySQL集群，更類似于垂直拆分。還有一種是按Schema拆分，Schema拆分就相當于說，這是跟應用相關的。比如說我B2B這樣應用，我會把它拆分到這個Schema機群里面來。另外W服務我會把它的數據庫拆到另外MySQL機群。但是對外提供的還是這一組，就是前面我也提到了，我們說的Cobar，可能還沒提到，就是說我們其實拆分負責數據拆分，我們有產品叫做Cobar，Cobar其實類似于MySQLProxy，他解析了MySQL所有的協議，就相當于是說，我們是可以把它看成MySQLServer來訪問的，它前端是掛了很多CobarServer的。根據Schema拆也好，按照表拆也好，在Cobar上面會根據你的需要，去定義自己的拆分策略。拆分好后，就自動會路由到MySQL不同的服務器上面去。還有一方面其實最關鍵的是，拆掉了之后，怎么樣做數據的擴容，其實我們從08年發展到現在，只能說還在路上，因為有些自動化以及自動化的配置，其實跟流動計算是相關的，我怎么樣要讓正在運行的，讓某MySQL機器人上來，然后，把比如說這里有一千萬數據，我把它對等的拆成各五百萬，拆到集群上面，然后再把這臺老的，MySQL上面的五百萬老數據干掉，我們最終理想的狀況是想自動化的完成，但目我們還是更多的是純人工的方式來做，就相當于是說先把這500萬搬過去，這時候其實有拆分原則的，但是我們內部，搬過去之后，然后再把這邊的切掉，這是純人工的。就數據遷移來講，我們內部，是有嚴格的五步走的策略，要把Oracle的一張表或者是數據庫拆分到MySQL上面去，這時候我們有嚴格的五個步驟來做的，每個步驟做完了，第一步驟做完了才能做第二個，第二個步驟做完了，做第三個，簡單來講其實就是說第一個Oracle讀寫，MySQL寫，就是慢慢的把一些數據寫到MySQL里面去，這時候要做過程就是要把Oracle的的數據要做一次數據搬遷，遷移到MySQL上面。后面，就是設一些閥值。比如說產生ID以上的一些數據，就寫到MySQL，以下的數據寫到Oracle。第二步是Oracle讀寫，然后MySQL讀，再到后面的一步一步的走，都有不同的策略，這時候，當這五步完成了之后，整個數據就遷移完了，最開始的第一個是最大的表，我們才遷移拆分，花了漫長的將近兩年時間，有一些原因是因為業務資源的配合問題，還有一塊我們是在摸著石頭過河，我們需要吃到一些虧，然后我們要去改進，吃到一些虧我們要去改進。但是到現在拆分基本上都是在兩三個月就能搞定。我們沒有像一些那種新興公司，他們做數據遷移就是直接通知用戶，我停一天，或者我停幾個小時，然后我把數據遷過去，你可以繼續登陸上來。基本上我們是不允許這么干的，所以我們通常來講，要么就是晚上，很短的時間點，我們把數據做一次遷移。另外一塊，我們要保證應用基本上不會受到影響，也就是說他可能需要配合我們做一些Restart，但是他的相關的一些操作，盡量不會影響到我們的網站用戶。后臺系統，目前后臺系統通常B2B是有專門的部門叫數據倉庫，就是DW部門的，他們會把我們的數據都拉過去，然后在那邊進行一些分析。目前來講，其實五花八門用的很多，比如說OracleRac，比如說Greenplum，當然也會用到我們的Cobar，還會用到前面提到的Erosa。其實之前來講，首先后臺基本上是一些離線數據，但是近幾年，特別是從09年開始，我們對于后臺的一些報表分析這一塊，對于數據的時時性要求也越來越高。從去年我們時時數據中心上了Erosa以后，我們數據時效性，從一天已經縮短到了五分鐘，甚至會更快。另外一方面，Hadoop應用在B2B相對而言比較少的，因為我們更多的是采用了Greenplum這種方式來做，就是做一些BI分析也好，還是報表分析也好，復雜SQL都是通過Greenplum來做的。但是，隨著我們的DW業務也在增長，所以他有一些時時性的查詢需求，目前我們Cobar也會提供，他們也搭建了一套Cobar集群，來提供這樣的在線數據服務，其實相當于現在DW我們已經搭建了一套相當于是分布式數據庫的原形，只是我們是東品西湊的把它拼