Introduction Of Apache Kafka

원글: https://kafka.apache.org/intro

Introduction

Apache Kafka® is a distributed streaming platform. What exactly does that mean?

Apache Kafka=분산 형 스트리밍 플랫폼의 정확한 의미는?

We think of a streaming platform as having three key capabilities:

스트리밍 플랫폼의 세 가지 핵심 기능.

1. It lets you publish and subscribe to streams of records. In this respect it is similar to a message queue or enterprise messaging system.
2. It lets you store streams of records in a fault-tolerant way.
3. It lets you process streams of records as they occur.

  1. 이를 통해 레코드 스트림을 발행하고 구독 할 수 있습니다. 이 점에서 이는 메시지 대기열 또는 엔터프라이즈 메시징 시스템과 유사합니다.

  2. 내장애성(일부장애 발생시에도 정상적으로 운용) 방식으로 레코드 스트림을 저장합니다.

  3. 발생하는 레코드 스트림을 처리할 수 있습니다.

What is Kafka good for?

It gets used for two broad classes of application:

활용되는 대표적인 두 가지 응용 프로그램분야가 있음

1. Building real-time streaming data pipelines that reliably get data between systems or applications
2. Building real-time streaming applications that transform or react to the streams of data

  1. 시스템 또는 응용 프로그램간에 안정적으로 데이터를 연계하는 실시간 스트리밍 데이터 파이프 라인 구축

  2. 데이터 스트림을 변환하거나 이에 반응하는 실시간 스트리밍 애플리케이션 구축

To understand how Kafka does these things, let's dive in and explore Kafka's capabilities from the bottom up.

카프카가 이러한 일을 어떻게하는지 이해하려면 카프카의 능력을 아래에서부터 탐구해보자.

First a few concepts: (기본컨셉)

• Kafka is run as a cluster on one or more servers.
• The Kafka cluster stores streams of records in categories called topics.
• Each record consists of a key, a value, and a timestamp.

• Kafka 는 하나 이상의 서버에서 클러스터로 방식으로 운용된다.
• The Kafka cluster 는 토픽이라고 불리우는 카테고리에 레코스 스트림을 저장한다. 
• 각 레코드는 키, 값, 시간기록(timestamp)으로 구성된다. 

Kafka has four core APIs: (구성하는 API)

• The Producer API allows an application to publish a stream of records to one or more Kafka topics.
• The Consumer API allows an application to subscribe to one or more topics and process the stream of records produced to them.
• The Streams API allows an application to act as a stream processor, consuming an input stream from one or more topics and producing an output stream to one or more output topics, effectively transforming the input streams to output streams.
• The Connector API allows building and running reusable producers or consumers that connect Kafka topics to existing applications or data systems. For example, a connector to a relational database might capture every change to a table.

• Producer API는 하나 이상의 카프카 (Kafka) 토픽에 레코드 스트림을 게시 할 수 있도록 합니다.
• Consumer API는 응용 프로그램에서 하나 이상의 항목을 구독하고 토픽으로부터 발행된 레코드 스트림을 처리 할 수 있습니다.

• Streams API는 응용 프로그램을 스트림 프로세서로 작동하게하며 하나 이상의 토픽에서 입력 스트림을 소비하고 하나 이상의 출력 항목으로 출력 스트림을 생성하여 효과적으로 입력 스트림을 출력 스트림으로 변환 할 수 있습니다.

• Connector API를 사용하면 기존 응용 프로그램 또는 데이터 시스템에 Kafka 토픽을 연결하여 재사용 가능한 생산자 또는 소비자를 구축할 수 있습니다. 예를 들어, 관계형 데이터베이스에 대한 커넥터는 테이블에 대한 모든 변경 사항을 캡처 할 수 있습니다.

 In Kafka the communication between the clients and the servers is done with a simple, high-performance, language agnostic TCP protocol. This protocol is versioned and maintains backwards compatibility with older version. We provide a Java client for Kafka, but clients are available in many languages.

Kafka에서, 클라이언트와 서버 간의 통신은 단순하고, 고성능이며, 언어에 구애받지 않는 TCP 프로토콜로 수행됩니다. 이 프로토콜은 버전이 지정되며 이전 버전과의 하위 호환성을 유지합니다. 우리는 카프카를 위한 자바 클라이언트를 제공하지만, 클라이언트는 여러 언어를 활용할 수 있습니다.

Topics and Logs

Let's first dive into the core abstraction Kafka provides for a stream of records—the topic.

