基于大數據平臺的

億級別非結構化數據的存儲實(shí)現

神州信息

趙軍

1.

項目背景

本次建設基于某政府單位的電子檔案系統，整體數據存儲量為240TB左右，使用Oracle存儲，并且按每年30%比例持續增長(cháng)，隨業(yè)務(wù)發(fā)展，預計未來(lái)5年內將達到1PB左右的數據量。當存儲的數據量過(guò)大時(shí)，Oracle數據庫將面臨需要更大的存儲空間，大數據量的導入導出將導致數據庫無(wú)法高效、穩定的運行；同時(shí)所需要的全備份周期會(huì )逐漸延長(cháng)，會(huì )影響到工作時(shí)間內業(yè)務(wù)運行；存儲資源需求過(guò)大，整個(gè)災備系統的存儲資源也會(huì )投入過(guò)大。

目前電子檔案數據庫數據

表1電子檔案主要表情況（截止到2021年底）

存儲空間嚴重不足

電子檔案數據庫總存儲量為240TB左右，按照現在的增長(cháng)速度呈指數級上升，5年內將達到1PB左右的數據量，Oracle數據庫將需要更大的存儲空間。從資金層面考慮數據庫 SAN 上的磁盤(pán)存儲通常比 Web 服務(wù)器場(chǎng)中使用的磁盤(pán)上的存儲更為昂貴。

數據存取方式落伍

原架構對于電子檔案數據采用直接通過(guò)服務(wù)器端程序將需要存儲的文件轉為二進(jìn)制文件流直接存在數據庫表的BLOB字段中，當需要查詢(xún)時(shí)同樣也是服務(wù)器端將文件以流的方式查詢(xún)出來(lái)，經(jīng)過(guò)處理后以二進(jìn)制流的方式發(fā)送給客戶(hù)端顯示出來(lái)。

此種方法從項目的角度上來(lái)說(shuō)，文件存儲和數據庫存儲最好是要分離的，二進(jìn)制的存儲方式特別是針對存儲文件大而多的情況，因為性能較差，且大量占用數據庫內存，已經(jīng)逐步淘汰。

計算壓力不堪重負

原電子檔案數據存儲在Oracle數據庫中，查詢(xún)條件單一，已不能滿(mǎn)足電子檔案業(yè)務(wù)的管理需求。隨著(zhù)數據量的上漲，服務(wù)器計算壓力也逐漸不堪重負。對電子檔案庫的查詢(xún)操作在原系統中發(fā)生非常頻繁，在工作日繁忙階段可產(chǎn)生高并發(fā)的情況，按目前通過(guò)文件二進(jìn)制流的查詢(xún)方式，查詢(xún)效率已經(jīng)不甚樂(lè )觀(guān)，隨著(zhù)數據量的不斷加大，如果繼續按目前的查詢(xún)方式來(lái)看查詢(xún)效率會(huì )不斷的下降，直接影響到日常業(yè)務(wù)，降低工作效率。

安全運行無(wú)法保障

大數據量的導入導出將導致數據庫無(wú)法高效、穩定的運行。加之數據庫單點(diǎn)故障、磁盤(pán)損壞等情況更會(huì )加劇數據庫走向奔潰。

全量備份周期延長(cháng)

隨著(zhù)數據量的增長(cháng)，所需要的全備份周期會(huì )逐漸延長(cháng)，會(huì )影響到工作時(shí)間內業(yè)務(wù)運行；存儲資源需求過(guò)大，整個(gè)災備系統的存儲資源也會(huì )投入過(guò)大。

2.

想法與設計

2.1 方案選擇

為解決電子檔案系統存儲空間不足、運行狀態(tài)不穩定、計算負荷過(guò)重、備份效率低下的問(wèn)題，我們迫切需要改變現有的電子檔案集中式存儲架構。集中式存儲服務(wù)器使用本地磁盤(pán)存放所有數據，增加磁盤(pán)是解決存儲空間唯一的辦法，計算能力無(wú)法提升，系統安全性和可靠性也無(wú)法得到保證，不能滿(mǎn)足大規模存儲應用的需求。而當前的電子檔案系統就是采用了這種架構模式。

表2 集中式存儲架構和分布式存儲架構特性比較

圖1 集中式存儲架構和分布式存儲架構比較

因此我們將采用分布式存儲架構替換原有的集中式存儲系統，分布式存儲系統采用可擴展的系統結構，利用多臺存儲服務(wù)器分擔存儲負荷，利用位置服務(wù)器定位存儲信息，它提高了系統的可靠性、可用性和存取效率，還易于擴展。分布式存儲架構的種種特性，都能夠完美的解決我們當下所面臨的問(wèn)題。

2.2 問(wèn)題解決

存儲空間嚴重不足

分布式存儲不再需要昂貴的磁盤(pán)陣列來(lái)解決存儲問(wèn)題，廉價(jià)的商用機器都能擴展器存儲能力。

分布式存儲系統通過(guò)對集群服務(wù)器規模進(jìn)行進(jìn)行擴展，從而使系統存儲容量、計算和性能得到提高。隨著(zhù)業(yè)務(wù)量的增大，對底層分布式存儲系統的性能要求也隨之增高。衡量可擴展性的要求集群具有線(xiàn)性的可擴展性，系統整體性能和服務(wù)數量是線(xiàn)性關(guān)系。分布式存儲有著(zhù)合理的分布式架構，能夠預估并且彈性擴展計算、存儲容量和性能。

