技術領域—海量存儲計算

PB時代的來臨

Petabyte，2的50次方個字節。這個對很多人還是很陌生的計量單位，已經變得越來越普遍和觸手可及。2004年8月，GOOGLE日常任務輸入的數據已經達到了3PB ；2005年Mark Hurd從Teradata來到HP出任CEO，開始建設基於Neo View的8PB的HP EDW。2006年，YAHOO構建了世界上第一個基於ORACLE RAC的PB級別數據中心。2007年9月，GOOGLE的日常任務的輸入數量膨脹到403個PB，而輸出文件的尺寸也達到了14PB。2008年6月，wired雜誌刊登標題爲The Petabyte Age的文章，不僅是互聯網行業，越來越多的傳統行業公司的數據中心也開始達到PB的數據量級。時至今日，最近看到的一個新聞是一家名爲Zynga的社會遊戲公司在2010年的 Oracle Open World 上宣佈，他們每天的數據淨增量達到了1個PB，每個禮拜需要新增1000臺服務器存儲這些數據。

再來看看我們自己公司內部的情況，基於hadoop的雲梯一羣集已經達到了1400臺服務器的規模。越來越多的用戶和業務數據被記錄在案，10億條記錄，只能存放B2B中文站2天的頁面曝光訪問(CTR)記錄。在這樣一個數據不斷膨脹的時代中，數據已經如洪水般洶涌氾濫。數據查找和調用困難，一些用戶提出申請之後往往要等到第二天才能得知結果，直接影響到了用戶滿意度的提升和新業務的佈局。在技術上，我們需要一個怎樣的技術基礎架構，才能夠滿足數據量的不斷膨脹下的計算和存儲需求。而當我們解決了最基礎的數據量和計算能力這個溫飽問題後，開始把目光移向數據服務、數據價值的時候，我們又需要怎樣的技術基礎架構，能夠將如此海量的數據提供對外的服務，將我們對數據的認識直接轉換爲數據的產品併爲我們的最終客戶帶來真正的價值？

THE NOSQL MOVEMENT

在談論我們的技術基礎架構前，我還想先花點時間談談最近非常熱的NOSQL。對於大多數開發人員而言，NOSQL更多時候意味着Say NO to SQL，或者Non-Schematic。傳統的關係數據庫模型和應用代碼對象模型通常是以不同方式建立起來的，這導致開發人員需要將代碼映射到關係模型去克服這種不兼容性。這個過程被稱爲對象/關係映射。而基於K/V的方式天生是基於對象的，相比基於關係模型和Schema的RDBMS更爲簡潔（對象/關係 VS 序列化/反序列化）；底層代碼中的對象類的映射關係比對象/關係映射要直接得多。這種簡潔的開發模式對於很多相對明確簡單的業務場景，很大程度上提高了開發人員的效率，顯著減少了開發時間。

對於很多系統架構師而言，在數據量如此膨脹的今天，一個必須要考慮的特性是系統的可伸縮性（Scalability），這個特性正變的越來越重要，以至於在重要性程度方面已經開始凌駕，甚至侵蝕其他系統特性。RDBMS經過20多年的歷史，數據一體化管理和分析已經發展的非常成熟了。RDBMS爲數據庫用戶提供了簡單、健壯、靈活以及兼容性的組合，但它在其中每個領域裏的性能，不一定就優於其他追求某一項好處的獨立替代方案[1]。在系統的可伸縮性上，RDBMS傳統的方案是向上擴展（Scale Up），但通常只能單臺服務器節點上進行（或者是在單組存儲上水平擴展）。Scale Up的方案操作簡單,但是規模有限,代價越來越大。即便拋開Scale Up的價格和規模問題，對可伸縮性的需求，可能會變化得非常迅速和龐大。如果你的系統負載一夜之間翻倍，你能在多少時間內完成硬件升級？這一特點使得RDBMS在大型應用場景被大幅限制，唯一的可選方案是Scale Out,通過增加多個邏輯單元的資源,並使它們如同一個集中的資源那樣提供服務來實現系統的擴展性。Sharding是一種scale out的擴展方法，但目前還沒有非常成功的Sharding框架，關係數據庫的複雜性開始影響Scale Out所能達到的潛在的擴展規模。當試圖擴展到成百上千個節點（而不是幾個）的時候將導致系統的複雜性不堪重負。

