HBase Go客户端Row构造注意事项
我们最近在一个项目中使用Hbase做日志数据的存储，在其之上做一些数据分析工作，相对java来说，团队成员对Go的使用更熟练，所以自然使用Go作为Client的开发语言， 以前从来没有跟Hbase打过交道，本来一个比较简单的任务，愣是磕磕绊绊做了好久。。。
本文只说说Hbase的Row构造时的注意事项
1 Hbase 的Go客户端语言使用方法
Hbase官方没有Go的客户端，但是它提供了thrift服务，我们可以用Go语言开发一个thrift 的client，通过向hbase的thrift server发送RPC请求，从而对Hbase做操作。 一个简单的请求流程如下：
Go Client –—> Hbase Thrift server –—> Hbase
其中的 Hbase Thrift Server是Hbase官方提供的，同时他们也提供Thrift服务描述文件，至于如何用Thrift服务描述文件声称Go Client的代码，github.com上有很多工具， thrift官方也有工具。
2 Hbase的Row使用注意事项
2.1 Row的前几个字段尽量散列
Hbase是一个集群服务，它会根据Row将数据分散到各后端存储机器上，如果您的Raw key有明显的聚集性，该Row对应的数据也会被集中在某几台后端机器上，这样在数据量特别大的 时候，读写的压力都集中在这几台机器上，会影响您的使用性能，所以第一个建议就是： 对raw key做散列，使有明显聚集性的raw key均匀（或近似均匀）地被分派到不同的后端存储机器上 最常用的使md5sum
2.2 Row的排序是把所有Row中的字符做字典排序
这一点很重要，下午掉进这个坑里半天才爬出来。为了说明这个问题，把我们的应用场景简化以下举例说明 我们的应用场景是：写Hbase是插入一堆带时间戳的data，读Hbase是读取data在时间段start和end之间的所有数据 我们的Row有两个关键字：一个字符串data和一个时间戳timestamp，基于这两个关键字我们构造Row的方法是： substring(md5sum(data), 0, 8) + data + timestamp Row中的前部分好说，都是字符串，关键是这个timestamp怎么构造？最初我是用下面的方法：
buf := make([]byte, 24 + len(data) ip := []byte(pack.data) tmp := md5.Sum(data) copy(buf[0:8], tmp[0:8]) copy(buf[8:8 + len(data)], data) binary.PutVarint(buf[8+len(data):], timestamp)
在这样写入到Hbase中之后（例如我写入了 data=aabbcc, timestamp=123456的数据 ），读取数据时有时候在start=0, end=234567时能读到数据，在start=1, end=234567时 却读不到数据，百思不得其解。后来发现原来是写入timestamp时的错误，请看下面的例子：
buf := make([]byte, 8) binary.PutVarint(buf, int64(1423484126)) fmt.Println(buf) binary.PutVarint(buf, int64(2)) fmt.Println(buf)
它的输出是：
[188 147 197 205 10 0 0 0] [4 147 197 205 10 0 0 0]
这样虽然timestamp 1423484126比2大，但是构造Row后，如果data相同，那么2的字典序竟然排在1423484126比的后面。这样就会产生上面提到的奇怪的现象。 所幸，Go没有辜负我们，它提供了一个方便的方法，能完成我们想要做的事情，请看下面的例子：
buf := make([]byte, 8) binary.BigEndian.PutUint64(buf, uint64(1423484126)) fmt.Println(buf) binary.BigEndian.PutUint64(buf, uint64(2)) fmt.Println(buf)
它的输出是：
[0 0 0 0 84 216 164 222] [0 0 0 0 0 0 0 2]
OK，问题解决。 以后接触陌生的知识，还是要先弄清楚基本原理，虽然这样投入的时间会多一些，但是从整体的收益来看，却是一种较好的方法。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