計算壓力不堪重負

分布式存儲的去中心化思想，讓各個(gè)節點(diǎn)都能分擔計算壓力，計算能力隨著(zhù)節點(diǎn)的擴展而提升。

系統的吞吐量和系統的響應延遲這兩項指標，經(jīng)常被用來(lái)衡量分布式存儲系統的性能。通常高性能的分布式存儲，能夠高效的管理讀緩存和寫(xiě)緩存，并且能夠自動(dòng)分級存儲。分布式存儲是通過(guò)把熱點(diǎn)區域內數據映射到高速緩存中，以此來(lái)提高系統響應的速度；如果這些區域不再是熱點(diǎn)，那么存儲系統就會(huì )將它們從高速緩存中剔除。而寫(xiě)緩存技術(shù)則是配合高速存儲，來(lái)使得整體存儲的性能有顯著(zhù)提高，按一定的策略，先將數據寫(xiě)入高速存儲，再在適當的時(shí)間進(jìn)行同步落盤(pán)。

安全運行無(wú)法保障

不用再擔心單點(diǎn)故障的問(wèn)題，數據多副本分散存儲，即使多個(gè)節點(diǎn)宕機，系統依然能對外提供服務(wù)。

使用網(wǎng)絡(luò )進(jìn)行松耦合連接，分布式存儲能夠允許高速存儲和低速存儲分開(kāi)部署，或者以任意比例混布，在業(yè)務(wù)環(huán)境不可預測，或者用于敏捷的情況下，將分層存儲的技術(shù)優(yōu)勢發(fā)揮到最佳。而且分布式存儲系統不受惡意訪(fǎng)問(wèn)和攻擊，能夠保護存儲數據不被竊取。

全量備份周期延長(cháng)

系統默認的多副本、多節點(diǎn)放置策略，無(wú)需再考慮數據備份的問(wèn)題，從而節省昂貴的異地容災備份。

分布式系統數據安全方面的容災與備份，數據可靠不丟失。在分布式存儲的容災中，一個(gè)重要的手段就是多時(shí)間點(diǎn)快照技術(shù)，這樣用戶(hù)生產(chǎn)系統可以實(shí)現在一定時(shí)間間隔內對各版本數據的保存。而且，多時(shí)間點(diǎn)快照技術(shù)，能夠支持同時(shí)提取多個(gè)時(shí)間點(diǎn)的樣本，并且同時(shí)進(jìn)行恢復。這一功能對于故障重現也很有幫助，可幫助進(jìn)行分析和研究，避免類(lèi)似災難的再次發(fā)生。多時(shí)間點(diǎn)快照，周期增量復制等技術(shù)為分布式存儲的高可靠性提供了保障。

2.3 產(chǎn)品選型

考慮到實(shí)際場(chǎng)景的需要，我們的目標是要建立一套全新的分布式存儲系統，既能滿(mǎn)足數據存儲的需要，也能提供快速高效的數據請求服務(wù)，并盡可能的避免對現有的業(yè)務(wù)審查系統造成影響。在我們產(chǎn)品選型方案中，FastDFS、MinIO、HDFS、HBase是我們根據場(chǎng)景需要進(jìn)行篩選比對之后，選擇最佳的一種。

FastDFS

圖2 FastDFS架構圖

雖說(shuō)能能解決海量非結構化數據（PDF）的存儲問(wèn)題，但是需要額外的關(guān)系型數據來(lái)存放PDF的關(guān)鍵信息（文件名稱(chēng)、大小、在FastDFS中的位置等），也不能很好的使用內存提高讀寫(xiě)效率。

MinIO

圖3 MinIO架構圖

MinIO對象存儲系統是為海量數據存儲、人工智能、大數據分析而設計，適合存儲海量圖片、視頻、日志文件、備份數據等，同樣的，關(guān)鍵信息也需要額外的關(guān)系型數據庫控制。

HDFS

圖4 HDFS架構圖

HDFS是指被設計成適合運行在通用硬件上的分布式文件系統，但其關(guān)鍵信息也需要額外的關(guān)系型數據庫控制，再者它不適合低延遲的數據訪(fǎng)問(wèn)，不支持并發(fā)寫(xiě)入和文件隨機修改，這不是我們想要的。

HBase

圖5 HBase架構圖

HBase特別適合于非結構化數據的存儲，關(guān)鍵信息與PDF一并存儲，不需額外的關(guān)系型數據庫。充分使用內存資源，從而能夠對外提供低延時(shí)、高并發(fā)的讀寫(xiě)請求服務(wù)，這最適合我們的業(yè)務(wù)需求。

按照HBase設計特性，有如下優(yōu)勢是我們業(yè)務(wù)場(chǎng)景迫切需要的：

1) 容量巨大

HBase的單表可以有百億行、百萬(wàn)列，可以在橫向和縱向兩個(gè)維度插入數據，具有很大的彈性。

當關(guān)系型數據庫的單表記錄在億級別時(shí)，查詢(xún)和寫(xiě)入的性能都會(huì )呈現指數級下降，這種龐大的數量對傳統數據庫來(lái)說(shuō)是一種災難，而HBase在限定某個(gè)列的情況下對于單表存儲百億甚至更多的數據都沒(méi)有性能問(wèn)題。

