雲上祕史 第一章 ： 緣起HBase
在遙遠的雲上，有著另一個神祕的世界。
這個世界自鴻蒙初闢，各路諸侯紛紛厲兵秣馬，攻城拔寨。十多載過去，世界的格局已經基本穩定。
在西方，有著AWS、Azure、GAE等幾大巨擘；在東方，也有著Aliyun、Tencent cloud、BAE等諸位新貴，這些豪門廣納天下游俠，雨露均沾，只要你能提供酬金，便可獲得一席暫居之地。江湖上，這些諸侯被稱為：「公有云」。
除此之外，在整個世界版圖上，除去這些幅員遼闊的名門望族，自給自足式的城邦也是星羅棋佈，他們雖然是小國寡民，但是能夠保證城邦與其公民的生產資料與生活資料的生產與再生產。他們則被稱為：「私有云」。
這個世界，夜以繼日，川流不息。在這裡，每天都有新的故事發生。
第一章 緣起HBase
我叫k7a1dd497d61f5bb2a5fd3b929bce521，是一條RowKey，大家叫我k就可以啦。我一出生就身處在一個有著上億子嗣的家庭——HBase，在這裡，大家長得高矮胖瘦，各不一樣，但又摩肩接踵，沒有絲毫間隙。在這種親密接觸的情況下，我很快就認識了樓上的傢伙，它長得比我高一些，也更壯實一些。
我主動向他打招呼：“hey，你好，我叫k，你叫什麼名字呀？來這裡多久了？”
他低下頭看了看我說：“我叫j5e98a87101c51946cd4f7245ff30994,我也是剛來一會兒呢，大家都叫我小j。”
HBase是當前主流的，一種分散式的、可伸縮的海量資料儲存系統。它往往儲存著幾千萬，甚至上億條資料。相較於傳統的關係性格資料庫，它的特點是可以儲存結構化和半結構化的資料，這被稱為“稀疏矩陣”，但並不會造成空間浪費，所有資料都是緊密壓縮在一起的。
RowKey作為HBase中表示唯一一行資料的主鍵，具有唯一性。而且HBase中的行是按照RowKey進行全域性排序的，這也是為什麼初生的k在小j樓下。在HBase中，只能依賴於這個單一的查詢維度。（實際上，由於資料量很大，相同首字母的RowKey會很多，這裡只是為了易於讀者理解，在小j下面直接安排了k）
我對他說：“你好，j，我初來乍到，能給我介紹一下這裡的情況嗎？”
小j開始彰顯出了話癆的本質：“我和你說哦，雖然我也才來這三秒鐘，但是對這裡的情況已經瞭解了個大概了呢。我們的大家庭HBase，近年來不斷髮展壯大，已經名聲遠揚了，我真感到自豪,這是關鍵詞搜尋在全球的趨勢，怎麼樣厲害吧。”說著他掏出了下面這張圖。
我發出輕微的驚歎。
“不過哦，偷偷告訴你，HBase表面上風光，其實還是Hadoop的附庸，我們還是需要依賴於Hadoop的檔案系統——HDFS。”小j突然神神祕祕地，“聽‘上面’的朋友說啊，Hadoop家族的白手起家的根本是源於Google高人的三條錦囊妙計。”
我環顧四周，雖然都是RowKey緊挨在一起，但是他們都在忙著自己的事情，似乎並沒有聽到我們的談話，“哪三條？”我對Hadoop家族的神祕背景起了興致。
“三條妙計分別是：GFS、MapReduce、BigTable。”小j頓了一下，彷彿這是一個莊嚴的時刻，“我們的祖先就是繼承了BigTable中的思想作為家訓，構建了HBase大家庭。”
“我們有什麼特點呢？”我看著平平無奇的自己，不禁發出了疑問。
我的問題彷彿正中小j的下懷，他不疾不徐地給我講解起來：
首先，人多力量大。我們的特點就是：大，一張表可以容納上億行，上百萬列。這對於傳統關係型資料庫來說，是難以想象的。而且如果家庭裡不斷有資料降生，只需要橫向拓展就可以了。
因此我們雖然處在同一張Table中，但是被劃分為多個Region，Region是在Table建立之初就需要確定劃分規則的，不同的資料行會根據這個規則進入不同的Region。RowKey的命名方式以及Region的劃分會直接影響整個HBase的獨寫效率，所以需要根據實際的業務場景來確定規則。
比如”天“字輩和”地“字輩的RowKey就會劃分在不同的Region，我能和你在這相識，真是有緣。
其次，我們每一行各有自己的特點，可以由不同的列構成。不像MYSQL家族那群大眾臉，一眼望去長得都一樣。小j給我畫了張草圖來方便我的理解：
關係型資料庫例如MYSQL，就像上面這張四四方方的表一樣。
而我們則是像這樣，無需遵循千篇一律的規範，活出自己的態度。我們每一行都有一個用於排序的RowKey和任意多的列，就像我的RowKey是j5e98a87101c51946cd4f7245ff30994，所以我排在你上面。
同一張表中不同的行可以有截然不同的列，不同的列組合在一起，就成為了列族。我們也被稱為”稀疏矩陣”。
再者，我們大家生而平等，都是字串型別。而且我們都有著多個版本，這是HBase家庭自動為我們分配的，版本號就是插入時的時間戳。它記錄著我們的過去和現在。
聽了他的介紹，我大致有些明白了。於是我隨手畫了一張圖給小j確認一下，他描述的和我理解的是否是一致的。
小j看了後，點了點頭，和我開玩笑道：”真是孺子可教也。“
我若有所思，“小j你剛才提到了MYSQL，他們作為RDBMS家族中的翹楚，享譽世界，我們拿什麼和他們競爭呢？”
小j笑道：“就知道你會問我這個，這也是我之前向其他RowKey提出過的問題。MYSQL雖然和我們同門——都是資料庫，但是屬於不同的派別，HBase從廣義上來講屬於NoSQL的一種，而且我們的適用場景也不太一樣。”
他如數家珍：
- 對於PB、TB級別的資料，傳統資料庫存在嚴重的瓶頸。需要讀寫分離、分庫、分表等一系列操作，而HBase能夠自動進行水平切分，只需要增加硬體橫向拓展即可。
- HBase適合寫入密集型，其特點之一就是插入速度快，尤其是對於碎片化的小型資料，比如日誌，訊息等等。
- HBase本身不支援複雜查詢，只支援基於rowKey這個維度的查詢，但是範圍查詢後續可以通過Hive實現。
等等。
“關於HBase的大概情況，初步告訴你這些就可以啦。”小j雖然只比我早來一會，卻比我懂了這麼多，我不禁暗暗自責。
我這時也關心起家庭的境況了，連忙問小j：“那麼，HBase在整個Hadoop家族中，是處於什麼樣的地位呢？”
小j將他珍藏已久的架構圖向我展示：
我看後不禁感嘆世界之大，我只是整個系統中的一粒塵埃而已。
欲知後事如何，且聽下回分解。
文章首發於我的公眾號：位元組流