hbase是否能取代mysql

    代志遠早年就職網易研究院從事MapReduce與DFS系統的自主研發，後加入支付寶資料平台負責Hadoop與HBase體系的架構設計與二次研發，支付寶流計算與分布式搜尋系統的設計和研發，後成為支付寶海量計算體系架構師兼支付寶三代架構成員。現就轉戰于阿裡巴巴集團-CDO-海量資料部門，負責創新性項目的研究和跟進，目前專注于Google第二代資料庫産品MegaStore的研究和在阿裡的落地。

    在即将召開的HBTC大會中，我們有幸邀請到代志遠作為我們的演講嘉賓，請他分享下阿裡巴巴在海量資料分布式資料庫領域的探索。我們也對他提前做了郵件采訪，讓使用者可以更快地了解阿裡巴巴海量資料分布式資料庫以及在Hadoop應用領域的實踐。

阿裡巴巴海量資料部門: 代志遠

CSDN: Hadoop目前是大資料處理領域的王者，你認為中小企業應用Hadoop的瓶頸在哪裡？

代志遠：首先因為Hadoop本身機制複雜，所依賴的參數配置頗多，并且Hadoop需要像資料庫一樣穩定，滿足性能的運作，就需要運維人員如同DBA一樣要懂網絡、磁盤、核心以及其他一些硬體知識，這對于運維人員的要求是比較高的。其次Hadoop社群蓬勃發展，生态圈不斷擴大，使用者不斷增多，規模極限也不斷突破，這就促使了Hadoop的架構和代碼發展非常快而且變更也比較快，正因為如此，系統在快速發展的時候容易引入很多的Bug和一些缺陷（可能因為稍稍的使用不當或比較小的問題就引起整體性能和穩定性的波動）。更重要的是，Hadoop代碼複雜，而且需要與社群接軌，能夠找到對Hadoop源碼熟悉并能優化更新和bugfix的人才是很難的，這對于一個公司的研發來說是個很大的挑戰。最後一點是公司的認知，除了類似Cloudera、MapR之類的軟體公司需要對軟體技術負責，其他多數公司無論大中小都依賴于公司業務，尤其中小公司業務壓力大、人員緊張，能夠從業務研發人員中抽調或通過其他方式組建專有的Hadoop運維團隊甚至是研發團隊，從公司規劃與發展上來說是比較困難的事情。

CSDN: Hadoop的本質是為全量而生，就是說它重吞吐量，響應時間完全沒有保障，那麼對于像淘寶、天貓在“雙11”活動搶購的時候，需要實時處理資料（可能是毫秒級，秒級的響應），是如何進行實作的？

代志遠：Hadoop是離線計算平台，其中包括分布式檔案系統（HDFS）和分布式計算（MapReduce），這本身是無法對響應時間做保證的。但是目前在Hadoop之上的生态系統越來越完善，其中HBase就是支援海量資料、高并發的線上資料庫，應對這種場景就非常适合。HBase在這次雙十一中與MySQL等線上資料庫共同作為線上庫使用，承擔了重要的責任，并創下了并在全天高壓力之下無故障的佳績。另外非Hadoop生态圈的流式計算架構Storm、S4也同樣可以為實時計算分擔一定的壓力。

CSDN: 你在雲計算大會時做的一場有關HBase的報告，主要講如何用HBase替代MySQL，HBase對比MySQL的優勢在哪裡？

代志遠：準确來說是HBase替換MySQL的一部分應用，這些應用自然是要符合HBase的應用場景（與MySQL對比），比如資料量大、對線性拓展有需求、對自動化運維（負載均衡）有要求而且應用模式簡單。在支付寶中因其增長速度快，業務量大，造成了很多應用都是資料量龐大而且速度增長快，是以有一些應用迫切需要一個資料庫能夠支撐現在的業務而降低對關系型的需求，是以嘗試了HBase的解決方案。

CSDN: 阿裡巴巴在部署Hadoop的過程中有哪些比較好的經驗可以跟技術人員分享？

代志遠：最重要的是要有一個完善團隊，健全的流程。

叢集越來越大，要樹立以叢集穩定性和性能為要領的工作思路。

現在進入Hadoop應用開發領域的人變多，但本身知識因其入行早晚而積累不同，無法對叢集的穩定性負責，常常會寫出跑死叢集的任務（資料庫中SQL使用不善也常會如此）。是以要有一個較好的管理流程限制開發人員做到責任分明，以便促使應用開發不僅要對自己的任務負責還要對叢集負責，不斷學習和檢查減少故障的産生。

要有一個好的運維團隊，懂硬體、重流程、負責任。

公司在資源和戰略上應有所傾斜，重視研發人員加強在研發的投入，畢竟分布式系統的入行門檻相比應用開發的技術門檻要高，當然有好的應用架構師能夠取長補短規避大多數問題也是可行的，但單一系統的穩定性還是需要靠人來保證。

CSDN: 請您簡要介紹一下本次HBTC2012大會上的議題的内容。