如同google倡導的那樣，The Data center as a Computer。對於一個從來沒有見過PB的數據量，上千臺機器的新人工程師，系統的擴展性要求能讓他像在單機上一樣開發。在這種情況下，基於分佈式、具有擴展性的鍵值存儲處理模式逐漸出現，爲此甚至會而犧牲掉關係數據庫所帶來的其他好處。使用大量且相對廉價的機器作爲存儲與計算結點以解決海量數據環境下的昂貴的硬件成本問題；採用鍵/值對(key/value pair的泛型結構)存儲，系統提供基本get(key),put(key, value),delete(key)等數據訪問接口；所有的數據都被看做是鍵/值對，這使得整個系統模型非常簡單，大多數系統採用“一致性哈希”（Consistent Hashing）來實現數據（鍵/值對）的羣集分佈、快速定位查找以及動態擴展時減少需要重新分佈的虛擬節點的數目。數據在結點上存在分割與冗餘，保證高可用性及性能；同時犧牲部分的數據一致性要求實現數據的高可用性和分區容錯性。根據CAP theorem，數據的一致性、高可用性和數據分佈三個方面是相互制約的，不可能同時達到最好。

萬能的鑰匙？

鍵/值對是面向於對象的，所有該對象的數據都能隨時被被存儲進該項目中。這個模型允許一個單一的項目包含完所有相關數據，以此消除對多表的數據連接的需求來擴充能滿足的業務場景。而在關係數據庫中，數據需要被聯接到一起，以便能重組爲相關屬性。對於數據的整合，這樣一個稀疏存儲(sparse storage)的數據模型是相當合適的，我們可以把來自不同業務系統的數據，根據統一個對象實體的KEY值放置入同一個數據域中。比如Member的信息，我們可以把來自網站的，CRM的，P4P的不同的源系統的Member信息按照同一個Key值整合到同一個對象實體中，利用Non-Schematic的特性實現用戶屬性的任意增刪，從而構造一張超級的大寬表，整合了該用戶的所有屬性。

雖然在關係數據庫中的需求在鍵/值數據庫已大爲減少，但是有些東西（關係聯接）還是不可避免。那些關係一般存在於核心實體之間。比如說，用戶的產品（Product/Offer）、訂單（Order）、反饋（Feedback）和用戶信息表(Member)之間的關係。一個用戶會擁有多個產品，訂單，反饋。在描述一個用戶所擁有的產品，訂單和反饋的時候，是沒有無法將所有這些產品，訂單，反饋的屬性信息都寫入到用戶的屬性表中（雖然在技術上可以用多個嵌套表或者Super Column Family來實現），在這個時候，兩個實體對象之間的Join不可避免。

