导入Phoenix/HBASE表后索引数据错误(快照)

Question

我需要将Phoenix/HBase表从一个非常老的集群迁移到一个新的集群。

起源集群版本

• HDP-2.5.3.0
hbase 1.1.2 (hdp-2.5.3.0-37)
• Phoenix 4.7.0 (HDP-2.5.3.0-37)
Ubuntu 12.04

目标集群版本

• BigTop(3.1.1)或vanilla Apache hadoop/Hbase二进制构建(相同行为)
• HBASE 2.4.11
• Phoenix 5.1.2 (for HBase 2.4)
Ubuntu 20.04

我使用了https://github.com/karthikhw/hbase-snapshot和HBASE文档(https://hbase.apache.org/book.html#ops.snapshots)中的方法和建议。

导出数据库

源集群，我已经快照了PIMEP_MDB2(带有hbase shell)

snapshot 'PIMEP_MDB2', 'PIMEP_MDB2_20221103'

接下来，我将快照复制到目标集群HDFS。

hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -snapshot PIMEP_MDB2_20221103 -copy-to hdfs://172.16.42.155:9000/hbase -mappers 16

在目标上导入数据库

目标集群使用Phoenix SQLine.py，我已经创建了数据库

CREATE TABLE IF NOT EXISTS PIMEP_MDB2 (
KINDEX FLOAT NOT NULL,
KLON FLOAT NOT NULL,
KLAT FLOAT NOT NULL,
KDATE DATE NOT NULL,
C.SSS_DEPTH_ARGO FLOAT,
C.SSS_DEPTH_MAMMAL FLOAT,
C.SSS_DEPTH_PLATFORM FLOAT,
C.DIST_TO_COAST_ARGO FLOAT,
C.DIST_TO_COAST FLOAT,
C.SSTARGO FLOAT,
C.SSTMAMMAL FLOAT,
C.SST_PLATFORM FLOAT,
C.SSSMAMMAL FLOAT,
C.SSS_PLATFORM FLOAT,
C.SSSARGO FLOAT,
C.TIMELAGS FLOAT,
C.SPATIALLAGS FLOAT,
C.DELTASSS FLOAT,
C.DMRTARGO FLOAT,
C.CMORPH3H FLOAT,
C.ASCATWIND FLOAT,
C.SSSSAT FLOAT,
C.SSSISAS FLOAT,
C.SSTDRIFTER FLOAT,
C.SSSDRIFTER FLOAT,
C.ASCATWINDARGO FLOAT,
CONSTRAINT pk PRIMARY KEY (KINDEX,KLON,KLAT,KDATE))
COLUMN_ENCODED_BYTES = 0;

在Hbase shell中，我已经禁用了数据库，导入了快照并重新启用了数据库。

disable 'PIMEP_MDB2'
import_snapshot 'PIMEP_MDB2_20221103'
enable 'PIMEP_MDB2'

看起来不错，但是当我查看目标集群上的数据时，我的KINDEX, KLON, KLAT和KDATE不一致。这些条目被连接起来创建Hbase的行键(参见CONSTRAINT pk PRIMARY KEY (KINDEX,KLON,KLAT,KDATE))关于创建数据库)。

错误的数据这里，期望的结果(来自原始集群))