A topic is a category or feed name to which records are published. Topics in Kafka are always multi-subscriber; that is, a topic can have zero, one, or many consumers that subscribe to the data written to it.

For each topic, the Kafka cluster maintains a partitioned log that looks like this:

먼저, Kafka가 제공하는 토픽의 레코드 스트림을 위한 핵심 추상화에 대해 알아 봅시다.

토픽은 레코드가 게시되는 카테고리 또는 피드 이름입니다. 

카프카의 토픽은 항상 다중 구독자가 있습니다.  즉, 한 토픽은 작성된 데이터를 구독하는 0, 1 또는 다수 사용자가 있을 수 있습니다.

각 토픽에 대해 Kafka 클러스터는 다음과 같은 파티션 로그를 유지합니다.:

Each partition is an ordered, immutable sequence of records that is continually appended to—a structured commit log. The records in the partitions are each assigned a sequential id number called the offset that uniquely identifies each record within the partition.

The Kafka cluster retains all published records—whether or not they have been consumed—using a configurable retention period. For example, if the retention policy is set to two days, then for the two days after a record is published, it is available for consumption, after which it will be discarded to free up space. Kafka's performance is effectively constant with respect to data size so storing data for a long time is not a problem.

각 파티션은 정렬되어 있고, 연속적으로 추가되어지는 서로 상호작용하지 않는 레코드들입니다. -구조화된 형태를 가진 저장된 로그 

파티션들 내의 레코드들은 각각 파티션 내의 각 레코드를 고유하게 식별하는 오프셋이라는 순차적 인 ID 번호가 각각 지정됩니다.

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

In fact, the only metadata retained on a per-consumer basis is the offset or position of that consumer in the log. This offset is controlled by the consumer: normally a consumer will advance its offset linearly as it reads records, but, in fact, since the position is controlled by the consumer it can consume records in any order it likes. For example a consumer can reset to an older offset to reprocess data from the past or skip ahead to the most recent record and start consuming from "now".

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

This combination of features means that Kafka consumers are very cheap—they can come and go without much impact on the cluster or on other consumers. For example, you can use our command line tools to "tail" the contents of any topic without changing what is consumed by any existing consumers.

이러한 모습들의 결합은 Kafka 소비자가 매우 저렴해진다는 것입니다. 클러스터 또는 다른 소비자에게 큰 영향을 미치지 않고 입출력 할 수 있습니다. 예를 들어, 커맨드 라인 도구인 "tail" 명령어를 사용하면 기존 소비자가 소비 하고 있는 것에 변화를 일으키지 않고 내용을 볼 수 있습니다. (Unix 유틸인 tail 명령어를 사용하면 기존의 로그 수행기능에 영향을 미치지 않고 파일에 기록된 최신 로그기록이 가능함을 예로들음)

The partitions in the log serve several purposes. First, they allow the log to scale beyond a size that will fit on a single server. Each individual partition must fit on the servers that host it, but a topic may have many partitions so it can handle an arbitrary amount of data. Second they act as the unit of parallelism—more on that in a bit.

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

Distribution

The partitions of the log are distributed over the servers in the Kafka cluster with each server handling data and requests for a share of the partitions. Each partition is replicated across a configurable number of servers for fault tolerance.

Each partition has one server which acts as the "leader" and zero or more servers which act as "followers". The leader handles all read and write requests for the partition while the followers passively replicate the leader. If the leader fails, one of the followers will automatically become the new leader. Each server acts as a leader for some of its partitions and a follower for others so load is well balanced within the cluster.

로그의 파티션은 Kafka 클러스터를 구성한 서버에 분배되며 각 서버는 데이터를 처리하고 파티션 공유에 대한 요청을 처리합니다. 각 파티션은 가용성을 위해 구성 가능한 서버들에 복제됩니다.

각 파티션에는 "리더"역할을하는 서버와 "팔로워"역할을하는 0 이상의 서버가 있습니다. 

리더는 팔로워가 리더를 수동적으로 복제하는 동안 파티션에 대한 모든 읽기 및 쓰기 요청을 처리합니다. 리더가 실패하면 추종자 중 하나가 자동으로 새로운 리더가됩니다. 

각 서버는 일부 파티션의 리더로 동작하고 다른 파티션에서는 팔로어로 작동하므로로드가 클러스터 내에서 잘 균형을 이루어집니다.

Producers

