nifi.apache.org/docs/nifi-docs/html/overview.html
NiFi 는 Host 운영체제의 JVM 내에서 실행
JVM 내에서 Web Server 를 운영하는데, 이는 HTTP 기반 명령 및 제어 API 를 호스팅하기 위함.
또한 WebUI 를 열기 위함
Extension 은 JVM 내에서 동작한다.
여기서 말하는 Extension 은, NiFi 가 제공하는 Processor 가 아닌
개발자가 직접 작성한 Processor 처럼 확장한 기능을 말함.
FlowFile Repo 는 현재 활성화된 FlowFile 에 대한 상태 정보를 갖고있음.
Content Repo 에 저장되는 FlowFile 의 실제 데이터들은 블럭 단위로 저장됨
그리고 단일 저장소 뿐 아니라, 물리적으로 나뉘어져있는 둘 이상의 저장소에 저장할 수 있음.
Flow Controller 라는 것이 있는데, 이게 정확하게 NiFi 의 어디에 있는지는 모르겠지만, NiFi 의 두뇌 역할을 한다고 함.
스케줄러인데, 특정 간격 혹은 Cron 표현식을 통해 스케줄링이 가능.
특정 프로세서에서 사용할 스레드를 스케줄링하는 엔진 역할이라고 함.
프로세서는 작업 실행이 완료되는 즉시 스레드를 반환함
따라서 작업이 끝나면 곧바로 CPU 자원이 돌아옴
NiFi는 JVM 내에 존재하므로 JVM이 제공하는 메모리 공간으로 제한
성능 최적화를 위해 충분히 큰 JVM 메모리 공간을 사용하는 것이 좋음
NiFi 는 Write-ahead Log 를 통해 disk 에 데이터를 쓰기 때문에 데이터를 안전하게 씀
그리고 데이터를 안전하게 운반하는 것을 보장함.
connection 내의 쌓인 FlowFile 을 우선순위를 정하여 처리할 수 있음.
기본적으로는 가장 먼저 쌓인 것(가장 오래된 것)부터 순서대로 처리하지만,
가장 나중에 쌓인 것(가장 최신 것), 가장 데이터 사이즈가 큰 것 등의 우선순위를 정하여 처리하도록 할 수 있음.
굉장히 중요한 데이터라서 손실이 절대 나지 말아야 하거나,
반드시 n초 이내에 처리되어야 하는 경우
NiFi 에서 Flow Specific QoS(Quality of Service) 를 통해 세분화된 흐름을 구성하는 것이 가능하다고 하는데...
내가 쓰고도 무슨 말인지 모르겠다.
nifi.apache.org/docs/nifi-docs/html/overview.html#high-level-overview-of-key-nifi-features
사용자가 암호같은 민감한 데이터를 flow 에 입력해도, 서버측에서 암호화를하기 때문에 client 측에 다시 노출되지 않음
일례로, EncryprContent 를 사용할 때 넣는 password 역시 내가 한 번 넣고나면 다시 보지 못하게 되었었음.
하나의 NiFi 서버를 여러 팀이 사용할 수 있다나 봄.
NiFi 관리자는 각 팀별로 세밀하게 권한을 제어할 수 있음.
다른 NiFi 서버와 통신할 때는 NiFi Site-to-Site 프로토콜을 사용하는게 좋다고 함.
쉽고 효율적이며 안전하게 데이터를 전송할 수 있기 때문.
NiFi 의 처리량을 증가시키기 위해, 스케줄링 탭에서 processor 의 concurrent tasks 수를 늘릴 수 있음
이로써 더 많은 프로세스를 동시에 실행할 수 있게 되어 처리량이 향상됨.
NiFi 가 다루는 데이터는 Content Repo 내에서
- 만료가 되거나
- 공간이 부족해지면
제거가 됨
참고
https://www.popit.kr/apache-nifi-overview-and-install/
'NiFi' 카테고리의 다른 글
[Nifi] Kubernetes 위에서 NiFi 구동시키는 방법 링크 (0) | 2020.11.09 |
---|---|
[Nifi] Getting Started with Apache NiFi 공부 필기 (0) | 2020.11.09 |
[Nifi] listSFTP/fetchSFTP 동작 방식 설명 (0) | 2020.11.03 |
[Nifi] Cluster 에서 HA 에 관한 고찰 링크 (0) | 2020.11.03 |
[Nifi] in depth 공부 필기 (0) | 2020.10.29 |