Reverse Engineer MapR-DB with ODI

Blog Post created by ihijazi on Jan 31, 2017

This is going to be a short write-up, a bonus to my previous post "Oracle Data Integrator & MapR Converged Data Platform: CHECK!".


MapR-DB client APIs can access both HBase tables and MapR-DB tables, it all depends on what you pass to its methods. So in case you need to reverse engineer your MapR-DB tables, this blog will give you what you need.


First, you need to make sure the following jars are presented in your additional_classpath.txt OR in a separate ODI Standalone Agent which you'll use ONLY for the purpose of reverse engineering MapR-DB:



Under HBase Physical Data Server, the physical schema values are NOT read by ODI, because (HBase 101): NoSQL databases are SCHEMALESS.



Finally, when you define your data store, under the Designer tab, you need to have slightly different value for the "Mask" property in the "Reverse" tab. So, if you want to reverse engineer HBase tables, keep things as is:



However, if you need to reverse engineer MapR-DB under a certain path, you need to modify the "Mask" value to match the path you're aiming to reverse engineer:



In the preceding example, I reversed engineer the MapR-DB tables under the path "/user/mapr/mapr-db":



Simple, no? If you have any question, leave it in the comments area below.


Don't forget to Like and Share


This content is originally on https://www.linkedin.com/pulse/reverse-engineer-mapr-db-odi-issam-hijazi 


Are you on Twitter? Then it's time to follow me @iHijazi



Safe Harbor Statement

The preceding is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.



The thoughts, practices and opinions expressed here are those of the author alone and do not necessarily reflect the views of Oracle.