Producers publish data to the topics of their choice. The producer is responsible for choosing which record to assign to which partition within the topic. This can be done in a round-robin fashion simply to balance load or it can be done according to some semantic partition function (say based on some key in the record). More on the use of partitioning in a second!

생산자는 선택한 토픽에 데이터를 게시합니다. 생산자는 토픽 내에서, 어떤 파티션에 어떤 레코드를 할당하는 역할을 가지고 있습니다. 이는 로드 균형을 맞추기 위해 라운드 로빈 방식으로 수행되거나 어떤 의미를 가진 파티션 함수 (레코드의 일부 키를 기반으로 함)에 따라 수행될 수 있습니다. 두 번째로 파티셔닝을 더 많이 사용합니다!

Consumers

Consumers label themselves with a consumer group name, and each record published to a topic is delivered to one consumer instance within each subscribing consumer group. Consumer instances can be in separate processes or on separate machines.

If all the consumer instances have the same consumer group, then the records will effectively be load balanced over the consumer instances.

If all the consumer instances have different consumer groups, then each record will be broadcast to all the consumer processes.

소비자는 소비자 그룹 이름을 사용하여 레이블을 지정하고, 토픽에 게시된 각 레코드는 각 구독소비자 그룹 내의 하나의 소비 인스턴스들에 전달됩니다. 소비자 인스턴스는 별도의 프로세스 또는 별도의 시스템에 있을 수 있습니다.

모든 소비자 인스턴스가 동일한 소비자 그룹에 있는 경우, 레코드는 소비자 인스턴스들간 효과적으로로드 밸런싱될 것입니다.

모든 소비자 인스턴스가 서로 다른 소비자 그룹을 갖고 있으면 각 레코드는 모든 소비자 프로세스에 브로드캐스팅될 것입니다.

A two server Kafka cluster hosting four partitions (P0-P3) with two consumer groups. Consumer group A has two consumer instances and group B has four.

More commonly, however, we have found that topics have a small number of consumer groups, one for each "logical subscriber". Each group is composed of many consumer instances for scalability and fault tolerance. This is nothing more than publish-subscribe semantics where the subscriber is a cluster of consumers instead of a single process.

두 대의 서버로 구성된 Kafka 클러스터는 네 개의 파티션 (P0-P3)으로 이루어져 있으며 두 개의 소비자 그룹이 있습니다.  소비자 그룹 A에는 두 개의 소비자 인스턴스가 있고 그룹 B에는 네 개의 인스턴스가 있습니다.

그러나 더 일반적으로, 우리는 토픽들은 적은 수의 소비자 그룹을 가지고 있으며 그중에 하나는 "논리적인 구독자"인 것을 발견했습니다. 각 그룹은 확장성 및 내결함성을 위해 많은 소비자 인스턴스들로 구성됩니다. 이는 단일 프로세스대신에 소비자의 묶음으로된 구독자로 이루어진  게시자-구독자 형태라는 것입니다.

The way consumption is implemented in Kafka/ is by dividing up the partitions in the log over the consumer instances so that each instance is the exclusive consumer of a "fair share" of partitions at any point in time. 

This process of maintaining membership in the group is handled by the Kafka protocol dynamically. If new instances join the group they will take over some partitions from other members of the group; if an instance dies, its partitions will be distributed to the remaining instances.

Kafka 에서 소비가 구현되는 방식은/ 소비자의 인스턴스들 위의 로그에서 파티션들을 나누는 것에 의한 것이다.  그래서 각 인스턴스는 어느 시점에서든 파티션의 "공정한 공유"의 독점적인 소비자가 된다. 

 

이 그룹 구성원을 유지하는 프로세스는 Kafka 프로토콜에 의해 동적으로 처리됩니다. 새 인스턴스가 그룹에 참여하면 그룹의 다른 구성원으로부터 일부 파티션을 인계받습니다; 만약 인스턴스가 종료되면 해당 파티션이 나머지 인스턴스에 배포됩니다.

Kafka only provides a total order over records within a partition, not between different partitions in a topic. Per-partition ordering combined with the ability to partition data by key is sufficient for most applications. However, if you require a total order over records this can be achieved with a topic that has only one partition, though this will mean only one consumer process per consumer group.

Kafka는, 한 토픽내의 다른 파티션들 사이가 아니라, 한 파티션 내의 레코드에 대해서만 전체 정렬을 제공합니다. 키 단위로 데이터를 분할하는 기능과 결합 된 분할 단위 별 정렬하는것은 대부분의 응용 프로그램에서 충분합니다. 