當我們在一個鍵/值對的平臺上積累彙總並整合來自各個業務系統的用戶數據，而且通過鍵/值對的方式，你已經可以對外提供基於某個KEY（比如某個用戶）的海量併發訪問，同時獲得極強的系統可伸縮性。現在你想爲客戶創造新價值，或者還想利用這些數據產生新的收入。你就會發現自己被嚴重限制了，甚至連直接的分析型查詢都很困難。在鍵/值對存儲的平臺上，類似追蹤（用戶的）使用模式、基於用戶歷史提供建議等事情，即便不是不可能也是非常困難的。當需要進行數據的範圍查找，多個搜索條件的合併這些情況下，這些應用對於RDBMS來說並不是太大的問題的問題，但是因爲NoSQL DB“分佈式框架”本身的特性，使得鍵/值對平臺中並不能很好支持範圍檢索（包括非等值比較），集合和針對集合的多個布爾表達式（Union/And/Or…）等等操作。雖然有一些技術手段(比如分佈式二級B樹索引，前置哈希索引，全文倒排索引)可以部分解決這些查詢問題，你會發現必須在系統中引入了越來越多複雜的機制來實現這些功能，實現的成本是巨大的，並導致整個系統的複雜度因此大大增加。結果，你將不得不從鍵/值數據庫中分離出來的，建立一個獨立的分析型數據庫，以便執行那樣的分析。你該在哪裏才能做這樣的事情？又該如何去做？歸根結底，雖然規模和可伸縮性是一項重要考慮因素，但不要把它排在使用數據，將數據轉換成爲資產的能力的前面。如果你的系統中沉澱的數據無法給用戶帶來真正的價值，這世上的一切伸縮性都將一無是處[1]。

接下來就公司目前使用的幾種不同類型的系統談談個人看法：

基於鍵/值的分佈式存儲

分佈式鍵/值存儲目前在B2B使用的比較廣泛的Cassandra，包括國際站，CRM,DW目前都在使用。Cassandra它在設計上整合了Google Big table和Amazon的 Dynamo優點的系統，在系統的設計上有很多的可取之處。一方面繼承了Dynamo在集羣方面的技術，另一方面又借鑑了Bigtable的數據模型，這使得Cassandra區別於Dynamo單純的key/value結構，具有更豐富的數據表現形式。Cassandra系統架構中一個閃亮的發光點是全對稱設計，沒有master節點的單點故障（相對而言，hadoop的hdfs的name node的單故障點目前還沒有一個太好的解決方案）。Cassandra採用Gossip 協議主要用來管理集羣會員信息，通訊效率非常高,只需要Log(N)回合就可以將狀態傳遞給集羣的N個節點，每隔T秒,每個節點都會自增自己的Heartbeat信息並通過Gossip傳遞給其他節點。

另一個顯著的優點是，雖然Cassandra被設計爲一個AP的系統，但是Cassandra允許你根據實際的需要來滿足不同的系統特性。如果系統要求必須100%的讀取到之前寫入的內容，可以將Consistency Level設置爲ALL要求所有節點都有數據的一致的副本，這時候系統不具有對任何節點失效和分區容錯性。而如果爲了獲取最佳的性能，將Consistency Level 設置爲ONE的情況下，從任意一個保存有這個副本的節點獲取數據就可以（此時系統擁有了非常高的可用性和分區容錯性）。而Consistency Level 設置爲QUORUM，則意味着大部分存放該數據的節點上的副本是一致的，這是一個折衷的設計，系統提供了合理的節點失效與網絡分裂的耐受性的同時也提供了很高的一致性。C,A,P在Cassandra中可以按需設置。

雖然Cassandra擁有了如此多的優點，它的缺點同樣也同樣顯著。因爲其底層存儲設計的特性，Cassandra 則更適合於實時事務處理和提供交互型數據，而不適合於數據倉庫、大型數據的處理和分析，這點從開發人員的背景上也能看出端倪。對於cassandra的性能描述，江湖傳言多有誤會的地方，據Facebook的工程師Avinash Lakshman介紹，Cassandra僅用0.12毫秒就可以寫入50GB的數據，比MySQL快了超過2500倍。這應該是個謬誤。

找來Avinash Lakshman的PPT對照：

MySQL > 50 GB Data ;Writes Average : ~300 ms;Reads Average : ~350 ms;

Cassandra > 50 GB Data;Writes Average : 0.12 ms;Reads Average : 15 ms;

這裏的0.12毫秒的寫入速度應該是50GB的數據庫尺寸下單個KV的寫入速度，而不是系統寫完50GB的時間。如果真要在0.12毫秒內寫完50GB，意味着這個系統每秒能寫入50/0.12*1000G=416TB。在實際的測試中，每次讀取Cassandra至少要將本地數據節點內該KEY的所有數據都讀取出來，MERGE最新的Timestamp的VALUE後返回結果，系統的讀取性能表現的較爲糟糕。

