根据hbase文档，同样遵循googlebigtable文件中的引用，这些行被认为是用行键的字典排序来存储的。
很明显，当我们在rowkey中有一个字符串或者如果我们将一个字符串转换成字节数组并存储它时，行是按字典顺序排序的。事实上，即使将整数转换为字符串，然后再转换为字节数组，这也是有意义的。e、 g:下面的hbase shell将数字作为字符串并存储

create 'test', 'cf'
put 'test', '1', 'cf:c1', 'xyz1'
put 'test', '2', 'cf:c1', 'xyz2'
put 'test', '11', 'cf:c1', 'xyz11'

scan 'test3'
ROW                                         COLUMN+CELL
 1                                          column=cf:c1, timestamp=1589736288540, value=xyz1
 11                                         column=cf:c1, timestamp=1589736311607, value=xyz11
 2                                          column=cf:c1, timestamp=1589736301167, value=xyz2
3 row(s) in 0.0080 seconds

另一方面，我可以使用hbase客户机实用程序以编程方式将数字转换为字节数组( org.apache.hadoop.hbase.util.Bytes ，它使用的是大端字符..）我看到行是自然排序的，而不是以字典的方式。对于上面类似的数据和表，我使用下面的代码将数据放到hbase表中。

val put = new Put(Bytes.toBytes(11L))
put.addColumn(Bytes.toBytes("cf"), Bytes.toBytes("c1"), Bytes.toBytes("abc"))
table.put(put)

扫描结果为

hbase(main):014:0> scan 'test2'
ROW                                        COLUMN+CELL
 \x01                                      column=cf:a, timestamp=1589727058289, value=abc \\1
 \x02                                      column=cf:a, timestamp=1589727099714, value=abc \\2
 \x0B                                      column=cf:a, timestamp=1589727147449, value=abc \\11
 {                                         column=cf:a, timestamp=1589733907127, value=abc \\123
 \xF8                                      column=cf:a, timestamp=1589733854179, value=abc \\112312312L
5 row(s) in 0.0080 seconds

我的问题是-
由整数生成的字节数组的字典顺序与自然顺序相同，或者我们将长字节数组转换为字节数组的方式实际上是用一些值填充以获得有效的自然顺序，这纯粹是巧合吗？
如果不是，为了处理非类型化的行键，我们是说行键是按字典排序的，这样当您与字符串和其他数据类型混合和匹配时，排序就有了预定的顺序吗？在后一种情况下，在我看来，行键按严格的字典顺序排序是不正确的，因为为了满足我们对非类型列（这里的行键）的需求，它是这样构建的。。！
基本上，这里的字节编码->bytes.tobytes（long）保持了 Long ? 也就是说，词典的排序 Array[Byte] 函数返回的顺序与 Long 作为输入？