淘寶網(wǎng)擁有國(guó)內(nèi)最具商業(yè)價(jià)值的海量數(shù)據(jù)。截至當(dāng)前，每天有超過(guò)30億的店鋪、商品瀏覽記錄，10億在線商品數(shù)，上千萬(wàn)的成交、收藏和評(píng)價(jià)數(shù)據(jù)。如何

從這些數(shù)據(jù)中挖掘出真正的商業(yè)價(jià)值，進(jìn)而幫助淘寶、商家進(jìn)行企業(yè)的數(shù)據(jù)化運(yùn)營(yíng)，幫助消費(fèi)者進(jìn)行理性的購(gòu)物決策，是淘寶數(shù)據(jù)平臺(tái)與產(chǎn)品部的使命。

為此，我們進(jìn)行了一系列數(shù)據(jù)產(chǎn)品的研發(fā)，比如為大家所熟知的量子統(tǒng)計(jì)、數(shù)據(jù)魔方和淘寶指數(shù)等。盡管從業(yè)務(wù)層面來(lái)講，數(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ù)產(chǎn)品的一個(gè)最大特點(diǎn)是數(shù)據(jù)的非實(shí)時(shí)寫(xiě)入，正因?yàn)槿绱?#xff0c;我們可以認(rèn)為，在一定的時(shí)間段內(nèi)，整個(gè)系統(tǒng)的數(shù)據(jù)是只讀的。這為我們?cè)O(shè)計(jì)緩存奠定了非常重要的基礎(chǔ)。

圖1 淘寶海量數(shù)據(jù)產(chǎn)品技術(shù)架構(gòu)

按照數(shù)據(jù)的流向來(lái)劃分，我們把淘寶數(shù)據(jù)產(chǎn)品的技術(shù)架構(gòu)分為五層(如圖1所示)，分別是數(shù)據(jù)源、計(jì)算層、存儲(chǔ)層、查詢(xún)層和產(chǎn)品層。位于架構(gòu)頂端的

是我們的數(shù)據(jù)來(lái)源層，這里有淘寶主站的用戶(hù)、店鋪、商品和交易等數(shù)據(jù)庫(kù)，還有用戶(hù)的瀏覽、搜索等行為日志等。這一系列的數(shù)據(jù)是數(shù)據(jù)產(chǎn)品最原始的生命力所

在。

在數(shù)據(jù)源層實(shí)時(shí)產(chǎn)生的數(shù)據(jù)，通過(guò)淘寶主研發(fā)的數(shù)據(jù)傳輸組件DataX、DbSync和Timetunnel準(zhǔn)實(shí)時(shí)地傳輸?shù)揭粋€(gè)有1500個(gè)節(jié)點(diǎn)

的Hadoop集群上，這個(gè)集群我們稱(chēng)之為“云梯”，是計(jì)算層的主要組成部分。在“云梯”上，我們每天有大約40000個(gè)作業(yè)對(duì)1.5PB的原始數(shù)據(jù)按照

產(chǎn)品需求進(jìn)行不同的MapReduce計(jì)算。這一計(jì)算過(guò)程通常都能在凌晨?jī)牲c(diǎn)之前完成。相對(duì)于前端產(chǎn)品看到的數(shù)據(jù)，這里的計(jì)算結(jié)果很可能是一個(gè)處于中間狀

態(tài)的結(jié)果，這往往是在數(shù)據(jù)冗余與前端計(jì)算之間做了適當(dāng)平衡的結(jié)果。

不得不提的是，一些對(duì)實(shí)效性要求很高的數(shù)據(jù)，例如針對(duì)搜索詞的統(tǒng)計(jì)數(shù)據(jù)，我們希望能盡快推送到數(shù)據(jù)產(chǎn)品前端。這種需求再采用“云梯”來(lái)計(jì)算效率

將是比較低的，為此我們做了流式數(shù)據(jù)的實(shí)時(shí)計(jì)算平臺(tái)，稱(chēng)之為“銀河”。“銀河”也是一個(gè)分布式系統(tǒng)，它接收來(lái)自TimeTunnel的實(shí)時(shí)消息，在內(nèi)存中

