Member since
02-01-2022
285
Posts
103
Kudos Received
60
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 1182 | 05-15-2025 05:45 AM | |
| 5123 | 06-12-2024 06:43 AM | |
| 8120 | 04-12-2024 06:05 AM | |
| 5995 | 12-07-2023 04:50 AM | |
| 3299 | 12-05-2023 06:22 AM |
06-07-2023
12:24 PM
2 Kudos
@SandyClouds Some clarity and additions to @cotopaul Pros and Cons: Single Node: PROs: - easy to manage. <-- Setup and managing configuration is easier since you only need to do that on one node. But in a cluster, all nodes configuration files will be almost the same (some variations in hostname properties and certificates if you secure your cluster). - easy to configure. <-- There are more configurations needed in a cluster setup, but once setup, nothing changes from the user experience when it comes to interacting with the UI. - no https required. <-- Not sure how this is a PRO. I would not recommend using an un-secure NiFi as doing so allow anyone access to your dataflows and the data being processed. You can also have an un-secure NiFi cluster while i do not recommend that either. CONs: - in case of issues with the node, you NiFi instance is down. <-- Very true, single point of failure. - it uses plenty of resources, when it needs to process data, as everything is done on a single node. Cluster: PROs: - redundancy and failover --> when a node goes down, the others will take over and process everything, meaning that you will not get affected. <-- Not complete accurate. Each node in a NiFi cluster is only aware of the data (FlowFiles) queued on that specific node. So each node works on the FlowFile present on that one node, so it is the responsibility of the dataflow designer/builder to make sure they built their dataflows in such away to ensure distribution of FlowFiles across all nodes. When a node goes down, any data FlowFiles currently queued on that down node are not going to be processed by the other nodes. However, other nodes will continue processing their data and all new data coming in to your dataflow cluster - the used resources will be split among all the nodes, meaning that you can cover more use cases as on a single node. <-- Different nodes do not share or pool resources from all nodes in the cluster. If your dataflow(s) are built correctly the volume of data (FlowFiles) being processed will be distributed across all your nodes along each node to process a smaller subset of the overall FlowFile volume. This means more resources available across yoru cluster to handle more volume. NEW -- A NiFi cluster can be accessed via any one of the member nodes. No matter which node's UI you access, you will be presented with stats for all nodes. There is a cluster UI accessible from the global menu that allows you to see a breakdown of each node. Any changes you make from the UI of any one of the member nodes will be replicated to all nodes. NEW -- Since all nodes run their own copy of the flow, a catastrophic node failure does not mean loss of all your work since the same flow.json.gz (contains everything related to your dataflows) can be retrieved from any of the other nodes in your cluster. CONs: - complex setup as it requires a Zookeeper + plenty of other config files. <-- NiFi cluster requires a multi node zookeeper setup. Zookeeper quorum is required for cluster stability and also stores cluster wide state needed for your dataflow. Zookeeper is responsible for electing a node in your cluster with the Cluster Coordinator role and Primary node role. IF a node goes down that has been assigned one of these roles, Zookeeper will elected one of the still up nodes to the role - complex to manage --> analysis will be done on X nodes instead of a single node. <-- not clear. Yes you have multiple nodes and all those nodes are producing their own set of NiFi-logs. However, if a component within your dataflow is producing bulletins (exceptions) it will report all nodes or the specific node(s) on which bulletin was produced. Cloudera offers centralized management of your NiFi cluster deployment via Cloudera Manager software. Makes deploying and managing NiFi cluster to multiple nodes easy, sets up and configures Zookeeper for you, and makes securing your NiFi easy as well by generating the needed certificates/keystores for you. Hope this helps, Matt
... View more
06-02-2023
09:00 AM
1 Kudo
Thanks STeven for your recommendation. The issue result. The invokeHttp oauth2 property looks like not able to select basic authorization from the setting or I might missing something. So have to ignore oauth2 setting and implement basic auth by sending client_id and _secret separately to get token first and then send actual payload later from another invokehttp processor. Thanks for your help
... View more
06-01-2023
12:40 PM
2 Kudos
@drewski7 You are looking for something like this, for "yesterday": ${now():minus(86400000):format('MM-dd-yyyy hh:mm:ss') } Then change 24 hours to 10 hours and add not reduce: ${now():plus(36000000):format('MM-dd-yyyy hh:mm:ss') } Let me know if this adapts to fit your use case!
... View more
06-01-2023
08:35 AM
Wow, that was fast, thank you very much @steven-matison!
... View more
06-01-2023
06:31 AM
1 Kudo
@drewski7 I think the solution you are looking for is to use one of the alternative data stores that lives outside of NiFi with the map cache. The options are Redis, Hbase, Cassandra, Couchbase: They will give you greater control and they are preferred for production and large volumes.
... View more
05-31-2023
07:29 AM
Cloudera making hard stuff easy again! Great article Ryan!!
... View more
05-31-2023
06:20 AM
1 Kudo
@steven-matison Thanks man. It is true, the session.commit() method can be found in the abstract processor class, which is why I did not think of adding it. This helped me a lot! Also I needed to close the Inputstream with IOUtils.closeQuietly(stream_content) Thirdly I had to use the enumerate function for the dictionnary, because it couldn't read the line file = session.putAttribute(file, "list_value", d[file]) So I just filled the dict with empty values and used session.putAttribute(file, "list_value", json_data['list'][i]) It is ugly, but works at least.
... View more
05-30-2023
07:29 PM
2 Kudos
Hi @steven-matison The issue got fixed after making below 2 changes in /etc/krb5.conf file 1. Issue was a include line in my /etc/krb5.conf file which was not valid. Removed below from /etc/krb5.conf "includedir /etc/krb5.conf.d/" 2. On macOS the default client does not fall back to TCP. In krb5.conf prefix kdc value with tcp/ to force the client to use TCP if your corporate network blocks UDP. kdc = tcp/kdc.example.com:88 Regards, Banshi.
... View more
05-22-2023
07:58 AM
It sounds like you are using OAuth, which means you ought to be using an OAuth2AccessTokenProvider controller service. See my screen shot, which shows that inside the InvokeHTTP there is a configuration line that lets you specify this controller service. This service automatically handles getting the token for you and embedding it in the header so your flowfile remains intact. This will greatly simplify your current flow because you can get rid of the map cache and that whole process cycle.
... View more
05-19-2023
04:05 AM
@soc88 Some suggestions so community can better help you: Show screen shots of processor's configuration tab. We need to see the properties and how you have setup the processor. For processors with errors (red boxes), you can click the box to see full error. We need to see the errors to suggest solutions. Look in nifi-app.log for these errors if you need more verbose errors than shown in the UI. You can also set the processor log level to see more in the UI. For example, set it to DEBUG and test again. I would suspect your error could be the configuration of the processor, but would more suspect opensearch permissions on receiving end and less about the version of NIFI.
... View more