共計 1472 個字符，預計需要花費 4 分鐘才能閱讀完成。

這篇文章主要介紹 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 時間戳修改帶來的問題有哪些”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注丸趣 TV 行業資訊頻道！