做實(shí)時(shí)計(jì)算，并把計(jì)算結(jié)果在盡可能短的時(shí)間內(nèi)刷新到NoSQL存儲(chǔ)設(shè)備中，供前端產(chǎn)品調(diào)用。

容易理解，“云梯”或者“銀河”并不適合直接向產(chǎn)品提供實(shí)時(shí)的數(shù)據(jù)查詢(xún)服務(wù)。這是因?yàn)?#xff0c;對(duì)于“云梯”來(lái)說(shuō)，它的定位只是做離線計(jì)算的，無(wú)法支持

較高的性能和并發(fā)需求；而對(duì)于“銀河”而言，盡管所有的代碼都掌握在我們手中，但要完整地將數(shù)據(jù)接收、實(shí)時(shí)計(jì)算、存儲(chǔ)和查詢(xún)等功能集成在一個(gè)分布式系統(tǒng)

中，避免不了分層，最終仍然落到了目前的架構(gòu)上。

為此，我們針對(duì)前端產(chǎn)品設(shè)計(jì)了專(zhuān)門(mén)的存儲(chǔ)層。在這一層，我們有基于MySQL的分布式關(guān)系型數(shù)據(jù)庫(kù)集群MyFOX和基于HBase的NoSQL

存儲(chǔ)集群Prom，在后面的文字中，我將重點(diǎn)介紹這兩個(gè)集群的實(shí)現(xiàn)原理。除此之外，其他第三方的模塊也被我們納入存儲(chǔ)層的范疇。

存儲(chǔ)層異構(gòu)模塊的增多，對(duì)前端產(chǎn)品的使用帶來(lái)了挑戰(zhàn)。為此，我們?cè)O(shè)計(jì)了通用的數(shù)據(jù)中間層——glider——來(lái)屏蔽這個(gè)影響。glider以HTTP協(xié)議對(duì)外提供restful方式的接口。數(shù)據(jù)產(chǎn)品可以通過(guò)一個(gè)唯一的URL獲取到它想要的數(shù)據(jù)。

以上是淘寶海量數(shù)據(jù)產(chǎn)品在技術(shù)架構(gòu)方面的一個(gè)概括性的介紹，接下來(lái)我將重點(diǎn)從四個(gè)方面闡述數(shù)據(jù)魔方設(shè)計(jì)上的特點(diǎn)。

關(guān)系型數(shù)據(jù)庫(kù)仍然是王道

關(guān)系型數(shù)據(jù)庫(kù)(RDBMS)自20世紀(jì)70年代提出以來(lái)，在工業(yè)生產(chǎn)中得到了廣泛的使用。經(jīng)過(guò)三十多年的長(zhǎng)足發(fā)展，誕生了一批優(yōu)秀的數(shù)據(jù)庫(kù)軟件，例如Oracle、MySQL、DB2、Sybase和SQL Server等。

圖2 MyFOX中的數(shù)據(jù)增長(zhǎng)曲線

盡管相對(duì)于非關(guān)系型數(shù)據(jù)庫(kù)而言，關(guān)系型數(shù)據(jù)庫(kù)在分區(qū)容忍性(Tolerance to Network Partitions)方面存在劣勢(shì)，但由于它強(qiáng)大的語(yǔ)義表達(dá)能力以及數(shù)據(jù)之間的關(guān)系表達(dá)能力，在數(shù)據(jù)產(chǎn)品中仍然占據(jù)著不可替代的作用。

淘寶數(shù)據(jù)產(chǎn)品選擇MySQL的MyISAM引擎作為底層的數(shù)據(jù)存儲(chǔ)引擎。在此基礎(chǔ)上，為了應(yīng)對(duì)海量數(shù)據(jù)，我們?cè)O(shè)計(jì)了分布式MySQL集群的查詢(xún)代理層——MyFOX，使得分區(qū)對(duì)前端應(yīng)用透明。

圖3 MyFOX的數(shù)據(jù)查詢(xún)過(guò)程

