使用phoenix踩的坑與設計思考
本文主要介紹在壓測HBase的二級索引phoenix時踩的一個坑，使用時需要特別注意，而且背後的原因也很有意思，可以看出HBase和Phoenix對元資料設計上的差異。
1.問題介紹
在做phoenix壓測時發現一個奇怪的現象。
壓測請求分佈非常均勻，但是有一臺機器的流量、負載都明顯高於其他機器。
如下圖所示。
請求均勻
資源利用率不均勻，單個節點明顯偏高。
2.排查思路
看到這個問題的第一反應，是去看下錶分佈是否均勻。
- hbase表分佈是否均勻
- 索引表分佈是否均勻
令人遺憾的是，確認後hbase表和索引表都是均勻分佈的，各個機器上的region數量、儲存用量都是一致，非常均勻。
然後在網上查相關資料，在官網上看到這樣一段描述。（http://phoenix.apache.org/language/index.html）
UPDATE_CACHE_FREQUENCY option (available as of Phoenix 4.7) determines how often the server will be checked for meta data updates (for example, the addition or removal of a table column or the updates of table statistics). Possible values are ALWAYS (the default), NEVER, and a millisecond numeric value. An ALWAYS value will cause the client to check with the server each time a statement is executed that references a table (or once per commit for an UPSERT VALUES statement). A millisecond value indicates how long the client will hold on to its cached version of the metadata before checking back with the server for updates.
大致的意思是，phoenix的表設計時有一個表級別引數UPDATE_CACHE_FREQUENCY，這個引數預設是ALWAYS，表示每次sql查詢都會先去請求meta資料。也可以設定為一定頻率，表示多久去請求一次meta資料。
那我們大概能猜想到了，因為設計表的時候沒有指定這個引數，所以為預設的always，而phoenix的meta資料正好落在了那個機器上。
我們查驗了下系統表的位置，果然如此！
於是立刻做了變更
alter table xxx set UPDATE_CACHE_FREQUENCY = xxxxx。
效果顯著！
不僅流量、負載均勻了，而且整體負載下降了很多！！！
那為什麼監控上請求量是均勻的呢？因為phoenix需要訪問catalog表，然後這個表剛才在core-2上，訪問這個表走的coprocessor，所以沒統計出請求數。
3.進一步思考
到上面為止，問題的原因找到了，也解決了。
但是熟悉HBase的同學肯定會馬上有個疑問，跟我一樣。為什麼會有這樣一個引數設定，HBase本身也有meta表，而HBase的meta表在客戶端快取就可以。
下面，就讓我們來思考下。
1）phoenix為什麼要這麼設計呢，而不是像hbase的meta表一樣？
這個問題得從phoenix的架構設計說起。
phoenix一直以來，都是重客戶端模式，即使是現在的輕客戶端版本，本質也是如此。只不過把客戶端放在了query server這個角色上，讓query server跑在服務端了。
但對hbase來說，phoenix的核心邏輯都在client側。元資料管理也是如此。phoenix和HBase不同的是，phoenix的元資料更復雜，如果元資料有變化，沒有拿到最新meta的客戶端不一定會拋錯。
舉個例子，比如一個查詢命中索引後會更高效。但是，某個客戶端它 不知道有這個索引表，於是就去查了主表，這個在phoenix上看也沒有毛病。
所以，關鍵原因是phoenix無法感知元資料是否發生了變化！而HBase可以。
因此，最初為了解決元資料同步的問題，就採用了比較激進的每次重新整理的方式。後來發現會影響效能，就加了一個週期性重新整理的功能，來避免per request去刷meta資料。
2）那可以alter table時觸發meta更新嗎？
這個是不可以的。因為客戶端可能比較多。而且，也不會有一個地方去記錄全域性有哪些client。即使有這樣一個地方，那某個client掛了怎麼辦？沒有通知成功怎麼辦？此時，alter操作是成功還是不成功呢？
3）結論
所以這個引數是phoenix的設計，而不是缺陷。phoenix預設情況下，每個請求都會去校驗一次表的元資料資訊，以避免因meta未重新整理導致失敗。為此，phoenix提供了一個表引數，來控制meta的重新整理頻率，比如1分鐘刷一次，類似這種。
可以在建表的時候設定：
craete table if not exists ns.table_demo (
id varchar not null primary key,
f1.a varchar,
f1.b varchar,
f1.c varchar
)
TTL=86400,
UPDATE_CACHE_FREQUENCY=900000;也可以變更表結構設定：
alter table xxx set UPDATE_CACHE_FREQUENCY = xxxxx; 設一個你期望的重新整理時間，就可以解決問題了。
當然，這樣帶來的副作用就是，如果未來你修改了這個表，比如add了一個新的列，或者新加了一個索引，最少要等待一個重新整理週期才能生效。但是無關大局，一般表結構變更就屬於低頻操作，而且能夠接受一定延遲。
看到這裡了，原創不易，點個關注、點個贊吧，你最好看了～
知識碎片重新梳理，構建Java知識圖譜：https://github.com/saigu/JavaKnowledgeGraph（歷史文章查閱非常方便）