HBase采用LSM樹(shù)作為內部數據存儲結構，這種結構會(huì )周期性的將小文件合并為大文件，以減少對磁盤(pán)的尋址時(shí)間。

2) 列存儲

與很多面向行存儲的關(guān)系型數據不同，HBase是面向列的存儲和權限控制的，它里面的每個(gè)列式單獨存儲額的，且支持基于列的獨立檢索。通過(guò)下圖的列子來(lái)看行存儲和列存儲的區別：

圖6 行存儲和列存儲區別

從上圖可以看到，行存儲里的一張表的數據都放在一起，但在列存儲里是按照列分開(kāi)保存的。在這種情況下，進(jìn)行數據的插入和更新，行存儲會(huì )相對容易。而進(jìn)行行存儲時(shí)，查詢(xún)操作需要讀取所有的數據，列存儲則只需要讀取相關(guān)列，可以大幅度降低系統的I/O吞吐量。

3) 稀疏性

通常在傳統的關(guān)系型數據庫中，每一列的數據類(lèi)型是事先定義好的，會(huì )占用固定的內存空間，在此情況下，屬性值為空（NULL）的列也需要占用存儲空間。

而在HBase中的數據都是以字符串形式存儲的，為空的列并不占用存儲空間，因此HBase的列存儲解決了數據稀疏的問(wèn)題，在很大程度上節省了存儲開(kāi)銷(xiāo)。所以HBase通?？梢栽O計成稀疏矩陣，同時(shí)這種方式比較接近實(shí)際的應用場(chǎng)景。

4) 擴展性強

HBase工作在HDFS之上，理所當然也支持分布式表，也繼承了HDFS的可擴展性。HBase是橫向擴展的，橫向擴展是指在擴展時(shí)不需要提升服務(wù)器本身的性能，只需要添加服務(wù)器到現有的集群即可。

HBase表根據Region的大小進(jìn)行分區，分別存儲在集群中不同的節點(diǎn)上，當添加新的節點(diǎn)時(shí)，集群就重新調整，在新的節點(diǎn)啟動(dòng)HBase服務(wù)器，動(dòng)態(tài)實(shí)現擴展。這里需要指出的是，HBase的擴展是熱擴展，即在不停止現有的服務(wù)器的前提下，可以隨時(shí)添加或減少節點(diǎn)。

5) 高可靠性

HBase運行在HDFS之上，HDFS的多副本存儲可以讓它在出現故障時(shí)自動(dòng)恢復，同時(shí)HBase內部也提供了WAL（預寫(xiě)日志文件）和Replication機制。

WAL（Write-Ahead-Log）預寫(xiě)日志是在HBase服務(wù)器處理數據插入和刪除的過(guò)程中用來(lái)記錄操作內容的日志的，保證了數據寫(xiě)入時(shí)不會(huì )因集群異常而導致寫(xiě)入數據的丟失；而Replicaiton機制是基于日志操作來(lái)做數據同步的。

當集群中的單個(gè)節點(diǎn)出現故障時(shí)，協(xié)調服務(wù)器組件ZooKeeper通知集群的主節點(diǎn)，將故障節點(diǎn)的HLog中的日志信息分發(fā)到各從節點(diǎn)進(jìn)行數據恢復。

2.4 設計目標

集群管理

集群管理方面：提供可視化的UI界面，實(shí)現集群自動(dòng)化安裝、中心化管理、集群監控、報警功能為一體的控制平臺。

平臺運行

平臺運行方面：保證低故障率、出現問(wèn)題快速修復；可提供全天候24小時(shí)不間斷服務(wù)。

讀寫(xiě)請求

讀寫(xiě)請求方面：即使在數據量急速上漲的情況下依然能夠提供低延遲、高并發(fā)的讀寫(xiě)請求。

數據遷移

數據遷移方面：保證由Oracle到HBase之間的數據遷移不影響當前業(yè)務(wù)系統使用，數據遷移準確無(wú)遺。

3.

實(shí)踐與落地

3.1 集群管理

根據我們的業(yè)務(wù)場(chǎng)景需求，我們希望能夠避免使用原生的Apache Hadoop來(lái)部署HBase，而是使用企業(yè)版大數據平臺來(lái)實(shí)現，即CDH（Cloudera Distributed Hadoop）。因為原生的Apache Hadoop和HBase都有很多未修復的Bug存在，而且實(shí)際過(guò)程中往往需要頻繁的操作命令行，不是一兩個(gè)人所能完成；而CDH解決了原生Hadoop的很多未修復問(wèn)題，升級和各個(gè)生態(tài)圈技術(shù)的兼容性，也提供了可視化UI界面來(lái)供運維人員部署其余組件，大大減少了集群的部署時(shí)間?？偟膩?lái)說(shuō)，CDH提供開(kāi)箱即用的企業(yè)使用所需的一切，換位滿(mǎn)足企業(yè)需求而構建，CDH將Hadoop與十幾個(gè)其他關(guān)鍵的開(kāi)源項目集成。

