Kafka introduce - swsuh93/study GitHub Wiki

Apache Kafka (A distributed streaming platform)

• 스트리밍 플랫폼의 주요 기능 메시지 큐 또는 엔터프라이즈 메시징 시스템과 유사하게 레코드 스트림을 게시하고 구독 내결함성이 강한 방식(N개의 노드들 중 하나 이상의 노드가 불능 상태여도 정상 작동)으로 레코드 스트림 저장 레코드 스트림을 처리

• 주 사용 응용프로그램 시스템 또는 응용프로그램간에 데이터를 안정적으로 얻는 실시간 스트리밍 데이터 파이프라인 구축 데이터 스트림을 변환하거나 이에 반응하는 실시간 스트리밍 애플리케이션 구축

• 개념 Kafka는 여러 데이터 센터로 확장 될 수 있는 하나 이상의 서버에서 클러스터로 실행됩니다. 카프카 클러스터는 'topic'이라는 카테고리에 '레코드'의 스트림을 저장합니다. 각 레코드는 키, 값, 타임스탬프로 구성됩니다

• 4가지 핵심 제공 API

  • Producer API : 애플리케이션이 하나 이상의 Kafka topic에 레코드의 스트림을 생산할 수 있도록 허용한다
  • Consumer API : 애플리케이션이 하나 이상의 topic을 구독하고, 그들에게 생산된 레코드의 스트림을 처리하도록 허용한다
  • Streams API : 애플리케이션이 스트림 프로세서 역할을 하도록 한다, 하나 이상의 topic으로부터 input stream을 소비하고, 하나 이상의 ouput topic에 ouput stream을 생산하는, 효과적으로 input stream을 ouput stream으로 변환하도록
  • Connector API : Kafka topic을 존재하는 애플리케이션이나 데이터 시스템에 연결하도록 재사용가능한 생산자 또는 소비자들의 building, running 을 허용한다 . 예를들어, 관계형 데이터베이스에 대한 connector 는 테이블에 대한 모든 변경 사항을 capture(포획,인지) 할 수 있다

• Kafka에서 클라이언트와 서버 간의 통신은 단순하고, 고성능이고, 언어에 구애받지 않는 TCP protocol로 수행된다. 이 프로토콜은 버전이 지정되며 이전 버전과의 하위 호환성을 유지한다. Kafka를 위한 Java client를 제공하지만 client들은 여러 언어로 사용 가능하다

• 각 파티션은 계속해서 추가되는 순서화 된 불변의 레코드 순서 인 구조화 된 커밋 로그입니다. 파티션의 레코드에는 파티션 내의 각 레코드를 고유하게 식별 하는 오프셋 이라는 순차적 인 ID 번호가 각각 지정 됩니다.

• Kafka 클러스터는 구성 가능한 보존 기간을 사용하여 게시 된 모든 레코드 (사용 여부와 상관없이)를 영구히 유지합니다. 예를 들어 보존 정책을 2 일로 설정하면 레코드를 게시 한 후 2 일 동안 소비 정책을 사용할 수 있으며 그 이후에는 사용 가능한 공간을 늘리기 위해 폐기됩니다. Kafka의 성능은 데이터 크기와 관련하여 사실상 일정하므로 데이터를 오랫동안 저장하는 것은 문제가되지 않습니다.

• 일반적으로 소비자는 레코드를 읽을 때 선형 적으로 오프셋을 진행하지만 실제로는 위치가 소비자에 의해 제어되므로 좋아하는 순서대로 레코드를 소비 할 수 있습니다. 예를 들어, 소비자는 과거의 데이터를 다시 처리하기 위해 오래된 오프셋으로 재설정하거나 가장 최근의 레코드로 건너 뛰고 "지금"에서 소비하기 시작할 수 있습니다.

• they can come and go without much impact on the cluster or on other consumers

• 로그의 파티션은 여러 가지 용도로 사용됩니다. 첫째, 로그를 단일 서버에 맞는 크기 이상으로 확장 할 수 있습니다. 각 개별 파티션은 호스트하는 서버에 적합해야하지만 주제에 많은 파티션이있어 임의의 양의 데이터를 처리 할 수 있습니다. 둘째, 그들은 병렬 처리의 단위처럼 행동합니다.

• 분포 : 로그의 파티션은 Kafka 클러스터의 서버를 통해 배포되며 각 서버는 데이터를 처리하고 파티션 공유에 대한 요청을 처리합니다. 각 파티션은 장애 허용을 위해 구성 가능한 수의 서버에 복제됩니다. 각 서버는 일부 파티션의 리더와 다른 서버의 팔로어로 작동하므로로드가 클러스터 내에서 잘 균형을 이룹니다

• Geo-Replication : Kafka MirrorMaker는 클러스터에 지리적 복제 지원을 제공합니다. 메시지가 여러 데이터 센터 또는 클라우드 region에 복제. 백업 및 복구를 위해 능동/수동 시나리오 사용 가능. 데이터 지역성 요구 지원 가능.

• Producers : 선택한 topic에 데이터 publish. topic 내에서 어떤 파티션에 어떤 레코드를 할당할지 선택해야 함. load balance를 맞추기 위해 라운드 로빈 방식을 사용하거나 일부 semantic partition function(레코드의 일부 키를 기반으로 함)) 에 따라 수행 될 수 있음. 두번째로 파티셔닝을 더 많이 사용함.

