running record count from SplitRecord processor Nifi - apache-nifi

Is there a way to get fragment index from SplitRecord processor Nifi? I am splitting a very big xls (4 mill records) into "Records Per Split" = 100000.
Now I want to just process first 2 splits, to see quality of the file and reject rest of the file.
I can see fragment index is in other split function (e.g. JsonSplit), but not in record split. Any other hack?

Method1:
By using Control Rate processor we can achieve this case
Control Rate Processor:
By this configs we are releasing 2 flowfiles for every minute and
Flow:
Configure the queue expiration to like 10 sec(or lower number if you need), then the flowfiles are going to expired in the queue but first 2 flowfiles are going to be released.
Method2:
By using SplitText processor then use RouteOnAttribute Processor and add new property as
${fragment.index:le(2)}
By using above expression language we are only allowing only the first 2 fragment indexes.
Refer to this link for splitting Big File in NiFi.

Related

inserting data to influxdb by nifi is too slow

I have data pipeline in NiFi , which listen to system log and process received data and extract attributes by "ExtractText" processors Then make influx input format by "ReplaceText" and at the end insert to influxdb by "PutInflux" processor. But I get a long queue before putInflux processor because insert speed is too slower than produced data. Please help me to increase insert speed.
Data PipeLine
ReplaceText processor configuration : (view_stat -> measurement , Listing_id -> tag, event_id -> value , Timestamp -> time )
PutInflux processor configuration
Are you putting multiple lines into Influx at once (i.e. multiple lines in a flow file) or one line at a time? If the latter, try a MergeContent or MergeRecord before PutInfluxDB, to get multiple lines into a file. Then you won't have to pay the overhead of transmitting each line over the wire, you can put a lot of them at once.
Thanks Mattyb,
I increased number of threads in PutInfluxDB processor and solved the problem :)

How to handle small files problem in Nifi

My current flow in Nifi is like
ListHDFS->FetchHDFS->SplitText->JoltransformJSon->PUTHBaseJSON.
Hourly input JSON files would be max of 10GB.
Single file size would be 80 -100MB.
Splittext & JoltTransform -> transform the text and sent it as 4KB files . Hence the hourly job is taking 50 to 1.20 minutest to complete the flow . How can I make this faster. What would be the best flow to handle the use case.
Have tried to use Mergecontent , didnt worked out well .
Thanks All
You can use MergeRecord processor After JoltTransfromJson Processor and
keep your maximum number of records to make flowfile eligible to merge into single flowfile.
Use Max Bin Age property as wildcard to force eligible the bin to be Merged.
Then use record oriented processor for HBase i.e PutHBaseRecord processor and configure your Record Reader controller service(JsonTree Reader) to read the incoming flowfile and tune the Batch size property value to get maximum performance.
By using this process we are processing chunks of records which eventually increase the performance of storing data into HBase.
Flow:
ListHDFS->FetchHDFS->SplitText->JoltransformJSon->MergeRecord ->PUTHBaseRecord
Refer to these links for Merge Record configs and Record Reader configs

What processors should be combined to process large JSON files in NiFi?

I would like to set up a NiFi workflow that pulls large JSON documents (between 500 MB and 3 GB), that have been gzipped from an FTP server, split the JSON objects into individual flow files, and finally convert each JSON object to SQL and insert it into a MySQL database.
I am running NiFi 1.6.0, on Oracle Java 8, and Java has 1024 MB heap space set.
My current flow is:
GetFTP -> CompressContent -> SplitJson -> EvaluateJsonPath -> AttributesToJson -> ConvertJSONToSQL -> PutSQL
This flow works great for JSON documents that are smaller. It throws Java OutOfMemory errors once a file that is larger than 400 MB enters the SplitJson processor. What changes can I make to the existing flow to enable it to process large JSON documents?
Generally you will want to avoid splitting to a flow file per document. You will get much better performance if you can keep many documents together in a single flow file. You will want to take a look at NiFi's record processing capabilities, specifically you will want to look at PutDatabaseRecord.
Here is a good intro to the record processing approach:
https://www.slideshare.net/BryanBende/apache-nifi-record-processing
If you absolutely have to perform splitting down to individual records per flow file, then you should at least perform a two phase split, where the first split processors splits to maybe 10k-20k per for flow file, then the second split processor splits down to 1 per flow file.

Nifi record counts

I am getting files from remote server using Nifi: my files are as follow:
timestamp (ms), nodeID,value
12345,x,12.4
12346,x,12.7
12348,x,13.4
12356,x,13,6
12355,y,12.0
I am now just get and fetch and split lines and send them to Kafka, but before hand, I need to apply a checksum approach on my records and aggregate them based on time stamp, what I need to do to add an additional column to my content and count the records based on aggregated time stamps, for example aggregation based on each 10 milliseconds and nodeID..
timestamp (ms), nodeID,value, counts
12345,x,12.4,3
12346,x,12.7,3
12348,x,13.4,3
12356,x,13,6,1
12355,y,12.0,1
How to do above process in NiFi. I am totally new to Nifi but need to add above functinality to my Nifi process. I am currently using below nifi process
This may not answer your question directly, but you should consider refactoring your flow to use the "record" processors. It would greatly simplify things and would probably get you closer to being able to do the aggregation.
The idea is to not split up the records, and instead process them in place. Given your current flow, the 4 processors after FetchSFTP would like change to a single ConvertRecord processor that converts CSV to JSON. You would first need to defined a simple Avro schema for your data.
Once you have the record processing setup, you might be able to use PartitionRecord to partition the records by the node id, and then from there the missing piece would be how to count by the timestamps.
Some additional resources...
https://blogs.apache.org/nifi/entry/record-oriented-data-with-nifi
https://bryanbende.com/development/2017/06/20/apache-nifi-records-and-schema-registries
https://www.slideshare.net/BryanBende/apache-nifi-record-processing

Apache Nifi processor that acts like a barrier to synchronize multiple flow files

I'm evaluating Nifi for our ETL process.
I want to build the following flow:
Fetch a lot of data from SQL database -> Split into chunks 1000 records
each -> Count error records in each chunk -> Count total number of error
records -> If it exceeds a threshold Fail process -> else save each chunk to the database.
The problem I can't resolve is how to wait until all chunks are validated.
If for example I have 5 validation tasks working concurrently, I need some
kind of barrier to wait until all chunks are processed and only after that
run error count processor because I don't want to save invalid data and
delete it if the threshold is reached.
The other question I have is if there is any possibility to run this
validation processor on multiple nodes in parallel and still have the
possibility to wait until they all are completed.
One solution to this is to use the ExecuteScript processor as a "relief valve" to hold a simple count in memory triggered off of the first receipt of a flowfile with a specific attribute value (store in the local/cluster state with basically a Map of key attribute-value to value count). Once that value reaches a threshold, you can generate a new flowfile to route to the success relationship containing the attribute value that has finished. In this case, send the other results (the flowfiles that need to be batched) to a MergeContent processor and set the minimum batching size to whatever you like. The follow-on processor to the valve should have its Scheduling Strategy set to Event Driven so it only runs when it receives a flowfile from the valve.
Updating count in distributed MapCache is not the correct way as fetch and update are separate and cannot be made in atomic processor which just increments counts.
http://apache-nifi-users-list.2361937.n4.nabble.com/How-do-I-atomically-increment-a-variable-in-NiFi-td1084.html

Resources