전통적인 메시지 브로커 및 스트리밍 데이터

Kafka 사이트 에 따르면 :

" Kakfa는 실시간 데이터 파이프 라인 및 스트리밍 앱을 구축하는 데 사용됩니다. "

인터넷을 광범위하게 검색하면서 " 스트림 데이터 "가 무엇인지에 대해 다음과 같이 일반적으로 수용되는 정의를 찾았습니다 .

• 스트림 데이터는 네트워크를 통해 소스에서 대상으로 연속적으로 흐르는 데이터입니다. 과
• 스트림 데이터는 본질적으로 원자 적이 지 않습니다 . 즉, 데이터 스트림이없는 한 바이트가 의미가없는 파일과 달리 흐르는 데이터 스트림의 일부는 의미 있고 처리 가능합니다. 과
• 스트림 데이터는 언제든지 시작 / 중지 할 수 있습니다. 과
• 소비자는 원하는대로 데이터 스트림을 연결 및 분리하고 원하는 부분 만 처리 할 수 ​​있습니다.

이제 위에서 말한 내용이 정확하지 않거나 불완전하거나 완전히 틀린 경우 먼저 수정 해주세요. 내가 거의 궤도에 있다고 가정하면 ...

"스트리밍 데이터"가 무엇인지 이해 했으므로 Kafka와 Kinesis가 스트리밍 데이터가있는 응용 프로그램의 처리 / 브로커 링 미들웨어로 청구 할 때의 의미를 이해합니다. 그러나 Kafka 또는 Kinesis와 같은 "스트림 미들웨어"를 기존 메시지 브로커와 같은 비 스트리밍 데이터에 사용할 수 있습니까? 그 반대의 경우 : RabbitMQ, ActiveMQ, Apollo 등과 같은 기존 MQ를 스트리밍 데이터에 사용할 수 있습니까?

애플리케이션이 처리해야하는 JSON 메시지의 백엔드 상수 공격을 전송하고 처리가 상당히 복잡한 경우 (유효성 검증, 데이터 변환, 필터링, 집계 등)를 예로 들어 보겠습니다.

• 사례 # 1 : 메시지는 영화의 각 프레임입니다. 프레임 데이터와 일부 지원 메타 데이터를 포함하는 비디오 프레임 당 하나의 JSON 메시지입니다.
• 사례 # 2 : 메시지는 시계열 데이터이며 시간의 함수로서 누군가의 심장 박동일 수 있습니다. 따라서 메시지 # 1은 t = 1에서 내 심장 박동을 나타내는 것으로 전송되고 메시지 # 2는 t = 2에서 내 심장 박동을 포함합니다.
• 사례 # 3 : 데이터는 시간에 따라 또는 "데이터 스트림"의 일부로 완전히 분리되어 있고 관련이 없습니다. 수백 명의 사용자가 버튼을 클릭하고 조치를 취하면서 애플리케이션을 탐색 할 때 발생하는 감사 / 보안 이벤트

Kafka / Kinesis의 청구 방법과 "스트리밍 데이터"가 무엇인지에 대한 이해를 바탕으로 Cases # 1 (연속 비디오 데이터) 및 # 2 (연속 시계열 데이터)에 대한 확실한 후보로 보입니다. 그러나 RabbitMQ와 같은 전통적인 메시지 브로커가 이러한 입력을 효율적으로 처리 할 수없는 이유는 없습니다 .

그리고 사례 # 3에서는 발생한 이벤트 만 제공되며 해당 이벤트에 대한 반응을 처리해야합니다. 나에게 이것은 RabbitMQ와 같은 전통적인 중개인이 필요하다는 것을 말합니다. 그러나 Kafka 나 Kinesis가 이벤트 데이터 처리를 처리하지 못한 이유도 없습니다.

그래서 기본적으로, 나는 Y 특성을 가진 X 데이터가 있다고 말하는 루 브릭을 설정하려고 합니다. 처리하려면 Kafka / Kinesis와 같은 스트림 프로세서를 사용해야합니다. 또는 반대로 결정하는 데 도움이되는 것 : Z 특성을 가진 W 데이터가 있습니다. 전통적인 메시지 브로커를 사용하여 처리해야합니다.

물어 그래서 : 스트리밍 데이터를 처리 할 수있는 모두 있기 때문에, 데이터 (또는 기타) 도움 조종 스트림 프로세서 또는 메시지 브로커 사이의 결정에 대해 요인, 둘 다 처리 할 수있는 메시지 데이터를 (비 스트리밍)?

Kafka는 순서대로 원자 메시지 로그를 처리합니다. pub/sub메시지 브로커 모드 와 같은 방식으로 볼 수 있지만 엄격한 순서와 과거에 디스크에서 계속 유지되는 메시지 스트림 (영원히 존재할 수 있음)을 순서대로 재생하거나 검색 할 수있는 기능을 제공합니다.

Kafka의 스트리밍 방식은 Thrift 또는 HTTP와 같은 원격 프로 시저 호출 과 Hadoop 에코 시스템과 같은 일괄 처리에 반대합니다 . RPC와 달리 구성 요소는 비동기식으로 통신합니다. 메시지가 전송 될 때와 수신자가 깨어나서 작동하는 시간 사이에 몇 시간 또는 며칠이 지나갈 수 있습니다. 서로 다른 시점에 수신자가 많을 수도 있고 아무도 메시지를 소비하지 않을 수도 있습니다. 여러 생산자가 소비자에 대한 지식없이 동일한 주제를 생산할 수 있습니다. Kafka는 구독 여부 또는 메시지 이용 여부를 알지 못합니다. 메시지는 단순히 관심있는 당사자가 읽을 수있는 로그에 커밋됩니다.