代志遠：06年Google發表論文Bigtable，社群随之出現HBase，後Google 08年發表第二代資料庫産品MegaStore至今未有社群同類産品出現，現今Google又出現新一代資料庫理論Spanner和F1。 而最近幾年随之Bigtable和NoSQL的興起，社群産品HBase逐漸走向NoSQL系統的主流産品，優勢明顯然而缺點也明顯，大資料平台下的業務由SQL向NoSQL的遷移比較複雜而應用人員學習成本頗高，并且無法支援事務和多元索引，使得許多業務無法享用來自NoSQL系統中線性拓展能力。

Google内部MegaStore就作為Bigtable的一個補充而出現，在Bigtable的上層支援了SQL，事務、索引、跨機房災備，并成為大名鼎鼎的Gmail、Google App Engine、Android Market的底層存儲。是以我們決定以MegaStore為理論模型進行探索如何在HBase系統上不犧牲線性拓展能力，同時又能提供跨行事務、索引、SQL的功能。

HBase系統故障恢複的優化實踐

    其實在第四屆中國雲計算大會上，當時還在支付寶資料平台的架構師代志遠就為大家帶來了題為“HBase系統故障恢複的優化實踐分享”的精彩演講，他分析了支付寶海量資料線上處理的現狀，以HBase解決方案取代傳統MySQL解決方案的技術曆程，并詳盡分享了Region Server的當機恢複流程（）。

    在Hadoop的體系當中，支援實時的一條線，HBase，支援海量資料庫初衷的時候，設計為了設計萬一級實時資料庫，HBase這個東西經過這幾年的發展，已經逐漸成為目前業界當中主要的實時資料庫，分布式資料庫，像支付寶直接上HBase系統，就是考慮到HBase的先進架構，能夠幫助支付寶完成現在很多的海量資料的存儲以及線上随機讀寫高性能的通路和存儲。

    不過在HBase的系統當中，展現它的可用性有幾個風險。第一個是HBase本身在底層依賴的HDFS，加載了唯一一塊資料，單台機器保證一緻性，HDFS保持了備援。第二點，恢複過程當中，Failover過程非常複雜，這個時間消耗越長，作為線上系統，這種時間越長可能會影響到線上通路使用者體驗。第三點它依賴的HDFS，HBase作為線上資料庫依賴HDFS有故障的，經過幾小時恢複提供生産業務，對業務方沒有直接感受，作為線上系統如果挂掉，如果需要經過近小時恢複時間，恐怕就會直接收到自于支付寶外部的使用者投訴了。HBase目前它自己的監控體系尚不完善，目前的監控力度非常得粗，隻能監控到單台的Region

Server的情況，看不到目前使用者表有多少讀寫比例，看不到目前服務結點寫作量多少，讀出量多少。

    Region Server在恢複過程當中有幾個流程，這個流程很複雜，流程非常非常多，以目前的系統規模，它凸顯出來的問題，這幾個流程是影響到它的恢複速度的關鍵流程。等待時間周期非常長，周期之是以比較長，是因為現在的機器發展速度非常得快，每台機器從兩個G到8個G，96G，140G的大層次的機器，Java語言實作了系統當中大記憶體管理本身存在問題，除非革新這門語言，否則别無他法。如果說在設計的參數不合理，就可能會導緻一個問題，有可能這台伺服器就會停止運作，發生這麼一次情況就非常可怕，幾十G的記憶體這個過程需要幾十秒甚至上分鐘，通常情況下，我們會設定到3分鐘，這就意味着，為了避免出現這種問題，就會同時引入新的問題，當機之後恢複等待時間需要三分鐘。第二個關鍵流程當中，當它感覺到已經挂掉了，線上資料庫協助WL資料重新做到存儲當中去，以保證明時更新是同步，否則這個資料庫肯定要丢出去，重做資料過程當中，會有一個過程，Split

Hlog，跟目前資料量有關系，Edit Log資料又比較多，大家在業餘時間可以進行測試，資料不以支付寶的為準，以目前資料系統大小為準。

    第三個關鍵流程，重做完資料之後，這部分重新上線，上線之前進行資料進行二次掃描，告訴系統，Region怎麼加入到Region Server當中去，掃描也存在問題，問題可能引發到兩分鐘到6分鐘，這也跟目前系統資料有關。第四部分，這個過程稱之為再次上線的過程，這個再次上線，上線時間跟目前這台機器的Region上線有關系。支付寶面對消費記錄查詢，使用者查不出來資料，15分鐘之後才能查到，在面臨線上問題上這是非常可怕的事情。

    針對Region Server這一關鍵流程，做了一些優化。這個優化正是提到關鍵流程第一點，在判斷當機超市的情況下，不強依賴于Zookeeper，支付寶又啟動了監控程序Mirror Process，每一台，Region Server當中都會起到PID存不存在，這種檢查并非完全可靠，當檢查PID不存在，就有理由認為已經挂掉了，要進行可靠檢查，通常DBA線上判斷資料庫是否可用，通常會用PIng連續服務端口，這就彌補了系動中的調用指令不可靠的事情。最後當發現服務端口不可用時，有理由認為目前程序已經死掉了，死掉了之後，那麼就按照現有邏輯删除結點，這三分鐘的時間就完全省略掉了。