淘寶數(shù)據(jù)魔方技術(shù)架構(gòu)解析

1、淘寶數(shù)據(jù)魔方技術(shù)架構(gòu)解析淘寶網(wǎng)擁有國內(nèi)最具商業(yè)價(jià)值的海量數(shù)據(jù)。截至當(dāng)前，每天有超過30億的店 鋪、商品瀏覽記錄，10億在線商品數(shù)，上千萬的成交、收藏和評價(jià)數(shù)據(jù)。如何從 這些數(shù)據(jù)中挖掘出真正的商業(yè)價(jià)值，進(jìn)而幫助淘寶、商家進(jìn)行企業(yè)的數(shù)據(jù)化運(yùn)營， 幫助消費(fèi)者進(jìn)行理性的購物決策，是淘寶數(shù)據(jù)平臺(tái)與產(chǎn)品部的使命。為此，我們進(jìn)行了一系列數(shù)據(jù)產(chǎn)品的研發(fā)，比如為大家所熟知的量子統(tǒng)計(jì)、數(shù) 據(jù)魔方和淘寶指數(shù)等。盡管從業(yè)務(wù)層面來講，數(shù)據(jù)產(chǎn)品的研發(fā)難度并不高;但在“海量”的限定下，數(shù)據(jù)產(chǎn)品的計(jì)算、存儲(chǔ)和檢索難度陡然上升。本文將以數(shù)據(jù)魔 方為例，向大家介紹淘寶在海量數(shù)據(jù)產(chǎn)品技術(shù)架構(gòu)方面的探索。淘寶海量數(shù)據(jù)產(chǎn)品技術(shù)架構(gòu)數(shù)據(jù)

2、產(chǎn)品的一個(gè)最大特點(diǎn)是數(shù)據(jù)的非實(shí)時(shí)寫入，正因?yàn)槿绱耍覀兛梢哉J(rèn)為， 在一定的時(shí)間段內(nèi)，整個(gè)系統(tǒng)的數(shù)據(jù)是只讀的。這為我們設(shè)計(jì)緩存奠定了非常重要 的基礎(chǔ)。計(jì)薦展按照數(shù)據(jù)的流向來劃分，我們把淘寶數(shù)據(jù)產(chǎn)品的技術(shù)架構(gòu)分為五層（如圖1所示），分別是數(shù)據(jù)源、計(jì)算層、存儲(chǔ)層、查詢層和產(chǎn)品層。位于架構(gòu)頂端的是我們存儲(chǔ)層異構(gòu)模塊的增多，對前端產(chǎn)品的使用帶來了挑戰(zhàn)。為此，我們設(shè)訃了通 用的數(shù)據(jù)中間層一一glider來屏蔽這個(gè)影響。glider以HTTP協(xié)議對外提供 restful方式的接口。數(shù)據(jù)產(chǎn)品可以通過一個(gè)唯一的URL獲取到它想要的數(shù)據(jù)。以上是淘寶海量數(shù)據(jù)產(chǎn)品在技術(shù)架構(gòu)方面的一個(gè)概括性的介紹，接下來我將重 點(diǎn)從四

3、個(gè)方面闡述數(shù)據(jù)魔方設(shè)計(jì)上的特點(diǎn)。關(guān)系型數(shù)據(jù)庫仍然是王道關(guān)系型數(shù)據(jù)庫(RDBMS)自20世紀(jì)70年代提出以來，在工業(yè)生產(chǎn)中得到了廣泛 的使用。經(jīng)過三十多年的長足發(fā)展，誕生了一批優(yōu)秀的數(shù)據(jù)庫軟件，例如 Oracle MySQL、 DB2、 Sybase 和 SQL Server 等。圖2 MyFOX中的數(shù)據(jù)增長曲線盡管相對于非關(guān)系型數(shù)據(jù)庫而言，關(guān)系型數(shù)據(jù)庫在分區(qū)容忍性(Tolerance to NetworkPartitions)方面存在劣勢，但由于它強(qiáng)大的語義表達(dá)能力以及數(shù)據(jù)之間的關(guān) 系表達(dá)能力，在數(shù)據(jù)產(chǎn)品中仍然占據(jù)著不可替代的作用。淘寶數(shù)據(jù)產(chǎn)品選擇MySQL的MylSAM引擎作為底層的數(shù)據(jù)存儲(chǔ)

