淘寶網(wǎng)擁有國內(nèi)最具商業(yè)價值的海量數(shù)據(jù)。截至當(dāng)前，每天有超過30億的店鋪、商品瀏覽記錄，10億在線商品數(shù)，上千萬的成交、收藏和評價數(shù)據(jù)。如何從這些數(shù)據(jù)中挖掘出真正的商業(yè)價值，進而幫助淘寶、商家進行企業(yè)的數(shù)據(jù)化運營，幫助消費者進行理性的購物決策，是淘寶數(shù)據(jù)平臺與產(chǎn)品部的使命。
為此，我們進行了一系列數(shù)據(jù)產(chǎn)品的研發(fā)，比如為大家所熟知的量子統(tǒng)計、數(shù)據(jù)魔方和淘寶指數(shù)等。盡管從業(yè)務(wù)層面來講，數(shù)據(jù)產(chǎn)品的研發(fā)難度并不高；但在 “海量”的限定下，數(shù)據(jù)產(chǎn)品的計算、存儲和檢索難度陡然上升。本文將以數(shù)據(jù)魔方為例，向大家介紹淘寶在海量數(shù)據(jù)產(chǎn)品技術(shù)架構(gòu)方面的探索。
淘寶海量數(shù)據(jù)產(chǎn)品技術(shù)架構(gòu)
數(shù)據(jù)產(chǎn)品的一個最大特點是數(shù)據(jù)的非實時寫入，正因為如此，我們可以認為，在一定的時間段內(nèi)，整個系統(tǒng)的數(shù)據(jù)是只讀的。這為我們設(shè)計緩存奠定了非常重要的基礎(chǔ)。
圖1 淘寶海量數(shù)據(jù)產(chǎn)品技術(shù)架構(gòu)
按照數(shù)據(jù)的流向來劃分，我們把淘寶數(shù)據(jù)產(chǎn)品的技術(shù)架構(gòu)分為五層（如圖1所示），分別是數(shù)據(jù)源、計算層、存儲層、查詢層和產(chǎn)品層。位于架構(gòu)頂端的是我們的數(shù)據(jù)來源層，這里有淘寶主站的用戶、店鋪、商品和交易等數(shù)據(jù)庫，還有用戶的瀏覽、搜索等行為日志等。這一系列的數(shù)據(jù)是數(shù)據(jù)產(chǎn)品最原始的生命力所在。
在數(shù)據(jù)源層實時產(chǎn)生的數(shù)據(jù)，通過淘寶主研發(fā)的數(shù)據(jù)傳輸組件DataX、DbSync和Timetunnel準實時地傳輸?shù)揭粋€有1500個節(jié)點的Hadoop集群上，這個集群我們稱之為“云梯”，是計算層的主要組成部分。在“云梯”上，我們每天有大約40000個作業(yè)對1.5PB的原始數(shù)據(jù)按照產(chǎn)品需求進行不同的MapReduce計算。這一計算過程通常都能在凌晨兩點之前完成。相對于前端產(chǎn)品看到的數(shù)據(jù)，這里的計算結(jié)果很可能是一個處于中間狀態(tài)的結(jié)果，這往往是在數(shù)據(jù)冗余與前端計算之間做了適當(dāng)平衡的結(jié)果。
不得不提的是，一些對實效性要求很高的數(shù)據(jù)，例如針對搜索詞的統(tǒng)計數(shù)據(jù)，我們希望能盡快推送到數(shù)據(jù)產(chǎn)品前端。這種需求再采用“云梯”來計算效率將是比較低的，為此我們做了流式數(shù)據(jù)的實時計算平臺，稱之為“銀河”。“銀河”也是一個分布式系統(tǒng)，它接收來自TimeTunnel的實時消息，在內(nèi)存中做實時計算，并把計算結(jié)果在盡可能短的時間內(nèi)刷新到NoSQL存儲設(shè)備中，供前端產(chǎn)品調(diào)用。
容易理解，“云梯”或者“銀河”并不適合直接向產(chǎn)品提供實時的數(shù)據(jù)查詢服務(wù)。這是因為，對于“云梯”來說，它的定位只是做離線計算的，無法支持較高的性能和并發(fā)需求；而對于“銀河”而言，盡管所有的代碼都掌握在我們手中，但要完整地將數(shù)據(jù)接收、實時計算、存儲和查詢等功能集成在一個分布式系統(tǒng)中，避免不了分層，最終仍然落到了目前的架構(gòu)上。
為此，我們針對前端產(chǎn)品設(shè)計了專門的存儲層。在這一層，我們有基于MySQL的分布式關(guān)系型數(shù)據(jù)庫集群MyFOX和基于HBase的NoSQL存儲集群Prom，在后面的文字中，我將重點介紹這兩個集群的實現(xiàn)原理。除此之外，其他第三方的模塊也被我們納入存儲層的范疇。
存儲層異構(gòu)模塊的增多，對前端產(chǎn)品的使用帶來了挑戰(zhàn)。為此，我們設(shè)計了通用的數(shù)據(jù)中間層——glider——來屏蔽這個影響。glider以HTTP協(xié)議對外提供restful方式的接口。數(shù)據(jù)產(chǎn)品可以通過一個唯一的URL獲取到它想要的數(shù)據(jù)。
以上是淘寶海量數(shù)據(jù)產(chǎn)品在技術(shù)架構(gòu)方面的一個概括性的介紹，接下來我將重點從四個方面闡述數(shù)據(jù)魔方設(shè)計上的特點。
關(guān)系型數(shù)據(jù)庫仍然是王道
關(guān)系型數(shù)據(jù)庫（RDBMS）自20世紀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 Network Partitions）方面存在劣勢，但由于它強大的語義表達能力以及數(shù)據(jù)之間的關(guān)系表達能力，在數(shù)據(jù)產(chǎn)品中仍然占據(jù)著不可替代的作用。
淘寶數(shù)據(jù)產(chǎn)品選擇MySQL的MyISAM引擎作為底層的數(shù)據(jù)存儲引擎。在此基礎(chǔ)上，為了應(yīng)對海量數(shù)據(jù)，我們設(shè)計了分布式MySQL集群的查詢代理層——MyFOX，使得分區(qū)對前端應(yīng)用透明。
圖3 MyFOX的數(shù)據(jù)查詢過程
目前，存儲在MyFOX中的統(tǒng)計結(jié)果數(shù)據(jù)已經(jīng)達到10TB，占據(jù)著數(shù)據(jù)魔方總數(shù)據(jù)量的95%以上，并且正在以每天超過6億的增量增長著（如圖2所示）。這些數(shù)據(jù)被我們近似均勻地分布到20個MySQL節(jié)點上，在查詢時，經(jīng)由MyFOX透明地對外服務(wù)（如圖3所示）。
圖4 MyFOX節(jié)點結(jié)構(gòu)
值得一提的是，在MyFOX現(xiàn)有的20個節(jié)點中，并不是所有節(jié)點都是“平等”的。一般而言，數(shù)據(jù)產(chǎn)品的用戶更多地只關(guān)心“最近幾天”的數(shù)據(jù)，越早的數(shù)據(jù)，越容易被冷落。為此，出于硬件成本考慮，我們在這20個節(jié)點中分出了“熱節(jié)點”和“冷節(jié)點”（如圖4所示）。
顧名思義，“熱節(jié)點”存放最新的、被訪問頻率較高的數(shù)據(jù)。對于這部分數(shù)據(jù)，我們希望能給用戶提供盡可能快的查詢速度，所以在硬盤方面，我們選擇了每分鐘15000轉(zhuǎn)的SAS硬盤，按照一個節(jié)點兩臺機器來計算，單位數(shù)據(jù)的存儲成本約為4.5W/TB。相對應(yīng)地，“冷數(shù)據(jù)”我們選擇了每分鐘7500轉(zhuǎn)的SATA硬盤，單碟上能夠存放更多的數(shù)據(jù)，存儲成本約為1.6W/TB。
將冷熱數(shù)據(jù)進行分離的另外一個好處是可以有效降低內(nèi)存磁盤比。從圖4可以看出，“熱節(jié)點”上單機只有24GB內(nèi)存，而磁盤裝滿大約有1.8TB（300 * 12 * 0.5 / 1024），內(nèi)存磁盤比約為4:300，遠遠低于MySQL服務(wù)器的一個合理值。內(nèi)存磁盤比過低導(dǎo)致的后果是，總有一天，即使所有內(nèi)存用完也存不下數(shù)據(jù)的索引了——這個時候，大量的查詢請求都需要從磁盤中讀取索引，效率大打折扣。
NoSQL是SQL的有益補充
在MyFOX出現(xiàn)之后，一切都看起來那么完美，開發(fā)人員甚至不會意識到MyFOX的存在，一條不用任何特殊修飾的SQL語句就可以滿足需求。這個狀態(tài)持續(xù)了很長一段時間，直到有一天，我們碰到了傳統(tǒng)的關(guān)系型數(shù)據(jù)庫無法解決的問題——全屬性選擇器（如圖5所示）。
圖5 全屬性選擇器
這是一個非常典型的例子。為了說明問題，我們?nèi)匀灰躁P(guān)系型數(shù)據(jù)庫的思路來描述。對于筆記本電腦這個類目，用戶某一次查詢所選擇的過濾條件可能包括 “筆記本尺寸”、“筆記本定位”、“硬盤容量”等一系列屬性（字段），并且在每個可能用在過濾條件的屬性上，屬性值的分布是極不均勻的。在圖5中我們可以看到，筆記本電腦的尺寸這一屬性有著10個枚舉值，而“藍牙功能”這個屬性值是個布爾值，數(shù)據(jù)的篩選性非常差。
在用戶所選擇的過濾條件不確定的情況下，解決全屬性問題的思路有兩個：一個是窮舉所有可能的過濾條件組合，在“云梯”上進行預(yù)先計算，存入數(shù)據(jù)庫供查詢；另一個是存儲原始數(shù)據(jù)，在用戶查詢時根據(jù)過濾條件篩選出相應(yīng)的記錄進行現(xiàn)場計算。很明顯，由于過濾條件的排列組合幾乎是無法窮舉的，第一種方案在現(xiàn)實中是不可取的；而第二種方案中，原始數(shù)據(jù)存儲在什么地方？如果仍然用關(guān)系型數(shù)據(jù)庫，那么你打算怎樣為這個表建立索引？
這一系列問題把我們引到了“創(chuàng)建定制化的存儲、現(xiàn)場計算并提供查詢服務(wù)的引擎”的思路上來，這就是Prometheus（如圖6所示）。
圖6 Prom的存儲結(jié)構(gòu)
從圖6可以看出，我們選擇了HBase作為Prom的底層存儲引擎。之所以選擇HBase，主要是因為它是建立在HDFS之上的，并且對于MapReduce有良好的編程接口。盡管Prom是一個通用的、解決共性問題的服務(wù)框架，但在這里，我們?nèi)匀灰匀珜傩赃x擇為例，來說明Prom的工作原 理。這里的原始數(shù)據(jù)是前一天在淘寶上的交易明細，在HBase集群中，我們以屬性對（屬性與屬性值的組合）作為row-key進行存儲。而row-key 對應(yīng)的值，我們設(shè)計了兩個column-family，即存放交易ID列表的index字段和原始交易明細的data字段。在存儲的時候，我們有意識地讓每個字段中的每一個元素都是定長的，這是為了支持通過偏移量快速地找到相應(yīng)記錄，避免復(fù)雜的查找算法和磁盤的大量隨機讀取請求。
圖7 Prom查詢過程
圖7用一個典型的例子描述的Prom在提供查詢服務(wù)時的工作原理，限于篇幅，這里不做詳細描述。值得一提的是，Prom支持的計算并不僅限于求和SUM運算，統(tǒng)計意義上的常用計算都是支持的。在現(xiàn)場計算方面，我們對Hbase進行了擴展，Prom要求每個節(jié)點返回的數(shù)據(jù)是已經(jīng)經(jīng)過“本地計算”的局部最優(yōu)解，最終的全局最優(yōu)解只是各個節(jié)點返回的局部最優(yōu)解的一個簡單匯總。很顯然，這樣的設(shè)計思路是要充分利用各個節(jié)點的并行計算能力，并且避免大量明細數(shù)據(jù)的網(wǎng)絡(luò)傳輸開銷。
用中間層隔離前后端
上文提到過，MyFOX和Prom為數(shù)據(jù)產(chǎn)品的不同需求提供了數(shù)據(jù)存儲和底層查詢的解決方案，但隨之而來的問題是，各種異構(gòu)的存儲模塊給前端產(chǎn)品的使用帶來了很大的挑戰(zhàn)。并且，前端產(chǎn)品的一個請求所需要的數(shù)據(jù)往往不可能只從一個模塊獲取。
舉個例子，我們要在數(shù)據(jù)魔方中看昨天做熱銷的商品，首先從MyFOX中拿到一個熱銷排行榜的數(shù)據(jù)，但這里的“商品”只是一個ID，并沒有ID所對應(yīng)的商品描述、圖片等數(shù)據(jù)。這個時候我們要從淘寶主站提供的接口中去獲取這些數(shù)據(jù)，然后一一對應(yīng)到熱銷排行榜中，最終呈現(xiàn)給用戶。
圖8 glider的技術(shù)架構(gòu)
有經(jīng)驗的讀者一定可以想到，從本質(zhì)上來講，這就是廣義上的異構(gòu)“表”之間的JOIN操作。那么，誰來負責(zé)這個事情呢？很容易想到，在存儲層與前端產(chǎn)品之間增加一個中間層，它負責(zé)各個異構(gòu)“表”之間的數(shù)據(jù)JOIN和UNION等計算，并且隔離前端產(chǎn)品和后端存儲，提供統(tǒng)一的數(shù)據(jù)查詢服務(wù)。這個中間層就是glider（如圖8所示）。
緩存是系統(tǒng)化的工程
除了起到隔離前后端以及異構(gòu)“表”之間的數(shù)據(jù)整合的作用之外，glider的另外一個不容忽視的作用便是緩存管理。上文提到過，在特定的時間段內(nèi)，我們認為數(shù)據(jù)產(chǎn)品中的數(shù)據(jù)是只讀的，這是利用緩存來提高性能的理論基礎(chǔ)。
在圖8中我們看到，glider中存在兩層緩存，分別是基于各個異構(gòu)“表”（datasource）的二級緩存和整合之后基于獨立請求的一級緩存。除此之外，各個異構(gòu)“表”內(nèi)部可能還存在自己的緩存機制。細心的讀者一定注意到了圖3中MyFOX的緩存設(shè)計，我們沒有選擇對匯總計算后的最終結(jié)果進行緩 存，而是針對每個分片進行緩存，其目的在于提高緩存的命中率，并且降低數(shù)據(jù)的冗余度。
大量使用緩存的最大問題就是數(shù)據(jù)一致性問題。如何保證底層數(shù)據(jù)的變化在盡可能短的時間內(nèi)體現(xiàn)給最終用戶呢？這一定是一個系統(tǒng)化的工程，尤其對于分層較多的系統(tǒng)來說。
圖9 緩存控制體系
圖9向我們展示了數(shù)據(jù)魔方在緩存控制方面的設(shè)計思路。用戶的請求中一定是帶了緩存控制的“命令”的，這包括URL中的query string，和 HTTP頭中的“If-None-Match”信息。并且，這個緩存控制“命令”一定會經(jīng)過層層傳遞，最終傳遞到底層存儲的異構(gòu)“表”模塊。各異構(gòu)“表” 除了返回各自的數(shù)據(jù)之外，還會返回各自的數(shù)據(jù)緩存過期時間（ttl），而glider最終輸出的過期時間是各個異構(gòu)“表”過期時間的最小值。這一過期時間 也一定是從底層存儲層層傳遞，最終通過HTTP頭返回給用戶瀏覽器的。
緩存系統(tǒng)不得不考慮的另一個問題是緩存穿透與失效時的雪崩效應(yīng)。緩存穿透是指查詢一個一定不存在的數(shù)據(jù)，由于緩存是不命中時被動寫的，并且出于容錯考慮，如果從存儲層查不到數(shù)據(jù)則不寫入緩存，這將導(dǎo)致這個存在的數(shù)據(jù)每次請求都要到存儲層去查詢，失去了緩存的意義。
有很多種方法可以有效地解決緩存穿透問題，最常見的則是采用布隆過濾器，將所有可能存在的數(shù)據(jù)哈希到一個足夠大的bitmap中，一個一定不存在的數(shù)據(jù)會被這個bitmap攔截掉，從而避免了對底層存儲系統(tǒng)的查詢壓力。在數(shù)據(jù)魔方里，我們采用了一個更為簡單粗暴的方法，如果一個查詢返回的數(shù)據(jù)為空（不管是數(shù)據(jù)不存在，還是系統(tǒng)故障），我們?nèi)匀话堰@個空結(jié)果進行緩存，但它的過期時間會很短，最長不超過五分鐘。
緩存失效時的雪崩效應(yīng)對底層系統(tǒng)的沖擊非?？膳?。遺憾的是，這個問題目前并沒有很完美的解決方案。大多數(shù)系統(tǒng)設(shè)計者考慮用加鎖或者隊列的方式保證緩存的單線程（進程）寫，從而避免失效時大量的并發(fā)請求落到底層存儲系統(tǒng)上。在數(shù)據(jù)魔方中，我們設(shè)計的緩存過期機制理論上能夠?qū)⒏鱾€客戶端的數(shù)據(jù)失效時間均 勻地分布在時間軸上，一定程度上能夠避免緩存同時失效帶來的雪崩效應(yīng)。
結(jié)束語
正是基于本文所描述的架構(gòu)特點，數(shù)據(jù)魔方目前已經(jīng)能夠提供壓縮前80TB的數(shù)據(jù)存儲空間，數(shù)據(jù)中間層glider支持每天4000萬的查詢請求，平均響應(yīng)時間在28毫秒（6月1日數(shù)據(jù)），足以滿足未來一段時間內(nèi)的業(yè)務(wù)增長需求。
盡管如此，整個系統(tǒng)中仍然存在很多不完善的地方。一個典型的例子莫過于各個分層之間使用短連接模式的HTTP協(xié)議進行通信。這樣的策略直接導(dǎo)致在流量高峰期單機的TCP連接數(shù)非常高。所以說，一個良好的架構(gòu)固然能夠在很大程度上降低開發(fā)和維護的成本，但它自身一定是隨著數(shù)據(jù)量和流量的變化而不斷變化的。我相信，過不了幾年，淘寶數(shù)據(jù)產(chǎn)品的技術(shù)架構(gòu)一定會是另外的樣子。
樂發(fā)網(wǎng)超市批發(fā)網(wǎng)提供超市貨源信息,超市采購進貨渠道。超市進貨網(wǎng)提供成都食品批發(fā),日用百貨批發(fā)信息、微信淘寶網(wǎng)店超市采購信息和超市加盟信息.打造國內(nèi)超市采購商與批發(fā)市場供應(yīng)廠商搭建網(wǎng)上批發(fā)市場平臺,是全國批發(fā)市場行業(yè)中電子商務(wù)權(quán)威性網(wǎng)站。
本文內(nèi)容整合網(wǎng)站：百度百科、知乎、淘寶平臺規(guī)則