使用CM（Cloudera Manager），我們可將集群自動(dòng)化安裝、中心化管理、集群監控、報警處理等功能融為一體。集群的安裝可以從幾天的時(shí)間縮短為幾個(gè)小時(shí)，運維人員也會(huì )從數十人降低到幾個(gè)人，這更適合我們的工作所需，將繁重的運維管理工作剝離出來(lái)，將工作重心集中的業(yè)務(wù)開(kāi)發(fā)中。

圖7 CM管理控制臺

CM集群管理的四大核心功能：

管理：對集群進(jìn)行管理，如添加、刪除節點(diǎn)等操作。

1) 批量自動(dòng)化部署節點(diǎn)：CM為我們提供了強大的集群管理能力，能夠批量自動(dòng)化部署節點(diǎn)。安裝一個(gè)Hadoop集群只需要添加安裝的節點(diǎn)，安裝需要的組件和角色這三大步，大大縮短了Hadoop的安裝時(shí)間，也簡(jiǎn)化了Hadoop的安裝過(guò)程。

2) 可視化的參數配置功能：Hadoop包含許多組件，不同組件都包含各種各樣的XML配置文件，使用CM，我們就可以在GUI界面可視化配置參數。

3) 智能參數驗證及優(yōu)化：當我們的配置部分參數值有問(wèn)題時(shí)，CM會(huì )給出智能提示信息，幫助我們更合理的修改配置參數。

4) 高可用配置：使用CM，我們可以對關(guān)鍵組件進(jìn)行HA部署，如CM的Web管理控制臺可以對HDFS NameNode啟用HA功能。

5) 權限管理：根據CM的權限控制級別，我們可以配置不同的用戶(hù)，如有的用戶(hù)只有訪(fǎng)問(wèn)CM的權限，但無(wú)對服務(wù)啟停操作的權限。

監控：監控集群的健康情況，對設置的各種指標和系統運行情況進(jìn)行全面監控。

1) 服務(wù)監控：查看服務(wù)和實(shí)例級別健康檢查的結果，對設置的各種指標和系統運行情況進(jìn)行全面監控。如果任何運行情況測試是不良（Bad），則服務(wù)或者角色的狀態(tài)就是不良（Bad）。如果運行狀態(tài)存在隱患（Concering，沒(méi)有任意一項目是不良），則服務(wù)或角色的狀況就是隱患（Concerning）。而且系統會(huì )對管理員應該采取的行動(dòng)提出建議。

2) 主機監控：監控集群內所有主機的有關(guān)信息，包括主機目前消耗到內存，主機上運行的角色分配等，不但顯示所有集群主機的匯總視圖，而且能夠進(jìn)一步顯示單個(gè)主機關(guān)鍵指標詳細視圖。

3) 行為監控：根據CM提供的列表或圖表來(lái)看查看集群上進(jìn)行的活動(dòng)，不僅顯示當前正在執行的任務(wù)行為，還可以通過(guò)儀表盤(pán)查看歷史活動(dòng)。

4) 事件活動(dòng)：根據CM監控界面，我們可以查看事件，可以通過(guò)時(shí)間范圍、服務(wù)、主機、關(guān)鍵字等信息過(guò)濾事件。

5) 報警：通過(guò)配置CM可以對指定的時(shí)間產(chǎn)生警報，并通過(guò)電子郵件或者SNMP的事件得到制定的警報通知。

6) 日志和報告：輕松點(diǎn)擊一個(gè)鏈接查看相關(guān)的特定服務(wù)的日志條目，并且CM為我們生成了收集的歷史日志監控數據統計報表。

診斷：對集群出現的問(wèn)題進(jìn)行診斷，對出現的問(wèn)題給出建議方案。

1) 周期性服務(wù)診斷：CM會(huì )對集群中運行的所有服務(wù)進(jìn)行周期性的運行狀況測試，以檢測這些服務(wù)的狀態(tài)知否正常。如果有異常，就會(huì )進(jìn)行告警，有利于更早的讓我們感知集群服務(wù)存在的問(wèn)題。

2) 日志采集及檢索：對于一個(gè)大規模的集群，CM為我們提供了日志收集功能，能夠通過(guò)統一的界面查看集群中每臺及其各項服務(wù)的日志，并且能夠根據日志級別等不同的條件進(jìn)行檢索。

3) 系統性能使用報告：根據CM，我們能夠查看系統性能使用報告，包括集群的CPU使用率，單節點(diǎn)的CPU使用率，單個(gè)進(jìn)程的CPU使用率等各項性能，這對于我們調試Hadoop集群的性能是很重要的。

集成：對Hadoop的多組件進(jìn)行整合。

1) 生態(tài)圈各組件集成：企業(yè)級大數據平臺就是有這樣的好處，其集成了整個(gè)Hadoop生態(tài)圈的各項組件。根據CM控制臺，我們可以輕松的部署各項服務(wù)，各項服務(wù)都默認了最優(yōu)的配置，我們只需根據情況適當調整即可。包括ZooKeeper、HDFS、YARN、SQOOP、Flume、Kafka、Hive、HBase、Impla、Oozie、Hue、Spark等都可以實(shí)現可視化安裝，無(wú)需配置。

2) 安全配置：為了方便Hadoop大數據平臺與原有的身份認證系統如AD、LDAP等的集成，CM只需在界面上配置即可。

3) Cloudera Manager API：通過(guò)Cloudera Manager API，能夠方便的將CM集成到企業(yè)原有管理系統中。