8月13號發佈的Cassandra 0.7 beta1版本，有很多很吸引人的特性，在讀取的性能上，做了很大的改進。

包括：

Ø 開始重點使用RowCache，將其讀取性能提升了8X。

Ø 支持secondary index，目前的實現機制就是用反轉的方式，支持聯合索引。

Ø 支持hadoop格式的輸出，可以使得數據倉庫更容易從Cassandra中抽取數據。

Ø 無索引的篩選過濾查詢仍然不支持，需要再通過hadoop的M/R實現。

基於文檔的分佈式數據庫

我們目前在使用Mongo DB在構建一個基於客戶的實時分析的系統。Mongo DB的名字來自humongous這個單詞的中間部分，從名字可見其野心所在就是海量數據的處理。跟CouchDB一樣，Mongo是一個面向文檔的JSON數據庫，被設計爲一個真正的對象數據庫，而不是一個純粹的鍵/值存儲。Mongodb的內存映射文件機制以及schema-free的特點，讓我們可以保持高速添加數據，不用擔心數據庫會出現堵塞。另外，MongoDB支持非常豐富的查詢功能。幾乎常用的SQL功能在它裏面都有相應的方法來實現。而且支持索引，能夠根據某一列進行WHERE條件快速篩選。MongoDB適合用來描述一個具有個性化特徵的實體對象正，快速無阻塞的數據數據並行寫入功能以及豐富的查詢功能是MongoDB的亮點，對於實時分析、logging、全文搜索這樣的場景是合適的選擇。

MongoDB其中一個問題是佔用空間過於虛高，原來1G的flatfile它需要4倍的磁盤空間存儲。另一方面mongodb的sharding到現在爲止仍不太成熟。Mongo DB沒有像其他一些NOSQL產品那樣選擇一致性哈希來進行數據分片。它使用的是一種RANGE-BASED機制來進行數據的分片，在使用sharding功能的時候會讓你指定一個COLUMN作爲SHARD KEY。我們嘗試通過一致性哈希算法來自己做DB之間的切片，把數據人工分到不同的機器上。採用自己實現的分片機制，性能相對使用Mongo DB自帶的sharding，性能更穩定，且更新速度一直保持在一個比較快的水平。當然，自己來實現數據分片，很多功能都需要自己手工來實現。比如說where條件的篩選，需要在每臺機器上都執行一遍，然後再對各個結果集進行一個合併。GROUP BY也一樣，先在每臺機器上GROUP BY一下，然後還要再來一次。而使用MongoDB自帶的sharding功能的時候，你只需要發一條命令給它，它會自動進行處理，直接返回最終的結果給你。

基於分佈式文件的數據庫

hadoop/Hbase/Hive/PIG是我們目前更爲使用廣泛的一項技術，在全球範圍hadoop也受到越來越多的關注，Shelton在他的presentation中很自豪的說hadoop是海量數據處理的趨勢和未來。2010年參加hadoop峯會達到了1000人（門票在開幕10天前就賣光了），包括James Gosling 也參加了這次峯會。Yahoo和facebook在hadoop上實現的應用令人印象極其深刻。Irving聲稱 “我們相信Hadoop已經爲主流企業的應用做好了準備”。

看看Yahoo們用hadoop都在做些什麼，他們使用hadoop個性化他們的主頁：[4]

Ø 實時服務系統使用Apache從數據庫中讀取從user到interest的映射

Ø 每隔5分鐘，他們使用生產環境中的Hadoop集羣基於最新數據重新排列內容，並每7分鐘更新結果

Ø 每個星期，他們在Hadoop科研集羣上重新計算他們關於類別的機器學習模式

