2. 程式人生 > >你想要的 HBase 原理都在這了

你想要的 HBase 原理都在這了

阿新 • • 發佈：2019-12-22

目錄

  • 一、 叢集架構
    • 叢集角色
    • 工作機制
  • 二、儲存機制
    • A. 儲存模型
    • B. LSM 與 Compaction
    • C. Region 分裂
    • D. 自動均衡
  • 三、訪問機制
  • 四、 鑑權
  • 五、 高可靠
    • 1.叢集高可靠
    • 2. 隔離性
    • 3. 容災
  • 參考文件

在前面的文章中，介紹過 HBase 的入門操作知識，但對於正考慮將 HBase 用於生產系統的專案來說還是遠遠不夠。

一般在對 HBase 做選型之前，還需要學習一些它的架構原理、彈性擴充套件及可靠性方面的知識。
本文來自筆者此前對 HBase 做的學習概括，可方便於對 HBase 的技術全景進行快速的掌握。

一、 叢集架構

儘管HBase可以工作在本地檔案系統之上，但在生產環境中，HBase需要依託 HDFS 作為其底層的資料儲存，而HDFS提供了預設的3副本來實現資料檔案的高可靠。
整個HBase 叢集主要由 Zookeeper、Master、RegionServer、HDFS所組成，如下圖：

叢集角色

Master
HBase Master 用於管理多個 Region Server，包括監測各個 Region Server 的狀態、分配 Region及自動均衡等。 具體職責包括：

  • 負責管理所有的RegionServer，實現RegionServer的高可用
  • 管理所有的資料分片(Region)到RegionServer的分配，包括自動均衡
  • 執行建表/修改表/刪除表等DDL操作

HBase 允許多個 Master 節點共存，當多個 Master 節點共存時，只有一個 Master 是提供服務的，這種主備角色的"仲裁"由 ZooKeeper 實現。

Region Server
Region Server 是真正的資料讀寫伺服器，即客戶端會直接連線 Region Server 進行操作。
一個 Region Server 會包括了多個 Region，這裡的 Region 則是真正存放 HBase 資料的區域單元，當一個表很大時，會拆分成很多個 Region 進行存放。

可以說，Region 是 HBase 分散式的基本單位。

Zookeeper
Zookeeper 對於 HBase的作用是至關重要的。

  • Zookeeper 提供了 HBase Master 的高可用實現，並保證同一時刻有且僅有一個主 Master 可用。
  • Zookeeper 儲存了 Region 和 Region Server 的關聯資訊(提供定址入口)，並儲存了叢集的元資料(Schema/Table)。
  • Zookeeper 實時監控Region server的上線和下線資訊，並實時通知Master。

就目前來說，Zookeeper 已經成為了分散式系統架構中最常用的標準框架之一。 除了 HBase之外，有許多分散式大資料相關的開源框架，都依賴於 Zookeeper 實現 HA。

HDFS
HDFS 是 Hadoop 的分散式檔案系統，提供了高可靠高擴充套件的檔案儲存能力。 其內部也是一個叢集結構，包含 NameNode、DataNode 角色。
其中 NameNode儲存的是 HDFS檔案目錄樹的元資料，包含檔案與Block的關聯資訊，而DataNode 則是HDFS的資料存放節點。

HDFS作為一個分散式檔案系統，自然需要檔案目錄樹的元資料資訊，另外，在HDFS中每一個檔案都是按照Block儲存的，檔案與Block的關聯也通過元資料資訊來描述。NameNode提供了這些元資料資訊的儲存。

工作機制

在一個完整的HBase 分散式叢集中，各個元件的互動工作如下圖所示：

首先 Zookeeper 維護了 Master 與各個 Region Server 之間的關係及狀態。 當一個 Client 需要訪問 HBase 叢集時，會先和 Zookeeper 進行通訊，並得到 Master和 RegionServer的地址資訊。
對於建立表/刪除表/修改表來說，客戶端會通過 Master 來進行操作，而正常的表資料讀寫，則是通過找到對應的 Region Server來操作。

Region Server 的作用

