| <!DOCTYPE html> |
| <html lang="en"> |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You under the Apache License, Version 2.0 |
| (the "License"); you may not use this file except in compliance with |
| the License. You may obtain a copy of the License at |
| http://www.apache.org/licenses/LICENSE-2.0 |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| <head> |
| <meta charset="utf-8" /> |
| <title>ConsumeKafkaRecord</title> |
| <link rel="stylesheet" href="../../../../../css/component-usage.css" type="text/css" /> |
| </head> |
| |
| <body> |
| <h2>Description</h2> |
| <p> |
| This Processor polls <a href="http://kafka.apache.org/">Apache Kafka</a> |
| for data using KafkaConsumer API available with Kafka 2.6. When a message is received |
| from Kafka, the message will be deserialized using the configured Record Reader, and then |
| written to a FlowFile by serializing the message with the configured Record Writer. |
| </p> |
| |
| <h2>Consumer Partition Assignment</h2> |
| <p> |
| By default, this processor will subscribe to one or more Kafka topics in such a way that the topics to consume from are randomly |
| assigned to the nodes in the NiFi cluster. Consider a scenario where a single Kafka topic has 8 partitions and the consuming |
| NiFi cluster has 3 nodes. In this scenario, Node 1 may be assigned partitions 0, 1, and 2. Node 2 may be assigned partitions 3, 4, and 5. |
| Node 3 will then be assigned partitions 6 and 7. |
| </p> |
| |
| <p> |
| In this scenario, if Node 3 somehow fails or stops pulling data from Kafka, partitions 6 and 7 may then be reassigned to the other two nodes. |
| For most use cases, this is desirable. It provides fault tolerance and allows the remaining nodes to pick up the slack. However, there are cases |
| where this is undesirable. |
| </p> |
| |
| <p> |
| One such case is when using NiFi to consume Change Data Capture (CDC) data from Kafka. Consider again the above scenario. Consider that Node 3 |
| has pulled 1,000 messages from Kafka but has not yet delivered them to their final destination. NiFi is then stopped and restarted, and that takes |
| 15 minutes to complete. In the meantime, Partitions 6 and 7 have been reassigned to the other nodes. Those nodes then proceeded to pull data from |
| Kafka and deliver it to the desired destination. After 15 minutes, Node 3 rejoins the cluster and then continues to deliver its 1,000 messages that |
| it has already pulled from Kafka to the destination system. Now, those records have been delivered out of order. |
| </p> |
| |
| <p> |
| The solution for this, then, is to assign partitions statically instead of dynamically. In this way, we can assign Partitions 6 and 7 to Node 3 specifically. |
| Then, if Node 3 is restarted, the other nodes will not pull data from Partitions 6 and 7. The data will remain queued in Kafka until Node 3 is restarted. By |
| using this approach, we can ensure that the data that already was pulled can be processed (assuming First In First Out Prioritizers are used) before newer messages |
| are handled. |
| </p> |
| |
| <p> |
| In order to provide a static mapping of node to Kafka partition(s), one or more user-defined properties must be added using the naming scheme |
| <code>partitions.<hostname></code> with the value being a comma-separated list of Kafka partitions to use. For example, |
| <code>partitions.nifi-01=0, 3, 6, 9</code>, <code>partitions.nifi-02=1, 4, 7, 10</code>, and <code>partitions.nifi-03=2, 5, 8, 11</code>. |
| The hostname that is used can be the fully qualified hostname, the "simple" hostname, or the IP address. There must be an entry for each node in |
| the cluster, or the Processor will become invalid. If it is desirable for a node to not have any partitions assigned to it, a Property may be |
| added for the hostname with an empty string as the value. |
| </p> |
| |
| <p> |
| NiFi cannot readily validate that all Partitions have been assigned before the Processor is scheduled to run. However, it can validate that no |
| partitions have been skipped. As such, if partitions 0, 1, and 3 are assigned but not partition 2, the Processor will not be valid. However, |
| if partitions 0, 1, and 2 are assigned, the Processor will become valid, even if there are 4 partitions on the Topic. When the Processor is |
| started, the Processor will immediately start to fail, logging errors, and avoid pulling any data until the Processor is updated to account |
| for all partitions. Once running, if the number of partitions is changed, the Processor will continue to run but not pull data from the newly |
| added partitions. Once stopped, it will begin to error until all partitions have been assigned. Additionally, if partitions that are assigned |
| do not exist (e.g., partitions 0, 1, 2, 3, 4, 5, 6, and 7 are assigned, but the Topic has only 4 partitions), then the Processor will begin |
| to log errors on startup and will not pull data. |
| </p> |
| |
| <p> |
| In order to use a static mapping of Kafka partitions, the "Topic Name Format" must be set to "names" rather than "pattern." Additionally, all |
| Topics that are to be consumed must have the same number of partitions. If multiple Topics are to be consumed and have a different number of |
| partitions, multiple Processors must be used so that each Processor consumes only from Topics with the same number of partitions. |
| </p> |
| |
| |
| <h2>Security Configuration:</h2> |
| <p> |
| The Security Protocol property allows the user to specify the protocol for communicating |
| with the Kafka broker. The following sections describe each of the protocols in further detail. |
| </p> |
| <h3>PLAINTEXT</h3> |
| <p> |
| This option provides an unsecured connection to the broker, with no client authentication and no encryption. |
| In order to use this option the broker must be configured with a listener of the form: |
| <pre> |
| PLAINTEXT://host.name:port |
| </pre> |
| </p> |
| <h3>SSL</h3> |
| <p> |
| This option provides an encrypted connection to the broker, with optional client authentication. In order |
| to use this option the broker must be configured with a listener of the form: |
| <pre> |
| SSL://host.name:port |
| </pre> |
| In addition, the processor must have an SSL Context Service selected. |
| </p> |
| <p> |
| If the broker specifies ssl.client.auth=none, or does not specify ssl.client.auth, then the client will |
| not be required to present a certificate. In this case, the SSL Context Service selected may specify only |
| a truststore containing the public key of the certificate authority used to sign the broker's key. |
| </p> |
| <p> |
| If the broker specifies ssl.client.auth=required then the client will be required to present a certificate. |
| In this case, the SSL Context Service must also specify a keystore containing a client key, in addition to |
| a truststore as described above. |
| </p> |
| <h3>SASL_PLAINTEXT</h3> |
| <p> |
| This option uses SASL with a PLAINTEXT transport layer to authenticate to the broker. In order to use this |
| option the broker must be configured with a listener of the form: |
| <pre> |
| SASL_PLAINTEXT://host.name:port |
| </pre> |
| In addition, the Kerberos Service Name must be specified in the processor. |
| </p> |
| <h4>SASL_PLAINTEXT - GSSAPI</h4> |
| <p> |
| If the SASL mechanism is GSSAPI, then the client must provide a JAAS configuration to authenticate. |
| </p> |
| <p> |
| An example of the JAAS config file would be the following: |
| <pre> |
| KafkaClient { |
| com.sun.security.auth.module.Krb5LoginModule required |
| useKeyTab=true |
| storeKey=true |
| keyTab="/path/to/nifi.keytab" |
| serviceName="kafka" |
| principal="nifi@YOURREALM.COM"; |
| }; |
| </pre> |
| <b>NOTE:</b> The serviceName in the JAAS file must match the Kerberos Service Name in the processor. |
| </p> |
| <p> |
| The JAAS configuration can be provided by either of below ways |
| <ol type="1"> |
| <li>specify the java.security.auth.login.config system property in |
| NiFi's bootstrap.conf. This limits you to use only one user credential across the cluster.</li> |
| <pre> |
| java.arg.16=-Djava.security.auth.login.config=/path/to/kafka_client_jaas.conf |
| </pre> |
| <li>add user attribute 'sasl.jaas.config' in the processor configurations. This method allows one to have multiple consumers with different user credentials or gives flexibility to consume from multiple kafka clusters.</li> |
| <pre> |
| sasl.jaas.config : com.sun.security.auth.module.Krb5LoginModule required |
| useKeyTab=true |
| storeKey=true |
| keyTab="/path/to/nifi.keytab" |
| serviceName="kafka" |
| principal="nifi@YOURREALM.COM"; |
| </pre> |
| </ol> |
| </p> |
| <p> |
| Alternatively, the JAAS |
| configuration when using GSSAPI can be provided by specifying the Kerberos Principal and Kerberos Keytab |
| directly in the processor properties. This will dynamically create a JAAS configuration like above, and |
| will take precedence over the java.security.auth.login.config system property. |
| </p> |
| <h4>SASL_PLAINTEXT - PLAIN</h4> |
| <p> |
| If the SASL mechanism is PLAIN, then client must provide a JAAS configuration to authenticate, but |
| the JAAS configuration must use Kafka's PlainLoginModule. An example of the JAAS config file would |
| be the following: |
| <pre> |
| KafkaClient { |
| org.apache.kafka.common.security.plain.PlainLoginModule required |
| username="nifi" |
| password="nifi-password"; |
| }; |
| </pre> |
| The JAAS configuration can be provided by either of below ways |
| <ol type="1"> |
| <li>specify the java.security.auth.login.config system property in |
| NiFi's bootstrap.conf. This limits you to use only one user credential across the cluster.</li> |
| <pre> |
| java.arg.16=-Djava.security.auth.login.config=/path/to/kafka_client_jaas.conf |
| </pre> |
| <li>add user attribute 'sasl.jaas.config' in the processor configurations. This method allows one to have multiple consumers with different user credentials or gives flexibility to consume from multiple kafka clusters.</li> |
| <pre> |
| sasl.jaas.config : org.apache.kafka.common.security.plain.PlainLoginModule required |
| username="nifi" |
| password="nifi-password"; |
| </pre> |
| <b>NOTE:</b> The dynamic properties of this processor are not secured and as a result the password entered when utilizing sasl.jaas.config will be stored in the flow.xml.gz file in plain-text, and will be saved to NiFi Registry if using versioned flows. |
| </ol> |
| </p> |
| <p> |
| <b>NOTE:</b> It is not recommended to use a SASL mechanism of PLAIN with SASL_PLAINTEXT, as it would transmit |
| the username and password unencrypted. |
| </p> |
| <p> |
| <b>NOTE:</b> The Kerberos Service Name is not required for SASL mechanism of PLAIN. However, processor warns saying this attribute has to be filled with non empty string. You can choose to fill any random string, such as "null". |
| </p> |
| <p> |
| <b>NOTE:</b> Using the PlainLoginModule will cause it be registered in the JVM's static list of Providers, making |
| it visible to components in other NARs that may access the providers. There is currently a known issue |
| where Kafka processors using the PlainLoginModule will cause HDFS processors with Keberos to no longer work. |
| </p> |
| <h4>SASL_PLAINTEXT - SCRAM</h4> |
| <p> |
| If the SASL mechanism is SCRAM, then client must provide a JAAS configuration to authenticate, but |
| the JAAS configuration must use Kafka's ScramLoginModule. Ensure that you add user defined attribute 'sasl.mechanism' and assign 'SCRAM-SHA-256' or 'SCRAM-SHA-512' based on kafka broker configurations. An example of the JAAS config file would |
| be the following: |
| <pre> |
| KafkaClient { |
| org.apache.kafka.common.security.scram.ScramLoginModule required |
| username="nifi" |
| password="nifi-password"; |
| }; |
| </pre> |
| The JAAS configuration can be provided by either of below ways |
| <ol type="1"> |
| <li>specify the java.security.auth.login.config system property in |
| NiFi's bootstrap.conf. This limits you to use only one user credential across the cluster.</li> |
| <pre> |
| java.arg.16=-Djava.security.auth.login.config=/path/to/kafka_client_jaas.conf |
| </pre> |
| <li>add user attribute 'sasl.jaas.config' in the processor configurations. This method allows one to have multiple consumers with different user credentials or gives flexibility to consume from multiple kafka clusters.</li> |
| <pre> |
| sasl.jaas.config : org.apache.kafka.common.security.scram.ScramLoginModule required |
| username="nifi" |
| password="nifi-password"; |
| </pre> |
| <b>NOTE:</b> The dynamic properties of this processor are not secured and as a result the password entered when utilizing sasl.jaas.config will be stored in the flow.xml.gz file in plain-text, and will be saved to NiFi Registry if using versioned flows. |
| </ol> |
| <p> |
| <b>NOTE:</b> The Kerberos Service Name is not required for SASL mechanism of SCRAM-SHA-256 or SCRAM-SHA-512. However, processor warns saying this attribute has to be filled with non empty string. You can choose to fill any random string, such as "null". |
| </p> |
| <h3>SASL_SSL</h3> |
| <p> |
| This option uses SASL with an SSL/TLS transport layer to authenticate to the broker. In order to use this |
| option the broker must be configured with a listener of the form: |
| <pre> |
| SASL_SSL://host.name:port |
| </pre> |
| </p> |
| <p> |
| See the SASL_PLAINTEXT section for a description of how to provide the proper JAAS configuration |
| depending on the SASL mechanism (GSSAPI or PLAIN). |
| </p> |
| <p> |
| See the SSL section for a description of how to configure the SSL Context Service based on the |
| ssl.client.auth property. |
| </p> |
| |
| <h2>Output Strategies</h2> |
| <div> |
| <p>This processor offers multiple output strategies (configured via processor property 'Output |
| Strategy') for converting Kafka records into FlowFiles.</p> |
| <ul> |
| <li>Output Strategy 'Write Value Only' (the default) emits flowfile records containing only the Kafka |
| record value. |
| </li> |
| <li>Output Strategy 'Use Wrapper' (new) emits flowfile records containing the Kafka record key, value, |
| and headers, as well as additional metadata from the Kafka record. |
| </li> |
| </ul> |
| |
| |
| <p>The record schema that is used when 'Use Wrapper' is active is as follows (in Avro format):</p> |
| <pre> |
| <code> |
| { |
| "type": "record", |
| "name": "nifiRecord", |
| "namespace": "org.apache.nifi", |
| "fields": [{ |
| "name": "key", |
| "type": [{ |
| < Schema is determined by the Key Record Reader, or will be "string" or "bytes", depending on the "Key Format" property (see below for more details) > |
| }, "null"] |
| }, |
| { |
| "name": "value", |
| "type": [ |
| { |
| < Schema is determined by the Value Record Reader > |
| }, |
| "null" |
| ] |
| }, |
| { |
| "name": "headers", |
| "type": [ |
| { "type": "map", "values": "string", "default": {}}, |
| "null"] |
| }, |
| { |
| "name": "metadata", |
| "type": [ |
| { |
| "type": "record", |
| "name": "metadataType", |
| "fields": [ |
| { "name": "topic", "type": ["string", "null"] }, |
| { "name": "partition", "type": ["int", "null"] }, |
| { "name": "offset", "type": ["int", "null"] }, |
| { "name": "timestamp", "type": ["long", "null"] } |
| ] |
| }, |
| "null" |
| ] |
| } |
| ] |
| } |
| </code> |
| </pre> |
| |
| <p>If the Output Strategy property is set to 'Use Wrapper', an additional processor configuration property |
| ('Key Format') is activated. This property is used to specify how the Kafka Record's key should be written out to the FlowFile. |
| The possible values for 'Key Format' are as follows:</p> |
| <ul> |
| <li>'Byte Array' supplies the Kafka Record Key as a byte array, exactly as they are received in the Kafka record.</li> |
| <li>'String' converts the Kafka Record Key bytes into a string using the UTF-8 character encoding. |
| (Failure to parse the key bytes as UTF-8 will result in the record being routed to the |
| 'parse.failure' relationship.) |
| </li> |
| <li>'Record' converts the Kafka Record Key bytes into a deserialized NiFi record, using the associated |
| 'Key Record Reader' controller service. |
| </li> |
| </ul> |
| |
| <p> |
| If the Key Format property is set to 'Record', an additional processor configuration property name 'Key Record Reader' is |
| made available. This property is used to specify the Record Reader to use in order to parse the Kafka Record's key as a Record. |
| </p> |
| |
| <p>Here is an example of FlowFile content that is emitted by <code>JsonRecordSetWriter</code> when strategy "Use Wrapper" is active:</p> |
| <pre> |
| <code> |
| [ |
| { |
| "key": { |
| "name": "Acme", |
| "number": "AC1234" |
| }, |
| "value": { |
| "address": "1234 First Street", |
| "zip": "12345", |
| "account": { |
| "name": "Acme", |
| "number": "AC1234" |
| } |
| }, |
| "headers": { |
| "attributeA": "valueA", |
| "attributeB": "valueB" |
| }, |
| "metadata": { |
| "topic": "accounts", |
| "partition": 0, |
| "offset": 0, |
| "timestamp": 0 |
| } |
| } |
| ] |
| </code> |
| </pre> |
| |
| <p>These new processor properties may be used to extend the capabilities of ConsumeKafkaRecord_2_6, by |
| optionally incorporating additional information from the Kafka record (key, headers, metadata) into the |
| outbound flowfile. Additionally, the Kafka records' keys may now be interpreted as records, rather than as a string. |
| This enables additional decision-making by downstream processors in your flow and enables handling of records where |
| the key is complex, such as an Avro record.</p> |
| |
| <p>Additionally, the choice of the 'Output Strategy' property affects the related properties |
| 'Headers to Add as Attributes (Regex)' and 'Key Attribute Encoding'. Since Output Strategy 'Use |
| Wrapper' includes headers and keys in the FlowFile content, they are not also added to the FlowFile |
| attributes. These properties are available only when the FlowFile Output Strategy is set to 'Write |
| Value Only'.</p> |
| </div> |
| |
| </body> |
| </html> |
