hbase 替換 mysql

    本文着眼於 生成環境使用的經驗.

    線下試玩:

數據從mysql遷移到hbase的一些思考及設計

    代志遠早年就職網易研究院從事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的解決方案。

  phil 備註: 對線上系統,運維的穩定性,可靠性,容災能力要求比較高,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連續服務端口，這就彌補了系動中的調用命令不可靠的事情。最後當發現服務端口不可用時，有理由認爲當前進程已經死掉了，死掉了之後，那麼就按照現有邏輯刪除結點，這三分鐘的時間就完全省略掉了。