聲明：
本文爲轉載（信息來源：三星應用社區-CSDN），文章標題爲本博自擬，與來源無關。本文僅作參考，如有版權問題，請與博主聯繫刪除。請勿轉載本文，因轉載導致的版權糾紛，與本博無關。
時至今日，“Big data”（大數據）時代的來臨已經毋庸置疑，尤其是在電信、金融等行業，幾乎已經到了“數據就是業務本身”的地步。這種趨勢已經讓很多相信數據之力量的企業做出改變。恰逢此時，爲了讓更多的人瞭解和使用分析大數據，CSDN獨家承辦的大數據技術大會於今日在北京中旅大廈召開。本次大會彙集Hadoop、NoSQL、數據分析與挖掘、數據倉庫、商業智能以及開源雲計算架構等諸多熱點話題。包括百度、淘寶、新浪等業界知名專家與參會者齊聚一堂，共同探討大數據浪潮下的行業應對法則以及大數據時代的抉擇。
淘寶核心系統存儲系統研發專家楊志豐表示淘寶每天大約有6000萬用戶登錄以及20億PV量。淘寶數據庫對於淘寶來說非常重要。幾乎所有淘寶業務都依賴淘寶數據庫。淘寶數據庫具備數以千計的數據庫服務器同時要應對單表幾億至幾百億條的記錄以及每天幾億至幾百億次訪問。
爲了應對大數據的衝擊，淘寶將以前的Oracle、小型機、高端存儲模式轉變到現今的MySQL、OceanBase、Hbase、MongoDB等數據庫，並使用普通PC服務器。楊志豐表示OceanBase可擴展數千億條記錄、數百TB數據、數十萬QPS以及數萬TPS。同時具備實時容錯、自動故障恢復和99.999%高可用性。
以下爲文字實錄：
大家好，我叫楊志豐，其實我們QceanBase的總架構師是楊振坤老師，名字很想象。很高興與大家分享一下我們淘寶的大數據解決之道，這個題目很大，我講的東西很具體，我們思路首先看看淘寶數據有多大，然後在淘寶數據裏面一大塊是在線結構化的存儲，這部分我們QceanBase這個系統就是解決其中的一個問題。這個問題一會我會着重落講，最後重點是在QceanBase這個系統上，希望我今天講完之後，大家能夠記住幾點，第一，淘寶數據有多大，第二，QceanBase的特點在什麼地方。
這幅圖上是淘寶網的年度交易額，淘寶成立於2003年，這是每年的交易額，基本上可以看到一年翻一番，有些年份略微不足一點，基本上是翻番的，就是指數增長。大家猜一下，淘寶現在每天的PV有多少，淘寶每天有6千萬用戶登錄，每天PV大約20億，這是alexa淘寶上流量，縱軸表示每天全球訪問互聯網的網民中有多少是訪問了淘寶，之後這個邊邊就是剛剛結束雙十一的促銷，馬上就上去了。淘寶有這麼多PV，每次頁面都要訪問後面數據庫幾十次。
我們運營人員需要很多報表，每一個發表都要分析幾T，甚至幾百T的數據。淘寶數據大概可以分成三塊，一個就是離線的數據，淘寶離線數據，其中一塊，我們存在Hadoop機羣裏面，有2千多個集羣，這裏面存了39P以上的數據，每天要運行4萬多個MapReduce，一方面產生各種運營報表，還有一些可能有利於我們賣家\開展運營。舉幾個例子，淘寶上最暢銷的手機價格區間，1千-2千塊錢。01年的什麼年貨最暢銷？糖果類。最後是什麼地方的人最愛吃大閘蟹，廣東，上海，這是一些離線數據。
另外一些在線數據，可以分成兩類，第一類非結構化的數據。非結構化數據，主要是圖片，以前的時候淘寶圖片都是賣家找一些，這種網盤了，都是外鏈，在外面面向外面網站，極大地影響了用戶體驗，後來淘寶一些大的賣家都可以把圖片存在淘寶裏面，這個數據目前有2700TB，他們都是存到淘寶自主研發TFS文件系統成本。
TFS文件系統，結構比較簡單，但是實時響應能力很好，實現同城熱備和同城備份。在線結構化數據，這部分數據是淘寶最核心的數據，包括商品庫，用戶庫，還有店鋪庫，還有一些評價庫等等，每一個庫可能就是一張大表，或者若干張表。舉一個例子，淘寶的商品庫，淘寶商品庫現在有，因爲我們商品庫裏面是分在線和已經下線商品，總共加起來有22億商品，峯值QPS是78K，TPS是2.7K，這是一個商品庫基本概況。
我們今天在具體一點講的是一個淘寶的收藏夾，這是用戶瀏覽商品，他如果喜歡這個寶貝就可以點擊收藏，用戶可以在自己收藏夾裏面看到所有收藏寶貝，這個寶貝可以按照價格，或者是它的收藏時間進行排序。另外後面有一個收藏人氣，這個寶貝被多少人收藏，這個信息對於賣家是非常重要的。收藏夾數據庫模型基本上很簡單，一個是寶貝的信息，包括每一個寶貝有一個唯一的ID，有它的價格，還有它的收藏人氣等等，還有其他一些屬性，這個我們叫做寶貝信息表。另外一個是收藏信息表，就是用戶ID和寶貝之間的關係，這個信息表現有65億記錄。
收藏夾這個應用對於數據庫是有非常大的挑戰，挑戰在什麼地方呢？首先，收藏夾的裏邊，每一個用戶可能會收藏上千條的寶貝，另外是一些熱門的寶貝，可能被十幾萬人收藏，其中價格和收藏人氣是隨時變化的。所以，每一個人在收藏的時候要實時把最新價格，或者人氣展現出來。另外還有一些其他應用要按照屬性進行排序。收藏夾每天有1.2億次人的訪問，這是平均，響應時間必須要求在100ms之內。
現在給大家簡單講一下收藏夾數據模型，左邊是一個收藏信息表，右邊是收藏寶貝表，收藏信息表裏面存了收藏寶貝，如果我們用關係數據庫去實現的話，他是一個很糟糕的情況，你的收藏寶貝表只能按照一種方法去做排序，用戶對於寶貝的收藏其實是一個隨機的。如果你想展現一個用戶所有收藏的寶貝，你是要去執行一個，對於收藏寶貝表是一個隨機的獨操作。剛纔提到性能指標，我們在100ms之內必須把這個結果返回，有些用戶可以收藏上千條寶貝，也就是說，你要在100ms之內完成上千次隨機讀，這個對於普通磁盤100ms，最好的磁盤只能做30次左右的隨機讀，1毫秒鐘不會超過300次。
所以，在這個應用對數據庫是一個非常大的挑戰。大家有經驗的就會想到，我能不能這麼做，我把剛纔左邊這個表和右邊的錶轉起來，存一個寬表，所謂寬表？就是說我們把寶貝的價格，人氣這些屬性都存到左邊這個表裏面去，這是一個很好的方案。但是，剛纔提到一個問題，用戶的收藏人氣是隨時會發生變化的，所以一旦你的寶貝屬性發生變化的時候，你對於左邊這個表來說要執行很多很多的修改操作，這個基本上很難實施完成。爲了解決，這個問題是QceanBase這個系統設計的初衷。
下面我們就引出QceanBase海量數據庫，剛纔講到淘寶數據庫，淘寶數據庫有一些特點，第一幾乎所有的淘寶業務都依賴於數據庫，因爲淘寶其實是從做數據庫開始的，最早的時候用MySQL，Oracle，這和其他很多互聯網公司不一樣。但是在電商這一塊很多都是這樣子的，淘寶的數據庫是數以千計數據庫服務器，他的數據量非常大，單表可能達到幾億到幾百億條數據，訪問量都是幾億到幾百億次訪問。
從最最懵懂的時候大家都是用MySQL開始，到最後就開始用Oracle，也許一個商業數據庫本質上是一個單機的系統。所以，就要用就開始用很多昂貴硬件，比如IBM小型機，還有一些EMC高端存儲，很大機櫃，這一很貴。第二，這種數據庫對運維人員來說是一個黑匣子，我們遇到問題只能求助於商業知識了。還有一個問題Oracle本身提供的默認分片，單個服務器承擔的數據量是有一個上線的，他本身分片對性能會有很大影響。對於數據庫的選型基本上是百花齊放，一個主要潮流，很多以前用Oracle的，如果你現在允許的話，儘量使用MySQL，還有QceanBase，還有Hbase，QceanBase是我們自主研發的系統，目前有很多應用在，最大系統就是我們剛纔講的收藏夾。如果要用MySQL傳統DPS去支持一個大的訪問量，大家都知道分庫和分表，你把數據庫根據你的組件分成好多小表，存在MySQL裏面，MySQL本身又提供備份，所以在換屆訪問量大的挑戰方面，這是一個解決的辦法。但是，這種一般分庫分表都需要應用業務來介入，比如說，實際上對應用來說不需要關心你下面，如果你的業務增長了，本來對應用應該沒有任何影響的，這種分庫分表對他們可見的話，這種分庫分表的邏輯都需要寫在應用裏面，業務邏輯要支持。
另外是擴展性的問題，我們說到分庫分表一般是用原來的解決方案，你要考慮到擴容，就要除以20，想到以後要變成20臺機器，就除以20。但是把它存到10臺機器上面，我們擴容都是機器要翻倍的，QceanBase這樣系統本身是單機系統，在做容錯方面需要很多人工介入。縱軸表示數據規模，一般DPS數據規模是千萬量級的，好的QceanBase數據庫一般都是千億到萬億量級的。但是，Hbase和Bigtable是支持單行，對於互聯網一些應用是支持的，對於淘寶的很多應用是不夠的。所以，他們兩個優劣，其中一個優點就是另一個缺點。理論上你的數據規模上去了，或者性能要求上去了，你就只需要加機器就可以了。
當然還有一個解決分佈式事務系統，在這個上面可以支持萬億事務，跨行跨表，因爲是搭在QceanBase上面，並且本身解決是分佈式事務的問題。所以，QceanBase我們希望找一個點，我們要提供跨行跨表的事務，在這方面像傳統DBMS看齊。但在可擴展性方面，希望找到一個折中點，我們提供不了那麼高的數據量，但是我們要比傳統DBMS要支持的數據量更大。
剛纔那個點，QceanBase的設計目標第一要提供千億級量級記錄數，我們假設每條記錄是1K的話就是數百TB數據，數十萬QPS，數萬TBS，要支持ACID完整的事務。因爲我們內部有很多要求，所以我們支持的範圍查詢，我們提供實時容錯，自動故障恢復，自動負載均衡，實現5個9的可用性，要實現普通PC服務器能做，不需要特別貴的硬件。
大家都說我們數據量很大，但是你每天更新的數據，其實沒那麼大。可能你說你有100T的數據，但是你更新的數據，每天能更新的數據不到1%。我們就沒有必要爲了這1%而去說，我們數據可以看作兩部分組成，一個是基準數據，一個就是增量數據，1%就是增量數據，我們可以對於基準數據和增量數據採用不同做法，不同的體系結構去做。
基準的數據我們使用分佈式的存儲，把他向QceanBase系統一樣分成很多片，分佈到一個分佈式存儲裏面去，他是一個靜態B+樹作用。增量數據，我們實現一個單點來實現，這是他設計最獨到的地方。下面我就圍繞這幅圖來講一下，最左邊是一個客戶端，然後我們系統裏面有四個角色，第一個是叫RootServer，剛纔說到靜態數據，是要把整個大數據分成很多很多片的，這些分片的位置信息，我們叫做原數據，這個原數據其實是一個數的根接點，這個根接點是存在RootServer上，同時在這些機器上還有一個UpdateServer，增量數據。這個RootServer跟UpdateServer做了準備，邏輯上是一個點。
ChunkServer，是把靜態數據劃成片之後，每一個小塊有若干個輔本存到這個上面去。所以，這上面UpdateServer是所有的寫，所有讀是通過這個MergeServer而，一個查詢請求來了之後，他首先要從本地ChunkServer把基本數據讀一下，把這個區間之內新增增量數據給我，提供進行讀事務。這個前面也說了基準數據是一個靜態的B+樹，這個樹的比價點是存在RootServer，他存在與若干臺輔本，這個Tablet就是在其上面的一個輔本。
增量數據存儲方式，不是存到硬盤上，是完全存在內存裏的，這是邏輯上是完全存在內存裏的。數據分成基準數據和增量數據之後，增量數據每天都在增加，你必須合到基準數據裏面去，這個做法有總控的節點，通知這些ChunkServer，我們會選擇一個低負載時段，淘寶數據很明顯，因爲我們用戶都是在一個地域之內的，所以他有一個明顯的高分和低谷，在低谷的時候我們用一些低優先級方式去進行合併操作，這個合併操作是這樣做的？我們數據不管是基準數據，還是增量數據都有一個版本號。比如最開始的時候，這個基準數據版本是1，我對應於這個基準數據這個增量數據版本是2，要開始合併了，合併的時候就把這部分數據給RootServer發一個命令，凍結之後就不能改了，如果凍結這個點做完之後又有新的數據來了，這就是一個新的版本，這個點做完之後，就通知所有ChunkServer，我現在數據是1恩，我要所有版本等於2的數據，你把那部分數據給我，這個過程我們叫做基準數據更新，這個更新，所有ChunkServer，去RootServer去要增量數據，將整個過程做完之後，就可以把這部分的增量數據從內存中釋放掉了。
所以，會存在一個時刻，一個很多副本，同一個版本數據必須是一模一樣的。這樣一個單點結構，肯定就會有質疑，你的性能是怎樣的，UpdataServer是用一個內存實現，不考慮後面要寫日誌，我們使用Copy的技術，你在修改的時候先拷貝出來，這個B樹有一個特點，你的一些讀操作。基於內存實現，我們先不考慮爲了數據持久性要寫日誌，光這個內存實現，他的性能是每秒鐘10萬次修改，每秒鐘100萬次讀操作。但是這樣肯定是不夠的，你每次修改之後，都要給用戶返回成功之前要保證這個數據實際上已經持久化了，我們實際上是寫了一個操作做的事情先記到日誌裏面，然後去做修改操作，修改操作做完了，這個日誌要同時傳過去，那邊也寫到紙板上我們才說成功了。不需要每一個操作日誌都寫，因爲磁盤有限，你等10ms可以拒絕幾十個，幾百個請求了，打包成一個日誌寫進去，這個技術叫做Group commit，下面用的有RAID卡，RAID卡是帶電池的，一旦寫給他，從軟件角度來看放心就可以了。
剛纔說到所有讀操作，每次讀操作都要經過UpdateServer，即使你數據沒有了，沒有一個更新數據也要去問他，這對網絡帶寬是一個很大壓力。我們現在UpdateServer用的是萬兆網卡，所有修改都是放在內存裏面，如果內存放不下怎麼辦，我們會轉儲到本地SSD裏面去。我們磁盤有兩種，存儲有兩種系統，一個是磁盤，一個是SSD，SSD是把內存整個結合進去，如果有了讀操作落到這部分，因此宕不出去內容裏面，就從SSD上去讀，SSD可以提供很好的隨機讀的性能。
如果是單機部署的話，每一個數據是有三個輔本，我們實現了多機羣部署，各集羣可以提供位於不同機房，這兩個機房有一個是同城，還有異地做災備的，如果同城兩個之間需要同步，每一個機房裏面只需要保存兩個副本就可以了，如果有遠程的災備就是2+2+2的模式。所有數據都是有校驗，一個重要特性，因爲我們系統初期可能會頻繁有升級，我們現在已經可以做到升級，或者你要切換的時候不停機。如果一個應用他同時部署兩個集羣，那麼他可以先把一個停掉，把另外一個變成主，然後你把那邊升級好之後再接上來，這樣倒一下就可以把整個系統升級了。
收藏夾應用在半年多前上線，我剛纔給大家講的收藏信息表，裏面有65億條記錄，每天有1.2億次訪問，我們平均響應時間大約在80毫秒左右。在使用QceanBase之前，我們是有16臺機器，現在已經降到，使用QceanBase之後只需要6臺機器就可以支撐同樣的訪問量。這是我們實際運行的一個監控圖，給大家一個直觀的概念，這是每一天訪問量，大概在晚上有一個高峯，在高峯的時候大概700，800左右。這是查詢，這是平均響應時間，可以看到平均響應時間是在80毫秒左右。
剛剛結束的世紀光棍節，我們叫雙十一網購狂歡節，就在那一天，我們整個收藏夾總庫量是170億條，一天有1.85億次更新操作，查詢有兩種，scan是順序讀，get可以看成一個隨機讀，分別達到2.3億和2.9億次。峯值QPS是9000+5000，一共14000次。
下一步工作裏面第一個是SSD，最新數據可以號稱達到100萬次隨機讀。ChunkServer有一個特點，沒有隨機寫，對於SSD來說，表面上比較怕隨機寫，我們ChunkServer沒有隨機寫，我們把這個也改成ChunkServer使用SSD單機QPS可以達到5萬次，雖然你多花了一點錢，但是你的機器數降下來了。使用SSD之後，我們由14臺機器變成6臺。
另外一塊是OLAP，從我們系統角度來看，剛纔已經給大家說了，在收藏夾裏面主要是UpdataServer，OLAP對於UpdateServer沒有多大差別，但是有一些BI用的比較複雜的查詢，實際上現在我們已經實現了，現在基於這麼一個SQL的依據，SELECT，FROM，WHERE，還有GROUP BY聚合請求，還有一個符合鏈，都是已經支持的。這部分支持主要是剛纔講的那四個方面功能點，對於其他模塊沒有什麼影響。
比如現在收藏夾裏面都有很多數據，要從線上數據庫裏面導出，導出Hadoop機羣裏面做計算，結算完之後再倒回來，對於數據倒來倒去是非常耗帶寬，可能會影響其他利用。我們希望能不能把MapReduce和我們本身QceanBase結合到一起。做法其實很簡單，首先Hadoop機羣本身和QceanBase處於一個機羣，另外去定製MapReduce程序的輸入輸出，這個已經在開發中了。
QceanBase現在不足，主要是功能上的一些問題。比如不支持，只實現部分的join，沒有實現一些高級特性。比如說一個缺陷，不支持輔助索引，這是很多問題。我們做QceanBase是一個非常開放的心態，我們所有代碼都是開源的，包括設計文檔，我們每次有一個新的版本，在內部
升級完之後，都是把它立即更新到開源的網站上去。在淘蝌蚪上還有很多淘寶核心系統部做的很多系統，比如存儲圖片還有，還有一些其他服務。
我們總結一下，今天講的兩個問題，第一希望大家記住淘寶的離線數據有39T，圖片有2700T，商品有14億+8億，下線的和在線的。
QceanBase最大的特點是把基準數據和增量數據分開，把讀事務和寫事務分開，這是QceanBase最大的特點，謝謝大家。