ksql - 아파치 카프카 용어 - 수정

아파치 카프카 입문서

ksqlDB는 Apache Kafka®에서 스트림 처리를 위해 특별히 구축된 데이터베이스입니다. 이 섹션에서는 ksqlDB를 효과적으로 사용하기 위해 필요한 최소한의 Kafka 개념에 대해 설명합니다. 자세한 내용은 공식 Apache Kafka 설명서 를 참조하십시오 .

Record

Kafka에서 데이터의 기본 단위는 이벤트입니다. 이벤트는 특정 시점에 세계에서 일어난 일을 모델링합니다. Kafka에서는 레코드라고 하는 데이터 구성을 사용하여 각 이벤트를 나타냅니다. 레코드에는 키, 값, 타임스탬프, 주제, 파티션, 오프셋 및 헤더와 같은 몇 가지 다른 종류의 데이터가 들어 있습니다.

레코드의 키는 이벤트의 ID를 나타내는 임의의 데이터입니다. 이벤트가 웹 페이지의 클릭인 경우 키는 클릭을 수행한 사용자의 ID일 수 있습니다.

값은 기본 데이터를 나타내는 데이터의 부분입니다. 클릭 이벤트의 값에는 이벤트가 발생한 페이지, 클릭된 DOM 요소 및 기타 정보가 포함될 수 있습니다.

타임 스탬프는 이벤트가 일어 났을 때입니다. 추적할 수 있는 몇 가지 다른 "종류" 시간이 있습니다. 

주제 와 파티션이 특정 이벤트에 속하고 큰 수집 및 이벤트의 하위 집합을 설명 오프셋 (아래 그에 더) 그 큰 컬렉션을 내 정확한 위치를 설명합니다.

마지막으로 헤더는 레코드에 대한 임의의 사용자 제공 메타데이터를 전달합니다.

ksqlDB는 이러한 정보 중 일부를 추상화하므로 이에 대해 생각할 필요가 없습니다. 다른 것들은 직접 노출되며 프로그래밍 모델의 필수적인 부분입니다. 예를 들어 ksqlDB에서 데이터의 기본 단위는 행 입니다. 행은 Kafka 레코드에 대한 유용한 추상화입니다. 행에는 키 열과 값 열의 두 가지 열이 있습니다. 그들은 또한 timestamp.

일반적으로 ksqlDB는 상위 수준 프로그래밍 모델에 기여하지 않는 Kafka 수준 구현 세부 정보를 올리는 것을 피합니다.

주제¶

주제는 명명된 레코드 모음입니다. 그들의 목적은 상호 관심사의 이벤트를 함께 개최할 수 있도록 하는 것입니다. 일련의 클릭 기록은 "클릭" 주제에 저장되어 한 곳에서 모두 액세스할 수 있습니다. 주제는 추가 전용입니다. 주제에 레코드를 추가하면 개별적으로 변경하거나 삭제할 수 없습니다.

어떤 종류의 레코드를 주제에 넣을 수 있는지에 대한 규칙은 없습니다. 그들은 같은 구조를 따를 필요가 없고, 같은 상황과 관련되거나 이와 유사한 것이 필요하지 않습니다. 주제에 대한 게시를 관리하는 방법은 전적으로 사용자 규칙 및 시행의 문제입니다.

ksqlDB는 스트림 과 테이블을 통해 주제에 대해 더 높은 수준의 추상화를 제공합니다 . 스트림 또는 테이블은 스키마를 Kafka 주제와 연결합니다. 스키마는 주제에 저장할 수 있는 레코드의 모양을 제어합니다. 이러한 종류의 정적 입력은 주제에 어떤 종류의 행이 있는지 이해하기 쉽게 하고 일반적으로 이를 처리하는 프로그램에서 실수를 줄이는 데 도움이 됩니다.

파티션¶

레코드가 주제에 배치되면 특정 파티션에 배치됩니다. 파티션은 오프셋별로 완전히 정렬된 레코드 시퀀스입니다. 주제에는 스토리지 및 처리의 확장성을 높이기 위해 여러 파티션이 있을 수 있습니다. 주제를 생성할 때 얼마나 많은 파티션이 있는지 선택합니다.

주제에 레코드를 추가할 때 파티션 전략은 레코드가 저장될 파티션을 선택합니다. 많은 파티션 전략이 있습니다. 가장 일반적인 방법은 전체 파티션 수에 대해 레코드 키의 내용을 해시하는 것입니다. 이는 동일한 ID를 가진 모든 레코드를 동일한 파티션에 배치하는 효과가 있으며, 이는 강력한 순서 보장 때문에 유용합니다.

레코드의 순서는 레코드가 추가될 때 설정되는 오프셋이라는 데이터에 의해 추적됩니다. 오프셋이 10인 레코드는 오프셋이 20인 동일한 파티션의 레코드보다 먼저 발생했습니다 .

여기에서 대부분의 역학은 사용자를 대신하여 ksqlDB에서 자동으로 처리됩니다. 스트림 또는 테이블을 생성할 때 확장성을 제어할 수 있도록 기본 주제에 대한 파티션 수를 선택합니다. 스키마를 선언할 때 키의 일부인 열과 값의 일부인 열을 선택합니다. 이 외에도 개별 파티션이나 오프셋에 대해 생각할 필요가 없습니다. 여기에 몇 가지 예가 있습니다.

레코드가 처리되면 키 내용이 해시되어 새 다운스트림 파티션이 동일한 키를 가진 다른 모든 레코드와 일치하게 됩니다. 레코드가 추가되면 오류나 오류가 있는 경우에도 올바른 오프셋 순서를 따릅니다. 쿼리가 행을 처리하려는 방식으로 인해 스트림의 키 콘텐츠가 변경되면( GROUP BY또는 를 통해 PARTITION BY) 기본 레코드 키가 다시 계산되고 레코드가 계산을 수행하기 위해 설정된 새 주제의 새 파티션으로 전송됩니다.

생산자와 소비자¶

생산자와 소비자는 주제로 또는 주제에서 레코드의 이동을 용이하게 합니다. 애플리케이션이 레코드를 게시하거나 구독하려고 할 때 API(일반적으로 클라이언트 라고 함 )를 호출하여 그렇게 합니다. 클라이언트는 구조화된 네트워크 프로토콜을 통해 브로커(아래 참조)와 통신합니다.

소비자는 주제에서 레코드를 읽을 때 절대 삭제하거나 변경하지 않습니다. 동일한 정보를 반복적으로 읽을 수 있는 이 패턴은 충돌하지 않는 방식으로 동일한 데이터 세트에 대해 여러 애플리케이션을 구축하는 데 도움이 됩니다. 또한 애플리케이션이 이벤트 스트림을 되감고 이전 정보를 다시 읽을 수 있는 "재생"을 지원하기 위한 기본 빌딩 블록입니다.

생산자와 소비자는 상당히 낮은 수준의 API를 노출합니다. 고유한 레코드를 구성하고, 스키마를 관리하고, 직렬화를 구성하고, 어디로 보내는지 처리해야 합니다.

ksqlDB는 상위 수준의 지속적인 생산자 및 소비자 역할을 합니다. 레코드의 모양을 선언한 다음 데이터를 채우고, 변경하고, 쿼리하는 방법을 설명하는 고급 SQL 명령을 실행하기만 하면 됩니다. 이러한 SQL 프로그램은 세부사항을 처리하는 저수준 클라이언트 API 호출로 변환됩니다.

브로커¶

브로커는 주제에 대한 액세스를 저장하고 관리하는 서버입니다. 여러 브로커가 함께 클러스터링되어 고가용성 내결함성 방식으로 주제를 복제할 수 있습니다. 클라이언트는 브로커와 통신하여 레코드를 읽고 씁니다.

ksqlDB 서버 또는 클러스터를 실행할 때 각 노드는 Kafka 브로커와 통신하여 처리를 수행합니다. Kafka 브로커의 관점에서 각 ksqlDB 서버는 클라이언트와 같습니다. 브로커에서 처리가 수행되지 않습니다. ksqlDB의 서버는 자체 노드에서 모든 계산을 수행합니다.

직렬 변환기¶

모든 문제에 완벽하게 맞는 데이터 형식은 없기 때문에 Kafka는 레코드의 키 및 값 부분에 있는 데이터 내용에 대해 불가지론적으로 설계되었습니다. 레코드가 클라이언트에서 브로커로 이동할 때 사용자 페이로드(키 및 값)는 바이트 배열로 변환되어야 합니다. 이를 통해 Kafka는 불투명한 일련의 바이트가 무엇인지 알 필요 없이 작업할 수 있습니다. 레코드가 소비자에게 전달될 때 해당 바이트 배열은 응용 프로그램에 의미 있는 원래 주제로 다시 변환되어야 합니다. 바이트 표현으로 변환하거나 변환하는 프로세스를 각각 직렬화 및 역직렬화 라고 합니다.

생산자가 주제에 레코드를 보낼 때 키와 값을 바이트 배열로 변환하는 데 사용할 직렬 변환기를 결정해야 합니다. 키 및 값 직렬 변환기는 독립적으로 선택됩니다. 소비자가 레코드를 받으면 바이트 배열을 원래 값으로 다시 변환하는 데 사용할 역직렬 변환기를 결정해야 합니다. 직렬 변환기와 역직렬 변환기는 쌍으로 제공됩니다. 다른 디시리얼라이저를 사용하면 바이트 내용을 이해할 수 없습니다.

ksqlDB는 직렬화의 추상화를 상당히 높입니다. 직렬 변환기를 수동으로 구성하는 대신 스트림/테이블 생성 시 구성 옵션을 사용하여 형식을 선언합니다. 어떤 주제가 어떤 방식으로 직렬화되었는지 추적하는 대신 ksqlDB는 각 스트림 및 테이블의 바이트 표현에 대한 메타데이터를 유지 관리합니다. 소비자는 올바른 deserializer를 사용하도록 자동으로 구성됩니다.

스키마¶

Kafka로 직렬화된 레코드는 불투명 바이트이지만 레코드를 처리할 수 있도록 하려면 구조에 대한 몇 가지 규칙이 있어야 합니다. 이 구조의 한 측면은 데이터의 모양과 필드를 정의하는 데이터 스키마입니다. 정수인가요? foo, bar, 및 키가 있는 맵 baz입니까? 다른 것?

시행 메커니즘이 없으면 스키마가 암시적입니다. 소비자는 어떻게든 생산된 데이터의 형태를 알아야 합니다. 종종 이것은 한 그룹의 사람들이 스키마에 구두로 동의하도록 함으로써 발생합니다. 그러나 이 접근 방식은 오류가 발생하기 쉽습니다. 스키마를 중앙에서 관리하고 감사하며 프로그래밍 방식으로 시행할 수 있는 경우가 더 좋습니다.

Kafka 외부 프로젝트인 Confluent Schema Registry 는 스키마 관리를 돕습니다. 스키마 레지스트리를 사용하면 생산자가 주제를 스키마에 등록할 수 있으므로 추가 데이터가 생성될 때 스키마를 준수하지 않으면 거부됩니다. 소비자는 스키마 레지스트리를 참조하여 모르는 주제에 대한 스키마를 찾을 수 있습니다.

생산자, 소비자 및 스키마 구성을 하나로 묶는 대신 ksqlDB는 스키마 레지스트리와 투명하게 통합됩니다. 두 시스템이 서로 통신할 수 있도록 구성 옵션을 활성화하여 ksqlDB는 모든 스트림 및 테이블 스키마를 스키마 레지스트리에 저장합니다. 그런 다음 이러한 스키마를 다운로드하여 ksqlDB 데이터로 작업하는 모든 애플리케이션에서 사용할 수 있습니다. 또한 ksqlDB는 기존 주제의 스키마를 자동으로 유추할 수 있으므로 스트림이나 테이블을 정의할 때 구조를 선언할 필요가 없습니다.

소비자 그룹¶

소비자 프로그램이 부팅되면 여러 소비자가 들어갈 수 있는 소비자 그룹에 등록됩니다 . 레코드를 사용할 수 있을 때마다 그룹의 정확히 한 소비자가 레코드를 읽습니다. 이는 일련의 프로세스가 레코드 소비를 조정하고 로드 밸런싱할 수 있는 방법을 효과적으로 제공합니다.

단일 주제의 레코드는 그룹의 한 프로세스에서 사용하도록 되어 있으므로 구독의 각 파티션은 한 번에 한 소비자만 읽습니다. 각 소비자가 담당하는 파티션 수는 총 소스 파티션 수를 소비자 수로 나눈 값으로 정의됩니다. 소비자가 그룹에 동적으로 가입하면 소유권이 다시 계산되고 파티션이 다시 할당됩니다. 소비자가 그룹을 떠나면 동일한 계산이 수행됩니다.

ksqlDB는 이 강력한 로드 밸런싱 프리미티브를 기반으로 합니다. ksqlDB 서버 클러스터에 퍼시스턴트 쿼리를 배포하면 소스 파티션 수에 따라 클러스터 전체에 워크로드가 분산된다. 이 모든 것이 자동으로 수행되기 때문에 그룹 구성원 자격을 명시적으로 관리할 필요가 없습니다.

예를 들어 소스 파티션이 10개인 영구 쿼리를 노드가 2개인 ksqlDB 클러스터에 배포하는 경우 각 노드는 5개의 파티션을 처리합니다. 서버를 잃어버리면 남은 유일한 서버가 자동으로 재조정되어 10개를 모두 처리합니다. 이제 4개의 서버를 더 추가하면 각각이 2개의 파티션을 처리하도록 재조정됩니다.

보유 및 압축¶

일정 기간 후에 오래된 레코드를 정리하는 것이 종종 바람직합니다. 보존과 압축은 이를 위한 두 가지 다른 옵션입니다. 둘 다 선택 사항이며 함께 사용할 수 있습니다.

보존은 레코드가 삭제되기 전에 저장되는 기간을 정의합니다. 보존은 주제의 레코드를 삭제하는 유일한 방법 중 하나입니다. 이 매개변수는 이벤트 스트림을 재생할 수 있는 시간 범위를 정의하기 때문에 스트림 처리에서 특히 중요합니다. 재생은 버그를 수정하거나, 새 애플리케이션을 빌드하거나, 일부 기존 논리를 백테스트하는 경우에 유용합니다.

ksqlDB를 사용하면 기본 스트림 및 테이블의 기본 주제 보존을 직접 제어할 수 있으므로 개념을 이해하는 것이 중요합니다. 자세한 내용 은 Kafka 문서의 주제 및 로그를 참조하십시오 .

대조적으로 압축은 키당 최신 레코드를 제외한 모든 레코드를 주기적으로 삭제하는 각 Kafka 브로커의 백그라운드에서 실행되는 프로세스입니다. 이는 선택적인 옵트인 프로세스입니다. 압축은 레코드가 상태 부분에 대한 일종의 업데이트를 나타내고 최신 업데이트가 결국 중요한 유일한 업데이트일 때 특히 유용합니다.

ksqlDB는 구체화된 테이블을 지원하는 기본 변경 로그를 지원하기 위해 압축을 직접 활용합니다. 이를 통해 ksqlDB는 장애 조치 시 테이블을 재구축하는 데 필요한 최소한의 정보를 저장할 수 있습니다. 자세한 내용 은 Kafka 문서의 로그 압축을 참조하세요 .