kafka & flume

https://hazel-developer.tistory.com/297

궁금한 점

• flume의 Multi-tiered-fan-in

  • 먼저, 네트워크 트래픽의 양을 제한하고 들어오는 데이터를 결국 HDFS에 직접 기록합니다

  그리고 좀 더 쉽게 확장할 수 있습니다

  예를 들어 이 레이어를 다른 레이어보다 천천히 확장할 수 있죠

  그리고 다수의 데이터 센터를 가지고 있는 경우에 이득이 됩니다

  단 몇 개의 라인만 들어가는 토폴로지의 일부나

  수많은 트래픽이 지나가는 광역통신망을 통과하는 것이

  같은 데이터 센터의 근거리 통신망에서 다뤄지도록 합니다

  그러니 이 패턴은 많은 유연함을 제공합니다

Study 정리

• 로그 데이터는 즉시 프로세싱해야 하므로 스트리밍 기술이 필요하다.

[kafka]

• 스토리지로도 쓰는 경우도 있다.
  • 데이터를 저장하는 기간이 길기 때문에
  • 메시지 큐로 일반적으로 사용
• offset을 이용한 설정이 매우 중요
  • 장애 대응
• 하둡을 위한 시스템은 아니지만 하둡에서도 잘 사용할 수 있다.
• 로그 데이터가 스트럭쳐 즉 구조화된 데이터가 아닌 경우에도 이를 구조화해주기 위해서 stream processor가 필요하다
  • 이런 기능을 하는 것들이 spark streaming, flink가 존재$$

→ consumer group 중요

• group id 설정 매우 중요
• 복제설정 가능
  • 리더와 팔로워가 존재하는데 리더는 하나뿐이다.
  • 같은 인싱크 레플리카(ISR)안에 있는 레플리카는 누구나 리더가 될 수 있다.
  • 주키퍼가 이러한 역할을 한다(raft는 아직 상용으로는 위험하다)
  • 리더가 되는 조건은 팔로워가 리더와 거의 동일한 상태를 가지고 있어야한다. 최신화가 되어야 한다.
• kafka scale
  • 같은 그룹의 consumer들은 메시지가 똑같이 배포된다.
  • 그래서 메시지 들의 사본을 다 각자 얻는다.

[Flume]