Facebook透露了更多使用hadoop的技術細節，他們展示了Hive與Hbase和RCFile的集成。Facebook正在嘗試將HBase用於數據倉庫裏對於維度屬性的持續更新。他們將Hive集成到20個節點的HBase集羣——從Hive向HBase載入6TB gzip壓縮的數據塊用了30個小時，在這種配置下可以達到30GB/每小時的增加載入速率。在HBase運行表掃描比執行原生的Hive查詢要慢五倍（使用了RCFile，Hive中一種新的存儲格式，將數據按列式存儲。採用這種格式，平均減少了20%的存儲需求，同時可以達到更好的性能）[3]

Facebook使用hadoop一個成功的經驗是：95%的Facebook任務由Hive寫成，通常可以在HIVE中可以用類SQL語言在十分鐘內完成一個任務（Schroepfer特別給了一個hadoop job和HIVE job的對比頁面）。Facebook提供一個稱之爲爲HiPai的Web工具讓業務分析師使用Hive，只需要簡單的撰寫查詢語句，支持查詢載入倉庫的近20000個表。say NO to SQL？NOWAY!NOSQL更確切的是NOT only SQL.對於絕大多的數據的分析任務而言，SQL是一種非常簡單、易懂、結構化且高效的語言，學習和使用成本都很低，能極大的降低使用者的門檻，將數據開放給更多的非技術的業務分析人員使用，從業務的角度理解並消費數據。對於數據分析人員而言，SQL是一個最簡單犀利的武器，遠沒有到對SQL說NO的時候。

另一個重要的變化是：雖然在最開始被設計爲批量任務處理（包括HDFS也是一個只允許一次寫入的文件系統），Hadoop一直被看做不適合於實時的數據分析，數據的實時更新一直是困擾hadoop的一個問題。從06年的研究到07年的科學影響分析再到08年日常生產任務，當前yahoo已經做到了每個頁面點擊背後都有hadoop。facebook通過將Hbase，Hive等各個模塊之間的協作整合，一步一步從每天的批處理過渡到實時的查詢——預見將會出現最快查詢在一分鐘內就可以返回的系統，這必將爲一系列新興的應用開啓大門。

必須看到，hadoop還不是一個完善的系統，包括這次峯會中Irving也提到的，當hadoop的集羣擴張到一定程度的時候，資源的調度機制在大量不同優先級的任務之間的調度就會顯的開始有些捉襟見肘（一般的認爲2000節點是hadoop的一個門檻，yahoo已經構建了一個4000節點的羣集）。去年yahoo在map reduce上改善的重點是在混合壓力的情況下，保證工作工作負載的健壯性，構造新的調度容量程序，通過安全圍欄（safety rails）來保證資源使用限制。

另一個問題還是老調重彈的非全對稱式的設計。爲了減輕HDFS的Name Node的單點故障問題他們都將數據複製到多個羣集，分佈式文件系統的中斷可以使用備份文件系統來彌補和解決name node出現的故障。同時，爲了保證應用的之間的解耦，無論是yahoo還是facebook，都將他們的hadoop羣集根據應用分解成多個羣集。

到這裏已經囉嗦了大約6000字談論了很多的背景和現狀，外面世界和公司內部的情況。數據中心將成爲整個企業數據化運營中一個環節，如yahoo號稱的那樣，data center behind every click；數據中心爲各個業務系統以及企業的外部用戶提供分析整合後的數據，通過對數據的整合和彙總計算，發現數據的規律與價值並通過數據服務提供給最終用戶，可以預見數據中心會越來越多的面臨來自以下兩個方面的需求和挑戰：

Ø 隨着對外提供數據服務的增加，數據中心將會成爲整個企業服務流程中的一個環節，對數據分析的結果需要直接的對外提供服務。這要求數據中心的系統平臺能夠對於廣告信息投放，用戶興趣預測，推薦引擎這樣的業務都能夠有更快的刷新計算頻率（1分鐘刷新），計算完成的結果能近乎實時的被前臺應用服務所直接訪問、應用；數據中心提供的數據服務要求是基於事件觸發（Event Driving Architecture）更爲靈活主動的架構，並直接面對網站用戶，要求7*24的系統可用性以及每日億萬級別PV的併發訪問需求；

