問題描述
我們有個系統設計的時候針對Hive創建表、洗掉表, 需要更新ES中的一個狀態,標記是否洗掉,在幾乎同時執行兩條下面的陳述句的時候,發現在ES 中出現表即使被創建了還是無法被查詢到的情況,針對該問題記錄下排查分析程序.
drop table if exists tmp.test_create_table;
create table if not exists tmp.test_create_table(
id int,
name string
) stored as parquet;
問題排查
查看ES資料
發現ES創建表的狀態沒有正常更新 yn 還是0
查看日志
查看日志, 截取部分關鍵資訊:
ReceiverController] [4eb1c8fd7b6987ae] - 接收的hive元資料為:{"data": ...
"eventType":"DROP_TABLE" ...
ReceiverController] [d1aa226b8739d352] - 接收的hive元資料為:{"data": ...
"eventType":"CREATE_TABLE" ...
[Kafka-Consume-Thread-bigdata_aa-0] [ec812addb0bf424d] - update table data to es: ... "yn":0}
[Kafka-Consume-Thread-bigdata_aa-0] [3085b7329053aaac] - update table data to es: ... "yn":1}
日志里有幾個關鍵線索：
-
建表與洗掉表的Hive元資料資訊正常上報上來了
-
建表刪表事件都執行了更新資料到ES的操作， [Kafka-Consume-Thread-bigdata_aa-0] 可以看出是單執行緒更新ES， 所以不會存在多執行緒并發的問題
-
基本可以定位是在es更新這塊出問題了
看對應代碼
final TableDocBean docBean = baseSearchService.getById(id);
setValueForBean(afterColumns, docBean);
log.info("update table data to es: {}", JSON.toJSONString(docBean));
baseSearchService.update(docBean);
代碼先通過表id 獲取對應ES檔案，然后賦值 執行更新資料操作
這塊沒有看出什么問題，考慮到兩個事件同時執行時間間隔較短，采用了在代碼里Thread.sleep(1000) 睡眠下試試，發現兩條SQL陳述句同時執行的基本每次都成功，可以在ES搜索到.
這種操作不免讓人覺得ES里執行更新操作，肯定是有延遲的，具體為什么延遲，就需要看下ES的更新原理
更新原理
ES更新請求先將index-buffer中檔案（document）決議完成的segment寫到filesystem cache之中，這樣避免了比較損耗性能io操作，又可以使document可以被搜索 , 從index-buffer中取資料到filesystem cache中的程序叫做refresh，es默認的refresh間隔時間是1s
ES資料在更新的時候并不是在原來的資料上做修改的, 而是找到該資料的索引Id，把原來的資料刪掉，再重新插入一條，但索引id是相同的
當洗掉、更新兩個操作間隔很短時間執行，上一個資料還沒有refresh 到 FileSystem Cache區域，就無法查詢，final TableDocBean docBean = baseSearchService.getById(id);
獲取不到資料，所以會導致資料更新失敗
解決方案
修改ES refresh到cache區域間隔時間:
curl -XPUT http://ip:9200/meta_es_data/_settings?pretty -d '
{
"refresh_interval" : "500ms"
}'
在每次更新操作后，休眠1s:
baseSearchService.update(docBean);
Thread.sleep(1000);
ES 請求介面有請求后強制重繪方法，但是一般用于測驗，不建議線上用
setRefreshPolicy(WriteRequest.RefreshPolicy.IMMEDIATE);
總結
- 不要忽視一個看起來貌似是一個小的問題,其背后有一定的設計、原理在里面
- 代碼關鍵處加一些有意義且清晰的日志是非常必要的, 可以提高解決問題的效率
- 排查問題就像破案,要有耐心找到一個個關鍵線索,最終破案. 現實作業中解決問題的能力非常重要
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/299296.html
標籤：其他