目前，存儲(chǔ)在MyFOX中的統(tǒng)計(jì)結(jié)果數(shù)據(jù)已經(jīng)達(dá)到10TB，占據(jù)著數(shù)據(jù)魔方總數(shù)據(jù)量的95%以上，并且正在以每天超過(guò)6億的增量增長(zhǎng)著(如圖2所示)。這些數(shù)據(jù)被我們近似均勻地分布到20個(gè)MySQL節(jié)點(diǎn)上，在查詢(xún)時(shí)，經(jīng)由MyFOX透明地對(duì)外服務(wù)(如圖3所示)。

圖4 MyFOX節(jié)點(diǎn)結(jié)構(gòu)

值得一提的是，在MyFOX現(xiàn)有的20個(gè)節(jié)點(diǎn)中，并不是所有節(jié)點(diǎn)都是“平等”的。一般而言，數(shù)據(jù)產(chǎn)品的用戶(hù)更多地只關(guān)心“最近幾天”的數(shù)據(jù)，越早的數(shù)據(jù)，越容易被冷落。為此，出于硬件成本考慮，我們?cè)谶@20個(gè)節(jié)點(diǎn)中分出了“熱節(jié)點(diǎn)”和“冷節(jié)點(diǎn)”(如圖4所示)。

顧名思義，“熱節(jié)點(diǎn)”存放最新的、被訪問(wèn)頻率較高的數(shù)據(jù)。對(duì)于這部分?jǐn)?shù)據(jù)，我們希望能給用戶(hù)提供盡可能快的查詢(xún)速度，所以在硬盤(pán)方面，我們選擇

了每分鐘15000轉(zhuǎn)的SAS硬盤(pán)，按照一個(gè)節(jié)點(diǎn)兩臺(tái)機(jī)器來(lái)計(jì)算，單位數(shù)據(jù)的存儲(chǔ)成本約為4.5W/TB。相對(duì)應(yīng)地，“冷數(shù)據(jù)”我們選擇了每分鐘7500

轉(zhuǎn)的SATA硬盤(pán)，單碟上能夠存放更多的數(shù)據(jù)，存儲(chǔ)成本約為1.6W/TB。

將冷熱數(shù)據(jù)進(jìn)行分離的另外一個(gè)好處是可以有效降低內(nèi)存磁盤(pán)比。從圖4可以看出，“熱節(jié)點(diǎn)”上單機(jī)只有24GB內(nèi)存，而磁盤(pán)裝滿大約有

1.8TB(300 * 12 * 0.5 /

1024)，內(nèi)存磁盤(pán)比約為4:300，遠(yuǎn)遠(yuǎn)低于MySQL服務(wù)器的一個(gè)合理值。內(nèi)存磁盤(pán)比過(guò)低導(dǎo)致的后果是，總有一天，即使所有內(nèi)存用完也存不下數(shù)據(jù)的

索引了——這個(gè)時(shí)候，大量的查詢(xún)請(qǐng)求都需要從磁盤(pán)中讀取索引，效率大打折扣。

NoSQL是SQL的有益補(bǔ)充

在MyFOX出現(xiàn)之后，一切都看起來(lái)那么完美，開(kāi)發(fā)人員甚至不會(huì)意識(shí)到MyFOX的存在，一條不用任何特殊修飾的SQL語(yǔ)句就可以滿足需求。這個(gè)狀態(tài)持續(xù)了很長(zhǎng)一段時(shí)間，直到有一天，我們碰到了傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)無(wú)法解決的問(wèn)題——全屬性選擇器(如圖5所示)。

圖5 全屬性選擇器

這是一個(gè)非常典型的例子。為了說(shuō)明問(wèn)題，我們?nèi)匀灰躁P(guān)系型數(shù)據(jù)庫(kù)的思路來(lái)描述。對(duì)于筆記本電腦這個(gè)類(lèi)目，用戶(hù)某一次查詢(xún)所選擇的過(guò)濾條件可能包

括

“筆記本尺寸”、“筆記本定位”、“硬盤(pán)容量”等一系列屬性(字段)，并且在每個(gè)可能用在過(guò)濾條件的屬性上，屬性值的分布是極不均勻的。在圖5中我們可以

看到，筆記本電腦的尺寸這一屬性有著10個(gè)枚舉值，而“藍(lán)牙功能”這個(gè)屬性值是個(gè)布爾值，數(shù)據(jù)的篩選性非常差。