Ø 提供數據服務的客戶越來越多，常規的數據報表的開發需要更爲簡單直觀，對報表組件工具需要組件化，做客戶化定製封裝；客戶消費數據的能力也越來越強，我們需要一個更爲開放的平臺，讓更多用戶隨時可以面對數據，隨時按照自己的想法來獲取所希望的數據；

現在，讓我們放鬆一下，連接上Pasiv Device跟隨Dream Architect，開始從現實系統進入未來的夢境的旅程，一起來構造屬於阿里巴巴未來所需要計算存儲平臺。

Overall System Architecture

系統的總體架構將滿足以下特性：

Ø Distributed & Parallel

如前文所述，系統的可伸縮性是我們的系統架構中必須要考慮的一個重要因素，解決Scale Out的必由之路是走分佈式計算的道路。將系統的數據、服務請求、負載壓力都能均攤到多個處理節點中。根據業務的需要，可以通過垂直分區（比如將業務功能拆分不同的功能模塊，並將這些不同的功能模塊交由不同的處理單元實現）和水平分區（比如將一組數據元素切分爲許多個實例，並這個數據元素的不同數據實例交由不同的處理單元完成）來實現功能的分佈式。

分佈式帶來的另一個好處並行化，將一個任務拆解爲許多個邏輯單元，將這許多個邏輯單元交由多個處理單元並行的處理從而大幅提升批處理任務的性能。

Ø Transparent & Elasticity

後臺複雜的分佈式邏輯對應用和開發人員隱藏，能讓開發人員開發代碼像在單機上一樣開發。

數據羣集存儲服務，應用對數據訪問透明，無需關心存儲的位置；遵循於CAP theorem的跨多節點數據分佈模型而設計，支持數據的水平伸縮。這意味着對於多數據中心和動態供應（在生產集羣中透明地加入/刪除節點）的必要支持，也即彈性[2]。

Ø High Availability & Fault Tolerance

Data Center發展到今天，已經不再是一個單純的後臺系統。隨着應用的深入和實時化的推進，Data Center越來越前臺化，需要提供7*24可用性級別；任意硬件設備導致的宕機是完全不可接受的；在系統的設計中，不應當把雞蛋都放在一個籃子中，需要儘量避免應用的中心點，否則這個中心點很容易就會變成故障的單點而損害整個系統的可用性。比如Master節點的存在（facebook和yahoo爲了避免HDFS namenode的單點，不得不構建了兩組羣集互爲備份）或者一個全局的配置文件或者一個基於關係型數據庫的元數據管理中心繫統（比如facebook最近的這次因爲一個錯誤的配置文件變更導致中心數據庫死鎖最終導致整個服務不可用）。像cassandra這樣的全對稱（Completely Symmetric）設計是一種優雅的設計，這在架構上杜絕了任意一個單點不會對系統造成致命的影響。

當我們的服務器羣集擴展到幾千臺幾萬臺的時候，你不能要求整個系統的任意硬件或者軟件是不會發生損壞的，這就要求在系統架構上設計上保證當系統中確實發生故障的時候（軟件的或者硬件的），系統應當能夠主動的對這些故障進行監控，並通過啓用備用節點將故障進行恢復，所有的這一切都應當是自動完成的。

Ø Dynamic Resource pool management supporting mixed workloads

系統之間的消息傳遞採用事件驅動的架構。每個服務所能佔用的資源和任務的優先級是不同的，對於不同等級的服務按照配額和優先級保證資源的配置管理，同時總是保證在用戶的配額內服務總是能成功，任務調度程序需要更加的智能與快速，能在儘可能短的時間內分配給任務必要的資源並快速啓動任務；

