MapR 5.0 Documentation : Mapping Table Namespace Between Apache HBase Tables and MapR-DB Tables

MapR's implementations of the HBase Java API and libhbase differentiate between Apache HBase tables and MapR-DB tables according to table names. In certain cases, such as migrating code from Apache HBase tables to MapR-DB tables, users need to force the API they are using to access a MapR-DB table, even though the table name could map to an Apache HBase table. The hbase.table.namespace.mappings property allows you to map Apache HBase table names to MapR-DB tables. This property is typically set in the configuration fileĀ /opt/mapr/hadoop/hadoop-<version>/conf/core-site.xml (Hadoop 1.x).

In general, if a table name includes a slash (/), the name is assumed to be a path to a MapR-DB table, because slash is not a valid character for Apache HBase table names. In the case of "flat" table names without a slash, namespace conflict is possible, and you might need to use table mappings.

Table Mapping Naming Conventions

A table mapping takes the form name:map, where name is the table name to redirect and map is the modification made to the name. The value in name can be a literal string or contain the * wildcard. When mapping a name with a wild card, the mapping is treated as a directory. Requests to tables with names that match the wild card are sent to the directory in the mapping.

When mapping a name that is a literal string, you can choose from two different behaviors:

  • End the mapping with a slash to indicate that this mapping is to a directory. For example, the mapping mytable1:/user/aaa/ sends requests for table mytable1 to the full path /user/aaa/mytable1.
  • End the mapping without a slash, which creates an alias and treats the mapping as a full path. For example, the mapping mytable1:/user/aaa sends requests for table mytable1 to the full path /user/aaa.

Mappings and Table Listing Behaviors

When you use the list command without specifying a directory, the command's behavior depends on two factors:

  • Whether a table mapping exists
  • Whether Apache HBase is installed and running

Here are three different scenarios and the resulting list command behavior for each.

  • There is a table mapping for *, as in *:/tables.
    In this case, the list command lists the tables in the mapped directory.
  • There is no mapping for *, and Apache HBase is installed and running.
    In this case, the list command lists the HBase tables.
  • There is no mapping for *, and Apache HBase is not installed or is not running.
    In this case, the shell will try to connect to an HBase cluster, but will not be able to. After a few seconds, it will give up and fall back to listing the MapR-DB tables in the user's home directory.

Table Mapping Examples

Example 1: Map all HBase tables to MapR-DB tables in a directory

In this example, any flat table name foo is treated as a MapR-DB table in the directory /tables_dir/foo.

<property>
  <name>hbase.table.namespace.mappings</name>
  <value>*:/tables_dir</value>
</property>

Example 2: Map specific Apache HBase tables to specific MapR-DB tables

In this example, the Apache HBase table name mytable1 is treated as a MapR-DB table at /user/aaa/mytable1. The Apache Hbase table name mytable2 is treated as a MapR-DB table at /user/bbb/mytable2. All other Apache HBase table names are treated as stock Apache HBase tables.

<property>
  <name>hbase.table.namespace.mappings</name>
  <value>mytable1:/user/aaa/,mytable2:/user/bbb/</value>
</property>

Example 3: Combination of specific table names and wildcards

Mappings are evaluated in order. In this example, the flat table name mytable1 is treated as a MapR-DB table at /user/aaa/mytable1. The flat table name mytable2 is treated as a MapR-DB table at /user/bbb/mytable2. Any other flat table name foo is treated as a MapR-DB table at /tables_dir/foo.

<property>
  <name>hbase.table.namespace.mappings</name>
  <value>mytable1:/user/aaa/,mytable2:/user/bbb/,*:/tables_dir</value>
</property>