一、寬表和高表定義
HBase 中的表可以設計爲高表（tall-narrow table） 和 寬表（flat-wide table）：
- 寬表是指很多列較少行，即列多行少的表，一行中的數據量較大，行數少；
- 高表是指很多行較少列，即行多列少，一行中的數據量較少，行數大。
二、寬表和高表的優劣
HBase的鍵分爲兩種：
- 列鍵：包括了列族名和限定符，定位到列的索引
- 行健：相當於關係型數據庫中的主鍵，通過行健得到邏輯佈局中一行的所有列
由於列鍵是由列族名和限定符組成的，屬於定位具體 StoreFile 的，所以應該將需要查詢的維度或者信息存儲在 row key 中，因爲用它來篩選數據效率最高！
Hbase 的 row key 是分佈式的索引，也是分片的依據。Hbase 的 row key + column family + column qualifier + timestamp + value 是 HFile 中數據排列依據。
據此，在HBase中使用寬表、高表的優劣總結如下：
- 查詢性能：高表查詢更好，因爲查詢條件都在 row key 中，是全局分佈式索引的一部分。高表一行中的數據較少。所以查詢緩存 BlockCache 能緩存更多的行，以行數爲單位的吞吐量會更高。
- 分片能力：高表分片粒度更細，各個分片的大小更均衡。HBase按行來分片，高表一行的數據較少，寬表一行的數據較多。
- 元數據開銷：高表元數據開銷更大。高錶行多，row key 多，可能造成region 數量也多，- root -、 .meta 表數據量更大。過大的元數據開銷，可能引起 HBase 集羣的不穩定、master 更大的負擔。
- 事務能力：寬表事務性更好。HBase對一行的寫入（Put）是有事務原子性的，一行的所有列要麼全部寫入成功，要麼全部沒有寫入。但是多行的更新之間沒有事務性保證。
- 數據壓縮比：如果我們對一行內的數據進行壓縮，寬表能獲得更高的壓縮比。因爲寬表中，一行的數據量較大，往往存在更多相似的二進制字節，有利於提高壓縮比。通過壓縮，緩解了寬表一行數據量太大，並導致分片大小不均勻的問題。查詢時，根據 row key 找到壓縮後的數據，進行解壓縮。而且解壓縮可以通過協處理器（coproesssor）在 HBase 服務器上做，而不是在業務應用的服務器上做，以充分應用 HBase 集羣的CPU能力。
三、寬表和高表的應用場景
3.1、高表的應用
在一個電子郵箱系統中，將行健設置爲用戶的唯一ID，其餘屬性作爲列族或者列族中的列，如此一來，同一個用戶的所有郵件信息都會被存儲在同一行中（因爲他們的行健相同），這在大部分情況下是通用的，但是有些用戶的郵件數量非常非常大，大到一行數據就超出了HFile 的最大限度，這樣一來，寬表設計方式就出現了致命的缺陷：表數據無法拆分，更無法進行 HBase 的負載均衡等特性。
PS：也許會有疑問，HFile 和 Region 達到一定大小的時候不是會自動切分的嗎？ 這是因爲HBase 只能按行切分，當行數量達到閾值的時候會根據行健進行切分。
解決這個問題更好的辦法是代替寬表，設計一個高表： 可以將行健設置爲用戶Id + 郵件Id，這樣一來，每封郵件都是單獨的一行，將寬表中的行數據釋放出來。
這樣做的好處是：
- 行數量可以更容易的被拆分；
- 行健中包含關鍵的篩選信息（郵件 Id 被移到了 row key），用戶可以直接根據行健定位到唯一的一封郵件；
- 擁有很好的擴展性，高表也是推薦的用法。
但是要使用高表還是寬表還要根據具體的業務場景來確定，因爲在以上高表的設計中，同一用戶的數據分佈在多行中，用戶不可能在一個簡單的操作中修改一個收件箱的全局屬性，因爲這涉及到了原子性的操作，如果用戶沒有一次修改整個收件箱的需求時，這種設計是非常合適的，但是如果用戶真的有這種需求，而且需求很大，那麼寬表反而更加合適，因爲 HBase 能夠保證行級別的原子性。
3.2、寬表的應用
Hbase 寬表可以應用在社區系統中，比如 BBS：可以用帖子的 Url 地址作爲row key 保存，而後面的每一個回覆，作爲列族中單獨的列。回覆越多，列族中單獨的列就越多，表就變寬了。
設計表時，可以不絕對追求高表、寬表，而是在兩者之間做好平衡。根據查詢模式，需要分佈式索引、分片、有很高選擇度（即能據此查詢條件迅速鎖定很小範圍的一些行）的查詢用字段，應該放入row key；能夠均勻地劃分數據字節數的字段，也應該放入 row key，作爲分片的依據。選擇度較低，並且不需要作爲分片依據的查詢用字段，放入 column family 和 column qualifier，不放入row key。
文章來源：https://blog.csdn.net/w1992wishes/article/details/95210789