大資料分析技術研究報告(二)
二 大資料背景下事務型處理系統相關技術
在google、facebook、taobao等大網際網路公司出現之後,這些公司註冊和線上使用者數量都非長大,因此該公司交易系統需要解決“海量資料+高併發+資料一致性+高可用性”的問題。
為了解決該問題,從目前資料來看,其實沒有一個通用的解決方案,各大公司都會根據自己業務特點定製開發相應的系統,但是常用的思路主要包括以下幾點:
(1)資料庫分片,結合業務和資料特點將資料分佈在多臺機器上。
(2)利用快取等機制,儘量利用記憶體,解決高併發時遇到的隨機IO效率問題。
(3)結合資料複製等技術實現讀寫分離,以及提高系統可用性。
(4)大量採用非同步處理機制,對應高併發衝擊。
(5)根據實際業務需求,儘量避免分散式事務。
1相關係統介紹
1) 阿里CORBAR系統
阿里COBAR系統是一個基於MYSQL資料庫的分散式資料庫系統,屬於基於分散式資料庫中介軟體的分散式資料庫系統。該系統是前身是陳思儒開發的“變形蟲”系統(以前調研過),由於陳思儒離開阿里去了盛大,阿里當心“變形蟲”穩定性等問題,重新開發該專案。
該系統主要採用資料庫分片思路,實現了:資料拆分、讀寫分離、複製等功能。由於此係統由於只需要滿足事務型操作即可,因此相對真正並行資料庫叢集(例如TeraData等),此類系統提供操作沒有也不需要提供一些複雜跨庫處理,因此該系統存在以下限制:
(1)不支援跨庫的join、分頁、排序、子查詢。
(2)insert等變更語句必須包括拆分欄位等。
(3)應該不支援跨機事務(以前變形蟲不支援)。
說白了此類系統不具備平行計算能力,基本上相當於資料庫路由器!
另外此類系統的在實際應用的關鍵問題是,根據什麼對資料進行切分,因為切分不好會導致分散式的事務問題。
2) 阿里OceanBase系統
該系統也是淘寶為了解決高併發、大資料環境下事務型處理而定製開發的一個系統。該系統主要思路和特點如下:
(1)他們發現在實際生成環境中,每天更新的資料只佔總體資料的1%不到,因此他們把資料分為:基線資料和增量更新資料。
(2)基線資料是靜態資料,採用分散式儲存方式進行儲存。
(3)只在一臺伺服器上儲存和處理增量更新資料,並且是在記憶體中儲存和處理更新資料。
(4)在系統負載輕的時候,把增量更新批量合併到基線資料中。
(5)資料訪問時同時訪問基線資料和增量更新資料併合並。
因此這樣好處是:
(1)讀事務和寫事務分離
(2)通過犧牲一點擴充套件性(寫是一個單點),來避免分散式事務處理。
說明:該系統雖然能處理高併發的事務型處理,號稱很牛逼,但其實也只是根據電商的事務處理來定製開發的專用系統,個人認為其技術難度小於oracle等通用型的資料庫。該系統無法應用到銀行或者12306等,因為其事務處理的邏輯遠遠比電商商品買賣處理邏輯複雜。
在目前的大資料時代,一定是基於應用定製才能找到好的解決方案!
3) 基於Hbase的交易系統
在hadoop平臺下,HBASE資料庫是一個分散式KV資料庫,屬於實時資料庫範疇。支付寶目前支付記錄就是儲存在HBASE資料庫中。
HBASE資料庫介面是非SQL介面,而是KV操作介面(基於Key的訪問和基於key範圍的scan操作),因此HBASE資料庫雖然可擴充套件性非常好,但是由於其介面限制導致該資料庫能支援上層應用很窄。基於HBASE應用的設計中,關鍵點是key的設計,要根據需要支援的應用來設計key的組成。
可以認為HBASE資料庫只支援作為KEY的這一列的索引。雖然目前HBASE有支援二級索引的方案,二級索引維護將會比較麻煩。
2併發和並行區別
併發是指同時執行通常不相關的各種任務,例如交易型系統典型屬於高併發系統。
並行是通過將一個很大的計算任務,劃分為多個小的計算任務,然後多個小計算任務的並行執行,來縮短該計算任務計算時間。
兩者主要區別在於:
(1)通訊與協調方面:在平行計算中,由於多個小任務同屬一個大的計算任務,因此小任務之間存在依賴關係,小任務之間需要大量通訊和協調;相反,併發中的多個任務之間基本相互獨立,任務與任務之間相關性很小。
(2)容錯處理方面:由於併發任務之間相互獨立,某個任務執行失敗並不會影響其它的任務。但是平行計算中的多個任務屬於一個大任務,因此某個子任務的失敗,如果不能恢復(粗粒度容錯與細粒度容錯),則整個任務都會失敗。
併發
並行
3本章總結
資料量大不一定需要平行計算,雖然資料量大,資料是分佈儲存,但是如果每次操作基本上還是針對少量資料,因此每次操作基本上都是在一臺伺服器上完成,不涉及平行計算。只是需要通過資料複製、資料快取、非同步處理等方式來支撐高併發訪問量。