在用戶(hù)所選擇的過(guò)濾條件不確定的情況下，解決全屬性問(wèn)題的思路有兩個(gè)：一個(gè)是窮舉所有可能的過(guò)濾條件組合，在“云梯”上進(jìn)行預(yù)先計(jì)算，存入數(shù)據(jù)

庫(kù)供查詢(xún)；另一個(gè)是存儲(chǔ)原始數(shù)據(jù)，在用戶(hù)查詢(xún)時(shí)根據(jù)過(guò)濾條件篩選出相應(yīng)的記錄進(jìn)行現(xiàn)場(chǎng)計(jì)算。很明顯，由于過(guò)濾條件的排列組合幾乎是無(wú)法窮舉的，第一種方案

在現(xiàn)實(shí)中是不可取的；而第二種方案中，原始數(shù)據(jù)存儲(chǔ)在什么地方？如果仍然用關(guān)系型數(shù)據(jù)庫(kù)，那么你打算怎樣為這個(gè)表建立索引？

這一系列問(wèn)題把我們引到了“創(chuàng)建定制化的存儲(chǔ)、現(xiàn)場(chǎng)計(jì)算并提供查詢(xún)服務(wù)的引擎”的思路上來(lái)，這就是Prometheus(如圖6所示)。

圖6 Prom的存儲(chǔ)結(jié)構(gòu)

從圖6可以看出，我們選擇了HBase作為Prom的底層存儲(chǔ)引擎。之所以選擇HBase，主要是因?yàn)樗墙⒃贖DFS之上的，并且對(duì)于

MapReduce有良好的編程接口。盡管Prom是一個(gè)通用的、解決共性問(wèn)題的服務(wù)框架，但在這里，我們?nèi)匀灰匀珜傩赃x擇為例，來(lái)說(shuō)明Prom的工作原

理。這里的原始數(shù)據(jù)是前一天在淘寶上的交易明細(xì)，在HBase集群中，我們以屬性對(duì)(屬性與屬性值的組合)作為row-key進(jìn)行存儲(chǔ)。而row-key

對(duì)應(yīng)的值，我們?cè)O(shè)計(jì)了兩個(gè)column-family，即存放交易ID列表的index字段和原始交易明細(xì)的data字段。在存儲(chǔ)的時(shí)候，我們有意識(shí)地讓

每個(gè)字段中的每一個(gè)元素都是定長(zhǎng)的，這是為了支持通過(guò)偏移量快速地找到相應(yīng)記錄，避免復(fù)雜的查找算法和磁盤(pán)的大量隨機(jī)讀取請(qǐng)求。

圖7 Prom查詢(xún)過(guò)程

圖7用一個(gè)典型的例子描述的Prom在提供查詢(xún)服務(wù)時(shí)的工作原理，限于篇幅，這里不做詳細(xì)描述。值得一提的是，Prom支持的計(jì)算并不僅限于求

和SUM運(yùn)算，統(tǒng)計(jì)意義上的常用計(jì)算都是支持的。在現(xiàn)場(chǎng)計(jì)算方面，我們對(duì)Hbase進(jìn)行了擴(kuò)展，Prom要求每個(gè)節(jié)點(diǎn)返回的數(shù)據(jù)是已經(jīng)經(jīng)過(guò)“本地計(jì)算”的

局部最優(yōu)解，最終的全局最優(yōu)解只是各個(gè)節(jié)點(diǎn)返回的局部最優(yōu)解的一個(gè)簡(jiǎn)單匯總。很顯然，這樣的設(shè)計(jì)思路是要充分利用各個(gè)節(jié)點(diǎn)的并行計(jì)算能力，并且避免大量明

細(xì)數(shù)據(jù)的網(wǎng)絡(luò)傳輸開(kāi)銷(xiāo)。

用中間層隔離前后端

上文提到過(guò)，MyFOX和Prom為數(shù)據(jù)產(chǎn)品的不同需求提供了數(shù)據(jù)存儲(chǔ)和底層查詢(xún)的解決方案，但隨之而來(lái)的問(wèn)題是，各種異構(gòu)的存儲(chǔ)模塊給前端產(chǎn)品的使用帶來(lái)了很大的挑戰(zhàn)。并且，前端產(chǎn)品的一個(gè)請(qǐng)求所需要的數(shù)據(jù)往往不可能只從一個(gè)模塊獲取。

