Kafka Connect - 4장 효과적인 데이터 파이프라인 설계

데이터 변환

데이터 파이프라인을 통해 데이터가 흐를 때 두가지 패턴을 사용한다.

• ETL: 저장 공간이 제한된 시스템
• ELT: 오랫동안 데이터가 원본을 유지하여 다른 목적으로 재사용 용이

 

카프카 커넥트는 이동중에 데이터를 변환할 수 있는 트랜스포메이션이 있으며 이는 ETL에 적합하다.

아래는 민감한 개인정보를 숨김 처리하는 카프카커넥트 예시이다.

 

 

시스템간 데이터 맵핑

데이터파이프라인을 구축할 때 서로 시스템간의 데이터를 맵핑을 꼼꼼히 따져봐야하며

이를 위해 카프카커넥트 태스크와 카프카의 파티션 사이의 상호작용을 고려해야 한다.

 

단일 태스크와 단일 파티션은 순서를 보장한다.

 

중복을 방지하기 위해 각각의 데이터를 읽는 복수의 태스크

 

개별 소스 커넥터는 어느 파티션으로 보낼지 직접 선택하거나 이미 정의된 파티셔닝 전략을 따른다.

커넥터는 동일한 파티션으로 보내야하므로 키를 통해 식별한다.

소스 작업은 데이터를 하나 이상의 파티션으로 전송할 수 있다.

 

싱크 커넥터에서도 병렬로 실행된다.

싱크 작업이 파티션과 상호 작용하는 방식도 실행할 수 있는 싱크 작업의 수에 영향을 준다.

각 파티션은 특정 커넥터에 대해 하나의 싱크 작업에서만 읽을 수 있으므로,

싱크 커넥터로 데이터 파이프라인을 만들 때는 커넥터가 읽는 토픽의 파티션 수를 염두에 두어야 한다.

3개의 파티션에서 데이터를 읽는 두 개의 싱크 작업을 보여줍니다.

 

따라서  Kafka Connect 데이터 파이프라인을 설계할 때,

tasks.max 옵션 및 파티션 구성 옵션을 미리 설계하는 것이 좋다.

 

 

스키마

Kafka Connect 파이프라인은 스키마를 사용하여 Kafka에 저장된 데이터를 설명할 수 있다. ( 옵션 수정을 통해 )

{"schema":{"type":"string","optional":false},"payload":"This is a string"}
{"schema":{"type":"string","optional":false},"payload":"Another string"}
{"schema":{"type":"string","optional":false},"payload":"A third string"}
{"schema":{"type":"string","optional":false},"payload":"The final string"}

모든 레코드에 대해 스키마 정보를 전송하면 오버헤드가 커지므로, 스키마 레지스트리를 사용한다.

가장 일반적으로 사용되는 두 가지는 Confluent 스키마 레지스트리와 Apicurio 레지스트리이다.

 

 

내부 사용 토픽

분산 모드의 Kafka Connect는 토픽을 사용하여 상태를 저장한다.

커넥터를 시작할 때 토픽이 아직 없는 경우 자동으로 생성한다.

• 구성 : config.storage.topic
• 오프셋 : offset.storage.topic
• 상태 : status.storage.topic

config.storage.topic

사용자가 시작한 모든 커넥터 및 작업의 구성이 저장된다.

사용자가 커넥터의 구성을 업데이트하거나 커넥터가 재구성을 요청할 때마다 이 토픽에 레코드가 전송된다.

각 엔티티의 마지막 상태를 항상 유지하여 많은 저장 공간을 사용하지 않는다.

 

offset.storage.topic

소스 커넥터의 오프셋을 저장한다.

각 소스 커넥터 작업이 정기적으로 이 토픽을 사용하여 위치를 기록하기 때문에,

여러 개의 파티션으로 토픽이 구성된다.

 

status.storage.topic

커넥터 및 작업의 현재 상태를 에 저장한다.

REST API 사용자가 쿼리하는 데이터의 중심이 되는 곳이다.

이를 통해 사용자는 모든 워커를 쿼리하고 실행 중인 모든 플러그인의 상태를 확인할 수 있다.

또한 압축되어 있으며 여러 개의 파티션을 사용한다.

Kafka Connect