背景使用者/內容畫像的對儲存的要求其實是比較高的：
能批量更新（比如更新所有使用者某個屬性）
大量隨機讀取（甚至可能沒有熱點資料）
隨機屬性更新/新增
可持久化
易於橫向擴充套件解決效能問題
上一次重度使用hbase已經是兩年前了。hbase能夠滿足上面五個要求，所以用hbase作為畫像體系的主要儲存引擎便水到渠成。
問題因為有批量更新，隨機屬性的更新/新增，那麼必然會快取失效，從而觸發磁碟io導致讀取響應時間受到影響。在畫像體系裡，隨機讀取量大，比如召回了1000個id,然後你需要取這1000個id的屬性集合，並且要求響應時間能夠控制在100ms。基本只要碰到磁碟io就歇菜了。所以現在我們希望hbase能夠把所有資料都快取住。
hbase讀快取特色
hbase的快取目前我所了解的是block cache. block cache是什麼概念的呢，我們知道hbase的最小檔案單元是hfile, hfile是有結構的，主要包含：
索引，可以是多層
資料元資料
當然還有乙個布隆過濾器，方便確定乙個元素是不是在hfile裡。
並且只會有三個動作：
新增hfile
hfile 合併
hfile的**
這裡需要注意hfile一旦生成裡面的元素就不會被改變。
乙個hfile的資料會被切分成多個block,每個block一般而言都會有一些元資訊。當然這些切分其實是邏輯上的。block cache就是前面三部分的cache. 在hbase裡，當開啟乙個hfile時，缺省會cache住一些索引資訊，檔案資訊，讀取時則會連資料都會cache起來。當然你也可以通過引數讓hbase在開啟時就把資料cache住。
如果是傳統意義上的快取，如果有更新，那麼必然會導致乙個問題：快取失效。但是hbase其實並沒有這個問題。乙個簡單的get請求，hbase的讀取方式是讀memstore 和hfile，讀hfile的時候會看資料是不是已經在blockcache裡。
memstore，這個是寫快取，但是是有結構的，可以直接查。
blockcache, 這個是讀快取，也是有結構的，可以直接查。
hfile，這個就是hdfs檔案，會touch到io。
假設我在讀取的時候，memstore沒有進行flush,那麼可能不會觸碰到磁碟，雖然blockcache的資料已經是老版本的了，memstore裡卻有最新版本的資料，所以hbase簡單的到memstore/blockcache都拿一遍。第二次再來拿，假設正好碰到memstore flush生成新的hfile,這個時候就觸發磁碟io了。當然，其他如compaction也會導致觸發磁碟。
解決方案
下面解決方案的前提是，可用於blockcache的記憶體大於你的資料。在畫像體系裡，這點可以做到的，因為內容和使用者都是有限的。
hfile.block.index.cacheonwrite 寫hfile時把索引加入到cache
hfile.block.bloom.cacheonwrite 寫hfile時把布隆過濾器加入到cache
hbase.rs.cacheblocksonwrite 寫hfile時把資料也寫入到cache裡
這裡我們基本知道寫cache的幾個時機點：
開啟hfile
讀hfile
寫hfile
大資料體系之HBase的產生
一 關係型資料庫的缺陷 1 很難進行分布式部署，i o瓶頸顯著，依賴於強大的伺服器。2 難以處理非結構化資料 二 cap定律 推動關係型資料庫向非關係型資料庫轉變 在任何分布式系統中，只可能滿足一致性，可用性和分割槽容忍性三者中的兩者，不可能全部滿足。三 什麼是分割槽容忍性 一 分割槽 在乙個分布式...
HBase體系結構
hbase hbase是apache hadoop的資料庫，基於hdfs檔案系統 random,realtime read write access to big data 開源 分布式 可擴充套件 面向列 larger tables billions of rows x millions of c...
HBase體系結構
hbase的伺服器體系結構遵從簡單的主從伺服器架構，它由hregion伺服器 hregion service 群和hbase master伺服器 hbase master server 構成。hbase master伺服器負責管理所有的hregion伺服器，而hbase中所有的伺服器是通過zooke...