舉個(gè)例子，我們要在數(shù)據(jù)魔方中看昨天做熱銷(xiāo)的商品，首先從MyFOX中拿到一個(gè)熱銷(xiāo)排行榜的數(shù)據(jù)，但這里的“商品”只是一個(gè)ID，并沒(méi)有ID所

對(duì)應(yīng)的商品描述、圖片等數(shù)據(jù)。這個(gè)時(shí)候我們要從淘寶主站提供的接口中去獲取這些數(shù)據(jù)，然后一一對(duì)應(yīng)到熱銷(xiāo)排行榜中，最終呈現(xiàn)給用戶(hù)。

圖8 glider的技術(shù)架構(gòu)

有經(jīng)驗(yàn)的讀者一定可以想到，從本質(zhì)上來(lái)講，這就是廣義上的異構(gòu)“表”之間的JOIN操作。那么，誰(shuí)來(lái)負(fù)責(zé)這個(gè)事情呢？很容易想到，在存儲(chǔ)層與前

端產(chǎn)品之間增加一個(gè)中間層，它負(fù)責(zé)各個(gè)異構(gòu)“表”之間的數(shù)據(jù)JOIN和UNION等計(jì)算，并且隔離前端產(chǎn)品和后端存儲(chǔ)，提供統(tǒng)一的數(shù)據(jù)查詢(xún)服務(wù)。這個(gè)中間

層就是glider(如圖8所示)。

緩存是系統(tǒng)化的工程

除了起到隔離前后端以及異構(gòu)“表”之間的數(shù)據(jù)整合的作用之外，glider的另外一個(gè)不容忽視的作用便是緩存管理。上文提到過(guò)，在特定的時(shí)間段內(nèi)，我們認(rèn)為數(shù)據(jù)產(chǎn)品中的數(shù)據(jù)是只讀的，這是利用緩存來(lái)提高性能的理論基礎(chǔ)。

在圖8中我們看到，glider中存在兩層緩存，分別是基于各個(gè)異構(gòu)“表”(datasource)的二級(jí)緩存和整合之后基于獨(dú)立請(qǐng)求的一級(jí)緩

存。除此之外，各個(gè)異構(gòu)“表”內(nèi)部可能還存在自己的緩存機(jī)制。細(xì)心的讀者一定注意到了圖3中MyFOX的緩存設(shè)計(jì)，我們沒(méi)有選擇對(duì)匯總計(jì)算后的最終結(jié)果進(jìn)

行緩 存，而是針對(duì)每個(gè)分片進(jìn)行緩存，其目的在于提高緩存的命中率，并且降低數(shù)據(jù)的冗余度。

大量使用緩存的最大問(wèn)題就是數(shù)據(jù)一致性問(wèn)題。如何保證底層數(shù)據(jù)的變化在盡可能短的時(shí)間內(nèi)體現(xiàn)給最終用戶(hù)呢？這一定是一個(gè)系統(tǒng)化的工程，尤其對(duì)于分層較多的系統(tǒng)來(lái)說(shuō)。

圖9 緩存控制體系

圖9向我們展示了數(shù)據(jù)魔方在緩存控制方面的設(shè)計(jì)思路。用戶(hù)的請(qǐng)求中一定是帶了緩存控制的“命令”的，這包括URL中的query

string，和

HTTP頭中的“If-None-Match”信息。并且，這個(gè)緩存控制“命令”一定會(huì)經(jīng)過(guò)層層傳遞，最終傳遞到底層存儲(chǔ)的異構(gòu)“表”模塊。各異構(gòu)“表”

除了返回各自的數(shù)據(jù)之外，還會(huì)返回各自的數(shù)據(jù)緩存過(guò)期時(shí)間(ttl)，而glider最終輸出的過(guò)期時(shí)間是各個(gè)異構(gòu)“表”過(guò)期時(shí)間的最小值。這一過(guò)期時(shí)間