그러나 레코드 전체 정렬이 필요하다면 이는, 비록 단지 소비자 그룹 당 하나의 소비자 프로세스를 의미할 것일지라도, 하나의 파티션만으로된 토픽에서만 가능합니다. 

Guarantees

At a high-level Kafka gives the following guarantees:

• Messages sent by a producer to a particular topic partition will be appended in the order they are sent. That is, if a record M1 is sent by the same producer as a record M2, and M1 is sent first, then M1 will have a lower offset than M2 and appear earlier in the log.
• A consumer instance sees records in the order they are stored in the log.
• For a topic with replication factor N, we will tolerate up to N-1 server failures without losing any records committed to the log.

More details on these guarantees are given in the design section of the documentation.

• 생산자가 특정 토픽 파티션으로 보낸 메시지는 보내진 순서대로 추가됩니다. 즉, 레코드 M1이 레코드 M2와 동일한 생성자에 의해 보내지고 M1이 먼저 보내지면 M1은 M2보다 더 낮은 오프셋을 가지며 로그에서 더 일찍 보여집니다.
• 소비자 인스턴스는 로그에 저장된 순서대로 레코드를 봅니다.
• N번의 복제되는 토픽인 경우, N-1 개의 서버에서 오류가 발생해도 로그에 커밋 된 레코드를 손실하지 않을 수 있습니다.  

이러한 보증에 대한 자세한 내용은 설명서의 디자인 섹션에 나와 있습니다.

Kafka as a Messaging System

How does Kafka's notion of streams compare to a traditional enterprise messaging system?

Messaging traditionally has two models: queuing and publish-subscribe. In a queue, a pool of consumers may read from a server and each record goes to one of them; in publish-subscribe the record is broadcast to all consumers. Each of these two models has a strength and a weakness. The strength of queuing is that it allows you to divide up the processing of data over multiple consumer instances, which lets you scale your processing. Unfortunately, queues aren't multi-subscriber—once one process reads the data it's gone. Publish-subscribe allows you broadcast data to multiple processes, but has no way of scaling processing since every message goes to every subscriber.

카프카의 스트림 개념은 기존 엔터프라이즈 메시징 시스템과 어떻게 비교 되는가?

메시징은 전통적으로 두 가지 모델을 가지고 있습니다 : 큐(대기열) 및 펍섭(게시자-구독자). 대기열에서 소비자 풀은 서버에서 읽을 수 있으며 각 레코드는 그 중 하나에 저장됩니다. publish-subscribe에서 레코드는 모든 소비자에게 브로드 캐스팅됩니다. 이 두 모델은 각각 강점과 약점을 가지고 있습니다. 큐처리 기능을 사용하면 여러 소비자 인스턴스에서 데이터 처리를 나눌 수 있으므로 처리 규모를 확장 할 수 있습니다. 유감스럽게도 큐는 다중 구독자가 아닙니다. 한번 한 프로세스가 데이터를 읽으면 그 데이터는 사라집니다.  Publish-subscribe는 여러 프로세스에 데이터를 브로드 캐스트 할 수 있지만 모든 메시지가 모든 구독자에게 전달되므로 처리를 조정할 방법이 없습니다.

The consumer group concept in Kafka generalizes these two concepts. 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.

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.

카프 카의 소비자 그룹 개념은 이 두 개념을 일반화합니다. 큐에서와 마찬가지로 소비자 그룹은 프로세스 모음 (소비자 그룹의 구성원)을 통해 처리를 구분할 수 있습니다. publish-subscribe와 마찬가지로 Kafka를 사용하면 여러 소비자 그룹에 메시지를 브로드 캐스트 할 수 있습니다.

Kafka의 모델의 장점은 모든 주제가 이러한 속성을 모두 갖추고 있다는 것입니다. 즉, 처리 규모를 조정할 수 있고 다중 가입자이기도하므로 둘 중 하나를 선택할 필요가 없습니다.

Kafka has stronger ordering guarantees than a traditional messaging system, too.

A traditional queue retains records in-order on the server, and if multiple consumers consume from the queue then the server hands out records in the order they are stored. However, although the server hands out records in order, the records are delivered asynchronously to consumers, so they may arrive out of order on different consumers. This effectively means the ordering of the records is lost in the presence of parallel consumption. Messaging systems often work around this by having a notion of "exclusive consumer" that allows only one process to consume from a queue, but of course this means that there is no parallelism in processing.