3.2 平臺運行

存儲擴展

對于傳統的關(guān)系型數據庫來(lái)說(shuō)，當存儲空間不足時(shí)，最好的辦法就是增加磁盤(pán)，隨著(zhù)數據量不斷增長(cháng)，不可避免的會(huì )遇到性能瓶頸，因為龐大的數據量導致每次查詢(xún)尋址時(shí)間過(guò)長(cháng)，造成業(yè)務(wù)系統請求阻塞，嚴重制約了關(guān)系型數據庫的使用范圍。這種只增加存儲不增加計算能力的辦法只可解決當下的問(wèn)題，卻無(wú)法面對長(cháng)遠的隱患問(wèn)題。

對于CDH來(lái)說(shuō)，存儲擴展將變得非常容易。當存儲不夠或者計算壓力過(guò)重時(shí)，我們可以適當的增加機器來(lái)提升系統性能，只要配置正確，新節點(diǎn)能非常兼容的加入集群中。這種即增加存儲也提升計算能力的辦法無(wú)論面對多大的數據量都不會(huì )是問(wèn)題。

圖8 CDH集群擴容

CDH的集群擴容非常簡(jiǎn)單，在CDH中，我們只在待添加的節點(diǎn)中做好基礎配置（網(wǎng)絡(luò )、域名、Selinux、文件打開(kāi)的最大數量、數據盤(pán)掛載）即可，添加節點(diǎn)的操作均在CM控制臺操作。添加節點(diǎn)時(shí)，輸入IP或者域名搜索，然后選定在新添加的節點(diǎn)中要配置的服務(wù)和角色即可，其余的均有CM自動(dòng)執行。

添加服務(wù)

CM是控制臺，其集成的各項服務(wù)才是CDH的核心。在原生的Hadoop中，添加服務(wù)是一件非常繁瑣的事情。首先在管理節點(diǎn)中將要添加的服務(wù)配置好（XML）；然后分發(fā)到所有的節點(diǎn)中；最后在各個(gè)節點(diǎn)中分別啟動(dòng)；以上所有的服務(wù)均是在命令行操作。而在CDH中，CM的Web頁(yè)面提供了一鍵添加服務(wù)甚至批量添加服務(wù)功能，所有的服務(wù)均由CM做了默認的配置（XML），只需根據自身情況做調整即可。

圖9 CDH添加服務(wù)

高可用性

為保證系統24小時(shí)不間斷提供服務(wù)，我們需要針對關(guān)鍵角色做故障自動(dòng)轉移配置，即HA配置。比如HDFS NameNode、YARN ResourceManager、HBase Master等關(guān)鍵的性的角色為了避免點(diǎn)單故障，需要對這些角色額外單獨（不同節點(diǎn)上）配置一個(gè)同樣的服務(wù)（備用），當發(fā)生故障時(shí)，備用服務(wù)自動(dòng)啟動(dòng)，做到無(wú)縫切換。

圖10 HDFS NameNode高可用配置

在原生的Hadoop中，如果要做HA配置，我們要做大量的手動(dòng)操作：選擇節點(diǎn)、同步配置文件、啟用HA、同步元數據、共享元數據、全部重啟服務(wù)等。而在CDH中，我們只需在控制臺中點(diǎn)擊“啟用High Availability”，選中HA節點(diǎn)，剩余的都交由CM去執行。

負荷分擔

面對過(guò)于沉重的荷載，對于Oracle來(lái)說(shuō)，我們慣用的方法是分庫分表分區等；對于Hive表來(lái)說(shuō)，也存在著(zhù)分區分桶等方法來(lái)避免全表掃描。對于HBase來(lái)說(shuō)，為了更好的提升性能，用拆分Region的方式來(lái)提升查詢(xún)速度。

圖11 HBase的拆分Region

HBase拆分Region有別于其他數據庫，HBase表的所有數據都按照RowKey排序，并且按照RowKey拆分Region，每個(gè)Region中包含一定范圍的數據（Start Key – End Key），每個(gè)Region中的數據又按照RowKey排序。

高可靠性

為保證系統的可靠性，我們配置冗余的數據備份，不同備份將不同磁盤(pán)、不同節點(diǎn)、不同機架分別存放。這樣部分節點(diǎn)宕機，或者某個(gè)磁盤(pán)損壞，甚至某臺節點(diǎn)宕機導致部分備份丟失，我們都不必當心數據安全問(wèn)題。此外，按照HDFS的Heart Beat機制，系統還會(huì )監控數據備份，一旦有備份丟失，系統將會(huì )自動(dòng)復制新的一份到其余節點(diǎn)中。

圖12 HDFS的數據備份策略

在CDH中，數據備份策略在CM控制臺中即可配置，無(wú)需在命令行去操作。

低故障率

對于Hadoop來(lái)說(shuō)，硬件故障是常態(tài)，為了避免硬件故障導致系統出現奔潰的情況，我們需要在內存、磁盤(pán)等方面做一些調整：

內存：在Hadoop中有些角色是需要內存資源用來(lái)存儲關(guān)鍵信息的，如HDFS NameNode元數據、HBase BlockCache等；因此給這些角色適當增加內存是有助于提升系統性能的。

磁盤(pán)：系統盤(pán)和數據盤(pán)獨立創(chuàng )建，系統盤(pán)做冗余磁盤(pán)陣列RAID1。