4、引擎。在此基礎(chǔ) 上，為了應(yīng)對海量數(shù)據(jù)，我們設(shè)計(jì)了分布式MySQL集群的查詢代理層一一MyFOX, 使得分區(qū)對前端應(yīng)用透明。取分片數(shù)舉（耶F）圖3 MyFOX的數(shù)據(jù)查詢過程LI前，存儲(chǔ)在MyFOX中的統(tǒng)訃結(jié)果數(shù)據(jù)已經(jīng)達(dá)到1OTB,占據(jù)著數(shù)據(jù)魔方總數(shù)據(jù) 量的95%以上，并且正在以每天超過6億的增量增長著（如圖2所示）。這些數(shù)據(jù)被 我們近似均勻地分布到20個(gè)MySQL節(jié)點(diǎn)上，在查詢時(shí)，經(jīng)山MyFOX透明地對外服 務(wù)（如圖3所示）。MyFOX熱節(jié)點(diǎn)（ MySQ冷節(jié)點(diǎn) MySQL )小釦 右：mu 3. ：:例莎：“內(nèi)樂圖4 MyFOX節(jié)點(diǎn)結(jié)構(gòu)值得一提的是，在MyFOX現(xiàn)有的20個(gè)節(jié)點(diǎn)中，并不是所有節(jié)點(diǎn)

5、都是“平等” 的。一般而言，數(shù)據(jù)產(chǎn)品的用戶更多地只關(guān)心最近兒天”的數(shù)據(jù)，越早的數(shù)據(jù), 越容易被冷落。為此，出于硬件成本考慮，我們在這20個(gè)節(jié)點(diǎn)中分出了 “熱節(jié) 點(diǎn)”和“冷節(jié)點(diǎn)”（如圖4所示）。顧名思義，“熱節(jié)點(diǎn)”存放最新的、被訪問頻率較高的數(shù)據(jù)。對于這部分?jǐn)?shù) 據(jù)，我們希望能給用戶提供盡可能快的查詢速度，所以在硬盤方面，我們選擇了每 分鐘15000轉(zhuǎn)的SAS硬盤，按照一個(gè)節(jié)點(diǎn)兩臺(tái)機(jī)器來計(jì)算，單位數(shù)據(jù)的存儲(chǔ)成本約 為4.5W/TB。相對應(yīng)地，“冷數(shù)據(jù)”我們選擇了每分鐘7500轉(zhuǎn)的SATA硬盤，單碟 上能夠存放更多的數(shù)據(jù)，存儲(chǔ)成本約為1. 6W/TBo將冷熱數(shù)據(jù)進(jìn)行分離的另外一個(gè)好處是可以有效降低內(nèi)

6、存磁盤比。從圖4可以 看出，“熱節(jié)點(diǎn)”上單機(jī)只有24GB內(nèi)存，而磁盤裝滿大約有1.8TB(300 * 12 * 0.5 / 1024),內(nèi)存磁盤比約為4:300,遠(yuǎn)遠(yuǎn)低于MySQL服務(wù)器的一個(gè)合理值。內(nèi) 存磁盤比過低導(dǎo)致的后果是，總有一天，即使所有內(nèi)存用完也存不下數(shù)據(jù)的索引 了一一這個(gè)時(shí)候，大量的查詢請求都需要從磁盤中讀取索引，效率大打折扣。NoSQL是SQL的有益補(bǔ)充在MyFOX出現(xiàn)之后，一切都看起來那么完美，開發(fā)人員甚至不會(huì)意識(shí)到MyFOX 的存在，一條不用任何特殊修飾的SQL語句就可以滿足需求。這個(gè)狀態(tài)持續(xù)了很長 一段時(shí)間，直到有一天，我們碰到了傳統(tǒng)的關(guān)系型數(shù)據(jù)庫無法解決的問題一一全屬

7、性選擇器(如圖5所示)。圖5全屬性選擇器這是一個(gè)非常典型的例子。為了說明問題，我們?nèi)匀灰躁P(guān)系型數(shù)據(jù)庫的思路來 描述。對于筆記本電腦這個(gè)類H,用戶某一次查詢所選擇的過濾條件可能包括“筆記 本尺寸”、“筆記本定位”、“硬盤容量”等一系列屬性（字段），并且在每個(gè)可能 用在過濾條件的屬性上，屬性值的分布是極不均勻的。在圖5中我們可以看到，筆 記本電腦的尺寸這一屬性有著10個(gè)枚舉值，而“藍(lán)牙功能”這個(gè)屬性值是個(gè)布爾 值，數(shù)據(jù)的篩選性非常差。在用戶所選擇的過濾條件不確定的情況下，解決全屬性問題的思路有兩個(gè):一 個(gè)是窮舉所有可能的過濾條件組合，在“云梯”上進(jìn)行預(yù)先計(jì)算，存入數(shù)據(jù)庫供查 詢；巧一個(gè)是存儲(chǔ)原始數(shù)

