KAFKA/version / / 2023. 1. 6. 13:20

[Version] Apache Kafka 3.3

반응형
confluent의 Apache Kafka 3.3(구글 번역기)

https://www.confluent.io/ko-kr/blog/apache-kafka-3-3-0-new-features-and-updates/

 

What’s New in Apache Kafka 3.3 - New Features, Updates, and More | KR

Apache Kafka 3.3 includes KRaft mode, improves partition scalability and resiliency while simplifying Kafka deployment, as well as updates to Kafka Streams, Connect, and more.

www.confluent.io

 

Kafka Broker, Controller, Producer, Consumer and Admin Client

KIP-833: Mark KRaft as Production Ready

KIP-833 marks KRaft as production-ready for new clusters in the Apache Kafka 3.3 release. KIP-833 also marks 3.5.0 as the bridge release. The bridge release is the release that would allow the migration of Apache Kafka clusters from ZK mode to KRaft mode.

 

KIP-833: KRaft를 생산 준비 완료로 표시

KIP-833 KRaft Apache Kafka 3.3 릴리스의 클러스터에 대해 프로덕션 준비가 것으로 표시합니다. KIP-833 또한 브리지 릴리스로 3.5.0 표시합니다. 브리지 릴리스는 Apache Kafka 클러스터를 ZK 모드에서 KRaft 모드로 마이그레이션할 있는 릴리스입니다.


KIP-778: KRaft to KRaft upgrades

KIP-778 allows the upgrade of KRaft clusters without the need for the infamous “double roll”. In order to facilitate upgrades of Apache Kafka in KRaft mode, we need the ability to upgrade controllers and brokers while holding back the use of new RPCs and record formats until the whole cluster has been upgraded.

 

KIP-778: KRaft에서 KRaft로 업그레이드

KIP-778 사용하면 악명 높은 "이중 " 없이도 KRaft 클러스터를 업그레이드할 있습니다. KRaft 모드에서 Apache Kafka 업그레이드를 용이하게 하려면 전체 클러스터가 업그레이드될 때까지 새로운 RPC 레코드 형식의 사용을 보류하면서 컨트롤러와 브로커를 업그레이드할 있는 기능이 필요합니다.


KIP-841: Fenced replicas should not be allowed to join the ISR in KRaft

KIP-841 improves the topic partitions’ availability during clean shutdown. It does this by enforcing the following invariants: 1) a fenced or in-controlled-shutdown replica is not eligible to be in the ISR; and 2) a fenced or in-controlled-shutdown replica is not eligible to become leader.

 

KIP-841: Fenced 복제본은 KRaft에서 ISR에 가입할 수 없습니다.

KIP-841 완전히 종료하는 동안 토픽 파티션의 가용성을 향상시킵니다. 다음과 같은 불변성을 적용하여 이를 수행합니다. 1) 차단되거나 제어되는 종료 복제본은 ISR 있을 없습니다. 2) 차단되거나 제어되는 종료 복제본은 리더가 없습니다.


KIP-836: Expose replication information of the cluster metadata

KIP-836 exposes the DescribeQuorum API to the Admin client and adds two new fields per replica to the response. This information can be used to query the availability and lag of the cluster metadata for the controllers and brokers in a KRaft cluster.

 

KIP-836: 클러스터 메타데이터의 복제 정보 노출

KIP-836 DescribeQuorum API Admin 클라이언트에 노출하고 복제본당 개의 필드를 응답에 추가합니다. 정보는 KRaft 클러스터의 컨트롤러 브로커에 대한 클러스터 메타데이터의 가용성 지연을 쿼리하는 사용할 있습니다.


KIP-835: Monitor KRaft Controller Quorum health

With KRaft mode, Apache Kafka added a new controller quorum to the cluster. These controllers need to be able to commit records for Apache Kafka to be available. KIP-835 measures availability by periodically causing the high-watermark and the last committed offset to increase. Monitoring services can compare that these last committed offsets are advancing. They can also use these metrics to check that all of the brokers and controllers are relatively within each other’s offset.

 

KIP-835: KRaft 컨트롤러 쿼럼 상태 모니터링

KRaft 모드에서 Apache Kafka 클러스터에 새로운 컨트롤러 쿼럼을 추가했습니다. 이러한 컨트롤러는 Apache Kafka 사용할 있도록 레코드를 커밋할 있어야 합니다. KIP-835 주기적으로 하이 워터마크와 마지막 커밋된 오프셋을 증가시켜 가용성을 측정합니다. 모니터링 서비스는 이러한 마지막 커밋된 오프셋이 진행되고 있는지 비교할 있습니다. 또한 이러한 메트릭을 사용하여 모든 브로커와 컨트롤러가 상대적으로 서로의 오프셋 내에 있는지 확인할 있습니다.


KIP-859: Add metadata log processing error related metrics

With KRaft mode, the cluster metadata replicated log is the source of metadata related information for all servers in the cluster. Any errors that occur while processing this log could lead to the in-memory state for the server becoming inconsistent. It is important that such errors are made visible. KIP-859 exposes metrics that can be monitored so that affected servers can be discovered.

 

KIP-859: 메타데이터 로그 처리 오류 관련 지표 추가

KRaft 모드에서 클러스터 메타데이터 복제 로그는 클러스터의 모든 서버에 대한 메타데이터 관련 정보의 소스입니다. 로그를 처리하는 동안 오류가 발생하면 서버의 메모리 상태가 일관성이 없게 있습니다. 이러한 오류를 표시하는 것이 중요합니다. KIP-859 영향을 받는 서버를 검색할 있도록 모니터링할 있는 메트릭을 노출합니다.


KIP-794: Strictly Uniform Sticky Partitioner

KIP-794 improves the default partitioner to distribute non-keyed data evenly in batches among healthy brokers and less data to unhealthy brokers. For example, the p99 latency for a producer workload with abnormal behavior was reduced from 11s to 154ms.

 

KIP-794: 엄격하게 균일한 점착 파티셔너

KIP-794 기본 파티셔너를 개선하여 키가 지정되지 않은 데이터를 건전한 브로커 간에 일괄적으로 균등하게 배포하고 비정상 브로커에 대한 데이터를 줄입니다. 예를 들어 비정상적인 동작이 있는 생산자 워크로드의 p99 대기 시간이 11초에서 154ms 감소했습니다.


KIP-373: Allow users to create delegation tokens for other users

KIP-373 allows users to create delegation tokens for other users. This allows the following use cases: 1) a designated superuser can create tokens without requiring individual user credentials; and 2) a designated superuser can run kafka clients on behalf of another user.

 

KIP-373: 사용자가 다른 사용자를 위한 위임 토큰을 생성하도록 허용

KIP-373 사용하면 사용자가 다른 사용자를 위한 위임 토큰을 만들 있습니다. 이를 통해 다음과 같은 사용 사례가 가능합니다. 1) 지정된 수퍼유저가 개별 사용자 자격 증명 없이 토큰을 생성할 있습니다. 2) 지정된 수퍼유저는 다른 사용자를 대신하여 kafka 클라이언트를 실행할 있습니다.


KIP-831: Add metric for log recovery progress

Log recovery is a process triggered when a Kafka server starts up, if it had a previous unclean shutdown. It is used to make sure the log is in a good state and is not corrupted. KIP-831 exposes metrics to allow users to monitor the progress of log recovery.

 

KIP-831: 로그 복구 진행률에 대한 지표 추가

로그 복구는 Kafka 서버가 이전에 비정상적으로 종료된 경우 시작할 트리거되는 프로세스입니다. 로그가 양호한 상태이고 손상되지 않았는지 확인하는 사용됩니다. KIP-831 사용자가 로그 복구 진행 상황을 모니터링할 있도록 메트릭을 노출합니다.


KIP-709: Extend OffsetFetch RPC to accept multiple group ids

KIP-709 streamlines the process of fetching offsets from consumer groups so that a single request can be made to fetch offsets for multiple groups. This carries the following advantages: 1) it reduces request overhead; and 2) it simplifies client side code.

 

KIP-709: 여러 그룹 ID를 허용하도록 OffsetFetch RPC 확장

KIP-709 단일 요청으로 여러 그룹의 오프셋을 가져올 있도록 소비자 그룹에서 오프셋을 가져오는 프로세스를 간소화합니다. 이는 다음과 같은 이점이 있습니다. 1) 요청 오버헤드를 줄입니다. 2) 클라이언트 코드를 단순화합니다.


KIP-827: Expose log dirs total and usable space via Kafka API

KIP-827 exposes an RPC for querying the disk total size and disk usage size per log directory. This is useful for tools that are interested in querying this information without relying on the exposed metrics.

 

KIP-827: Kafka API를 통해 총 로그 디렉터리 및 사용 가능한 공간 노출

KIP-827 로그 디렉터리당 디스크 크기 디스크 사용량 크기를 쿼리하기 위해 RPC 노출합니다. 이는 노출된 메트릭에 의존하지 않고 정보를 쿼리하는 관심이 있는 도구에 유용합니다.


KIP-851: Add requireStable flag into ListConsumerGroupOffsetsOptions

KIP-851 adds the option in the Admin client for querying the committed offsets when using exactly once semantics.

 

KIP-851: ListConsumerGroupOffsetsOptions에 requireStable 플래그 추가

KIP-851 정확히 의미 체계를 사용할 커밋된 오프셋을 쿼리하기 위해 관리 클라이언트에 옵션을 추가합니다.


KIP-843: Adding addMetricIfAbsent method to Metrics

KIP-843 allows the metrics API to atomically query a metric if present or create a metric if absent.

 

KIP-843: 메트릭에 addMetricIfAbsent 메서드 추가

KIP-843 사용하면 메트릭 API 메트릭이 있는 경우 원자적으로 쿼리하거나 없는 경우 메트릭을 생성할 있습니다.


KIP-824: Allowing dumping segment logs limiting the batches in the output

KIP-824 allows the kafka-dump-logs tool to be configured to only scan and print the records at the start of the log segment instead of the entire log segment.

 

KIP-824: 출력의 배치를 제한하는 세그먼트 로그 덤핑 허용

KIP-824 사용하면 kafka-dump-logs 도구가 전체 로그 세그먼트 대신 로그 세그먼트 시작 부분의 레코드만 스캔하고 인쇄하도록 구성할 있습니다.


Kafka Streams

KIP-846: Source/sink node metrics for consumed/produced throughput in Streams

With the metrics available today in the plain consumer it is possible for users of Kafka Streams to derive the consumed throughput of their applications at the subtopology level, but the same is not true for the produced throughput.

KIP-846 fills in this gap and gives end users a way to compute the production rate of each subtopology by introducing two new metrics for the throughput at sink nodes. Even though it is possible to derive the consumed throughput with existing client level metrics, KIP-846 also adds two new metrics for the throughput at source nodes to provide an equally fine-grained metrics scope as for the newly added metrics at the sink nodes and to simplify the user experience.

 

KIP-846: Streams에서 사용/생산 처리량에 대한 소스/싱크 노드 지표

현재 일반 소비자에서 사용할 수 있는 메트릭을 통해 Kafka Streams 사용자는 하위 토폴로지 수준에서 애플리케이션의 소비된 처리량을 도출할 수 있지만 생산된 처리량에 대해서는 그렇지 않습니다.

KIP-846 이러한 격차를 메우고 최종 사용자에게 싱크 노드의 처리량에 대한 가지 새로운 메트릭을 도입하여 하위 토폴로지의 생산 속도를 계산하는 방법을 제공합니다. 기존 클라이언트 수준 메트릭으로 소비된 처리량을 도출할 있지만 KIP-846 소스 노드의 처리량에 대한 가지 새로운 메트릭을 추가하여 싱크 노드에서 새로 추가된 메트릭과 동일하게 세분화된 메트릭 범위를 제공합니다. 사용자 경험을 단순화합니다.


KIP-834: Pause/resume KafkaStreams topologies

KIP-834 adds the ability to pause and resume topologies. This can be used to reduce resources used or modify data pipelines. Paused topologies skip processing, punctuation, and standby tasks. For distributed Streams applications, each instance will need to be paused and resumed separately.

 

KIP-834: KafkaStreams 토폴로지 일시 중지/재개

KIP-834 토폴로지를 일시 중지하고 다시 시작하는 기능을 추가합니다. 이는 사용되는 리소스를 줄이거나 데이터 파이프라인을 수정하는  사용할  있습니다. 일시 중지된 토폴로지는 처리, 구두점  대기 작업을 건너뜁니다. 분산 스트림 애플리케이션의 경우  인스턴스를 개별적으로 일시 중지하고 다시 시작해야 합니다.


KIP-820: Consolidate KStream transform() and process() methods

KIP-820 generalizes the KStream API to consolidate Transformers (which could forward results) and Processors (which could not). The change makes use of the new type-safe Processor API. This simplifies Kafka Streams, making it easier to use and learn.

 

KIP-820: KStream transform() 및 process() 메서드 통합

KIP-820 KStream API 일반화하여 트랜스포머(결과를 전달할 있음) 프로세서( 없음) 통합합니다. 변경 사항은 새로운 유형 안전 프로세서 API 사용합니다. 이는 Kafka Streams 단순화하여 사용 학습을 쉽게 만듭니다.


KIP-812: Introduce another form of the KafkaStreams.close() API that forces the member to leave the consumer group

KIP-812 can efficiently close the stream permanently by forcing the member to leave the consumer group.

 

KIP-812: 구성원이 소비자 그룹을 떠나도록 강제하는 KafkaStreams.close() API의 다른 형식을 도입합니다.

KIP-812 구성원이 소비자 그룹을 떠나도록 강제하여 스트림을 영구적으로 효율적으로 닫을 있습니다.


Kafka Connect

KIP-618: Exactly-once support for source connectors

KIP-618 adds exactly one semantic support to source connectors. The Connect framework was expanded to atomically write source records and their source offsets to Apache Kafka, and to prevent zombie tasks from producing data to Apache Kafka.

 

KIP-618: 소스 커넥터에 대한 정확히 한 번 지원

KIP-618 소스 커넥터에 정확히 하나의 시맨틱 지원을 추가합니다. Connect 프레임워크는 Apache Kafka 대한 소스 레코드 해당 소스 오프셋을 원자적으로 작성하고 좀비 작업이 Apache Kafka 데이터를 생성하는 것을 방지하도록 확장되었습니다.


Summary

See the release notes for 3.3.0 and 3.3.1 for the full list of changes

반응형

'KAFKA > version' 카테고리의 다른 글

[Version] Apache Kafka 3.5  (0) 2023.07.10
[Version] Apache Kafka 3.4  (0) 2023.07.10
  • 네이버 블로그 공유
  • 네이버 밴드 공유
  • 페이스북 공유
  • 카카오스토리 공유