每一個 Region Server 會管理很多個 Region(區域), 這個就是之前提到的 HBase 資料分散式及高可靠的一個單元。 每個 Region 只會儲存一個表中的的一段資料，這是按 RowKey 的區間來分隔的。
而且，一個 Region 的儲存空間有一個上限(Threshold)，當存放資料的大小達到該上限時，Region 就會進行分裂併產生多個新的 Region，隨著一個Region Server 上的 Region 越來越多，Master 可以監測到不均衡的情況，並自動將Region進行重新分配。
因此，資料可以源源不斷的寫入到 HBase時，通過這種 Region的分裂、自動均衡來支援海量資料的儲存。

對於一個Region來說，其內部是由 多個Store構成的，而一個Store 對應於一個ColumnFamily(列族)。
在實現上一個Store物件會包含一個MemStore以及多個StoreFile。 當資料寫入 Region時，先寫入MemStore(保持有序)。
當MemStore 寫滿了之後就會 Flush 到StoreFile，這裡的 StoreFile 就對應了一個HDFS中的 HFile檔案。
最終 Region會對應到多個 持久化的 HFile，當這些 HFile 越來越多時，Region Server 會執行合併操作(Compaction)來合併為一個大的HFile，以此來優化讀取效能，這個機制則是基於LSM的原理實現的。

HLog 和可靠性

HBase 提供了HLog來保證資料寫入的可靠性，HLog 本質上就是一種 WAL(事務機制中常見的預寫日誌)，其同樣是通過HDFS來持久化的(對應於一個Sequence檔案)。 每個Region Server 都包含一個HLog，其中記錄了所有發生在Region Server上的資料變更操作。
當資料發生寫入時，會先記錄日誌到 HLog中，然後再寫入 MemStore，最終才持久化到 HFile中。 這樣當 Region Server 宕機時，儘管 MemStore中的資料會丟失，但還可以通過 HLog來恢復之前的資料，從而保證了高可靠。
那麼，HFile 是否可靠呢？ 這點則是由 HDFS 來保證的，一個HFile 預設會有3個副本。

除此之外，HLog 也是HBase 實現叢集同步複製的關鍵手段。

二、儲存機制

接下來，我們看看HBase中的資料是怎樣被儲存及管理的。

A. 儲存模型

首先需要澄清的一點是，Region 和 Column Family (簡稱CF) 的區別。

Region 是HBase 分散式儲存的基本單位，其本質上是一種水平切分單位，可以理解為資料的分片；而Column Family(列族)則是垂直切分的單位，可理解為一種列的分組。
這兩者的區別可以參考下圖：

無論是Region、還是CF，都是邏輯上的一個概念，對於物理上的實現則如下圖所示：

儲存模組說明

  • 一個 Region 包含多個Store,一個store對應一個CF
  • Store包括位於記憶體中的 Memstore 和多個持久化的 Storefile;
  • 寫操作先寫入 Memstore，當 Memstore 中的資料大小達到某個閾值後會Flush到一個單獨的 Storefile
  • 當 Storefile 檔案的數量增長到一定閾值後，系統會進行合併，形成更大的 Storefile(Compaction)
  • 當一個 Region 所有 Storefile 的大小總和超過一定閾值後，會把當前的 Region 分割為兩個(分裂)
  • Master 自動檢測RegionServer 上Region的分配情況，自動進行均衡遷移
  • 客戶端檢索資料，優先從 Memstore查詢，然後再查詢 Storefile

HFile 結構

HFile 是HDFS 的儲存單元，其結構如下圖：

HFile 由很多個數據塊（Block）組成，並且有一個固定的結尾塊。其中的資料塊是由一個 Header 和多個 Key-Value 的鍵值對組成。
在結尾的資料塊中包含了資料相關的索引資訊，系統也是通過結尾的索引資訊找到 HFile 中的資料。

HFile 中的資料塊大小預設為 64KB。如果訪問 HBase 資料庫的場景多為有序的訪問，那麼建議將該值設定的大一些。
如果場景多為隨機訪問，那麼建議將該值設定的小一些。一般情況下，通過調整該值可以提高 HBase 的效能

B. LSM 與 Compaction

HBase 在儲存上是基於LSM樹 實現的，與傳統的B/B+樹原理不同的是，LSM樹非常適用於寫入要求非常高的場景。

LSM的原理

將一個大的B(B+)樹拆分成N棵小樹，資料首先寫入記憶體中(有序)，隨著資料寫入越來越多，記憶體中的資料會被flush到磁碟中形成一個檔案；
在讀取資料時，則需要合併磁碟中歷史資料和記憶體中最近修改的操作後返回。 由於資料是順序寫入的，因此LSM的寫入效能非常高，但讀取時可能會訪問較多的磁碟檔案，效能較差。
為了緩解讀效能低下的問題，LSM樹會定時將磁碟中的多個檔案(小樹)進行合併，以優化讀效能。

在HBase的實現中，記憶體中的資料則是對應於MemStore，而磁碟中的資料則對應於 StoreFile (HFile實現)。 當MemStore寫滿後會Flush到一個HFile 中。
隨著HFile 檔案的不斷增多，Region 的讀效能就會受到影響(IOPS 增加)。因此 HBase 的 Region Server 會定期進行Compaction操作，將多個HFile 合併為一個大的 有序的 HFile。
HBase 中執行的 Compaction 動作有兩種：

  • Minor Compaction，列族中小範圍的HFile檔案合併，一般較快，佔用IO低
  • Major Compaction，列族中所有的HFile檔案合併，同時清理TTL過期以及延遲刪除的資料，該過程會產生大量IO操作，效能影響較大。

具體的過程如下圖所示：

圖片出處：http://www.nosqlnotes.com/

Flush 效能影響

如果 Memstore 很小，意味著Flush 的次數會很多，一旦Compaction的速度跟不上就會產生大量的HFile 檔案，這會導致讀效能惡化，為了減緩這個問題，HBase 使用了 In Memory Flush And Compact 的方法，即資料在 MemStore 中先經分段(Segement)、Flush、Compaction 過程，到達一定大小後再 Flush 到 HFile。在這裡，MemStore 使用了 ConcurrentSkipListMap(併發跳躍表) 來保證一定的讀寫併發能力。ConcurrentSkipListMap 在容量超過一定大小後效能下降明顯，因此 MemStore 也不能設定得太大，當前的預設值在128MB。

觸發Flush 行為的條件包括：

  • Memstore級別：Region中任意一個MemStore達到了 hbase.hregion.memstore.flush.size 控制的上限（預設128MB），會觸發Memstore的flush。
  • Region級別：Region中Memstore大小之和達到了 hbase.hregion.memstore.block.multiplier hbase.hregion.memstore.flush.size 控制的上限（預設 2 128M = 256M），會觸發Memstore的flush。
  • RegionServer級別：Region Server中所有Region的Memstore大小總和達到了 hbase.regionserver.global.memstore.upperLimit ＊ hbase_heapsize 控制的上限（預設0.4，即RegionServer 40%的JVM記憶體），將會按Memstore由大到小進行flush，直至總體Memstore記憶體使用量低於 hbase.regionserver.global.memstore.lowerLimit ＊ hbase_heapsize 控制的下限（預設0.38， 即RegionServer 38%的JVM記憶體）。
  • RegionServer中HLog數量達到上限：將會選取最早的 HLog對應的一個或多個Region進行flush（通過引數hbase.regionserver.maxlogs配置）。
  • HBase定期flush：確保Memstore不會長時間沒有持久化，預設週期為1小時。為避免所有的MemStore在同一時間都進行flush導致的問題，定期的flush操作有20000左右的隨機延時。
  • 手動執行flush：使用者可以通過shell命令 flush ‘tablename’或者flush ‘region name’分別對一個表或者一個Region進行flush。

除此以外，為了保證Compaction的進度與Flush對齊，HBase會在HFile數量到達一定閥值後阻塞Flush操作，如下面的引數：

  • hbase.hstore.blockingStoreFiles，觸發Flush阻塞等待的StoreFiles數量上限，2.x版本預設為16
  • hbase.hstore.blockingWaitTime，阻塞Flush的時間，2.x版本預設為90s

Compaction 策略

Compaction 的目的是優化讀效能，但會導致 IO 放大，這是因為在合併過程中，檔案需要不斷的被讀入、寫出，加上 HDFS 的多副本複製，則會再一次增加多次的IO操作。
此外，Compaction 利用了緩衝區合併來避免對已有的 HFile 造成阻塞，只有在最後合併 HFile 元資料時會有一點點的影響，這幾乎可以忽略不計。
但 Compaction 完成後會淘汰Block Cache，這樣便會造成短期的讀取時延增大。

在效能壓測時通常可以看到由 Compaction 導致的一些"毛刺"現象，但這是不可避免的，我們只能是根據業務場景來選擇一些合理的 Compaction 策略。

一般，Minor Compaction 會配置為按需觸發，其合併的範圍小，時間短，對業務效能的影響相對可控。
但 Major Compaction 則建議是在業務閒時手動觸發，以避免業務造成嚴重的卡頓。

關於如何選擇合併檔案的範圍，HBase 提供了以下幾種策略：

  • Stripe Compaction
    將一個Region劃分為多個子區域(Stripes)，Compaction嚴格控制在單個Stripe範圍內發生，這樣可以有效降低Compaction對IO資源的佔用。
    Stripe 範圍是根據RowKey來設定的，因此這適用於RowKey單調遞增寫入的場景

  • Date Tiered Compaction
    與Stripe Compaction 類似，但卻是基於時間戳來決定子區域的範圍，適合時序資料的場景(僅按時間範圍檢索)

  • MOB Compaction
    與 MOB 特性繫結的 Compaction，MOB 用於儲存檔案資料，其將元資料與檔案資料分離儲存，其中檔案資料不參與Compaction，這樣就大大減少了Compaction帶來的IO放大的影響。

  • RatioBased Compaction
    基於比例計算的 Compaction 策略，在0.96之前預設的策略，該策略會根據下列引數來選擇 Compaction 的檔案。

hbase.hstore.compaction.ratio：最小待合併檔案數
hbase.hstore.compaction.min：最小待合併檔案數
hbase.hstore.compaction.max：最大待合併檔案數
hbase.hstore.compaction.min.size最小合併檔案總大小

一般由於舊檔案都是經過Compaction的會比較大，因此通常會基於新檔案來做合併。
關於該策略的詳細討論可參考這裡

  • Exploring Compaction
    RatioBased Compaction 演進後的預設版本，基本演算法類似，但Exploring會根據價效比來進一步篩選，此時考慮的因素為：

檔案數量較多(讀效能增益)，總體大小偏小(降低IO放大)

C. Region 分裂

假設某個Region增長到了極限，將會切分為兩個子Region(原來的Region稱為父Region)該過程的步驟如下：

  1. RegionServer 初始化兩個子Region資訊，寫入一個ZK節點資料：/hbase/region-in-transition/region-name=SPLITING
  2. Master 通過Watch機制獲知該region狀態改變，此時可通過Master的UI介面觀察到；
  3. RegionServer 建立.split臨時目錄，用於儲存split後的子Region資訊；
  4. RegionServer 關閉父Region並執行Flush操作，此後在短暫的時間內對於父Region的讀寫操作都會失敗；
  5. RegionServer 在.split資料夾下新建兩個子Region的目錄，同時分別生成拆分後的reference檔案(僅僅是引用資訊);
  6. RegionServer 將.split資料夾下的子Region的目錄拷貝到HBase根目錄下，形成兩個新的Region；
  7. RegionServer 修改 hbase.meta 表(連線該元資料表對應的RegionServer)，將父Region 標記為Split完成，Offline=true，即表示分裂完成後下線；
  8. RegionServer 開啟兩個子Region，表示可接收讀寫操作；
  9. RegionServer 修改 hbase.meta 表，將子Region上線的資訊寫入；
  10. RegionServer 修改ZK節點資料：/hbase/region-in-transition/region-name=SPLIT，此後Master獲知分裂完成。 如果有正在執行的均衡任務，則會考慮進一步處理；

可以發現，整個分裂過程僅僅是建立了一些資料檔案的引用及元資料更新操作，對於業務的影響是非常微小的。
那麼，在分裂後的一段時間內，引用資料檔案還會持續存在，一直到當子Region發生Compaction操作時，才會將父Region的HFile資料拷貝到子Region目錄。

關於 Region切分的細節分析進一步參考

http://hbasefly.com/2017/08/27/hbase-split/?dspinw=x0dnj2&uypslg=eyr0j3

D. 自動均衡

HBase 的 Region 分配和自動均衡是由 Master 節點控制的，在初始化表時會先分配一個Region，然後指定給某個Region Server。 如果使用預分割槽，那麼Master 會按照輪詢的方式平均分配到每個 Region Server。
此後，隨著Region不斷的增大和裂變，Region Server 上的 Region 數量開始變得不均衡。
如果開啟了自動均衡開關，Master 會通過定時器來檢查叢集中的Regions在各個RegionServer之間的負載是否是均衡。一旦檢測到不均衡的情況，就會生成相應的Region遷移計劃。

關於均衡的方式，HBase 提供以下兩種策略：

  • DefaultLoadBalancer 預設的策略，根據 Region 個數來進行均衡
  • StochasticLoadBalancer 根據讀寫壓力評估來進行均衡

由於HBase的的資料(包括HLog、StoreFile等)都是寫入到HDFS檔案系統中的， 因此 HBase 的 Region 遷移是非常輕量級的。
在做Region遷移時，Region所對應的HDFS檔案是不變的，此時只需要將 Region 的元資料重新分配到目標 Region Server 就可以了。
遷移過程的步驟包含：

1.建立Region 遷移計劃，指定 RegionID、源 Region Server 和目標 Region Server；
2.源 Region Server 解綁，此時會關閉 Region
3.目標 Region Server 繫結，重新開啟 Region

三、訪問機制

HBase 支援多種讀寫客戶端訪問方式，具體包括：

  • 基於Java Client，一般是通過 RPC 呼叫 HBase。
  • 基於RestFul API，需要啟用 Rest Server 代理元件，該元件通過 Java Client 實現。
  • 基於Thrift API，需要啟用 Thrift Server 代理元件，該元件通過 Java Client 實現。
  • 基於 MapReduce 的批處理 API
  • 基於HBase Shell，其內部也是通過 Java Client 實現的。

無論使用何種呼叫方式，始終還是離不開最基礎的 RPC 呼叫流程。
該流程的互動邏輯如下圖所示：

  1. 連線 ZooKeeper
    在進行資料操作之前，客戶端首先需要接入ZooKeeper，並初始化一個ZooKeeper Session。
    該Session由ZooKeeper Client與ZooKeeper Server端之間建立，並通過心跳機制保持長連線

  2. 獲取meta Region路由資訊
    HBase 將Region分佈的元資料存放在hbase.meta這個表中，該表記錄了每一個使用者表Region的路由以及狀態資訊，它的 RowKey 包含如下的資訊：
  • 表名 Table Name
  • Region StartKey
  • Region ID
    客戶端通過Zookeeper 先找到 meta Region 所在的 Region Server，然後獲得 meta Region資訊。
    之後根據操作的 RowKey 就可以定位到對應的Region ID，最後再通過 Zookeeper 的對映表就可以得到Region 所在的 Region Server了。
    需要注意的是，客戶端一般會對 meta Region 資訊進行快取，避免每次都要耗費時間讀取。
  1. 讀寫 Region Server
    在得到真實資料所在的 Region Server 之後，客戶端便通過RPC介面向目標 Region Server 發起訪問。
    對於一些批量請求，客戶端會先通過Region 進行分組，再併發的向多個 Region Server 發出請求。

對於使用 Rest Server 或是 Thrift Server 等中間元件的情況，呼叫流程如下圖：

四、 鑑權

HBase 的安全同時依賴於 Zookeeper、HDFS。

ACL許可權

HBase 支援RWXCA許可權模型設定：

讀取（R） - 可以讀取給定範圍的資料。
寫入（W） - 可以在給定範圍寫入資料。
執行（X） - 可以在給定範圍內執行協處理器端點。
建立（C） - 可以在給定範圍內建立表或刪除表（甚至不建立它們）。
管理員（A） - 可以執行群集操作，例如在給定的範圍內平衡群集或分配區域。

需要以最小許可權原則為資料庫表配置對應的使用者許可權

同樣，為了保證整體的安全性，需要對ZooKeeper、HDFS都設定合理的ACL控制，包括檔案系統。

身份認證和授權

HBase 叢集中可使用KerberOS來實現節點之間的身份鑑權，包括：

  • 節點接入 Zookeeper
  • 節點連線 Master、RegionServer
  • 節點接入 HDFS
  • 外加的 Rest Server、Thrift Server

Kerberos 是一個常見的身份認證及鑑權協議系統，使用 Kerberos 的系統在設計上採用C/S結構及AES對稱加密技術，並且能夠進行雙方認證。
支援防止竊聽、防止replay攻擊、保護資料完整性等特性。 Kerberos 認證過程需要依賴於單獨的 Kerberos Server(KDC)，一個認證過程如下圖：

  1. Kerberos Authentication: 客戶端請求認證伺服器(AS)，獲得Ticket Granting Ticket (TGT)
  2. Kerberos Authorization: 客戶端通過TGT票據請求TGS(Ticket授權服務)，通過後會獲得一個授權的Service Ticket
  3. Service Request: 客戶端使用Service Ticket訪問目標服務，目標服務會對Service Ticket進行本地校驗，如果通過則表示認證成功。

關於KerberOS的詳細原理，可以參考NoSQL漫談-圖解 KerberOS這篇文章

對於HBase叢集來說，各個節點使用KerberOS認證時，需要先配置keytab檔案，該檔案中就記錄了實體ID(pricipal)、以及金鑰的資訊。
而這些實體ID及金鑰都是由KerberOS 服務生成並管理的。

傳輸層安全

  • 對客戶端RPC 設定hbase.rpc.protection=privacy可以開啟RPC加密功能，這對效能存在一定損失(約10%)
  • 還可以使用TLS傳輸協議進一步提升安全性。

五、 高可靠

1.叢集高可靠

Zookeeper 高可靠

Zookeeper 本身是叢集多節點的架構，其內部使用 Paxos 演算法來實現選舉和資料的強一致性。
在部署上通常可以選擇3節點的架構來保證可靠性。

Master 高可靠

HBase 可以開啟 Backup Master 來實現 Master 節點高可用，同一時間內只有主 Master 可以工作，Master 宕機後由 備Master 自動接管
Master 的 HA 機制是藉助 Zookeeper 完成的

RegionServer 高可靠

Region Server 通常會部署為多個節點，每個節點分別接管不同的 Region
而 Master 會對 Region Server 的狀態進行檢測，一旦發現 Region Server 宕機，則會將該 Server 上的 Region 列表重新指派給一個新的 Region Server。
此外，Master還會將已宕機的Region Server的HLog 做一定拆分，並分發到新的 Region Server 上做資料恢復。

該過程不涉及資料遷移，只是元資料的變更，操作資料量少並不會對業務造成很大的影響。

資料高可靠

Region Server 本身提供了 HLog(WAL) 來提供斷電保護，當Server 異常宕機時，MemStore內丟失的資料可以通過 HLog 來回放恢復。

HDFS 高可靠

HDFS 本身提供了一系列的可靠性機制，包括：

  • NameNode可以部署多個
  • DataNode可以部署多個
  • HFile 存在多副本(預設3個)，保證了資料檔案可靠性

2. 隔離性

在部署上，通常依據一些原則策略來保證可靠性：

  • 控制節點與資料節點分離部署
  • 主備Master、Region節點分離部署
  • NameNode之間、DataNode之間分離部署
  • 資料節點磁碟物理隔離

3. 容災

儘管HDFS提供了三副本的機制，但對於關鍵業務來說，往往需要支援跨機房的容災能力。

HBase 支援 Replication 機制，該機制設計的主導思想是基於操作日誌 (put/get/delete) 做資料同步的功能，這類似於MySQL的BinLog，或者是MongoDB的OpLog。
Replication的關鍵就在於前面所提到過的 HLog，這個日誌除了用作資料斷電保護之外，還被用來實現叢集複製的功能。

如下圖：

客戶端的 put/delete 操作會先被 RegionServer 寫入本地的 HLog ，之後由一個獨立的執行緒將 HLog 內容以緩衝寫的形式推送到 Slave 叢集中的某個 Region Server 上。
整個複製的HLog資訊、包括複製偏移量都會儲存在 Zookeeper上，同時複製動作是非同步的，即不會阻塞當前的客戶端讀寫。

參考文件

HBase 深入淺出
詳細介紹了HBase的由來以及特性，文中提供了HBase叢集、儲存機制的一些簡介，非常適合入門閱讀
https://www.ibm.com/developerworks/cn/analytics/library/ba-cn-bigdata-hbase/index.html

HBase叢集元件通訊埠(較全)
https://blog.cloudera.com/blog/2013/07/guide-to-using-apache-hbase-ports/

HBase-所有Region切分的細節都在這裡了
http://hbasefly.com/2017/08/27/hbase-split/?dspinw=x0dnj2&xwlcvg=jhww23

一條資料的HBase之旅
http://www.nosqlnotes.com/technotes/hbase/hbase-overview-concepts/

Hbase架構與原理
https://www.jianshu.com/p/3832ae37fac4

HBase的一致性
https://www.cnblogs.com/captainlucky/p/4720986.html

深入理解HBase Memstore
https://www.cnblogs.com/cxzdy/p/5121365.html

HBase Region Balance實踐
http://openinx.github.io/2016/06/21/hbase-balance/

阿里Hbase的業務和容災實踐
http://velocity.oreilly.com.cn/2013/ppts/hbase_automated_operation_and_disaster_recovery_in_ali.pdf

關於HBase 的安全
http://www.mamicode.com/info-detail-449760.html

圖解KerberOS
http://www.nosqlnotes.com/technotes/kerberos-protocol/

HBase 官方文件中文版
https://www.w3cschool.cn/hbase_doc/hbase_doc-caye2osm.html

相關推薦

Guitar Pro中文版下載，你想要的，都在這啦！

全能 cnblogs strong 開始 demo 愛好 blank 支持 詳細 我的音樂我做主！Guitar Pro7中文版的發布為更多音樂愛好者帶來更多更優質的體驗！為幫助所有吉他愛好者學習、繪譜、創作而設計的音樂空間！為前所未有的音樂盛聽而震撼，音樂才子，等的就是你！

你想要的我都有

首先建立一個繼承於UITableViewController的類 var sectionName:[String] = [] var rowName1:[String] = [] var rowName2:[String] = [] var rowName3:[String] = [] va

sqoop安裝與快速使用-----你想要的sqoop都在這裡

場景 傳統型缺點，分散式儲存。把傳統型資料庫資料遷移。 Sqoop安裝部署 1)下載安裝包 2)解壓 tar -zxvf .tar 3)修改配置 vi sqoop-env.sh export HADOOP_COMMON_HOME=/root/hd/hadoop-2.8.4

移動端適配，你想要的這裡都有

