Cloudera Docs

Replicating Phoenix 4.14 and newer versions including 5.x

Phoenix 4.14 and 5.x have options which may or may not use column encoding, whereas the older versions did not have this feature. You must determine if your existing Phoenix table uses column encoding. Following are the various ways to check this.

You can also create an HBase replication policy using Cloudera Replication Manager to replicate Phoenix 4.14 and 5.x versions into Cloudera Operational Database. For more information, refer to the second row of the Replication methods table in HBase Migration through Replication Manager.
  1. Follow the same steps as described for Phoenix older than 4.14, steps 1 - 4, and modify step 5 according to the following instructions.
  2. Scan the raw data in HBase, and inspect if there are human-readable column names in the column qualifier. If you see human-readable names, you must set COLUMN_ENCODED_BYTES = 0. If you encounter a binary data (‘\x00’), assume that COLUMN_ENCODED_BYTES must be set.
  3. Inspect the create-table command from the legacy product. If you explicitly set COLUMN_ENCODED_BYTES in an earlier version, you must use the same value when re-creating the Phoenix table in Cloudera Operational Database.
  4. Validate the query using phoenix-sqlline. This must return the expected data from your Phoenix table.
    You might have installed python2 or python3, depending on the operating system version installed on your system; however, for the phoenix-sqlline script to work properly, you must ensure that the Python alternatives point to a specific version. Consider the following examples for Python alternatives,
    $ alternatives --list|grep python
python                                         auto    /usr/bin/python3.6

    Or

    $ alternatives --list|grep python
python                                         auto    /usr/bin/python2.9