Kafka를 사용한 데이터 모델링? 주제와 파티션

비 RDBMS 데이터 저장소 또는 메시지 대기열과 같은 새 서비스를 사용할 때 가장 먼저 생각하는 것 중 하나는 "데이터를 어떻게 구성해야합니까?"입니다.

소개 자료를 읽고 봤습니다. 특히 Kafka : 로그 처리를위한 분산 메시징 시스템을 예로 들어 보겠습니다 .

• "주제는 메시지와 관련된 컨테이너입니다"
• "가장 작은 병렬 처리 단위는 주제의 파티션입니다. 이는 주제의 특정 파티션에 속하는 모든 메시지가 소비자 그룹의 소비자가 사용함을 의미합니다."

이것을 알면 주제와 파티션을 사용하는 방법을 보여주는 좋은 예는 무엇입니까? 언제 주제가되어야합니까? 언제 파티션이되어야합니까?

예를 들어, (Clojure) 데이터가 다음과 같다고 가정 해 봅시다.

{:user-id 101 :viewed "/page1.html" :at #inst "2013-04-12T23:20:50.22Z"}
{:user-id 102 :viewed "/page2.html" :at #inst "2013-04-12T23:20:55.50Z"}

토픽에 근거해야합니까 user-id? viewed? at? 파티션은 어떻습니까?

어떻게 결정합니까?

Kafka에 대한 데이터를 구성 할 때 실제로 소비되는 방식에 따라 다릅니다.

내 생각에 주제는 동일한 유형의 소비자가 사용하는 유사한 유형의 메시지 그룹입니다. 위의 예에서는 단일 주제 만 있고 다른 종류의 Kafka를 통해 데이터에 대해 나중에 새 주제를 추가 할 수 있습니다.

주제는 ZooKeeper에 등록되어 있습니다. 즉, 사용자가 백만 명이고 사용자 당 주제를 작성하기로 결정한 경우 등 너무 많은 항목을 추가하려고하면 문제가 발생할 수 있습니다.

반면에 파티션은 메시지 소비를 병렬화하는 방법이며 브로커 클러스터의 총 파티션 수는 분할 기능을 이해하기 위해 소비자 그룹의 소비자 수와 최소한 같아야합니다. 소비자 그룹의 소비자는 파티션에 따라 주제를 처리해야하는 부담을 분할에 따라 분할하여 한 소비자가 파티션 자체의 메시지 만 "할당"하도록 할 수 있습니다.

생산자 측의 파티션 키를 사용하여 파티셔닝을 명시 적으로 설정하거나 제공하지 않으면 모든 메시지에 대해 임의의 파티션이 선택됩니다.

이벤트 스트림을 분할하는 방법을 알고 나면 주제 이름이 쉬워 지므로 먼저 해당 질문에 대답하겠습니다.

@Ludd는 정확합니다. 선택한 파티션 구조는 주로 이벤트 스트림 처리 방법에 따라 다릅니다. 이상적으로는 이벤트 처리가 partition-local 인 파티션 키를 원합니다 .

예를 들면 다음과 같습니다.

1. 사용자의 평균 현장 방문 시간에 관심이 있다면로 분할해야합니다 :user-id. 이렇게하면 단일 사용자의 사이트 활동과 관련된 모든 이벤트를 동일한 파티션에서 사용할 수 있습니다. 이는 Apache Samza 와 같은 스트림 처리 엔진 이 단일 파티션의 이벤트를보고 특정 사용자에 대한 평균 현장 방문 시간을 계산할 수 있음을 의미 합니다. 따라서 비용이 많이 드는 파티션 전역 처리 를 수행하지 않아도됩니다.
2. 웹 사이트에서 가장 인기있는 페이지에 관심이 있다면 페이지별로 분할해야합니다 :viewed. 다시 한 번 Samza는 단일 파티션의 이벤트를보고 특정 페이지의 조회수를 유지할 수 있습니다.

일반적으로 DynamoDB 또는 Cassandra와 같은 원격 데이터베이스에 카운트를 유지하는 등 전역 상태에 의존하지 않고 파티션 로컬 상태를 사용하여 작업 할 수 있습니다. 이는 로컬 상태가 스트림 처리의 기본 요소 이기 때문 입니다.

위의 사용 사례가 모두 필요한 경우 Kafka의 일반적인 패턴은 먼저 by 로 파티션을 나누고 다음 단계의 처리를 위해 준비 :user-id하여 다시 파티션 하는 것 :viewed입니다.

주제 이름에서-여기에 분명한 것은 events또는 user-events입니다. 좀 더 구체적으로 말하면 events-by-user-id및 / 또는와 함께 갈 수 events-by-viewed있습니다.

이것은 질문과 정확히 관련이 없지만 주제를 기반으로 레코드의 논리적 분리를 이미 결정하고 Kafka의 주제 / 파티션 수를 최적화하려는 경우이 블로그가 유용 할 수 있습니다.

간단히 말해서 주요 내용 :

• 일반적으로 Kafka 클러스터에 파티션이 많을수록 처리량이 더 높아집니다. 생산을 위해 단일 파티션에서 달성 가능한 최대 값은 p 이고 소비량은 c 입니다. 목표 처리량이 t 라고 가정 해 봅시다 . 그런 다음 최소한 max ( t / p , t / c ) 파티션 이 있어야 합니다.

• 현재 Kafka에서 각 브로커는 모든 로그 세그먼트의 인덱스와 데이터 파일 모두의 파일 핸들을 엽니 다. 따라서 파티션이 많을수록 기본 운영 체제에서 열린 파일 핸들 제한을 구성해야 할 필요성이 높아집니다. 예를 들어 프로덕션 시스템에서 too many files are open약 3600 개의 주제 파티션이있는 동안 오류가 발생했습니다 .

• 브로커가 부정하게 종료되면 (예 : kill -9) 관찰 할 수없는 가용성은 파티션 수에 비례 할 수 있습니다.

• Kafka의 종단 간 대기 시간은 생산자가 메시지를 게시 한 시점부터 소비자가 메시지를 읽을 때까지의 시간으로 정의됩니다. 일반적으로 대기 시간에 관심이 있다면 브로커 당 파티션 수를 100 x b x r 로 제한하는 것이 좋습니다 . 여기서 b 는 Kafka 클러스터의 브로커 수이고 r 은 복제 요소입니다.

주제 이름은 일종의 메시지의 결론이라고 생각하며 생산자는 주제를 구독하고 소비자는 구독 주제를 통해 메시지를 구독합니다.

주제에는 많은 파티션이있을 수 있습니다. 파티션은 병렬 처리에 좋습니다. partition은 복제 단위이기도하므로 Kafka에서는 리더 및 추종자도 파티션 수준에서 말합니다. 실제로 파티션은 메시지가 도착한 순서 인 주문 된 대기열입니다. 그리고 주제는 간단한 단어로 하나 이상의 대기열로 구성됩니다. 이는 구조를 모델링하는 데 유용합니다.

Kafka는 LinkedIn에서 로그 집계 및 전달을 위해 개발했습니다. 이 장면은 예를 들어 매우 좋습니다.

웹 서버에서 웹 또는 앱의 사용자 이벤트를 기록한 다음 생산자를 통해 Kafka 브로커로 보낼 수 있습니다. 생산자에서는 예를 들어 이벤트 유형 (다른 이벤트가 다른 파티션에 저장 됨) 또는 이벤트 시간 (앱 논리에 따라 하루를 다른 기간으로 분할) 또는 사용자 유형 또는 논리가없고 모든 로그의 균형을 조정하는 등의 파티션 방법을 지정할 수 있습니다 많은 파티션으로.

해당 사례에 대해 "page-view-event"라는 주제를 하나 만들고 해시 키를 통해 N 개의 파티션을 만들어 로그를 모든 파티션에 고르게 분배 할 수 있습니다. 또는 파티션 논리를 선택하여 로그를 자신의 정신으로 배포 할 수 있습니다.