Store in HBase Table

This step provides the opportunity to store a variable in a HBase Table. The connection settings are configured in the step.

The description below assumes that the general architecture of the HBase cluster is understood. See the notes below for a description of how the data is inserted into the HBase Table.

Properties

Store in HBase Table is configured using the following properties:

ZooKeeper Quorum Hostnames:
The list of hostnames used for connecting to the underlying ZooKeeper Quorum that directs access to HBase. The Quorum should give access to a HBase master holding the table the variable will be stored in. A value can either be selected or hard coded at design time, or the list can be dynamically constructed at runtime using a variable, an expression or converters - An error will occur if no database with this name exists when the robot is executed.
HBase Table:
Controls which HBase table the variable will be stored in. A value can either be selected or hard coded at design time, or the table name can be dynamically constructed at runtime using a variable, an expression or converters - An error will occur if no database with this name exists when the robot is executed.
Column Family:
Controls which column family the variable will be stored in. A value can either be selected or hard coded at design time, or the column family name can be dynamically constructed at runtime using a variable, an expression or converters - An error will occur if no database with this name exists when the robot is executed.
Variable:
Select the variable to store. This must be a regular variable and not a simple type variable.
Key:
The unique key for the variable which is stored. The key may be defined in the type (by marking variables as "Part of Database Key"), or defined using a variable, an expression or converters.
If a value with the given key already exists, this step will update the existing record; if no value with this key exists, a new record will be inserted. See note below for important information on the key.
Execute in Design Mode:
If this is enabled, the step will be executed even in Design Mode inside Design Studio. If this is disabled, the step will do nothing when you navigate the robot in Design Mode.

Notes

As all data (including keys and column names) stored by HBase are arrays of bytes, Design Studio will convert all data to byte arrays using UTF-8 encoding before inserting into the table.

The variable data is written to the row with the key specified in the attribute key. If the key is set to be composed of the attributes marked as "Part of Database Key", the key is the concatenation of the value of those attributes separated by underscores (and ordered as in the type editor). For example, if writing a variable of type Company with two ordered attributes marked "Part of Database Key":

the resulting key is Kapow_1999. Note that if choosing a binary attribute as part of the key, a hash of the value will be used instead of the actual value. Furthermore, an underscore present in the attribute values used as "Part of Database Key" will be replaced by double underscores.

Writing data to the HBase table is done by putting the value of each attribute in a column having the same qualifier as the name of the attribute. The columns are located in the column family specified. All data in the variable, including the attributes selected to be "Part of Database Key" is written to each row. The two house-hold fields RobotName and ExecutionId described in the section on Storing Data in Databases are updated in the table every time the step is executed. The remaining five house-hold fields from that page are not stored in the table. No specific timestamp is chosen for the write, it is up to HBase to choose a reasonable value. Using the example from above and Column Family = cf, the data inserted is (ignoring the timestamp):

    Kapow_1999 => [cf:Name = Kapow, cf:Year = 1999, cf:RobotName = XXXX, cf:ExecutionId = YYYY]