基于大數(shù)據(jù)平臺(tái)的
億級(jí)別非結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)實(shí)現(xiàn)
神州信息
趙軍
1.
項(xiàng)目背景
本次建設(shè)基于某政府單位的電子檔案系統(tǒng)，整體數(shù)據(jù)存儲(chǔ)量為240TB左右，使用Oracle存儲(chǔ)，并且按每年30%比例持續(xù)增長(zhǎng)，隨業(yè)務(wù)發(fā)展，預(yù)計(jì)未來5年內(nèi)將達(dá)到1PB左右的數(shù)據(jù)量。當(dāng)存儲(chǔ)的數(shù)據(jù)量過大時(shí)，Oracle數(shù)據(jù)庫(kù)將面臨需要更大的存儲(chǔ)空間，大數(shù)據(jù)量的導(dǎo)入導(dǎo)出將導(dǎo)致數(shù)據(jù)庫(kù)無法高效、穩(wěn)定的運(yùn)行；同時(shí)所需要的全備份周期會(huì)逐漸延長(zhǎng)，會(huì)影響到工作時(shí)間內(nèi)業(yè)務(wù)運(yùn)行；存儲(chǔ)資源需求過大，整個(gè)災(zāi)備系統(tǒng)的存儲(chǔ)資源也會(huì)投入過大。
目前電子檔案數(shù)據(jù)庫(kù)數(shù)據(jù)
表1電子檔案主要表情況（截止到2021年底）
存儲(chǔ)空間嚴(yán)重不足
電子檔案數(shù)據(jù)庫(kù)總存儲(chǔ)量為240TB左右，按照現(xiàn)在的增長(zhǎng)速度呈指數(shù)級(jí)上升，5年內(nèi)將達(dá)到1PB左右的數(shù)據(jù)量，Oracle數(shù)據(jù)庫(kù)將需要更大的存儲(chǔ)空間。從資金層面考慮數(shù)據(jù)庫(kù) SAN 上的磁盤存儲(chǔ)通常比 Web 服務(wù)器場(chǎng)中使用的磁盤上的存儲(chǔ)更為昂貴。
數(shù)據(jù)存取方式落伍
原架構(gòu)對(duì)于電子檔案數(shù)據(jù)采用直接通過服務(wù)器端程序?qū)⑿枰鎯?chǔ)的文件轉(zhuǎn)為二進(jìn)制文件流直接存在數(shù)據(jù)庫(kù)表的BLOB字段中，當(dāng)需要查詢時(shí)同樣也是服務(wù)器端將文件以流的方式查詢出來，經(jīng)過處理后以二進(jìn)制流的方式發(fā)送給客戶端顯示出來。
此種方法從項(xiàng)目的角度上來說，文件存儲(chǔ)和數(shù)據(jù)庫(kù)存儲(chǔ)最好是要分離的，二進(jìn)制的存儲(chǔ)方式特別是針對(duì)存儲(chǔ)文件大而多的情況，因?yàn)樾阅茌^差，且大量占用數(shù)據(jù)庫(kù)內(nèi)存，已經(jīng)逐步淘汰。
計(jì)算壓力不堪重負(fù)
原電子檔案數(shù)據(jù)存儲(chǔ)在Oracle數(shù)據(jù)庫(kù)中，查詢條件單一，已不能滿足電子檔案業(yè)務(wù)的管理需求。隨著數(shù)據(jù)量的上漲，服務(wù)器計(jì)算壓力也逐漸不堪重負(fù)。對(duì)電子檔案庫(kù)的查詢操作在原系統(tǒng)中發(fā)生非常頻繁，在工作日繁忙階段可產(chǎn)生高并發(fā)的情況，按目前通過文件二進(jìn)制流的查詢方式，查詢效率已經(jīng)不甚樂觀，隨著數(shù)據(jù)量的不斷加大，如果繼續(xù)按目前的查詢方式來看查詢效率會(huì)不斷的下降，直接影響到日常業(yè)務(wù)，降低工作效率。
安全運(yùn)行無法保障
大數(shù)據(jù)量的導(dǎo)入導(dǎo)出將導(dǎo)致數(shù)據(jù)庫(kù)無法高效、穩(wěn)定的運(yùn)行。加之?dāng)?shù)據(jù)庫(kù)單點(diǎn)故障、磁盤損壞等情況更會(huì)加劇數(shù)據(jù)庫(kù)走向奔潰。
全量備份周期延長(zhǎng)
隨著數(shù)據(jù)量的增長(zhǎng)，所需要的全備份周期會(huì)逐漸延長(zhǎng)，會(huì)影響到工作時(shí)間內(nèi)業(yè)務(wù)運(yùn)行；存儲(chǔ)資源需求過大，整個(gè)災(zāi)備系統(tǒng)的存儲(chǔ)資源也會(huì)投入過大。
2.
想法與設(shè)計(jì)
2.1 方案選擇
為解決電子檔案系統(tǒng)存儲(chǔ)空間不足、運(yùn)行狀態(tài)不穩(wěn)定、計(jì)算負(fù)荷過重、備份效率低下的問題，我們迫切需要改變現(xiàn)有的電子檔案集中式存儲(chǔ)架構(gòu)。集中式存儲(chǔ)服務(wù)器使用本地磁盤存放所有數(shù)據(jù)，增加磁盤是解決存儲(chǔ)空間唯一的辦法，計(jì)算能力無法提升，系統(tǒng)安全性和可靠性也無法得到保證，不能滿足大規(guī)模存儲(chǔ)應(yīng)用的需求。而當(dāng)前的電子檔案系統(tǒng)就是采用了這種架構(gòu)模式。
表2 集中式存儲(chǔ)架構(gòu)和分布式存儲(chǔ)架構(gòu)特性比較
圖1 集中式存儲(chǔ)架構(gòu)和分布式存儲(chǔ)架構(gòu)比較
因此我們將采用分布式存儲(chǔ)架構(gòu)替換原有的集中式存儲(chǔ)系統(tǒng)，分布式存儲(chǔ)系統(tǒng)采用可擴(kuò)展的系統(tǒng)結(jié)構(gòu)，利用多臺(tái)存儲(chǔ)服務(wù)器分擔(dān)存儲(chǔ)負(fù)荷，利用位置服務(wù)器定位存儲(chǔ)信息，它提高了系統(tǒng)的可靠性、可用性和存取效率，還易于擴(kuò)展。分布式存儲(chǔ)架構(gòu)的種種特性，都能夠完美的解決我們當(dāng)下所面臨的問題。
2.2 問題解決
存儲(chǔ)空間嚴(yán)重不足
分布式存儲(chǔ)不再需要昂貴的磁盤陣列來解決存儲(chǔ)問題，廉價(jià)的商用機(jī)器都能擴(kuò)展器存儲(chǔ)能力。
分布式存儲(chǔ)系統(tǒng)通過對(duì)集群服務(wù)器規(guī)模進(jìn)行進(jìn)行擴(kuò)展，從而使系統(tǒng)存儲(chǔ)容量、計(jì)算和性能得到提高。隨著業(yè)務(wù)量的增大，對(duì)底層分布式存儲(chǔ)系統(tǒng)的性能要求也隨之增高。衡量可擴(kuò)展性的要求集群具有線性的可擴(kuò)展性，系統(tǒng)整體性能和服務(wù)數(shù)量是線性關(guān)系。分布式存儲(chǔ)有著合理的分布式架構(gòu)，能夠預(yù)估并且彈性擴(kuò)展計(jì)算、存儲(chǔ)容量和性能。
計(jì)算壓力不堪重負(fù)
分布式存儲(chǔ)的去中心化思想，讓各個(gè)節(jié)點(diǎn)都能分擔(dān)計(jì)算壓力，計(jì)算能力隨著節(jié)點(diǎn)的擴(kuò)展而提升。
系統(tǒng)的吞吐量和系統(tǒng)的響應(yīng)延遲這兩項(xiàng)指標(biāo)，經(jīng)常被用來衡量分布式存儲(chǔ)系統(tǒng)的性能。通常高性能的分布式存儲(chǔ)，能夠高效的管理讀緩存和寫緩存，并且能夠自動(dòng)分級(jí)存儲(chǔ)。分布式存儲(chǔ)是通過把熱點(diǎn)區(qū)域內(nèi)數(shù)據(jù)映射到高速緩存中，以此來提高系統(tǒng)響應(yīng)的速度；如果這些區(qū)域不再是熱點(diǎn)，那么存儲(chǔ)系統(tǒng)就會(huì)將它們從高速緩存中剔除。而寫緩存技術(shù)則是配合高速存儲(chǔ)，來使得整體存儲(chǔ)的性能有顯著提高，按一定的策略，先將數(shù)據(jù)寫入高速存儲(chǔ)，再在適當(dāng)?shù)臅r(shí)間進(jìn)行同步落盤。
安全運(yùn)行無法保障
不用再擔(dān)心單點(diǎn)故障的問題，數(shù)據(jù)多副本分散存儲(chǔ)，即使多個(gè)節(jié)點(diǎn)宕機(jī)，系統(tǒng)依然能對(duì)外提供服務(wù)。
使用網(wǎng)絡(luò)進(jìn)行松耦合連接，分布式存儲(chǔ)能夠允許高速存儲(chǔ)和低速存儲(chǔ)分開部署，或者以任意比例混布，在業(yè)務(wù)環(huán)境不可預(yù)測(cè)，或者用于敏捷的情況下，將分層存儲(chǔ)的技術(shù)優(yōu)勢(shì)發(fā)揮到最佳。而且分布式存儲(chǔ)系統(tǒng)不受惡意訪問和攻擊，能夠保護(hù)存儲(chǔ)數(shù)據(jù)不被竊取。
全量備份周期延長(zhǎng)
系統(tǒng)默認(rèn)的多副本、多節(jié)點(diǎn)放置策略，無需再考慮數(shù)據(jù)備份的問題，從而節(jié)省昂貴的異地容災(zāi)備份。
分布式系統(tǒng)數(shù)據(jù)安全方面的容災(zāi)與備份，數(shù)據(jù)可靠不丟失。在分布式存儲(chǔ)的容災(zāi)中，一個(gè)重要的手段就是多時(shí)間點(diǎn)快照技術(shù)，這樣用戶生產(chǎn)系統(tǒng)可以實(shí)現(xiàn)在一定時(shí)間間隔內(nèi)對(duì)各版本數(shù)據(jù)的保存。而且，多時(shí)間點(diǎn)快照技術(shù)，能夠支持同時(shí)提取多個(gè)時(shí)間點(diǎn)的樣本，并且同時(shí)進(jìn)行恢復(fù)。這一功能對(duì)于故障重現(xiàn)也很有幫助，可幫助進(jìn)行分析和研究，避免類似災(zāi)難的再次發(fā)生。多時(shí)間點(diǎn)快照，周期增量復(fù)制等技術(shù)為分布式存儲(chǔ)的高可靠性提供了保障。
2.3 產(chǎn)品選型
考慮到實(shí)際場(chǎng)景的需要，我們的目標(biāo)是要建立一套全新的分布式存儲(chǔ)系統(tǒng)，既能滿足數(shù)據(jù)存儲(chǔ)的需要，也能提供快速高效的數(shù)據(jù)請(qǐng)求服務(wù)，并盡可能的避免對(duì)現(xiàn)有的業(yè)務(wù)審查系統(tǒng)造成影響。在我們產(chǎn)品選型方案中，F(xiàn)astDFS、MinIO、HDFS、HBase是我們根據(jù)場(chǎng)景需要進(jìn)行篩選比對(duì)之后，選擇最佳的一種。
FastDFS
圖2 FastDFS架構(gòu)圖
雖說能能解決海量非結(jié)構(gòu)化數(shù)據(jù)（PDF）的存儲(chǔ)問題，但是需要額外的關(guān)系型數(shù)據(jù)來存放PDF的關(guān)鍵信息（文件名稱、大小、在FastDFS中的位置等），也不能很好的使用內(nèi)存提高讀寫效率。
MinIO
圖3 MinIO架構(gòu)圖
MinIO對(duì)象存儲(chǔ)系統(tǒng)是為海量數(shù)據(jù)存儲(chǔ)、人工智能、大數(shù)據(jù)分析而設(shè)計(jì)，適合存儲(chǔ)海量圖片、視頻、日志文件、備份數(shù)據(jù)等，同樣的，關(guān)鍵信息也需要額外的關(guān)系型數(shù)據(jù)庫(kù)控制。
HDFS
圖4 HDFS架構(gòu)圖
HDFS是指被設(shè)計(jì)成適合運(yùn)行在通用硬件上的分布式文件系統(tǒng)，但其關(guān)鍵信息也需要額外的關(guān)系型數(shù)據(jù)庫(kù)控制，再者它不適合低延遲的數(shù)據(jù)訪問，不支持并發(fā)寫入和文件隨機(jī)修改，這不是我們想要的。
HBase
圖5 HBase架構(gòu)圖
HBase特別適合于非結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)，關(guān)鍵信息與PDF一并存儲(chǔ)，不需額外的關(guān)系型數(shù)據(jù)庫(kù)。充分使用內(nèi)存資源，從而能夠?qū)ν馓峁┑脱訒r(shí)、高并發(fā)的讀寫請(qǐng)求服務(wù)，這最適合我們的業(yè)務(wù)需求。
按照HBase設(shè)計(jì)特性，有如下優(yōu)勢(shì)是我們業(yè)務(wù)場(chǎng)景迫切需要的：
1) 容量巨大
HBase的單表可以有百億行、百萬列，可以在橫向和縱向兩個(gè)維度插入數(shù)據(jù)，具有很大的彈性。
當(dāng)關(guān)系型數(shù)據(jù)庫(kù)的單表記錄在億級(jí)別時(shí)，查詢和寫入的性能都會(huì)呈現(xiàn)指數(shù)級(jí)下降，這種龐大的數(shù)量對(duì)傳統(tǒng)數(shù)據(jù)庫(kù)來說是一種災(zāi)難，而HBase在限定某個(gè)列的情況下對(duì)于單表存儲(chǔ)百億甚至更多的數(shù)據(jù)都沒有性能問題。
HBase采用LSM樹作為內(nèi)部數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)，這種結(jié)構(gòu)會(huì)周期性的將小文件合并為大文件，以減少對(duì)磁盤的尋址時(shí)間。
2) 列存儲(chǔ)
與很多面向行存儲(chǔ)的關(guān)系型數(shù)據(jù)不同，HBase是面向列的存儲(chǔ)和權(quán)限控制的，它里面的每個(gè)列式單獨(dú)存儲(chǔ)額的，且支持基于列的獨(dú)立檢索。通過下圖的列子來看行存儲(chǔ)和列存儲(chǔ)的區(qū)別：
圖6 行存儲(chǔ)和列存儲(chǔ)區(qū)別
從上圖可以看到，行存儲(chǔ)里的一張表的數(shù)據(jù)都放在一起，但在列存儲(chǔ)里是按照列分開保存的。在這種情況下，進(jìn)行數(shù)據(jù)的插入和更新，行存儲(chǔ)會(huì)相對(duì)容易。而進(jìn)行行存儲(chǔ)時(shí)，查詢操作需要讀取所有的數(shù)據(jù)，列存儲(chǔ)則只需要讀取相關(guān)列，可以大幅度降低系統(tǒng)的I/O吞吐量。
3) 稀疏性
通常在傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)中，每一列的數(shù)據(jù)類型是事先定義好的，會(huì)占用固定的內(nèi)存空間，在此情況下，屬性值為空（NULL）的列也需要占用存儲(chǔ)空間。
而在HBase中的數(shù)據(jù)都是以字符串形式存儲(chǔ)的，為空的列并不占用存儲(chǔ)空間，因此HBase的列存儲(chǔ)解決了數(shù)據(jù)稀疏的問題，在很大程度上節(jié)省了存儲(chǔ)開銷。所以HBase通?？梢栽O(shè)計(jì)成稀疏矩陣，同時(shí)這種方式比較接近實(shí)際的應(yīng)用場(chǎng)景。
4) 擴(kuò)展性強(qiáng)
HBase工作在HDFS之上，理所當(dāng)然也支持分布式表，也繼承了HDFS的可擴(kuò)展性。HBase是橫向擴(kuò)展的，橫向擴(kuò)展是指在擴(kuò)展時(shí)不需要提升服務(wù)器本身的性能，只需要添加服務(wù)器到現(xiàn)有的集群即可。
HBase表根據(jù)Region的大小進(jìn)行分區(qū)，分別存儲(chǔ)在集群中不同的節(jié)點(diǎn)上，當(dāng)添加新的節(jié)點(diǎn)時(shí)，集群就重新調(diào)整，在新的節(jié)點(diǎn)啟動(dòng)HBase服務(wù)器，動(dòng)態(tài)實(shí)現(xiàn)擴(kuò)展。這里需要指出的是，HBase的擴(kuò)展是熱擴(kuò)展，即在不停止現(xiàn)有的服務(wù)器的前提下，可以隨時(shí)添加或減少節(jié)點(diǎn)。
5) 高可靠性
HBase運(yùn)行在HDFS之上，HDFS的多副本存儲(chǔ)可以讓它在出現(xiàn)故障時(shí)自動(dòng)恢復(fù)，同時(shí)HBase內(nèi)部也提供了WAL（預(yù)寫日志文件）和Replication機(jī)制。
WAL（Write-Ahead-Log）預(yù)寫日志是在HBase服務(wù)器處理數(shù)據(jù)插入和刪除的過程中用來記錄操作內(nèi)容的日志的，保證了數(shù)據(jù)寫入時(shí)不會(huì)因集群異常而導(dǎo)致寫入數(shù)據(jù)的丟失；而Replicaiton機(jī)制是基于日志操作來做數(shù)據(jù)同步的。
當(dāng)集群中的單個(gè)節(jié)點(diǎn)出現(xiàn)故障時(shí)，協(xié)調(diào)服務(wù)器組件ZooKeeper通知集群的主節(jié)點(diǎn)，將故障節(jié)點(diǎn)的HLog中的日志信息分發(fā)到各從節(jié)點(diǎn)進(jìn)行數(shù)據(jù)恢復(fù)。
2.4 設(shè)計(jì)目標(biāo)
集群管理
集群管理方面：提供可視化的UI界面，實(shí)現(xiàn)集群自動(dòng)化安裝、中心化管理、集群監(jiān)控、報(bào)警功能為一體的控制平臺(tái)。
平臺(tái)運(yùn)行
平臺(tái)運(yùn)行方面：保證低故障率、出現(xiàn)問題快速修復(fù)；可提供全天候24小時(shí)不間斷服務(wù)。
讀寫請(qǐng)求
讀寫請(qǐng)求方面：即使在數(shù)據(jù)量急速上漲的情況下依然能夠提供低延遲、高并發(fā)的讀寫請(qǐng)求。
數(shù)據(jù)遷移
數(shù)據(jù)遷移方面：保證由Oracle到HBase之間的數(shù)據(jù)遷移不影響當(dāng)前業(yè)務(wù)系統(tǒng)使用，數(shù)據(jù)遷移準(zhǔn)確無遺。
3.
實(shí)踐與落地
3.1 集群管理
根據(jù)我們的業(yè)務(wù)場(chǎng)景需求，我們希望能夠避免使用原生的Apache Hadoop來部署HBase，而是使用企業(yè)版大數(shù)據(jù)平臺(tái)來實(shí)現(xiàn)，即CDH（Cloudera Distributed Hadoop）。因?yàn)樵腁pache Hadoop和HBase都有很多未修復(fù)的Bug存在，而且實(shí)際過程中往往需要頻繁的操作命令行，不是一兩個(gè)人所能完成；而CDH解決了原生Hadoop的很多未修復(fù)問題，升級(jí)和各個(gè)生態(tài)圈技術(shù)的兼容性，也提供了可視化UI界面來供運(yùn)維人員部署其余組件，大大減少了集群的部署時(shí)間?？偟膩碚f，CDH提供開箱即用的企業(yè)使用所需的一切，換位滿足企業(yè)需求而構(gòu)建，CDH將Hadoop與十幾個(gè)其他關(guān)鍵的開源項(xiàng)目集成。
使用CM（Cloudera Manager），我們可將集群自動(dòng)化安裝、中心化管理、集群監(jiān)控、報(bào)警處理等功能融為一體。集群的安裝可以從幾天的時(shí)間縮短為幾個(gè)小時(shí)，運(yùn)維人員也會(huì)從數(shù)十人降低到幾個(gè)人，這更適合我們的工作所需，將繁重的運(yùn)維管理工作剝離出來，將工作重心集中的業(yè)務(wù)開發(fā)中。
圖7 CM管理控制臺(tái)
CM集群管理的四大核心功能：
管理：對(duì)集群進(jìn)行管理，如添加、刪除節(jié)點(diǎn)等操作。
1) 批量自動(dòng)化部署節(jié)點(diǎn)：CM為我們提供了強(qiáng)大的集群管理能力，能夠批量自動(dòng)化部署節(jié)點(diǎn)。安裝一個(gè)Hadoop集群只需要添加安裝的節(jié)點(diǎn)，安裝需要的組件和角色這三大步，大大縮短了Hadoop的安裝時(shí)間，也簡(jiǎn)化了Hadoop的安裝過程。
2) 可視化的參數(shù)配置功能：Hadoop包含許多組件，不同組件都包含各種各樣的XML配置文件，使用CM，我們就可以在GUI界面可視化配置參數(shù)。
3) 智能參數(shù)驗(yàn)證及優(yōu)化：當(dāng)我們的配置部分參數(shù)值有問題時(shí)，CM會(huì)給出智能提示信息，幫助我們更合理的修改配置參數(shù)。
4) 高可用配置：使用CM，我們可以對(duì)關(guān)鍵組件進(jìn)行HA部署，如CM的Web管理控制臺(tái)可以對(duì)HDFS NameNode啟用HA功能。
5) 權(quán)限管理：根據(jù)CM的權(quán)限控制級(jí)別，我們可以配置不同的用戶，如有的用戶只有訪問CM的權(quán)限，但無對(duì)服務(wù)啟停操作的權(quán)限。
監(jiān)控：監(jiān)控集群的健康情況，對(duì)設(shè)置的各種指標(biāo)和系統(tǒng)運(yùn)行情況進(jìn)行全面監(jiān)控。
1) 服務(wù)監(jiān)控：查看服務(wù)和實(shí)例級(jí)別健康檢查的結(jié)果，對(duì)設(shè)置的各種指標(biāo)和系統(tǒng)運(yùn)行情況進(jìn)行全面監(jiān)控。如果任何運(yùn)行情況測(cè)試是不良（Bad），則服務(wù)或者角色的狀態(tài)就是不良（Bad）。如果運(yùn)行狀態(tài)存在隱患（Concering，沒有任意一項(xiàng)目是不良），則服務(wù)或角色的狀況就是隱患（Concerning）。而且系統(tǒng)會(huì)對(duì)管理員應(yīng)該采取的行動(dòng)提出建議。
2) 主機(jī)監(jiān)控：監(jiān)控集群內(nèi)所有主機(jī)的有關(guān)信息，包括主機(jī)目前消耗到內(nèi)存，主機(jī)上運(yùn)行的角色分配等，不但顯示所有集群主機(jī)的匯總視圖，而且能夠進(jìn)一步顯示單個(gè)主機(jī)關(guān)鍵指標(biāo)詳細(xì)視圖。
3) 行為監(jiān)控：根據(jù)CM提供的列表或圖表來看查看集群上進(jìn)行的活動(dòng)，不僅顯示當(dāng)前正在執(zhí)行的任務(wù)行為，還可以通過儀表盤查看歷史活動(dòng)。
4) 事件活動(dòng)：根據(jù)CM監(jiān)控界面，我們可以查看事件，可以通過時(shí)間范圍、服務(wù)、主機(jī)、關(guān)鍵字等信息過濾事件。
5) 報(bào)警：通過配置CM可以對(duì)指定的時(shí)間產(chǎn)生警報(bào)，并通過電子郵件或者SNMP的事件得到制定的警報(bào)通知。
6) 日志和報(bào)告：輕松點(diǎn)擊一個(gè)鏈接查看相關(guān)的特定服務(wù)的日志條目，并且CM為我們生成了收集的歷史日志監(jiān)控?cái)?shù)據(jù)統(tǒng)計(jì)報(bào)表。
診斷：對(duì)集群出現(xiàn)的問題進(jìn)行診斷，對(duì)出現(xiàn)的問題給出建議方案。
1) 周期性服務(wù)診斷：CM會(huì)對(duì)集群中運(yùn)行的所有服務(wù)進(jìn)行周期性的運(yùn)行狀況測(cè)試，以檢測(cè)這些服務(wù)的狀態(tài)知否正常。如果有異常，就會(huì)進(jìn)行告警，有利于更早的讓我們感知集群服務(wù)存在的問題。
2) 日志采集及檢索：對(duì)于一個(gè)大規(guī)模的集群，CM為我們提供了日志收集功能，能夠通過統(tǒng)一的界面查看集群中每臺(tái)及其各項(xiàng)服務(wù)的日志，并且能夠根據(jù)日志級(jí)別等不同的條件進(jìn)行檢索。
3) 系統(tǒng)性能使用報(bào)告：根據(jù)CM，我們能夠查看系統(tǒng)性能使用報(bào)告，包括集群的CPU使用率，單節(jié)點(diǎn)的CPU使用率，單個(gè)進(jìn)程的CPU使用率等各項(xiàng)性能，這對(duì)于我們調(diào)試Hadoop集群的性能是很重要的。
集成：對(duì)Hadoop的多組件進(jìn)行整合。
1) 生態(tài)圈各組件集成：企業(yè)級(jí)大數(shù)據(jù)平臺(tái)就是有這樣的好處，其集成了整個(gè)Hadoop生態(tài)圈的各項(xiàng)組件。根據(jù)CM控制臺(tái)，我們可以輕松的部署各項(xiàng)服務(wù)，各項(xiàng)服務(wù)都默認(rèn)了最優(yōu)的配置，我們只需根據(jù)情況適當(dāng)調(diào)整即可。包括ZooKeeper、HDFS、YARN、SQOOP、Flume、Kafka、Hive、HBase、Impla、Oozie、Hue、Spark等都可以實(shí)現(xiàn)可視化安裝，無需配置。
2) 安全配置：為了方便Hadoop大數(shù)據(jù)平臺(tái)與原有的身份認(rèn)證系統(tǒng)如AD、LDAP等的集成，CM只需在界面上配置即可。
3) Cloudera Manager API：通過Cloudera Manager API，能夠方便的將CM集成到企業(yè)原有管理系統(tǒng)中。
3.2 平臺(tái)運(yùn)行
存儲(chǔ)擴(kuò)展
對(duì)于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)來說，當(dāng)存儲(chǔ)空間不足時(shí)，最好的辦法就是增加磁盤，隨著數(shù)據(jù)量不斷增長(zhǎng)，不可避免的會(huì)遇到性能瓶頸，因?yàn)辇嫶蟮臄?shù)據(jù)量導(dǎo)致每次查詢尋址時(shí)間過長(zhǎng)，造成業(yè)務(wù)系統(tǒng)請(qǐng)求阻塞，嚴(yán)重制約了關(guān)系型數(shù)據(jù)庫(kù)的使用范圍。這種只增加存儲(chǔ)不增加計(jì)算能力的辦法只可解決當(dāng)下的問題，卻無法面對(duì)長(zhǎng)遠(yuǎn)的隱患問題。
對(duì)于CDH來說，存儲(chǔ)擴(kuò)展將變得非常容易。當(dāng)存儲(chǔ)不夠或者計(jì)算壓力過重時(shí)，我們可以適當(dāng)?shù)脑黾訖C(jī)器來提升系統(tǒng)性能，只要配置正確，新節(jié)點(diǎn)能非常兼容的加入集群中。這種即增加存儲(chǔ)也提升計(jì)算能力的辦法無論面對(duì)多大的數(shù)據(jù)量都不會(huì)是問題。
圖8 CDH集群擴(kuò)容
CDH的集群擴(kuò)容非常簡(jiǎn)單，在CDH中，我們只在待添加的節(jié)點(diǎn)中做好基礎(chǔ)配置（網(wǎng)絡(luò)、域名、Selinux、文件打開的最大數(shù)量、數(shù)據(jù)盤掛載）即可，添加節(jié)點(diǎn)的操作均在CM控制臺(tái)操作。添加節(jié)點(diǎn)時(shí)，輸入IP或者域名搜索，然后選定在新添加的節(jié)點(diǎn)中要配置的服務(wù)和角色即可，其余的均有CM自動(dòng)執(zhí)行。
添加服務(wù)
CM是控制臺(tái)，其集成的各項(xiàng)服務(wù)才是CDH的核心。在原生的Hadoop中，添加服務(wù)是一件非常繁瑣的事情。首先在管理節(jié)點(diǎn)中將要添加的服務(wù)配置好（XML）；然后分發(fā)到所有的節(jié)點(diǎn)中；最后在各個(gè)節(jié)點(diǎn)中分別啟動(dòng)；以上所有的服務(wù)均是在命令行操作。而在CDH中，CM的Web頁(yè)面提供了一鍵添加服務(wù)甚至批量添加服務(wù)功能，所有的服務(wù)均由CM做了默認(rèn)的配置（XML），只需根據(jù)自身情況做調(diào)整即可。
圖9 CDH添加服務(wù)
高可用性
為保證系統(tǒng)24小時(shí)不間斷提供服務(wù)，我們需要針對(duì)關(guān)鍵角色做故障自動(dòng)轉(zhuǎn)移配置，即HA配置。比如HDFS NameNode、YARN ResourceManager、HBase Master等關(guān)鍵的性的角色為了避免點(diǎn)單故障，需要對(duì)這些角色額外單獨(dú)（不同節(jié)點(diǎn)上）配置一個(gè)同樣的服務(wù)（備用），當(dāng)發(fā)生故障時(shí)，備用服務(wù)自動(dòng)啟動(dòng)，做到無縫切換。
圖10 HDFS NameNode高可用配置
在原生的Hadoop中，如果要做HA配置，我們要做大量的手動(dòng)操作：選擇節(jié)點(diǎn)、同步配置文件、啟用HA、同步元數(shù)據(jù)、共享元數(shù)據(jù)、全部重啟服務(wù)等。而在CDH中，我們只需在控制臺(tái)中點(diǎn)擊“啟用High Availability”，選中HA節(jié)點(diǎn)，剩余的都交由CM去執(zhí)行。
負(fù)荷分擔(dān)
面對(duì)過于沉重的荷載，對(duì)于Oracle來說，我們慣用的方法是分庫(kù)分表分區(qū)等；對(duì)于Hive表來說，也存在著分區(qū)分桶等方法來避免全表掃描。對(duì)于HBase來說，為了更好的提升性能，用拆分Region的方式來提升查詢速度。
圖11 HBase的拆分Region
HBase拆分Region有別于其他數(shù)據(jù)庫(kù)，HBase表的所有數(shù)據(jù)都按照RowKey排序，并且按照RowKey拆分Region，每個(gè)Region中包含一定范圍的數(shù)據(jù)（Start Key – End Key），每個(gè)Region中的數(shù)據(jù)又按照RowKey排序。
高可靠性
為保證系統(tǒng)的可靠性，我們配置冗余的數(shù)據(jù)備份，不同備份將不同磁盤、不同節(jié)點(diǎn)、不同機(jī)架分別存放。這樣部分節(jié)點(diǎn)宕機(jī)，或者某個(gè)磁盤損壞，甚至某臺(tái)節(jié)點(diǎn)宕機(jī)導(dǎo)致部分備份丟失，我們都不必當(dāng)心數(shù)據(jù)安全問題。此外，按照HDFS的Heart Beat機(jī)制，系統(tǒng)還會(huì)監(jiān)控?cái)?shù)據(jù)備份，一旦有備份丟失，系統(tǒng)將會(huì)自動(dòng)復(fù)制新的一份到其余節(jié)點(diǎn)中。
圖12 HDFS的數(shù)據(jù)備份策略
在CDH中，數(shù)據(jù)備份策略在CM控制臺(tái)中即可配置，無需在命令行去操作。
低故障率
對(duì)于Hadoop來說，硬件故障是常態(tài)，為了避免硬件故障導(dǎo)致系統(tǒng)出現(xiàn)奔潰的情況，我們需要在內(nèi)存、磁盤等方面做一些調(diào)整：
內(nèi)存：在Hadoop中有些角色是需要內(nèi)存資源用來存儲(chǔ)關(guān)鍵信息的，如HDFS NameNode元數(shù)據(jù)、HBase BlockCache等；因此給這些角色適當(dāng)增加內(nèi)存是有助于提升系統(tǒng)性能的。
磁盤：系統(tǒng)盤和數(shù)據(jù)盤獨(dú)立創(chuàng)建，系統(tǒng)盤做冗余磁盤陣列RAID1。
3.3 讀寫請(qǐng)求
根據(jù)業(yè)務(wù)場(chǎng)景，我們所有的業(yè)務(wù)數(shù)據(jù)（結(jié)構(gòu)化和非結(jié)構(gòu)化）都存儲(chǔ)在HBase中，因此對(duì)CDH的讀寫請(qǐng)求更主要針對(duì)HBase的讀寫請(qǐng)求。提升HBase的讀寫請(qǐng)求效率是電子檔案系統(tǒng)最核心的需求，因此HBase的優(yōu)化工作是我們工作的重中之重。適當(dāng)調(diào)高HBase內(nèi)存、調(diào)整垃圾回收策略、更改默認(rèn)的Region大小、選擇合適的小文件合并時(shí)機(jī)和拆分Region時(shí)機(jī)、啟用Snappy壓縮、預(yù)創(chuàng)建Region、避免Region熱點(diǎn)等等都可以提高HBase的存取速度。
調(diào)整HBase內(nèi)存
這里首先涉及HBase服務(wù)的堆內(nèi)存設(shè)置。一般剛部署的HBase集群，默認(rèn)配置只給Master和RegionServer分配了1G的內(nèi)存，RegionServer中MemStore默認(rèn)占40%即400M左右的空間，而一個(gè)MemStore刷寫閾值默認(rèn)為128M，所以一個(gè)RegionServer也就能正常管理3個(gè)Region，多了就可能產(chǎn)生小文件了，另外也容易發(fā)生Full GC。因此建議合理調(diào)整Master和RegionServer的內(nèi)存，比如：
其次要考慮開啟BlockCache，首先，BlockCache是RegionServer級(jí)別的，一個(gè)RegionServer只有一個(gè)BlockCache。BlockCache的工作原理是讀請(qǐng)求會(huì)首先檢查Block是否存在于BlockCache，存在就直接返回，如果不存在再去HFile和MemStore中獲取，返回?cái)?shù)據(jù)時(shí)把Block緩存到BlockCache中，后續(xù)同一請(qǐng)求或臨近查詢可以直接從BlockCache中讀取，避免過多昂貴的IO操作。
調(diào)整垃圾回收策略
1) G1收集器VS CMS收集器
CMS收集器在物理上區(qū)分年輕代和年老代空間。G1收集器會(huì)將heap分成很多region，然后在邏輯區(qū)分年輕代和年老代空間。G1收集器主要用于控制垃圾回收的時(shí)間。對(duì)于HBase使用場(chǎng)景，大部分年老代的對(duì)象是memsotre或者blockcache。對(duì)比測(cè)試發(fā)現(xiàn)，CMS收集器有更好的表現(xiàn)。
2) CMS配置調(diào)優(yōu)
設(shè)置較大的heap size。使用CMSInitiatingOccupancyFraction=70，值為70為JVM的使用百分比，當(dāng)達(dá)到這個(gè)閾值后將啟動(dòng)回收任務(wù)，這個(gè)值比較適合的值是要略大約memstore 40%+blockcache 20%。如果CMSInitiatingOccupancyFraction這個(gè)值小于60會(huì)導(dǎo)致GC報(bào)警。
3) 新生代收集器UseParNewGC
使用UseParNewGC收集器，并加大新生代空間大小占heap size 25%，因?yàn)閙emstore（40%）+blockcache（20%）占總heap（60%），這兩部分空間會(huì)被存放在年老年空間。所以新生代空間不應(yīng)該大小1-60%，讓更多的GC發(fā)生在新生代，UseParNewGC可以并行收集，收集成本低。
4) TargetSurvivorRatio設(shè)置
TargetSurvivorRatio=90設(shè)置Survivor區(qū)的可使用率。這里設(shè)置為90%，則允許90%的Survivor空間被使用。默認(rèn)值為50%，故該值設(shè)置提高了Survivor區(qū)的使用率。但存放的對(duì)象超過這個(gè)百分比，則對(duì)象會(huì)向年老代壓縮。因此，這個(gè)選項(xiàng)更有助于將對(duì)象留在年老代。
選擇合適的Region數(shù)量
通常較少的region數(shù)量可使群集運(yùn)行的更加平穩(wěn)，官方指出每個(gè)RegionServer大約100個(gè)regions的時(shí)候效果最好，理由如下：
1) HBase的一個(gè)特性MSLAB，它有助于防止堆內(nèi)存的碎片化，減輕垃圾回收Full GC的問題，默認(rèn)是開啟的。但是每個(gè)MemStore需要2MB（一個(gè)列簇對(duì)應(yīng)一個(gè)寫緩存memstore）。所以如果每個(gè)region有2個(gè)family列簇，總有1000個(gè)region，就算不存儲(chǔ)數(shù)據(jù)也要3.95G內(nèi)存空間。
2) 如果很多region，它們中Memstore也過多，內(nèi)存大小觸發(fā)Region Server級(jí)別限制導(dǎo)致flush，就會(huì)對(duì)用戶請(qǐng)求產(chǎn)生較大的影響，可能阻塞該Region Server上的更新操作。
3) HMaster要花大量的時(shí)間來分配和移動(dòng)Region，且過多Region會(huì)增加ZooKeeper的負(fù)擔(dān)。
4) 從HBase讀入數(shù)據(jù)進(jìn)行處理的mapreduce程序，過多Region會(huì)產(chǎn)生太多Map任務(wù)數(shù)量，默認(rèn)情況下由涉及的region數(shù)量決定。
所以，如果一個(gè)HRegion中Memstore過多，而且大部分都頻繁寫入數(shù)據(jù)，每次flush的開銷必然會(huì)很大，因此我們也建議在進(jìn)行表設(shè)計(jì)的時(shí)候盡量減少ColumnFamily的個(gè)數(shù)。每個(gè)region都有自己的MemStore，當(dāng)大小達(dá)到了上限(hbase.hregion.memstore.flush.size，默認(rèn)128MB)，會(huì)觸發(fā)Memstore刷新。
計(jì)算集群region數(shù)量的公式：((RS Xmx) * hbase.regionserver.global.memstore.size) / (hbase.hregion.memstore.flush.size * (# column families))
假設(shè)一個(gè)RS有16GB內(nèi)存，那么16384*0.4/128m 等于51個(gè)活躍的region。
如果寫很重的場(chǎng)景下，可以適當(dāng)調(diào)高h(yuǎn)base.regionserver.global.memstore.size，這樣可以容納更多的region數(shù)量。
建議分配合理的region數(shù)量，根據(jù)寫請(qǐng)求量的情況，一般20-200個(gè)之間，可以提高集群穩(wěn)定性，排除很多不確定的因素，提升讀寫性能。監(jiān)控Region Server中所有Memstore的大小總和是否達(dá)到了上限(hbase.regionserver.global.memstore.upperLimit ＊ hbase_heapsize，默認(rèn) 40%的JVM內(nèi)存使用量)，超過可能會(huì)導(dǎo)致不良后果，如服務(wù)器反應(yīng)遲鈍或compact風(fēng)暴。
更改默認(rèn)的Region大小
HBase中數(shù)據(jù)一開始會(huì)寫入memstore，滿128MB（看配置）以后，會(huì)flush到disk上而成為storefile。當(dāng)storefile數(shù)量超過觸發(fā)因子時(shí)（可配置），會(huì)啟動(dòng)compaction過程將它們合并為一個(gè)storefile。對(duì)集群的性能有一定影響。而當(dāng)合并后的storefile大于max.filesize，會(huì)觸發(fā)分割動(dòng)作，將它切分成兩個(gè)region。
1) 當(dāng)hbase.hregion.max.filesize比較小時(shí)，觸發(fā)split的機(jī)率更大，系統(tǒng)的整體訪問服務(wù)會(huì)出現(xiàn)不穩(wěn)定現(xiàn)象。
2) 當(dāng)hbase.hregion.max.filesize比較大時(shí)，由于長(zhǎng)期得不到split，因此同一個(gè)region內(nèi)發(fā)生多次compaction的機(jī)會(huì)增加了。這樣會(huì)降低系統(tǒng)的性能、穩(wěn)定性，因此平均吞吐量會(huì)受到一些影響而下降。
3) hbase.hregion.max.filesize不宜過大或過小，經(jīng)過實(shí)戰(zhàn)，生產(chǎn)高并發(fā)運(yùn)行下，最佳大小5-10GB！關(guān)閉某些重要場(chǎng)景的HBase表的major_compact！在非高峰期的時(shí)候再去調(diào)用major_compact，這樣可以減少split的同時(shí)，顯著提供集群的性能，吞吐量、非常有用。
HFile文件是否太多
文件越多，檢索所需的IO次數(shù)必然越多，讀取延遲也就越高。文件數(shù)量通常取決于Compaction的執(zhí)行策略，一般和兩個(gè)參數(shù)有關(guān)：
hbase.hstore.compactionThreshold和hbase.hstore.compaction.max.size，前者表示一個(gè)store中的文件數(shù)超過多少個(gè)就應(yīng)該合并，后者表示參數(shù)合并的文件大小最大是多少，超過此大小的文件不能參與合并。
hbase.hstore.compactionThreshold設(shè)置不能太大，默認(rèn)是3個(gè)；設(shè)置需要根據(jù)Region的大小，通?？梢哉J(rèn)為是
hbase.hstore.compaction.max.size=RegionSize/hbase.hstore.compactionThreshold。
選擇合適的小文件合并策略
Compaction是將小文件合并為大文件，提高后續(xù)業(yè)務(wù)隨機(jī)讀性能，但是也會(huì)帶來IO放大以及帶寬消耗問題，問題主要產(chǎn)生于配置不合理導(dǎo)致Minor Compaction太過頻繁，或者Region設(shè)置太大情況下發(fā)生Major Compaction。
觀察系統(tǒng)IO資源以及帶寬資源使用情況，再觀察Compaction隊(duì)列長(zhǎng)度，確認(rèn)是否由于Compaction導(dǎo)致系統(tǒng)資源消耗過多。
Minor Compaction設(shè)置：hbase.hstore.compactionThreshold設(shè)置不能太大，也不能太小，因此建議設(shè)置為5~6；
hbase.hstore.compaction.max.size=RegionSzie/hbase.hstore.compactionThreshold。
Major Compaction設(shè)置：大Region讀延遲敏感業(yè)務(wù)（100G以上）通常不建議開啟自動(dòng)Major Compaction，手動(dòng)低峰觸發(fā)。小Region或延遲不敏感業(yè)務(wù)也可以開啟自動(dòng)Major Compaction，但建議限制流量。
Region拆分策略
Region為什么要拆分？隨著數(shù)據(jù)的增加，一個(gè)Region管理的數(shù)據(jù)條數(shù)越來越多，出現(xiàn)傳統(tǒng)SQL數(shù)據(jù)庫(kù)的單節(jié)點(diǎn)并發(fā)問題，將Region拆分，將Region移動(dòng)均衡到其他節(jié)點(diǎn)。
Region拆分有三種方式：預(yù)拆分、自動(dòng)拆分、手動(dòng)強(qiáng)制拆分
1) 預(yù)拆分：指定每個(gè)預(yù)拆分的Region的RowKey的開始值
create 'test_table', 'table_spilt_test1', SPLITS=> ['1001', '2001', '3001']
2) 自動(dòng)拆分
Region的默認(rèn)大小問10G，超過10G就自動(dòng)拆分，Region大小通過下面這個(gè)參數(shù)控制，生產(chǎn)環(huán)境如果預(yù)分區(qū)后，每個(gè)Region數(shù)據(jù)都比較大可改成20G 30G：
hbase.hregion.max.filesize
3) 強(qiáng)制拆分
可在HBase shell根據(jù)提示，對(duì)某個(gè)Region進(jìn)行強(qiáng)制拆分：
也可以調(diào)用HBase JAVA API來操作。
啟用Snappy壓縮
啟用壓縮可以大大提高集群的可用性，scan性能顯著提升。目前HBase默認(rèn)支持的壓縮包括GZ、LZO以及Snappy，測(cè)試對(duì)比之后選擇Snappy壓縮算法。
表3 不同壓縮算法測(cè)試性能比較
create ‘test’,{NAME => ‘info’,VERSIONS => 1,COMPRESSION => ‘snappy’}
預(yù)創(chuàng)建Region
HBase中的預(yù)分區(qū)就是在創(chuàng)建表之前，指定好RowKey在哪個(gè)范圍的數(shù)據(jù)會(huì)落到哪個(gè)分區(qū)中，因?yàn)镠Base會(huì)按照字典順序把RowKey進(jìn)行排序。預(yù)分區(qū)的好處是一方面可以提高讀寫效率，二是防止數(shù)據(jù)傾斜，起到負(fù)載均衡的作用。
創(chuàng)建表格時(shí)指定分區(qū)邊界：
create ‘staff’,’info’,’partition’,SPLITS = > [‘1000’,’2000’,’3000’,’4000’]
使用16進(jìn)制算法生成預(yù)分區(qū)
ceate ‘staff’,’info’,’partiton’,{COLUMNS = > 15,SPLITALGO => ‘’HexStringSplit’}
避免Region熱點(diǎn)
檢索HBase的記錄首先要通過RowKey來定位數(shù)據(jù)，當(dāng)大量的Client方位HBase集群的一個(gè)或者幾個(gè)Region，會(huì)造成少數(shù)RegionServer的讀寫請(qǐng)求過多、負(fù)載過大，而其他RegionServer負(fù)載卻很小，就造成了“熱點(diǎn)”現(xiàn)象。
常見的避免熱點(diǎn)的方法：
1) 加鹽：這里的加鹽不是密碼學(xué)中的加鹽，而是在RowKey的前面增加隨機(jī)數(shù)，具體就是給RowKey分配一個(gè)隨機(jī)前綴使得它和之前的RowKey的開頭不同。給多少個(gè)前綴，這個(gè)數(shù)量應(yīng)該和我們要分散數(shù)據(jù)到不同的Region數(shù)量一致。
2) 哈希：哈希會(huì)使同一行永遠(yuǎn)用一個(gè)前綴加鹽。哈希也可以使負(fù)載分散到整個(gè)集群，但是讀卻是可以預(yù)測(cè)的。使用確定的哈?？梢宰尶蛻舳酥貥?gòu)完整的RowKey，可以使用get操作準(zhǔn)確獲取某一個(gè)行數(shù)據(jù)。
3) 反轉(zhuǎn)：反轉(zhuǎn)固定長(zhǎng)度或者數(shù)字格式的RowKey。這樣可以使得RowKey中經(jīng)常改變的部分（最沒有意義的部分）放在
前面。這樣可以有效的隨機(jī)RowKey，但是犧牲了RowKey的有序性。
4) RowKey唯一原則：必須在設(shè)計(jì)上保證其唯一性，RowKey是按照二進(jìn)制字節(jié)數(shù)據(jù)排序存儲(chǔ)的，因此設(shè)計(jì)RowKey的時(shí)候，要充分利用這個(gè)排序的特點(diǎn)，經(jīng)常讀的數(shù)據(jù)存儲(chǔ)的一起，將最近可能會(huì)被訪問的數(shù)據(jù)放到一塊。
5) RowKey長(zhǎng)度原則：RowKey是一個(gè)二進(jìn)制碼流，可以是任意字符串，最大長(zhǎng)度64kb，實(shí)際應(yīng)用中一般為10-100byte，以byte[]形式保存，一般設(shè)計(jì)成定長(zhǎng)度，建議越短越好，不要超過16個(gè)字節(jié)（因?yàn)镽owKey是要加載到內(nèi)存中的）。
6) RowKey散列原則：如果RowKey按照時(shí)間戳的方式遞增，不要將時(shí)間放到二進(jìn)制碼的前面，建議將RowKey高位作為三列字段，由程序隨機(jī)生成，低位放時(shí)間字段，這樣將提高數(shù)據(jù)均衡分布在每個(gè)Region上，以實(shí)現(xiàn)負(fù)載均衡的幾率。
Swap的設(shè)置
推薦設(shè)置為0，這樣只有在物理內(nèi)存不夠的情況下才會(huì)使用交換分區(qū)。這個(gè)參數(shù)由于JVM虛擬機(jī)如果使用了Swap在GC回收時(shí)會(huì)花費(fèi)更多到時(shí)間。
3.4 數(shù)據(jù)遷移
SQOOP數(shù)據(jù)導(dǎo)入
使用SQOOP執(zhí)行數(shù)據(jù)遷移的目的是需要將Oracle中的結(jié)構(gòu)化數(shù)據(jù)（ID）遷移到Hive中，然后在Hive中計(jì)算要預(yù)分Region的RowKey值：
預(yù)分Region的RowKey（start key和end key）計(jì)算
##創(chuàng)建臨時(shí)表并分區(qū)分桶，目的是為了更快的計(jì)算
MR接口編程
Oracle到HBase表之間的數(shù)據(jù)轉(zhuǎn)移以MapReduce分布式計(jì)算框架執(zhí)行：
1) Mapper：
2) Reduce：
3) 主程序入口：
4.
質(zhì)變與總結(jié)
在數(shù)據(jù)存儲(chǔ)方面：電子檔案系統(tǒng)不用再承受Oracle頻繁增加磁盤和數(shù)據(jù)量猛增的情況下帶來的痛苦，即使再大的數(shù)據(jù)量，對(duì)于分布式集群來說，都是添加節(jié)點(diǎn)的事情。即使在廉價(jià)的商用機(jī)器上，大數(shù)據(jù)平臺(tái)都能得到很好的部署，讓數(shù)據(jù)存儲(chǔ)不再是個(gè)問題。
在讀寫速度方面：因?yàn)镠Base的特性，返回同樣的數(shù)據(jù)HBase比Oracle有著更低的延遲、更高的效率。
在運(yùn)行狀態(tài)方面：因?yàn)榉植际郊翰淮嬖趩吸c(diǎn)故障問題，系統(tǒng)穩(wěn)定方面有了很大的保證，可確保24小時(shí)不間斷提供服務(wù)。
在用戶體驗(yàn)方面：隨著請(qǐng)求速度的提升，用戶不用再長(zhǎng)時(shí)間的等待數(shù)據(jù)庫(kù)請(qǐng)求結(jié)果，極大的提高了用戶工作效率。