Ø NUMU Architecture

根據阿姆達爾定律（Amdahl’s Law）並行處理器環境中的速度受制於程序串行的部分。對於傳統 SMP 來說，CPU 增多未必系統性能就好，因爲共享系統總線的限制了 CPU 數量，CPU 越多內部通信量越大共享總線越容易達到瓶頸。而 NUMA 架構通過給每個核提供單獨的本地內存，減少多個CPU對於內存以及共享總線的競爭。在設計上，將每顆CPU和內存都劃分爲獨立的邏輯單元，讓系統的變得簡潔並進而提高系統的可擴展性。

Data Tier

在數據層，提供結構化和半結構化的數據存儲服務；對於不同的訪問模式（彙總分析查詢、K/V方式的主鍵訪問）允許制定不同的存儲策略以保證系統性能（按照需要讀取的列全列掃描或者通過索引的快速掃描）使用鬆耦合類型、可擴展的數據模式來對數據進行邏輯建模，而不是使用固定的關係模式元組來構建數據模型。

Ø Mixed Storage Model

NSM（N-ary Storage Model），即基於行的存儲模型。隨着硬件的發展，NSM對於緩存的利用率較低。NSM在每個磁盤頁面中連續的存儲記錄，使相對頁面的偏移記錄每條記錄的開始。

DSM（Decomposition Storage Model）。列存儲模型並不是一個新鮮的概念，在1985年就已經提出，2005年左右隨着數據分析應用的廣泛開展獲得新生。對數據的使用，特別是分析的需求，常常只使用一條記錄的一部分數據。爲了減少IO的消耗，提出了“分解存儲模型”。DSM將關係垂直分爲n個子關係，屬性僅當需要時才加以存取訪問。對於涉及多個屬性的查詢來說需要額外的開銷用於連接子關係。

PAX（Partition Attribute Across）。PAX是記錄在頁面中的混合佈局方式，結合了NSM和DSM的優點，避免了對主存不需要的訪問。PAX首先將儘可能多的關係記錄採用NSM方式加以存儲。在每個頁面內，使用按屬性和minipage進行類似於DSM的存儲。在順序掃描時，PAX充分利用了緩存的資源。同時，所有的記錄都位於相同的頁面。對於記錄的重構操作，僅僅在minipage之間進行，並不涉及跨頁的操作。相對於DSM來說，對於多屬性的查詢來說PAX優於DSM，因爲DSM需要更多的跨頁重構時間。

混合存儲模型，我們可以將所有的數據都理解爲由Key/Value/Description（column name）構成的三元組存儲模型。KV模型允許你按照你想要的模式來組織數據的存儲，如果應用總是按照行來訪問的（比如總是訪問某個用戶的大部分數據），那麼就可以把數據按照同一個Key組織在一起（實際上就是NSM），而如果某個應用總是分析彙總查詢，可以按照Description（column name）將數據組織在一起（DSM或者PAX的實現）。

Ø Column Exchange

基於列存儲的對同一對象實體的全量屬性快速Merge實現。基本思想是通過DSM模型存儲數據，對不同屬性通過不同的數據服務進行數據的全量刷新，極端情況，可以考慮對同一個實體(數據粒度相同)的每個屬性建立一個數據全量刷新服務。傳統的關係模型中，如果有A,B,C,D表需要整合成一個對象，總是需要將A和B得到A’,A’和C進行JOIN得到A’’,再將A’’和D進行JOIN，得到最終的結果寬表。CE可以在最大程度上避免構建寬表過程中，後置屬性的更新任務（比如刷新來自D表的任務）對前置任務（比如刷新來自C表的任務）的依賴，只需要建立一個獨立的任務來刷新來自D表的屬性，並得到一個D’,通過Column Exchange（可以把他想象成分區表的分區交換），將D‘快速的Merge進目標寬表中，而無需依賴刷新其他屬性的任務。在這個過程中，目標寬表始終是處於可用狀態，無需等待最後一個刷新D的任務完成後才能對外提供服務。

