hbase時間戳修改帶來的問題有哪些

這篇文章主要介紹hbase時間戳修改帶來的問題有哪些，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

公司業務：數據錄入的時候，同一時刻，一條數據的某個字段存在多版本情況。
根據資料，hbase 插入數據的時候可以手動設置時間戳，這樣把多個版本的時間戳區別開，但是發現hbase數據不能刪除。

經過分析，這是由于：插入數據時候，人為設定的時間戳大于，刪除的時間戳。 當client端系統時間大于集群系統時間，就會可能出現這種情況。

作結，hbase java代碼部署的client服務器，最好和集群hbase服務器時間做同步，就會避免以上問題。

像OB，HBase這種存儲系統，插入數據的時候，一般數據上都會有一個時間戳(ts)。

Hbase有一個TTL（time to live），可以標識數據的有效期，比如，可以把TTL設置成86400*1000，也就是說數據將于1天后過期。這是一個表級的設置，必須在建表時指定。

但是如果說你需要存儲某一天內的數據，到第二天0點失效。這種情況TTL是沒法控制的，因為TTL只能控制數據在一段時間后失效，而不能控制在特定的時間點失效。

TTL的本質是通過對比數據的ts，與當前系統時間，然后確定是否應該失效，于是，我們可以通過ts來hack一下。

假設數據的TTL是1天，如果我在凌晨1點插入數據，那么正常情況，它會到第二天凌晨1點失效。實際上就是判斷：currentMilliseconds - ts > 86400*1000，如果滿足，數據就失效了。

這時如果要控制數據在第二天0點就失效，我們把插入數據的ts往后推一小時就可以了，它就會提前失效。

這個方案理論上看起來沒有問題，但是如果你的表涉及到刪除數據，那么，坑就來了。

HBase普通的操作，都會寫入WAL（Write ahead log），累積到一定數量后（或者根據時間），根據操作的ts，進行merge，然后對真實的數據做commit，這個跟數據庫的log是有點類似的。

這里面隱含的一點是，hbase中的操作，是需要ts比當前數據中的ts大，操作才會有效，否則就無效（正常的都是這樣的，因為時間是不斷變大的嘛）。

比如當前有2個操作：

put 'key', 'value', ts=1

put 'key', 'value', ts=2

那么經過合并后，實際上只會有一個操作：

put 'key', 'value', ts=2（因為這個時間戳比較大嘛）

接著來，如果有3個操作：

put 'key', 'value', ts=1

put 'key', 'value', ts=2

del 'key', 'value', ts=3

那么，合并后，就只有delete的操作了。

坑就在這里，因為我們是手動設置插入數據的ts的。這就意味著，如果要刪除數據，那必須要將刪除操作的ts設置得比原來的數據的ts要大（在我們的情況中，兩個時間都是未來）。

如果刪除操作，使用了系統默認的ts，那么造成的結果是：數據無法被刪除。

OK，那我們就知道，會將刪除的ts設大。可是這時，如果你再插入數據，就必須將插入數據的ts設置得比刪除操作的ts還要大。。。其實就是，對同一個cell的操作，要想你的操作有效，你必須將它的ts設置為比當前操作序列中最大的還要大。。。

然后，如果一不小心，你想當然地把刪除的ts設置成了Long.MAX_VALUE，你就會發現，你永遠也插入不了數據了。。。。（其實不是永遠啦，要到下一次major compact）。

以上是“hbase時間戳修改帶來的問題有哪些”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！