0: jdbc:phoenix:> select * from PIMEP_MDB2 limit 10;
+----------+------------+-----------+--------------------------+-----------------+-------------------+---------------------+------------+
|  KINDEX  |    KLON    |   KLAT    |          KDATE           | SSS_DEPTH_ARGO  | SSS_DEPTH_MAMMAL  | SSS_DEPTH_PLATFORM  | DIST_TO_CO |
+----------+------------+-----------+--------------------------+-----------------+-------------------+---------------------+------------+
| 35010.0  | -179.986   | -0.135    | 2016-05-08 06:19:15.000  | 4.1             | null              | null                | null       |
| 35010.0  | -179.993   | -19.317   | 2016-06-08 04:25:24.000  | 6.1             | null              | null                | null       |
| 35010.0  | -179.9976  | 18.612    | 2017-10-07 02:44:55.000  | 0.92            | null              | null                | null       |
| 35010.0  | -179.99    | 21.355    | 2015-10-21 11:54:23.000  | 4.2             | null              | null                | null       |
| 35010.0  | -179.998   | -39.668   | 2012-05-13 19:04:25.000  | 4.2             | null              | null                | null       |
| 35010.0  | -179.979   | 15.085    | 2013-03-21 00:27:21.000  | 5.2             | null              | null                | null       |
| 35010.0  | -179.999   | 59.138    | 2012-09-12 23:08:00.000  | 6.4             | null              | null                | null       |
| 35010.0  | -179.99    | -37.369   | 2014-07-21 23:04:05.000  | 6.1             | null              | null                | null       |
| 35010.0  | -179.999   | -28.172   | 2013-02-13 19:15:28.000  | 5.8             | null              | null                | null       |
| 35010.0  | -179.998   | -39.2038  | 2017-12-18 22:57:10.000  | 4.4             | null              | null                | null       |
+----------+------------+-----------+--------------------------+-----------------+-------------------+---------------------+------------+

这里，目标集群的结果(看KDATE !但是KINDEX也有问题)

0: jdbc:phoenix:> select * from PIMEP_MDB2 limit 10;
+--------------+---------------+----------------+------------+----------------+------------------+--------------------+-----------------+
|    KINDEX    |     KLON      |      KLAT      |   KDATE    | SSS_DEPTH_ARGO | SSS_DEPTH_MAMMAL | SSS_DEPTH_PLATFORM | DIST_TO_COAST_A |
+--------------+---------------+----------------+------------+----------------+------------------+--------------------+-----------------+
| -2.458617E38 | -1.297347E38  | 1.5667962E-25  | 4891-02-17 | 4.1            | null             | null               | null            |
| -2.458617E38 | -1.2973468E38 | 2.3466038E29   | 4716-06-14 | 2.0            | null             | null               | null            |
| -2.458617E38 | -1.2973466E38 | -3.26837102E12 | 8274-04-12 | 5.5            | null             | null               | null            |
| -2.458617E38 | -1.2973464E38 | 7.959833E8     | 2659-08-04 | 1.16           | null             | null               | null            |
| -2.458617E38 | -1.2973464E38 | 3.9434477E36   | 3920-01-27 | 5.5            | null             | null               | null            |
| -2.458617E38 | -1.2973464E38 | 3.9718884E36   | 8031-07-08 | 5.4            | null             | null               | null            |
| -2.458617E38 | -1.2973464E38 | 8.041029E36    | 7064-02-01 | 2.9            | null             | null               | null            |
| -2.458617E38 | -1.2973462E38 | -0.002895198   | 4131-09-25 | 4.1            | null             | null               | null            |
| -2.458617E38 | -1.2973459E38 | -4.6812513E26  | 3387-11-24 | 6.2            | null             | null               | null            |
| -2.458617E38 | -1.2973453E38 | -24859.004     | 0216-05-26 | 4.1            | null             | null               | null            |
+--------------+---------------+----------------+------------+----------------+------------------+--------------------+-----------------+

似乎Hbase的行键不能正确分割凤凰"列"(KINDEX, KLON, KLAT, KDATE)…

创建时，我遵循与原始集群相同的顺序和数据类型(根据原始元数据)。

如果有人有一个线索(好)或解决方案(更好)，它将使我不会发疯。

最诚挚的问候,Tristan

Answer 1

答案在盐里…原始HBASE/Phoenix表被盐化。目标表必须有相同的桶号。

在原始集群上，我们需要检索salt_buckets(这里是12)。

select table_name, salt_buckets from SYSTEM.CATALOG where salt_buckets is not null and TABLE_NAME = 'PIMEP_MDB2';

接下来，当在目标上创建表时，我们必须使用COLUMN_ENCODED_BYTES = 0, SALT_BUCKET = 12;而不是COLUMN_ENCODED_BYTES = 0。

导入成功，数据一致。

希望对大家有所帮助