※注意としてここで解説しているのは私の感覚の基づいたものが大きい。公式の文章のままでピンと来ない人になんとなくこういうものって認識でいいと思うよ、というスタンスで記載している。
もし間違いがあればコメントいただけるとありがたい。その場合、補足なりとなんらかの形で追記をしていこうと思う。

Processor

NiFi の画面にひたすら置かれている四角いアイツが Processor
Processor とは?と言われると答えが難しいが、プログラマ向けに言えば一つの関数と思っていただければ良い(というか NiFi 自体 Java で作られているのであながち間違いでもない)
NiFi はこれを組み合わせてフローを作り上げていく。
中には Script を用いることのできる Processor も用意されているが、それを使わなくともある程度の処理は数ある Processor を用いることで実装が可能。
そうして プログラムレス で代わりに Processor を置いて実装をガシガシ進められるのが NiFI の利点であることは間違いない。慣れると本当に早い。

Relationships

リレーションシップ(ス)。直訳すると「関係」。
Processor 同士を繋げる線があるが、ざっくり言えばアレのこと。
勿論、正確に言えば違う。
Processor は必ずこの Relationships が用意されている。それは「success」だったり「failure」だったり、他にも色々種類があり、自分で用意することができる Processor もある。(例:matched,unmatched,response,retry,etc..)
これはプロセッサ同士を繋げる時に必ず NiFi から尋ねられる。一つのみを指定してもいいし、複数選択することも可能。
では Relationships とはなんぞや?ということだが…
Processor 処理後の結果を表すもの、である。
要はそのプロセッサの処理の結果が失敗したのなら、「failure」にプロセスは流れ、成功すれば「success」のプロセスに流れる。
そのため Relationships を見ておくとそのプロセッサがどういう挙動をするのか、どういうエラーを想定しているのかを把握することができる。

FlowFile

NiFI は数々のプロセッサから成り立つフロー。そのフローをデータが通っていくわけだが、そのデータオブジェクトのことを NiFi では FlowFile と呼ぶ。…でいいと思う。
もっとこう簡単に言うと、NiFi を動かすとデータが流れてって、どこかを停止するとその直前のフローに数字が溜まっていくと思う。アレのこと。
FlowFile は固有の ID を持っていて、uuid と呼ばれる。ただしこれは注意が必要で…後述する。

Attribute

直訳すると「属性」となる。がまあ難しく考えず「変数」であると考えるとよいかと。プログラム経験者向けにもうちょい言うと「グローバル変数」のこと。前述した FlowFile が持つものの一つである。前述した FlowFile の uuid もこの形で持っている。

Content

正直正式名称かはわからない。ただ Attributeと合わせて使われることが多いので多分この名称でいいと思う。
所謂ボディの部分。ちなみに Attribute はヘッドの部分と言っても間違いではないかもしれない。リクエストを受けた時に送られてきたリクエストボディはここに格納される。また同じように http 通信を行う場合はここに格納されたものをリクエストボディとして送るし、同様にレスポンスボディとして返しもする。
※Attribute に関してはヘッドと言ったものの、InvokeHTTP(http 通信プロセッサ)使用時勝手にヘッドに含まれることはない。ボディは固有の設定を行わないと勝手に送られるため注意が必要)

uuid

前述の通り FlowFIle が固有に持つ ID。
ログなどを追う時、ログが勝手に出力されるプロセッサが実行される時必ずこの ID が付属して出力される。
ただし注意が必要で、フロー次第では頭から足まで必ず同じ ID というわけではない。
ではどういう時に変わるのかと言うと、主にhttp 通信時、である。
自分なりの解釈としては、FlowFile が持つ固有の ID ではなく、実は Content が持つ固有の ID という認識のほうがしっくり来る。
NiFi フロー内部で Content を操作、編集する時は uuid の変更は起きないが、http 通信時、つまりレスポンスを受けた時のみ変わる。レスポンスを受けるということは何かしらの Body を持っていること。
結論としてはこうだ。
Content を直接弄る操作の時は uuid が据え置き であり、
Content を丸々入れ替える操作のときは新しく uuid が発行される。
ちなみに http 通信に限らず、DB 連携(ExecuteSQL等)時にも再発行される。
上記の事からログの途中で uuid が変わっていようとも、その付近のプロセッサ自体ではありうるということを覚えとくとよいか。

とりあえずこんなところ。何かあればコメントまで。
また思いついたら追記していきます・