3.3 讀寫(xiě)請求

根據業(yè)務(wù)場(chǎng)景，我們所有的業(yè)務(wù)數據（結構化和非結構化）都存儲在HBase中，因此對CDH的讀寫(xiě)請求更主要針對HBase的讀寫(xiě)請求。提升HBase的讀寫(xiě)請求效率是電子檔案系統最核心的需求，因此HBase的優(yōu)化工作是我們工作的重中之重。適當調高HBase內存、調整垃圾回收策略、更改默認的Region大小、選擇合適的小文件合并時(shí)機和拆分Region時(shí)機、啟用Snappy壓縮、預創(chuàng )建Region、避免Region熱點(diǎn)等等都可以提高HBase的存取速度。

調整HBase內存

這里首先涉及HBase服務(wù)的堆內存設置。一般剛部署的HBase集群，默認配置只給Master和RegionServer分配了1G的內存，RegionServer中MemStore默認占40%即400M左右的空間，而一個(gè)MemStore刷寫(xiě)閾值默認為128M，所以一個(gè)RegionServer也就能正常管理3個(gè)Region，多了就可能產(chǎn)生小文件了，另外也容易發(fā)生Full GC。因此建議合理調整Master和RegionServer的內存，比如：

其次要考慮開(kāi)啟BlockCache，首先，BlockCache是RegionServer級別的，一個(gè)RegionServer只有一個(gè)BlockCache。BlockCache的工作原理是讀請求會(huì )首先檢查Block是否存在于BlockCache，存在就直接返回，如果不存在再去HFile和MemStore中獲取，返回數據時(shí)把Block緩存到BlockCache中，后續同一請求或臨近查詢(xún)可以直接從BlockCache中讀取，避免過(guò)多昂貴的IO操作。

調整垃圾回收策略

1) G1收集器VS CMS收集器

CMS收集器在物理上區分年輕代和年老代空間。G1收集器會(huì )將heap分成很多region，然后在邏輯區分年輕代和年老代空間。G1收集器主要用于控制垃圾回收的時(shí)間。對于HBase使用場(chǎng)景，大部分年老代的對象是memsotre或者blockcache。對比測試發(fā)現，CMS收集器有更好的表現。

2) CMS配置調優(yōu)

設置較大的heap size。使用CMSInitiatingOccupancyFraction=70，值為70為JVM的使用百分比，當達到這個(gè)閾值后將啟動(dòng)回收任務(wù)，這個(gè)值比較適合的值是要略大約memstore 40%+blockcache 20%。如果CMSInitiatingOccupancyFraction這個(gè)值小于60會(huì )導致GC報警。

3) 新生代收集器UseParNewGC

使用UseParNewGC收集器，并加大新生代空間大小占heap size 25%，因為memstore（40%）+blockcache（20%）占總heap（60%），這兩部分空間會(huì )被存放在年老年空間。所以新生代空間不應該大小1-60%，讓更多的GC發(fā)生在新生代，UseParNewGC可以并行收集，收集成本低。

4) TargetSurvivorRatio設置

TargetSurvivorRatio=90設置Survivor區的可使用率。這里設置為90%，則允許90%的Survivor空間被使用。默認值為50%，故該值設置提高了Survivor區的使用率。但存放的對象超過(guò)這個(gè)百分比，則對象會(huì )向年老代壓縮。因此，這個(gè)選項更有助于將對象留在年老代。

選擇合適的Region數量

通常較少的region數量可使群集運行的更加平穩，官方指出每個(gè)RegionServer大約100個(gè)regions的時(shí)候效果最好，理由如下：

1) HBase的一個(gè)特性MSLAB，它有助于防止堆內存的碎片化，減輕垃圾回收Full GC的問(wèn)題，默認是開(kāi)啟的。但是每個(gè)MemStore需要2MB（一個(gè)列簇對應一個(gè)寫(xiě)緩存memstore）。所以如果每個(gè)region有2個(gè)family列簇，總有1000個(gè)region，就算不存儲數據也要3.95G內存空間。

2) 如果很多region，它們中Memstore也過(guò)多，內存大小觸發(fā)Region Server級別限制導致flush，就會(huì )對用戶(hù)請求產(chǎn)生較大的影響，可能阻塞該Region Server上的更新操作。

3) HMaster要花大量的時(shí)間來(lái)分配和移動(dòng)Region，且過(guò)多Region會(huì )增加ZooKeeper的負擔。

4) 從HBase讀入數據進(jìn)行處理的mapreduce程序，過(guò)多Region會(huì )產(chǎn)生太多Map任務(wù)數量，默認情況下由涉及的region數量決定。

所以，如果一個(gè)HRegion中Memstore過(guò)多，而且大部分都頻繁寫(xiě)入數據，每次flush的開(kāi)銷(xiāo)必然會(huì )很大，因此我們也建議在進(jìn)行表設計的時(shí)候盡量減少ColumnFamily的個(gè)數。每個(gè)region都有自己的MemStore，當大小達到了上限(hbase.hregion.memstore.flush.size，默認128MB)，會(huì )觸發(fā)Memstore刷新。