8、據(jù)，在用戶查詢時(shí)根據(jù)過濾條件篩選岀相應(yīng)的記錄進(jìn)行現(xiàn) 場訃算。很明顯，山于過濾條件的排列組合兒乎是無法窮舉的，笫一種方案在現(xiàn)實(shí) 中是不可取的;而第二種方案中，原始數(shù)據(jù)存儲(chǔ)在什么地方，如果仍然用關(guān)系型數(shù)據(jù) 庫，那么你打算怎樣為這個(gè)表建立索引，這一系列問題把我們引到了 “創(chuàng)建定制化的存儲(chǔ)、現(xiàn)場訃算并提供查詢服務(wù)的引擎”的思路上來,這就是Prometheus （如圖6所示）。HbaacPram圖6 Prom的存儲(chǔ)結(jié)構(gòu)從圖6可以看岀，我們選擇了 HBase作為Prom的底層存儲(chǔ)引擎。之所以選擇 HBase,主要是因?yàn)樗墙⒃贖DFS之上的，并且對于MapReduce有良好的編程接 口。盡管Prom是一

9、個(gè)通用的、解決共性問題的服務(wù)框架，但在這里，我們?nèi)匀灰?全屬性選擇為例，來說明Prom的工作原 理。這里的原始數(shù)據(jù)是前一天在淘寶上的交易明細(xì)，在HBase集群中，我們以屬性對（屬性與屬性值的組合）作為row-key進(jìn) 行存儲(chǔ)。而row-key對應(yīng)的值，我們設(shè)計(jì)了兩個(gè)column-family,即存放交易ID列表的index字段和原 始交易明細(xì)的data字段。在存儲(chǔ)的時(shí)候，我們有意識(shí)地讓每個(gè)字段中的每一個(gè)元 素都是定長的，這是為了支持通過偏移量快速地找到相應(yīng)記錄，避免復(fù)雜的查找算法和磁盤的大量隨機(jī)讀取請求。K性伯|筆e雄恰13口耐勞迄02不丘卜:iLif .if)匯總計(jì)算 寫入級存圖7 Prom

10、查詢過程圖7用一個(gè)典型的例子描述的Prom在提供查詢服務(wù)時(shí)的工作原理，限于篇幅，這里不做詳細(xì)描述。值得一提的是，Prom支持的計(jì)算并不僅限于求和SUM運(yùn) 算，統(tǒng)計(jì)意義上的常用計(jì)算都是支持的。在現(xiàn)場汁算方面，我們對Hbase進(jìn)行了擴(kuò) 展，Prom要求每個(gè)節(jié)點(diǎn)返回的數(shù)據(jù)是已經(jīng)經(jīng)過“本地計(jì)算”的局部最優(yōu)解，最終 的全局最優(yōu)解只是各個(gè)節(jié)點(diǎn)返回的局部最優(yōu)解的一個(gè)簡單匯總。很顯然，這樣的設(shè) 計(jì)思路是要充分利用各個(gè)節(jié)點(diǎn)的并行計(jì)算能力，并且避免大量明細(xì)數(shù)據(jù)的網(wǎng)絡(luò)傳輸 開銷。用中間層隔離前后端上文提到過，MyFOX和Prom為數(shù)據(jù)產(chǎn)品的不同需求提供了數(shù)據(jù)存儲(chǔ)和底層查詢 的解決方案，但隨之而來的問題是，各種異構(gòu)的

11、存儲(chǔ)模塊給前端產(chǎn)品的使用帶來了很大的挑戰(zhàn)。并且，前端產(chǎn)品的一個(gè)請求所需要的數(shù)據(jù)往往不可能只從一個(gè)模塊獲 取。舉個(gè)例子，我們要在數(shù)據(jù)魔方中看昨天做熱銷的商品，首先從MyFOX中拿到一 個(gè)熱銷排行榜的數(shù)據(jù)，但這里的“商品”只是一個(gè)ID,并沒有ID所對應(yīng)的商品描 述、圖片等數(shù)據(jù)。這個(gè)時(shí)候我們要從淘寶主站提供的接口中去獲取這些數(shù)據(jù)，然后一一對應(yīng)到熱 銷排行榜中，最終呈現(xiàn)給用戶。Controller二購存_呃存 action圖8 glider的技術(shù)架構(gòu)有經(jīng)驗(yàn)的讀者一定可以想到，從本質(zhì)上來講，這就是廣義上的異構(gòu)“表”之間 的J0I操作。那么，誰來負(fù)責(zé)這個(gè)事情呢，很容易想到，在存儲(chǔ)層與前端產(chǎn)品之間 增加一個(gè)

