OpenTsdb 写入数据

1. 关于 Metrics, value, tag name, tag value

• opentsdb的每个时间序列必须有一个metric和一个或多个tag对，每个时间序列每小时的数据保存一行。
• opentsdb的metrics, tag name, tag value的编码长度都是3byte, 所以UID的数量上限为 2^24 个。编码长度可以扩展到 8byte，即2^64 个， 一般不建议修改。
• tag name和tag value的UID分配是完全独立的，比如tag value的取值为整数2,那么这个值完全可以被多个tag name所使用， cpu=2, interface=2, hdd=2等。
• Time Series Cardinality
  
  • 这里的Cardinality指：metric的数量。默认 2^24 = 16 million
  • 在设计系统的时候，确保metric,tag name, tag value的Cardinality取值在较小的范围内，如果他们太多了，会影响到查询速度。
• 注意点：
  
  • Be consistent with your naming to reduce duplication. Always use the same case for metrics, tag names and values.
  • 对每个metric使用相同数目和相同类型的 tag name & tag value. 不要这样使用my.metric host=foo and my.metric datacenter=lga.
  • 根据常用的查询方式，设计优化的schema. 比如常用的tag，放在rowkey组合的前面(metric后)。
  • Think about how you may want to drill down when querying。下钻查询，细化查询。
  • metric的tag不要太多，尽量不要超过5个， 最多8个。
• metric和tag的命名规则：大小写敏感，不允许空格，只允许一下字符: a to z, A to Z, 0 to 9, -, _, ., / or Unicode letters (as per the specification).

2. 数据点 Data Point

• 一个Data Point必须包括：metric，至少一个tag, 时间戳, 一个数值(整数或浮点数)
• 时间戳：一定是整数，13位毫秒，10位秒。在一个序列中尽量使用同样的时间戳，混合不同单位的时间戳会引起查询变缓慢。如果没有必要，使用秒为单位，降低存储空间的消耗。
• 数值value：只能由数字和小数点组成，如果没有小数点，则认为是整数，否则是浮点数。整数使用可变长编码方式，最少一字节，最多8字节。浮点数为4字节单精度浮点数。由于浮点数是单精度类型，因此不支持需要精确值得浮点数，例如15.2会被保存为15.199999809265137
• 写入数据时，不必按照时间序列写入，时间戳在后的数据可以先写入，在写入时间戳在前的数据。
• 数据重复写入的问题：
  
  • 在同一小时内多次写入相同的数据不会有问题。
  • 如果设置compaction操作，那么如果前后两次写入的数据类型不同，则在查询时一定会抛出异常。如果两次写入的数据类型相同，那么在该行还没有进行compaction操作之前，前面的数据将被覆盖掉。
  • 2.1版本，可以设置tsd.storage.fix_duplicates=true. 最近写入的数据会被返回。

3. 数据写入方式

1. telnet方式：
   telnet ip port
   put

4. 性能点

1. UID 预先生成：尽量预先为所有的metric,tag name, tag value生成UID。 工具有：
   mkmetric, uid, /api/uid
2. Random 生成UID：如果连续的热点metric被创建时，他们生成的UID是连续，写入时会被连续的写入同一个regionserver，这样会导致热点，写入性能不是很好。在2.2版本，可以随机分配UID，设置tsd.core.uid.random_metrics即可。当然使用随机生成时，可能会由于连续冲突导致写入数据失败。降低这个概率的办法就是：增加UID的byte。

3. salting: 2.2版本，可以在rowkey的前面添加salt，使得每行数据分散在hbase不同的region上，以便写入性能更好。比如如果一个metric有100万的时间序列，则他们会被存储在一个regionserver. 添加salt以后，这100万行就会分散存储。

   tsd.storage.salt.width and optionally tsd.storage.salt.buckets

4. Appends: 2.2之前TSD写HBase的时候，是将一行的数据缓存在cache里，等到一个小时候后，组成一行数据然后一次性写入HBase，这样会在这个点会对HBase进行大量数据的写入，可能会冲垮RS. 2.2 版本增加了append的方式，就是连续不断的写入HBase，这样将一个点的压力均摊到各个时间点，不过对HBase的资源占用较多，比如RPC，需要实时监控好HBase。
   tsd.storage.repair_appends

5. Tsdb表预切分: 这个就是HBase建表时需要注意点，每次建表前都做好表预切分。避免表region在运行时自动切分。

6. 多个TSD服务节点: 一个TSD节点能够接受处理 数千 次写请求，实际中需要部署多个TSD节点，然后使用时通过balancer来访问。
7. 持久链接: 保持client与TSD为长连接，避免每次读写时 频繁的打开与关闭连接。tsd.network.keep_alive
8. Disable Meta Data and Real Time Publishing:
   OpenTSDB 2.0 introduced meta data for tracking the kinds of data in the system. When tracking is enabled, a counter is incremented for every data point written and new UIDs or time series will generate meta data. The data may be pushed to a search engine or passed through tree generation code. These processes require greater memory in the TSD and may affect throughput. 默认是关闭的。
   2.0 also introduced a real-time publishing plugin where incoming data points can be emitted to another destination immediately after they’re queued for storage. 默认是关闭的。