計算集群region數量的公式：((RS Xmx) * hbase.regionserver.global.memstore.size) / (hbase.hregion.memstore.flush.size * (# column families))

假設一個(gè)RS有16GB內存，那么16384*0.4/128m 等于51個(gè)活躍的region。

如果寫(xiě)很重的場(chǎng)景下，可以適當調高hbase.regionserver.global.memstore.size，這樣可以容納更多的region數量。

建議分配合理的region數量，根據寫(xiě)請求量的情況，一般20-200個(gè)之間，可以提高集群穩定性，排除很多不確定的因素，提升讀寫(xiě)性能。監控Region Server中所有Memstore的大小總和是否達到了上限(hbase.regionserver.global.memstore.upperLimit ＊ hbase_heapsize，默認 40%的JVM內存使用量)，超過(guò)可能會(huì )導致不良后果，如服務(wù)器反應遲鈍或compact風(fēng)暴。

更改默認的Region大小

HBase中數據一開(kāi)始會(huì )寫(xiě)入memstore，滿(mǎn)128MB（看配置）以后，會(huì )flush到disk上而成為storefile。當storefile數量超過(guò)觸發(fā)因子時(shí)（可配置），會(huì )啟動(dòng)compaction過(guò)程將它們合并為一個(gè)storefile。對集群的性能有一定影響。而當合并后的storefile大于max.filesize，會(huì )觸發(fā)分割動(dòng)作，將它切分成兩個(gè)region。

1) 當hbase.hregion.max.filesize比較小時(shí)，觸發(fā)split的機率更大，系統的整體訪(fǎng)問(wèn)服務(wù)會(huì )出現不穩定現象。

2) 當hbase.hregion.max.filesize比較大時(shí)，由于長(cháng)期得不到split，因此同一個(gè)region內發(fā)生多次compaction的機會(huì )增加了。這樣會(huì )降低系統的性能、穩定性，因此平均吞吐量會(huì )受到一些影響而下降。

3) hbase.hregion.max.filesize不宜過(guò)大或過(guò)小，經(jīng)過(guò)實(shí)戰，生產(chǎn)高并發(fā)運行下，最佳大小5-10GB！關(guān)閉某些重要場(chǎng)景的HBase表的major_compact！在非高峰期的時(shí)候再去調用major_compact，這樣可以減少split的同時(shí)，顯著(zhù)提供集群的性能，吞吐量、非常有用。

HFile文件是否太多

文件越多，檢索所需的IO次數必然越多，讀取延遲也就越高。文件數量通常取決于Compaction的執行策略，一般和兩個(gè)參數有關(guān)：

hbase.hstore.compactionThreshold和hbase.hstore.compaction.max.size，前者表示一個(gè)store中的文件數超過(guò)多少個(gè)就應該合并，后者表示參數合并的文件大小最大是多少，超過(guò)此大小的文件不能參與合并。

hbase.hstore.compactionThreshold設置不能太大，默認是3個(gè)；設置需要根據Region的大小，通?？梢哉J為是

hbase.hstore.compaction.max.size=RegionSize/hbase.hstore.compactionThreshold。

選擇合適的小文件合并策略

Compaction是將小文件合并為大文件，提高后續業(yè)務(wù)隨機讀性能，但是也會(huì )帶來(lái)IO放大以及帶寬消耗問(wèn)題，問(wèn)題主要產(chǎn)生于配置不合理導致Minor Compaction太過(guò)頻繁，或者Region設置太大情況下發(fā)生Major Compaction。

觀(guān)察系統IO資源以及帶寬資源使用情況，再觀(guān)察Compaction隊列長(cháng)度，確認是否由于Compaction導致系統資源消耗過(guò)多。

Minor Compaction設置：hbase.hstore.compactionThreshold設置不能太大，也不能太小，因此建議設置為5~6；

hbase.hstore.compaction.max.size=RegionSzie/hbase.hstore.compactionThreshold。

Major Compaction設置：大Region讀延遲敏感業(yè)務(wù)（100G以上）通常不建議開(kāi)啟自動(dòng)Major Compaction，手動(dòng)低峰觸發(fā)。小Region或延遲不敏感業(yè)務(wù)也可以開(kāi)啟自動(dòng)Major Compaction，但建議限制流量。

Region拆分策略

Region為什么要拆分？隨著(zhù)數據的增加，一個(gè)Region管理的數據條數越來(lái)越多，出現傳統SQL數據庫的單節點(diǎn)并發(fā)問(wèn)題，將Region拆分，將Region移動(dòng)均衡到其他節點(diǎn)。

Region拆分有三種方式：預拆分、自動(dòng)拆分、手動(dòng)強制拆分

1) 預拆分：指定每個(gè)預拆分的Region的RowKey的開(kāi)始值

create 'test_table', 'table_spilt_test1', SPLITS=> ['1001', '2001', '3001']

2) 自動(dòng)拆分

Region的默認大小問(wèn)10G，超過(guò)10G就自動(dòng)拆分，Region大小通過(guò)下面這個(gè)參數控制，生產(chǎn)環(huán)境如果預分區后，每個(gè)Region數據都比較大可改成20G 30G：

hbase.hregion.max.filesize

3) 強制拆分

可在HBase shell根據提示，對某個(gè)Region進(jìn)行強制拆分：

也可以調用HBase JAVA API來(lái)操作。

啟用Snappy壓縮

