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时间戳修改带来的问题有哪些”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注亿速云行业资讯频道！