일괄 처리와 달리 대규모 메시지 모음이 아닌 단일 메시지에 관심이 있습니다. (카프카 메시지를 HDFS의 Parquet 파일에 보관하고 Hive 테이블로 쿼리하는 것은 드문 일이 아닙니다).

사례 1 : Kafka는 생산자와 소비자 사이의 특정 시간적 관계를 유지하지 않습니다. Kafka는 속도를 늦추고, 속도를 높이고, 적합하게 움직이고, 시작하는 등의 이유로 비디오 스트리밍에 적합하지 않습니다. 스트리밍 미디어의 경우 전체 처리량을 낮고 더 중요한 안정적인 대기 시간 (다른 방법으로) 으로 바꾸고 싶습니다 낮은 지터라고도 함). 카프카는 또한 메시지를 잃지 않기 위해 큰 고통을 겪습니다. 스트리밍 비디오에서는 일반적으로 UDP를 사용하며 비디오 실행을 유지하기 위해 여기 저기 프레임을 드롭하는 컨텐츠입니다. Kafka 지원 프로세스의 SLA는 일반적으로 건강 상태가 몇 초에서 몇 분, 건강 상태가 몇 시간에서 며칠입니다. 스트리밍 미디어의 SLA는 수십 밀리 초입니다.

Netflix는 Kafka를 사용하여 시간당 테라 바이트 단위의 비디오를 트랜스 코딩하여 디스크에 저장하지만 화면으로 전송하지 않는 내부 시스템에서 프레임을 이동할 수 있습니다.

사례 2 : 물론입니다. 우리는 고용주에게 Kafka를 이런 식으로 사용합니다.

사례 3 : 당신은 이런 종류의 일에 Kafka를 사용할 수 있지만 우리는 할 수 있지만 주문을 유지하기 위해 불필요한 오버 헤드를 지불하고 있습니다. 주문에 신경 쓰지 않기 때문에 다른 시스템에서 더 많은 성능을 낼 수 있습니다. 그러나 회사에서 이미 Kafka 클러스터를 유지 관리하고 있다면 다른 메시징 시스템의 유지 관리 부담을 감수하기보다는 재사용하는 것이 가장 좋습니다.

Kafka / Kinesis는 스트림으로 모델링됩니다. 스트림에는 메시지와 다른 속성이 있습니다.

• 스트림에는 컨텍스트가 있습니다. 그들은 순서가 있습니다. 스트림에 창 기능을 적용 할 수 있습니다. 스트림의 각 항목은 의미가 있지만 주변의 상황에서는 더 의미가있을 수 있습니다.
• 스트림에는 순서가 있으므로이를 사용하여 처리의 의미론에 대한 특정 명령문을 작성할 수 있습니다. 예를 들어 Apache Trident는 Kafka 스트림에서 소비 할 때 정확히 한 번의 의미를 갖습니다.
• 스트림에 함수를 적용 할 수 있습니다. 실제로 소비하지 않고 스트림을 변환 할 수 있습니다. 느리게 스트림을 소비 할 수 있습니다. 스트림의 일부를 건너 뛸 수 있습니다.
• 본질적으로 Kafka에서 스트림을 재생할 수 있지만 추가 소프트웨어 없이는 메시지 대기열을 재생할 수 없습니다. 이것은 데이터로 무엇을하고 싶은지조차 모를 때 유용합니다. AI 교육에도 유용합니다.

일반적으로 오프라인 스트림 처리에는 Kafka를 사용하고 실시간 클라이언트-서버 메시지에는 메시지 큐를 사용하십시오.

중추적 사용 사례의 예 :

Kafka : 웹 사이트 활동 추적, 메트릭, 로그 집계, 스트림 처리, 이벤트 소싱 및 커밋 로그

RabbitMQ : 범용 메시징 ...은 종종 사용자가 결과를 기다리는 동안 리소스가 많은 절차를 수행하지 않고 웹 서버가 요청에 빠르게 응답 할 수 있도록하는 데 사용됩니다. AMQP 0-9-1, STOMP, MQTT, AMQP 1.0과 같은 기존 프로토콜을 사용해야 할 때 사용

때로는 둘 다 사용하는 것이 유용 할 수도 있습니다! 예를 들어, 유스 케이스 # 2에서, 페이스 메이커의 데이터 스트림 인 경우 페이스 메이커가 즉시 하트 비트 데이터를 (MQTT와 같은 멋진 프로토콜을 사용하여) RabbitMQ 메시지 큐로 전송하면 즉시 처리됩니다. 소스의 심장이 여전히 뛰고 있는지 확인하십시오. 이를 통해 대시 보드 및 비상 대응 시스템에 전원을 공급할 수 있습니다. 메시지 대기열은 또한 시계열 데이터를 Kafka에 저장하여 시간이 지남에 따라 하트 비트 데이터를 분석 할 수 있습니다. 예를 들어, 하트 비트 스트림의 추세를 파악하여 심장병을 탐지하는 알고리즘을 구현할 수 있습니다.