也一定是從底層存儲(chǔ)層層傳遞，最終通過(guò)HTTP頭返回給用戶(hù)瀏覽器的。

緩存系統(tǒng)不得不考慮的另一個(gè)問(wèn)題是緩存穿透與失效時(shí)的雪崩效應(yīng)。緩存穿透是指查詢(xún)一個(gè)一定不存在的數(shù)據(jù)，由于緩存是不命中時(shí)被動(dòng)寫(xiě)的，并且出于容錯(cuò)考慮，如果從存儲(chǔ)層查不到數(shù)據(jù)則不寫(xiě)入緩存，這將導(dǎo)致這個(gè)存在的數(shù)據(jù)每次請(qǐng)求都要到存儲(chǔ)層去查詢(xún)，失去了緩存的意義。

有很多種方法可以有效地解決緩存穿透問(wèn)題，最常見(jiàn)的則是采用布隆過(guò)濾器，將所有可能存在的數(shù)據(jù)哈希到一個(gè)足夠大的bitmap中，一個(gè)一定不存

在的數(shù)據(jù)會(huì)被這個(gè)bitmap攔截掉，從而避免了對(duì)底層存儲(chǔ)系統(tǒng)的查詢(xún)壓力。在數(shù)據(jù)魔方里，我們采用了一個(gè)更為簡(jiǎn)單粗暴的方法，如果一個(gè)查詢(xún)返回的數(shù)據(jù)為

空(不管是數(shù)據(jù)不存在，還是系統(tǒng)故障)，我們?nèi)匀话堰@個(gè)空結(jié)果進(jìn)行緩存，但它的過(guò)期時(shí)間會(huì)很短，最長(zhǎng)不超過(guò)五分鐘。

緩存失效時(shí)的雪崩效應(yīng)對(duì)底層系統(tǒng)的沖擊非常可怕。遺憾的是，這個(gè)問(wèn)題目前并沒(méi)有很完美的解決方案。大多數(shù)系統(tǒng)設(shè)計(jì)者考慮用加鎖或者隊(duì)列的方式保

證緩存的單線程(進(jìn)程)寫(xiě)，從而避免失效時(shí)大量的并發(fā)請(qǐng)求落到底層存儲(chǔ)系統(tǒng)上。在數(shù)據(jù)魔方中，我們?cè)O(shè)計(jì)的緩存過(guò)期機(jī)制理論上能夠?qū)⒏鱾€(gè)客戶(hù)端的數(shù)據(jù)失效時(shí)

間均 勻地分布在時(shí)間軸上，一定程度上能夠避免緩存同時(shí)失效帶來(lái)的雪崩效應(yīng)。

結(jié)束語(yǔ)

正是基于本文所描述的架構(gòu)特點(diǎn)，數(shù)據(jù)魔方目前已經(jīng)能夠提供壓縮前80TB的數(shù)據(jù)存儲(chǔ)空間，數(shù)據(jù)中間層glider支持每天4000萬(wàn)的查詢(xún)請(qǐng)求，平均響應(yīng)時(shí)間在28毫秒(6月1日數(shù)據(jù))，足以滿足未來(lái)一段時(shí)間內(nèi)的業(yè)務(wù)增長(zhǎng)需求。

盡管如此，整個(gè)系統(tǒng)中仍然存在很多不完善的地方。一個(gè)典型的例子莫過(guò)于各個(gè)分層之間使用短連接模式的HTTP協(xié)議進(jìn)行通信。這樣的策略直接導(dǎo)致

在流量高峰期單機(jī)的TCP連接數(shù)非常高。所以說(shuō)，一個(gè)良好的架構(gòu)固然能夠在很大程度上降低開(kāi)發(fā)和維護(hù)的成本，但它自身一定是隨著數(shù)據(jù)量和流量的變化而不斷

變化的。我相信，過(guò)不了幾年，淘寶數(shù)據(jù)產(chǎn)品的技術(shù)架構(gòu)一定會(huì)是另外的樣子。

原文： http://kb.cnblogs.com/page/110840/

總結(jié)

以上是生活随笔為你收集整理的python爬取淘宝数据魔方_淘宝数据魔方技术架构解析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。