Sometimes, you need to process any number of table changes sent from tools via Apache Kafka. As long as they have proper header data and records in JSON, it's really easy in Apache NiFi.

Requirements:

Process each partition separately.

Process records in order, as each message is an insert, update, or delete to an existing table in our receiving JDBC store.

Re-process if data lost.

The main processor for routing must only run on the Primary Node.

Enforcing Order

We use kafka.offset to order the records, which makes sense in Apache Kafka topics.

After insert, update, and delete queries are built, let's confirm and enforce that strict ordering.

To further confirm processing in order, we make each connection in the flow FirstInFirstOutPrioritizer.

We route each partition to a different processor group (one local, the other remote):

Let's store some data in HDFS for each table:

Connect to Kafka and grab from our topic:

Let's connect to our JDBC store:

Let's do an update (table name is dynamic):

The Jolt processor has an awesome tester for trying out Jolt:

Make sure we connect our remote partitions:

Routing from routing server (Primary Node):

For processing partition 0 (run on the routing server):

We infer the schema with InferAvroSchema, so we don't need to know the embedded table layouts before a record arrives. In production, it makes sense to know all these in advance and to do integration tests and versioning of schemas. This is where Hortonworks Schema Registry is awesome. We name the Avro record after the table dynamically. We can get and store permanent schemas in the Hortonworks Schema Registry.

Process partition 1 (we can have one server or cluster per partition):

Using a simple EvaluateJsonPath, we pull out these control fields; for example, $.before.

The table name for ConvertJSONtoSQL is ${table:substringAfter('.')}. This is to remove all leading schema/tablespace names. From the drop-down for each of the three, we pick either UPDATE, INSERT, or DELETE based on the op_type.

We follow this with a PutSQL, which will execute on our destination JDBC database sink.

After that, I collect all the attributes, convert them to a JSON flow file, and save that to HDFS for logging and reporting. This step could be skipped or could be in another format or sent elsewhere.