我最终决定做的是：
分析并将该点归类为无用或有用。
用它的tsuid检索点
使用api/注解端点，使用tsuid向其添加本地注解

这个链接很好地解释了opentsdb版本2.3如何处理数据修改。我的理解是2.4是相似的。

http://opentsdb.net/docs/build/html/user_guide/writing/index.html#duplicate-data-points

简而言之：它取决于该点每次写入的数据类型以及是否发生压缩。如果数据类型相同（包括#字节），并且没有压缩，那么它将工作。如果压实了，它就不起作用了。如果数据类型不同，则它将不起作用。将tsd.storage.fix\u duplicates设置为true将允许上述场景遵循last write win策略。
引用相关章节
在opentsdb中写入数据点通常在原始写入的一小时内是幂等的。这意味着您可以在时间戳1356998400处写入值42，然后在同一时间再次写入42，不会发生任何不好的情况。但是，如果启用了压缩以减少存储消耗，并在压缩数据行后写入相同的数据点，则在查询该行时可能会返回异常。如果尝试用相同的时间戳写入两个不同的值，则在查询期间可能会引发重复的数据点异常。这是由于1、2、4或8字节上的整数和浮点数的编码不同造成的。如果第一个值是整数，第二个值是浮点，则将始终引发重复错误。但是，如果这两个值都是浮点数，或者它们都是可以在同一长度上编码的整数，那么如果行上没有发生压缩，则原始值可能会被覆盖。
在大多数情况下，如果写入了重复的数据点，则通常表示数据源出了问题，例如进程意外重新启动或脚本中出现错误。opentsdb在查询包含一个或多个重复项的行时会抛出异常，从而“安全”地失败，这样就可以解决问题。
使用opentsdb 2.1，您可以通过将tsd.storage.fix\u duplicates配置值设置为true来启用上次写入wins。启用此标志后，在查询时，将返回记录的最新值，而不是引发异常。日志文件中还将写入一条警告，指出发现了重复项。如果同时启用压缩，则原始压缩值将被最新值覆盖。
对于第二个问题，度量可以有一个或多个与之关联的标记k/v。因此，度量可以有几个公共或不相交的tagk空间以及相关的tagv。