• Consumers : 소비자는 소비자 그룹 이름을 사용하여 자신에게 레이블 을 지정하고 주제에 게시 된 각 레코드는 각 구독 소비자 그룹 내의 하나의 소비자 인스턴스에 전달됩니다. 소비자 인스턴스는 별도의 프로세스 또는 별도의 시스템에있을 수 있습니다. 모든 소비자 인스턴스가 동일한 소비자 그룹을 갖는 경우 레코드는 소비자 인스턴스보다 효과적으로로드 밸런싱됩니다. 모든 소비자 인스턴스가 서로 다른 소비자 그룹을 갖고 있으면 각 레코드가 모든 소비자 프로세스에 브로드 캐스팅됩니다.

• Multi-tenancy : Kafka를 멀티 테넌트 솔루션으로 배포할 수 있다. 멀티 테넌시는 데이터를 생성 또는 소비할 수 있는 topic을 구성하여 사용할 수 있다. 할당량에 대한 운영 지원도 있다. 관리자는 클라이언트가 사용하는 브로커 자원을 제어하라는 요청에 대해 할당량을 정의하고 시행할 수 있다.

• Guarantees : 순서를 지킴(먼저간 메시지에 대해 낮은 오프셋, 로그에 일찍 나타남) : consumer instance는 로그에 저장된 순서대로 레코드를 봄 : 복제 인자 N이 있는 topic의 경우, 로그에 commit 된 레코드를 손실하지 않고 최대 N-1개의 서버 오류 허용

• Kafka as a Messaging System : As with a queue the consumer group allows you to divide up processing over a collection of processes (the members of the consumer group). As with publish-subscribe, Kafka allows you to broadcast messages to multiple consumer groups.[queuing와 publish-subscribe 방식 모두 가능] : The advantage of Kafka's model is that every topic has both these properties—it can scale processing and is also multi-subscriber—there is no need to choose one or the other.[모든 topic 이 이러한 속성(처리 규모 조정, 다중 가입자)을 갖추고 있다] : Kafka has stronger ordering guarantees than a traditional messaging system, too.[강력한 ordering guarantees] : By having a notion of parallelism—the partition—within the topics, Kafka is able to provide both ordering guarantees and load balancing over a pool of consumer[병렬 처리 개념으로 ordering guarantees와 load balancing 모두 제공] however that there cannot be more consumer instances in a consumer group than partitions.[소비자 그룹에는 파티션보다 더 많은 소비자 인스턴스가 있을 수 없다]

• Kafka as a Storage System : Data written to Kafka is written to disk and replicated for fault-tolerance[Kafka에 기록된 데이터는 디스크에 기록되고 내결함성을 위해 복제된다] : The disk structures Kafka uses scale well—Kafka will perform the same whether you have 50 KB or 50 TB of persistent data on the server[Kafka가 scale well-Kafka를 사용하는 디스크 구조는 서버에 50KB 또는 50TB의 지속적인 데이터를 가지고 있더라도 동일하게 수행합니다] : As a result of taking storage seriously and allowing the clients to control their read position, you can think of Kafka as a kind of special purpose distributed filesystem dedicated to high-performance, low-latency commit log storage, replication, and propagation. [고성능, 낮은 대기 시간의 commit 로그 저장, 복제, 번식 등의 특별한 목적의 분산 파일 시스템]

• Kafka for Stream Processing[Stream API] : It isn't enough to just read, write, and store streams of data, the purpose is to enable real-time processing of streams [스트림의 실시간 처리를 가능하게 하는 것] : This facility helps solve the hard problems this type of application faces: handling out-of-order data, reprocessing input as code changes, performing stateful computations, etc. [순서가 잘못된 데이터 처리, 코드 변경 사항으로 입력 재 처리, 상태 계산 등에 도움] : The streams API builds on the core primitives Kafka provides: it uses the producer and consumer APIs for input, uses Kafka for stateful storage, and uses the same group mechanism for fault tolerance among the stream processor instances. [스트림 API는 Kafka가 제공하는 핵심 기본 요소를 기반으로합니다. 입력에 생산자 및 소비자 API를 사용하고, 상태 저장을 위해 Kafka를 사용하며, 스트림 프로세서 인스턴스 간의 내결함성을 위해 동일한 그룹 메커니즘을 사용합니다.]

• 조각 맞추기 : 메시징, 스토리지, 스트림 처리의 결합은 보기 드물다. 그러나 이것이 중요한 streaming platform으로써의 Kafka의 역할이다 : Kafka combines both of these capabilities, and the combination is critical both for Kafka usage as a platform for streaming applications as well as for streaming data pipelines.[과거의 기록 데이터 저장, 처리 / 미래의 데이터 도착하는데로 처리 모두 가능] : By combining storage and low-latency subscriptions, streaming applications can treat both past and future data the same way. That is a single application can process historical, stored data but rather than ending when it reaches the last record it can keep processing as future data arrives. This is a generalized notion of stream processing that subsumes batch processing as well as message-driven applications.[과거 및 미래 데이터 동일 방식 처리 / 마지막 레코드 도달 시 종료하지 않고 이후 데이터 도착 시 처리] : Likewise for streaming data pipelines the combination of subscription to real-time events make it possible to use Kafka for very low-latency pipelines; but the ability to store data reliably make it possible to use it for critical data where the delivery of data must be guaranteed or for integration with offline systems that load data only periodically or may go down for extended periods of time for maintenance. The stream processing facilities make it possible to transform data as it arrives.[스트리밍 데이터 파이프 라인의 경우 매우 짧은 지연시간의 파이프라인 사용이 가능하다.]