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