Ø Parallel update with Non-Schematic

陶勇說這是個有意思的需求，對於跨表merge/join是一個有力補充；也是一個非常具有技術挑戰和難度的問題。是dandelion data model在對於實時變更的維度數據實現方式，大致的思想是將應用屬性與對象實體之間進行解耦，在Non-Schematic的數據模型下，允許我們通過不同的服務對同一個對象實體（Key）不同的屬性進行並行更新，每個服務只關注於自己需要更新的屬性信息，不同的服務之間即使更新的同一個對象實體，相互之間也無需通信，沒有關聯。當實體的需要新增某個屬性的時候，只需要爲該屬性新增一個服務，無需調整其他的服務。同樣的，當某個屬性不再需要的時候，只需要停用該屬性的服務，對其他屬性同樣不會產生影響。在技術上，只需要通過對Key的Set方法進行屬性更新，對並行寫入的性能要求很高，要求不同服務對同一Key值的更新是完全無鎖，不阻塞的。

Ø Pluggable Storage Engine

存儲引擎應當是可插拔的，在大多數情況下人們發現基於組合方案的解決方案是最佳的選擇。既能通過內存數據存儲支持高性能，又能在寫入足夠多的數據後存儲到磁盤來保證持續性。

Ø Snapshot

通過對實時數據區的snapshot功能，獲得一個整合後的數據主題的快照；基於該快照，進行數據的深度整合加工、分析，該區域爲固定報表和數據挖掘、數據分析探查的數據輸入；接口數據區的數據是整合的，記錄歷史的；

Ø Compress

尋求不同類型數據的最佳壓縮模式和算法。雖然當前SATA硬盤已經降到一個較低的價格，在海量的數據環境下，壓縮還是可以取得非常高的效益。Yahoo報道說在他們hadoop羣機上，採用壓縮降低了20%的存儲。淘寶採用了極限存儲後，每日淨增數據量從25TB降低到12TB。在我們實際測試中，通過對數據的預排序和列存儲後，在未改變壓縮算法的前提下，對OFFER表的壓縮率從1:5提升到1:20。對數據採用壓縮可以取得另兩個收益是：降低了數據同步到不同數據中心的數據帶寬，同時降低了對磁盤IO吞吐率的需求，從而減輕了對磁盤的壓力，這對保護磁盤，降低系統故障率都能有很高的貢獻。

Service Tier

數據層的結構化或者半結構化的數據，允許根據特定的需求選擇合適的編程語言對數據進行直接的訪問，可以允許SQL,C，R，PERL,PYTHON等不同的編程語言在數據接口層之上直接開發，允許採用Map Reduce編程模式進行海量大規模數據處理編程；允許常駐的服務進程訪問數據並直接對外提供海量併發的查詢訪問；

Interface Tier

爲了消除底層多樣化的數據存儲帶來的耦合性因素，在上層進行訪問接口的抽象，它能夠很好的支持多樣化的數據存儲需求，並且隔離底層變化帶來的影響。

長期來看，我們嘗試構建支持混合負載與混合應用場景的分佈式計算存儲平臺，滿足上述的系統特性。在獲得系統的可伸縮能力的同時，通過各種不同的可插拔組件和數據模型滿足各種不同的業務需求。

短期內我們關注以下技術實現：

Ø 在前臺查詢環境中，實現K/V查詢時數據的路由自動化；

Ø 在前臺查詢環境中，多節點的多表的數據彙總分析查詢，聯合查詢；

Ø 在前臺查詢環境引入列存儲引擎，並在此基礎之上，實現列交換；

Ø 在前臺查詢環境，支持Schema-free的併發數據更新；

Ø 在後臺計算平臺引入列存儲引擎，並在此基礎之上，實現列交換；

Further Reading

Google’s Colossus Makes Search Real-time by Dumping MapReduce

The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines