前言：古人有言，欲修仙者，財侶法地缺一不可。
所謂侶，即同修、道友。
修仙漫漫不歸路，多少人在攀登高峰的時候，或失足，或飢寒，或懈怠，倒在路邊。這個時候，假如有人扶你一把，給你半個饅頭，也許你就有了前進的動力，這就是道侶。
簡而言之，共同學習，共同**，共同進步的同志。
科普中國-百科科學詞條
hbase是乙個分布式的、面向列的開源資料庫，該技術**於 fay chang 所撰寫的google**「bigtable：乙個結構化資料的分布式儲存系統」。就像bigtable利用了google檔案系統（file system）所提供的分布式資料儲存一樣，hbase在hadoop之上提供了類似於bigtable的能力。hbase是apache的hadoop專案的子專案。hbase不同於一般的關聯式資料庫，它是乙個適合於非結構化資料儲存的資料庫。另乙個不同的是hbase基於列的而不是基於行的模式。
列簇維度、時間維度(預設3個)在 hbase 中，row-key 加上 cf（列簇） 加上 qulifier（列） 再加上乙個時間戳才可以定位到乙個單元格資料（hbase 中每個單元格預設有 3 個時間戳的版本資料）查詢命令：get 'ns_scpdm:tdm_fillup_suggest_order_d','003173091_7616_04_20171110_10127836_00360374250501'
從技術上來說，hbase 更像是"資料儲存"而非"資料庫"
因此，hbase 缺少很多 rdbms 特性，如列型別，二級索引，觸發器和高階查詢語言等。然而, hbase 也具有許多其他特徵同時支援線性化和模組化擴充。最明顯的方式，我們可以通過增加 region server 的數量擴充套件 hbase。並且 hbase 可以放在普通的伺服器中，例如將集群從 5 個擴充到 10 個 region server 時，儲存空間和處理容量都可以同時翻倍。當然 rdbms 也能很好的擴充，但僅對乙個點，尤其是對乙個單獨資料庫伺服器而言，為了更好的效能，往往需要特殊的硬體和儲存裝置（往往**也非常昂貴）。
hbase 的工作流程
無需過多了解
只是關注如何使用以及使用場景
首先，要確信有足夠多資料，如果有上億或上千億行資料，hbase 才會是乙個很好的備選。其次，需要確信業務上可以不依賴 rdbms 的額外特性，例如，列資料型別, 二級索引，sql 查詢語言等。再而，需要確保有足夠硬體。且不說 hbase，一般情況下當 hdfs 的集群小於 5 個資料節點時，也幹不好什麼事情 (hdfs 缺省會將每乙個 block 資料備份 3 分)，還要加上乙個 namenode。
其實rowkey設計準則一般就2條
1、唯一性
2、雜湊性（資料傾斜--熱點）
商品編碼一般是反轉就能雜湊，但是 如果有的商品編碼就1條記錄，有的商品編碼有幾百萬條記錄 那麼這樣資料還是傾斜掉 了。
蛋疼，這個 就涉及到了hbase的工作流程
為啥有那倆個設計原則呢？
首先，乙個 hbase 資料庫是否高效，很大程度會和 row-key 的設計有關。因此，如何設計 row-key 是使用 hbase 時，乙個非常重要的話題。隨著資料訪問方式的不同，row-key 的設計也會有所不同。不過概括起來的宗旨只有乙個，那就是盡可能選擇乙個 row-key，可以使你的資料均勻的分布在集群中。這也很容易理解，因為 hbase 是乙個分布式環境，client 會訪問不同 region server 獲取資料。如果資料排布均勻在不同的多個節點，那麼在批量的 client 便可以從不同的 region server 上獲取資料，而不是瓶頸在某乙個節點，效能自然會有所提公升。對於具體的建議我們一般有幾條：
一切都是為了搞笑-高效：
當客戶端需要頻繁的寫一張表，隨機的 rowkey 會獲得更好的效能。
當客戶端需要頻繁的讀一張表，有序的 rowkey 則會獲得更好的效能。
對於時間連續的資料（例如 log），有序的 rowkey 會很方便查詢一段時間的資料（scan 操作）。例如：key:20171201,20171202
場景、功能描述：
資料庫（包括其他一些關係型資料庫）在單錶記錄數超過100w時就會變得很慢。解決方法是分表，或者遷移到專注於處理海量資料的nosql
a）hbase對資料操作的響應速度與當前表中的資料量無關，但是與資料的split以及本地快取等配置項有很大關係。 比如rowkey的合理設計，使相關資料相鄰存放；比如使用scan時setcatch(num)方法中num的取值。
b）hbase對資料操作的響應在毫秒級，滿足我們前端顯示的需要
案例：用過濾器的前提是： 你scan的資料範圍 已經用 start 和end 限定的很小了，基於列的過濾都是沒有索引的 效能很差
結構圖：
資料傾斜：
hbase的表會被劃分為1....n個region,被託管在regionserver中。region二個重要的屬性：startkey與endkey表示這個region維護的rowkey的範圍，當我們要讀寫資料時，如果rowkey落在某個start-end key範圍內，那麼就會定位到目標region並且讀寫到相關的資料。
預設情況下，當我們通過hbaseadmin指定tabledescriptor來建立一張表時，只有乙個region正處於混沌時期，start-end key無邊界，可謂海納百川。所有的rowkey都寫入到這個region裡，然後資料越來越多，region的size越來越大時，大到一定的閥值，hbase就會將region一分為二，成為2個region，這個過程稱為**（region-split）。
如果我們就這樣預設建表，表裡不斷的put資料，更嚴重的是我們的rowkey還是順序增大的，是比較可怕的。存在的缺點比較明顯：首先是熱點寫，我們總是向最大的start key所在的region寫資料，因為我們的rowkey總是會比之前的大，並且hbase的是按公升序方式排序的。所以寫操作總是被定位到無上界的那個region中；其次，由於熱點，我們總是往最大的start key的region寫記錄，之前**出來的region不會被寫資料，有點打入冷宮的感覺，他們都處於半滿狀態，這樣的分布也是不利的。
如果在寫比較頻繁的場景下，資料增長太快，split的次數也會增多，由於split是比較耗費資源的，所以我們並不希望這種事情經常發生。
在集群中為了得到更好的並行性，我們希望有好的load blance，讓每個節點提供的請求都是均衡的，我們也不希望，region不要經常split，因為split會使server有一段時間的停頓，如何能做到呢？
隨機雜湊與預分割槽二者結合起來，是比較完美的。預分割槽一開始就預建好了一部分region，這些region都維護著自己的start-end keys，在配合上隨機雜湊，寫資料能均衡的命中這些預建的region，就能解決上面的那些缺點，大大提供效能。
解決思路-額外：
提供兩種思路：hash與partition
HBase基本概念
1.簡介 hbase是乙個分布式的 面向列的開源資料庫,源於google的一篇 bigtable 乙個結構化資料的分布式儲存系統 hbase是google bigtable的開源實現，它利用hadoop hdfs作為其檔案儲存系統，利用hadoop mapreduce來處理hbase中的海量資料，利...
Zookeeper的基本概念與應用場景
什麼是 zab zookeeper 的應用場景 zookeeper 是一種分布式協調服務，用於管理大型主機。在分布式環境中協調和管理服務是乙個複雜的過程。zookeeper 通過其簡單的架構和 api 解決了這個問題。zookeeper 允許開發人員專注於核心應用程式邏輯，而不必擔心應用程式的分布式...
HBase內的基本概念
在搭建集群的時候,我們需要去了解hbase各個部分是做什麼的,否則一上來就找文章進行搭建,完全就是按著人家的做,而根本不知道自己在做什麼 hbase的部署結構主要分為master伺服器和regionserver伺服器,master也可以配置ha,即乙個活動節點,乙個備用節點,當活動節點掛掉,備用節點...