共计 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 行业资讯频道！