12、中間層，它負(fù)責(zé)各個(gè)異構(gòu)“表”之間的數(shù)據(jù)JOE（和UI0N等計(jì)算，并且 隔離前端產(chǎn)品和后端存儲(chǔ)，提供統(tǒng)一的數(shù)據(jù)查詢服務(wù)。這個(gè)中間層就是glider（如 圖8所示）。緩存是系統(tǒng)化的丄程除了起到隔離前后端以及異構(gòu)“表”之間的數(shù)據(jù)整合的作用之外，glider的另 外一個(gè)不容忽視的作用便是緩存管理。上文提到過，在特定的時(shí)間段內(nèi)，我們認(rèn)為 數(shù)據(jù)產(chǎn)品中的數(shù)據(jù)是只讀的，這是利用緩存來提高性能的理論基礎(chǔ)。在圖8中我們看到，glider中存在兩層緩存，分別是基于各個(gè)異構(gòu)“表”(datasource)的二級緩存和整合之后基于獨(dú)立請求的一級緩存。除此之外， 各個(gè)異構(gòu)“表”內(nèi)部可能還存在自己的緩存機(jī)制。細(xì)心的讀者一定注

13、意到了圖3中 MyFOX的緩存設(shè)訃，我們沒有選擇對匯總計(jì)算后的最終結(jié)果進(jìn)行緩存，而是針對 每個(gè)分片進(jìn)行緩存，其U的在于提高緩存的命中率，并且降低數(shù)據(jù)的冗余度。大量使用緩存的最大問題就是數(shù)據(jù)一致性問題。如何保證底層數(shù)據(jù)的變化在盡 可能短的時(shí)間內(nèi)體現(xiàn)給最終用戶呢，這一定是一個(gè)系統(tǒng)化的工程，尤其對于分層較 多的系統(tǒng)來說。圖9緩存控制體系圖9向我們展示了數(shù)據(jù)魔方在緩存控制方面的設(shè)計(jì)思路。用戶的請求中一定是 帶了緩存控制的“命令”的，這包括URL中的query string,和HTTP頭中的 If-None-Match信息。并且，這個(gè)緩存控制“命令” 一定會(huì)經(jīng)過層層傳遞，最 終傳遞到底層存儲(chǔ)的異構(gòu)“表”

14、模塊。各異構(gòu)“表”除了返回各自的數(shù)據(jù)之外， 還會(huì)返回各自的數(shù)據(jù)緩存過期時(shí)間(ttl),而glider最終輸岀的過期時(shí)間是各個(gè)異 構(gòu)“表”過期時(shí)間的最小值。這一過期時(shí)間也一定是從底層存儲(chǔ)層層傳遞，最終 通過HTTP頭返回給用戶瀏覽器的。緩存系統(tǒng)不得不考慮的另一個(gè)問題是緩存穿透與失效時(shí)的雪崩效應(yīng)。緩存穿透是指查詢一個(gè)一定不存在的數(shù)據(jù)，山于緩存是不命中時(shí)被動(dòng)寫的，并且出于容錯(cuò)考 慮，如果從存儲(chǔ)層查不到數(shù)據(jù)則不寫入緩存，這將導(dǎo)致這個(gè)存在的數(shù)據(jù)每次請求都 要到存儲(chǔ)層去查詢，失去了緩存的意義。有很多種方法可以有效地解決緩存穿透問題，最常見的則是采用布隆過濾器， 將所有可能存在的數(shù)據(jù)哈希到一個(gè)足夠大的bit

15、map中，一個(gè)一定不存在的數(shù)據(jù)會(huì) 被這個(gè)bitmap攔截掉，從而避免了對底層存儲(chǔ)系統(tǒng)的查詢壓力。在數(shù)據(jù)魔方里， 我們采用了一個(gè)更為簡單粗暴的方法，如果一個(gè)查詢返回的數(shù)據(jù)為空（不管是數(shù)據(jù)不存在，還是系統(tǒng)故 障），我們?nèi)匀话堰@個(gè)空結(jié)果進(jìn)行緩存，但它的過期時(shí)間會(huì)很短，最長不超過五分 鐘。緩存失效時(shí)的雪崩效應(yīng)對底層系統(tǒng)的沖擊非?？膳?。遺憾的是，這個(gè)問題口前 并沒有很完美的解決方案。大多數(shù)系統(tǒng)設(shè)計(jì)者考慮用加鎖或者隊(duì)列的方式保證緩存 的單線程（進(jìn)程）寫，從而避免失效時(shí)大量的并發(fā)請求落到底層存儲(chǔ)系統(tǒng)上。在數(shù)據(jù) 魔方中，我們設(shè)計(jì)的緩存過期機(jī)制理論上能夠?qū)⒏鱾€(gè)客戶端的數(shù)據(jù)失效時(shí)間均勻 地分布在時(shí)間軸上，一定程度上能夠避免緩存同時(shí)失效帶來的雪崩效應(yīng)。結(jié)束語正是基于本文所描述的架構(gòu)特點(diǎn)，數(shù)據(jù)魔方LI前已經(jīng)能夠提供壓縮前80TB的 數(shù)據(jù)存儲(chǔ)空間，數(shù)據(jù)中間