Kafka는 전통적인 메시징 시스템보다 강력한 전달 순서 보증을 제공합니다.

전통적인 큐는 서버에서 순서대로 레코드를 보유하고, 여러 소비자가 큐에서 소모하는 경우 서버는 저장된 순서대로 레코드를 전달합니다. 그러나 서버가 레코드를 순서대로 전달하더라도 레코드는 비동기 적으로 소비자에게 전달되므로 서로 다른 소비자에게 순서가 잘못 될 수 있습니다. 이것은 사실상 병렬 소비가 발생하면 레코드의 순서가 손실된다는 것을 의미합니다. 메시징 시스템은 대기열에서 하나의 프로세스 만 사용할 수있는 "독점적 인 소비자"라는 개념을 사용하여 이 문제를 해결하기도하지만, 처리 과정에서 병렬 처리가 없다는 것을 의미합니다.

Kafka does it better. 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 processes. This is achieved by assigning the partitions in the topic to the consumers in the consumer group so that each partition is consumed by exactly one consumer in the group. By doing this we ensure that the consumer is the only reader of that partition and consumes the data in order. Since there are many partitions this still balances the load over many consumer instances. Note however that there cannot be more consumer instances in a consumer group than partitions.

카프카는 더 좋습니다. 토픽 내에서 병렬 처리 개념 (파티션)을 가짐으로써 카프카는 소비자 프로세스 풀에 대해 순서 보증과 로드 밸런싱을 모두 제공 할 수 있습니다. 이는 토픽의 파티션을 소비자 그룹의 소비자에게 할당하여 각 파티션이 그룹의 정확히 한 소비자에 의해 소비되도록하여 수행됩니다. 이렇게하면 소비자가 해당 파티션의 유일한 독자이고 순서대로 데이터를 사용하게됩니다. 파티션이 많으므로 많은 소비자 인스턴스에서로드의 균형을 유지합니다. 그러나 소비자 그룹에는 파티션보다 더 많은 소비자 인스턴스가있을 수 없습니다.

Kafka as a Storage System

Any message queue that allows publishing messages decoupled from consuming them is effectively acting as a storage system for the in-flight messages. What is different about Kafka is that it is a very good storage system.

Data written to Kafka is written to disk and replicated for fault-tolerance. Kafka allows producers to wait on acknowledgement so that a write isn't considered complete until it is fully replicated and guaranteed to persist even if the server written to fails.

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.

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.

For details about the Kafka's commit log storage and replication design, please read this page.

소비자가 없는 메세지를 생산은 메세지 큐는 흘러가는(in-flight) 메세지의 효과적인 저장소로 이용될 수 있습니다. 카프카의 메세지큐와의 차이점은  매우 훌륭한 저장 시스템이라는 것입니다. Kafka에 쓰여진 데이터는 디스크에 기록되고 내결함성을 위해 복제됩니다.

Kafka는 생산자가 ac신호를 기다리도록 허용합니다. 그래서  Kafka가 심지어 서버에서 쓰기가 실패할지라도 저장소에 완전히 복제되고 보장될때까지 쓰기가 정상적으로  종료되었는지 신경쓰지 않습니다. 

Kafka가 scale well-Kafka를 사용하는 디스크 구조는 서버에 50KB 또는 50TB의 영구 데이터를 가지고 있더라도 동일하게 수행합니다.

스토리지를 중요하게 생각하고 클라이언트가 읽기 위치를 제어 할 수있게 된 결과, Kafka는 고성능, 낮은 대기 시간의 커밋 로그 저장, 복제 및 전달 전용의 일종의 특수 목적의 분산 파일 시스템으로 생각할 수 있습니다.

Kafka의 커밋 로그 저장 및 복제 디자인에 대한 자세한 내용은 이 페이지를 참조하십시오.

Kafka for Stream Processing

It isn't enough to just read, write, and store streams of data, the purpose is to enable real-time processing of streams.

In Kafka a stream processor is anything that takes continual streams of data from input topics, performs some processing on this input, and produces continual streams of data to output topics.

For example, a retail application might take in input streams of sales and shipments, and output a stream of reorders and price adjustments computed off this data.

It is possible to do simple processing directly using the producer and consumer APIs. However for more complex transformations Kafka provides a fully integrated Streams API. This allows building applications that do non-trivial processing that compute aggregations off of streams or join streams together.

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.

스트림 프로세스는 단지 데이터 스트림을 읽고, 쓰고, 저장하는 것만으로는 충분하지 않습니다. 목적은 스트림의 실시간 처리를 가능하게 하는 것입니다.