啟用壓縮可以大大提高集群的可用性，scan性能顯著(zhù)提升。目前HBase默認支持的壓縮包括GZ、LZO以及Snappy，測試對比之后選擇Snappy壓縮算法。

表3 不同壓縮算法測試性能比較

create ‘test’,{NAME => ‘info’,VERSIONS => 1,COMPRESSION => ‘snappy’}

預創(chuàng )建Region

HBase中的預分區就是在創(chuàng )建表之前，指定好RowKey在哪個(gè)范圍的數據會(huì )落到哪個(gè)分區中，因為HBase會(huì )按照字典順序把RowKey進(jìn)行排序。預分區的好處是一方面可以提高讀寫(xiě)效率，二是防止數據傾斜，起到負載均衡的作用。

創(chuàng )建表格時(shí)指定分區邊界：

create ‘staff’,’info’,’partition’,SPLITS = > [‘1000’,’2000’,’3000’,’4000’]

使用16進(jìn)制算法生成預分區

ceate ‘staff’,’info’,’partiton’,{COLUMNS = > 15,SPLITALGO => ‘’HexStringSplit’}

避免Region熱點(diǎn)

檢索HBase的記錄首先要通過(guò)RowKey來(lái)定位數據，當大量的Client方位HBase集群的一個(gè)或者幾個(gè)Region，會(huì )造成少數RegionServer的讀寫(xiě)請求過(guò)多、負載過(guò)大，而其他RegionServer負載卻很小，就造成了“熱點(diǎn)”現象。

常見(jiàn)的避免熱點(diǎn)的方法：

1) 加鹽：這里的加鹽不是密碼學(xué)中的加鹽，而是在RowKey的前面增加隨機數，具體就是給RowKey分配一個(gè)隨機前綴使得它和之前的RowKey的開(kāi)頭不同。給多少個(gè)前綴，這個(gè)數量應該和我們要分散數據到不同的Region數量一致。

2) 哈希：哈希會(huì )使同一行永遠用一個(gè)前綴加鹽。哈希也可以使負載分散到整個(gè)集群，但是讀卻是可以預測的。使用確定的哈?？梢宰尶蛻?hù)端重構完整的RowKey，可以使用get操作準確獲取某一個(gè)行數據。

3) 反轉：反轉固定長(cháng)度或者數字格式的RowKey。這樣可以使得RowKey中經(jīng)常改變的部分（最沒(méi)有意義的部分）放在

前面。這樣可以有效的隨機RowKey，但是犧牲了RowKey的有序性。

4) RowKey唯一原則：必須在設計上保證其唯一性，RowKey是按照二進(jìn)制字節數據排序存儲的，因此設計RowKey的時(shí)候，要充分利用這個(gè)排序的特點(diǎn)，經(jīng)常讀的數據存儲的一起，將最近可能會(huì )被訪(fǎng)問(wèn)的數據放到一塊。

5) RowKey長(cháng)度原則：RowKey是一個(gè)二進(jìn)制碼流，可以是任意字符串，最大長(cháng)度64kb，實(shí)際應用中一般為10-100byte，以byte[]形式保存，一般設計成定長(cháng)度，建議越短越好，不要超過(guò)16個(gè)字節（因為RowKey是要加載到內存中的）。

6) RowKey散列原則：如果RowKey按照時(shí)間戳的方式遞增，不要將時(shí)間放到二進(jìn)制碼的前面，建議將RowKey高位作為三列字段，由程序隨機生成，低位放時(shí)間字段，這樣將提高數據均衡分布在每個(gè)Region上，以實(shí)現負載均衡的幾率。

Swap的設置

推薦設置為0，這樣只有在物理內存不夠的情況下才會(huì )使用交換分區。這個(gè)參數由于JVM虛擬機如果使用了Swap在GC回收時(shí)會(huì )花費更多到時(shí)間。

3.4 數據遷移

SQOOP數據導入

使用SQOOP執行數據遷移的目的是需要將Oracle中的結構化數據（ID）遷移到Hive中，然后在Hive中計算要預分Region的RowKey值：

預分Region的RowKey（start key和end key）計算

##創(chuàng )建臨時(shí)表并分區分桶，目的是為了更快的計算

MR接口編程

Oracle到HBase表之間的數據轉移以MapReduce分布式計算框架執行：

1) Mapper：

2) Reduce：

3) 主程序入口：

4.

質(zhì)變與總結

在數據存儲方面：電子檔案系統不用再承受Oracle頻繁增加磁盤(pán)和數據量猛增的情況下帶來(lái)的痛苦，即使再大的數據量，對于分布式集群來(lái)說(shuō)，都是添加節點(diǎn)的事情。即使在廉價(jià)的商用機器上，大數據平臺都能得到很好的部署，讓數據存儲不再是個(gè)問(wèn)題。

在讀寫(xiě)速度方面：因為HBase的特性，返回同樣的數據HBase比Oracle有著(zhù)更低的延遲、更高的效率。

在運行狀態(tài)方面：因為分布式集群不存在單點(diǎn)故障問(wèn)題，系統穩定方面有了很大的保證，可確保24小時(shí)不間斷提供服務(wù)。

在用戶(hù)體驗方面：隨著(zhù)請求速度的提升，用戶(hù)不用再長(cháng)時(shí)間的等待數據庫請求結果，極大的提高了用戶(hù)工作效率。