移動端畫素的概念   移動端有兩種畫素的概念，一種是裝置物理畫素，另一種是裝置邏輯畫素，裝置邏輯畫素是與裝置物理畫素無關的。 比如，iPhone的螢幕解析度： iPhone5 ：邏輯畫素解析度 320 * 568，物理畫素解析度 640 * 1136(裝

你想要的 HBase 原理都在這了

目錄 一、 叢集架構 叢集角色 工作機制 二、儲存機制 A. 儲存模型 B. LSM 與 Compaction C. Region 分裂

不吹不擂，你想要的Python面試都在這裏了【315+道題】

def 每天 leet soup XML unique 通信 cors 後進先出 https://www.cnblogs.com/wupeiqi/p/9078770.html 近日恰逢學生畢業季，課程後期大家“期待+苦逼”的時刻莫過於每天早上內容回顧和面試題問答部分【臨

移動安全技能提升播報，你想要的這類都有！

ges 能力 毫無 安卓 如何 種類 漏洞挖掘 樂趣 疑問 近年來，利用app滲透工具展開攻擊的案例層出不窮，受害者也與日俱增。雖說只要消除安全漏洞就能夠杜絕這些攻擊，但這就需要安全從業者掌握正確的安全知識。 隨著移動互聯網的迅速發展，智能手機，平板電腦，一些可穿戴設備逐漸

最新學習資料，你想要的這裏都有！

工具 sele 移動 頁面開發 全棧 百度網盤 深入 實戰 管理 H5&JS進階與組件化網頁開發 Java Web進階：數據庫與MyBatis入門-職業路徑 Java Web強化：SSM框架整合-職業路徑 Java 仿抖音短視頻小程序開發 全棧式實戰項目 Nginx

iOS開發中高階進階書籍資源彙總（你想要了解的這裡都有）

最近很多同事跟我說，雖然開發時間不短，但是，說實話在工作過程中接觸書籍的時間少之又少。今天，讓我來給大家推薦幾本比較好的書籍，包括 （網路層、架構、程式設計、程式設計思想、進階、動畫、資料結構與演算法、Swift、跨平臺、面試文件）。 希望對大家的開發有幫助！！！ 一、網路層  

iOS開發書籍資源彙總（你想要了解的這裡都有）

最近很多同事跟我說，雖然開發時間不短，但是，說實話在工作過程中接觸書籍的時間少之又少。今天，讓我來給大家推薦幾本比較好的書籍，包括（網路層、架構、程式設計、程式設計思想、進階、動畫、資料結構與演算法、Swift、跨平臺、面試文件）。希望對大家的開發有幫助！！！一、網路層二、架

iOS 二維碼掃描（你想要的都在這裡了）

#pragma mark - imageToTransparent void ProviderReleaseData (void *info, const void *data, size_t size){ free((void*)data); } + (UIImage*)imageBlackToTransp

你想要的Python面試都在這裡了【315+道題】

第一部分 Python基礎篇（80題）1、為什麼學習Python？2、通過什麼途徑學習的Python？3、Python和Java、PHP、C、C#、C++等其他語言的對比？4、簡述解釋型和編譯型程式語言

計算機視覺學習之路（目錄）------你想要的都在這裡了

## 計算機視覺學習之路------你想要的都在這裡了 (根據自己的學習進度後期不斷更新喲！！！) ### 一、OpenCV+TensorFlow入門人工智慧影象處理基礎 [1.anaconda一站式環境的搭建（anaconda、tensorflow、opencv）](https://www.cnblo

【Spring】IOC容器註解彙總，你想要的都在這兒了！！

## 寫在前面 > 之前，我們在【Spring】專題中更新了不少關於Spring註解相關的文章，有些小夥伴反饋說，看歷史文章的話比較零散，經常會忘記自己看到哪一篇了。當開啟一篇新文章時，總感覺自己似乎是看到過了，又感覺自己沒有看到過。那怎麼辦呢？為了小夥伴們檢視方便，我在這裡將Spring註解的使用方

全開源ASP.NET工作流快速開發平臺，你想要的強大工作流引擎就在這裏！

名詞 全面 節點 eight 想要 stat 生活 委托 的人 現在辦公要流程化，營銷也有流程，流程現在已經是各種生活活動不可缺少的一部分了。就像這句耳熟能詳的話：“凡事，我們先走個流程嘛！”，在信息化、流程化的背景下。工作流引擎，這個名詞就出現了！那麽，什麽是工作流引擎呢

大數據：數據大合集，你想要的這裏或許會有

數據資源大數據時代，用數據做出理性分析顯然更為有力。做數據分析前，能夠找到合適的的數據源是一件非常重要的事情，獲取數據的方式有很多種，不必局限。下面將從公開的數據集、爬蟲、數據采集工具、付費API等等介紹。給大家推薦一些能夠用得上的數據獲取方式。 一、公開數據庫 1.常用數據公開網站 UCI：經典的機器學習、

Word神器！輸入幾個字你想要啥都能給你！就是哆啦A夢的口袋啊！

今天小編教大家一個word神奇功能，你想要什麼就有什麼，當你輸入幾個字，點選【F3】，就能自動彈出你想要的內容，是不是很神奇，這一款功能，他的名字叫做【自動圖文集】。我們來看看吧！   1. 如圖效果顯示，當我們在word的輸入"個人簡歷，"就能自動彈出一份簡歷模板，輸入"房

你想要的巨集基因組-微生物組知識全在這(180901)

徵稿、轉載、合作 文章分類導航目錄 精選文章推薦 培訓、會議、招聘廣告 科研經驗 軟體和資料庫 擴增子分析 巨集基因組分

你想要的巨集基因組-微生物組知識全在這(181001)

文章目錄 徵稿、轉載、合作 文章分類導航目錄 精選文章推薦 培訓、會議、招聘廣告 科研經驗 軟體和資料庫 擴增子分析 巨集基因組分析 R統計繪圖 實驗設計與技

這就是你想要的 C#8.0 和.NET Core 3.0

      C# 的下一個主要版本是 8.0。我們已經為它工作了很長一段時間，即使我們構建併發布了次要版本 C# 7.1, 7.2 和 7.3，我仍然對 8.0 將帶來的新特性感到非常興奮。 目前的計劃是 C# 8.0 將與 .NET Core 3.