Kafka에서, 스트림 프로세서는 입력 항목에서 연속적인 데이터 스트림을 가져 와서이 입력에 대한 일부 처리를 수행하고 토픽을 출력하기 위해 지속적인 데이터 스트림을 생성하는 것입니다.

예를 들어, 소매 응용 프로그램은 판매 및 출하의 입력 스트림을 받아 들여이 데이터에서 계산된 재주문 및 가격 조정 스트림을 출력 할 수 있습니다.

생산자 API와 소비자 API를 사용하여 직접 간단한 처리를 수행 하는것이 가능합니다. 그러나 보다 복잡한 변경처리를 위해 Kafka는 완전히 통합된 Streams API를 제공합니다 . 따라서 스트림에서 집계를 계산하거나 스트림을 함께 결합하는 사소하지 않은 처리를 하는 응용 프로그램을 작성할 수 있습니다.

이 기능은 이러한 유형의 애플리케이션이 직면 한 어려운 문제를 해결하는 데 도움이됩니다. 즉, 순서가 잘못된 데이터 처리, 코드 변경 사항으로 입력 재 처리, 수행중인 상태 계산 등입니다.

스트림 API는 Kafka가 제공하는 핵심 기본 요소를 기반으로합니다. 입력에 발행 및 구독 API를 사용하고, 상태 저장을 위해 Kafka를 사용하며 스트림 프로세서 인스턴스 간의 내고장성을 위해 동일한 그룹 메커니즘을 사용합니다.

Putting the Pieces Together

This combination of messaging, storage, and stream processing may seem unusual but it is essential to Kafka's role as a streaming platform.

A distributed file system like HDFS allows storing static files for batch processing. Effectively a system like this allows storing and processing historical data from the past.

A traditional enterprise messaging system allows processing future messages that will arrive after you subscribe. Applications built in this way process future data as it arrives.

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.

For more information on the guarantees, APIs, and capabilities Kafka provides see the rest of the documentation.

메시징, 스토리지 및 스트림 처리의 이러한 결합은 드문 것처럼 보일 수 있지만 스트리밍 플랫폼으로서의 카프카의 역할에 필수적입니다.

HDFS와 같은 분산 파일 시스템을 사용하면, 일괄 처리를 위해 정적 파일을 저장할 수 있습니다. 사실상 이와 같은 시스템을 사용하면 과거의 기록 데이터를 저장하고 처리 할 수 ​​있습니다 .

기존 엔터프라이즈 메시징 시스템을 사용하면 가입 한 후에 도착할 향후 메시지를 처리 ​​할 수 ​​있습니다. 이런 식으로 작성된 응용 프로그램은 도착하는대로 미래의 데이터를 처리합니다.

Kafka는이 두 가지 기능을 모두 갖추고 있으며 두가지 기능의 결합은 스트리밍 응용 프로그램과 스트리밍 데이터 파이프 라인의 플랫폼으로 Kafka를 사용시 중요합니다.

스토리지 및 대기 시간이 짧은 구독을 결합하여 스트리밍 응용 프로그램은 과거 및 미래 데이터를 동일한 방식으로 처리 할 수 ​​있습니다. 즉, 단일 응용 프로그램에서 기록 된 저장된 데이터를 처리 할 수 ​​있지만 마지막 레코드에 도달 할 때 종료하지 않고 이후 데이터가 도착할 때 처리를 유지할 수 있습니다. 이는 메시지 처리 응용 프로그램뿐만 아니라 일괄 처리를 포함하는 스트림 처리의 일반화 된 개념입니다.

마찬가지로 스트리밍 데이터 파이프 라인의 경우 실시간 이벤트 구독 기능과의 결합은 매우 짧은 지연 시간의 파이프 라인을 위해 Kafka를 사용할 수 있게합니다. 데이터를 안정적으로 저장하는 기능은 데이터 전달을 보장해야하는 중요한 데이터 또는 주기적으로 데이터를로드하는 오프라인 시스템과의 통합을 위해 사용하거나 유지 관리를 위해 오랜 기간 동안 중단 될 수 있습니다. 스트림 처리 설비는 도착하는대로 데이터를 변환 할 수있게합니다.

Kafka가 제공하는 보증, API 및 기능에 대한 자세한 내용은 나머지 설명서를 참조하십시오 .

c.f) 일부 오역이 있을 수 있습니다. 구글번역기의 도움을 받았습니다.