작성
·
166
·
수정됨
답변 1
0
안녕하십니까,
질문을 잘 이해하지 못했습니다.
Source connector 를 말씀하시는 건가요? Sink Connector를 말씀하시는 건가요?(Sink 같습니다만 ^^)
그리고
value에 pk 값이 이미 있고, config를 통해 pk 필드가 무엇인지 까지 지정해줬는데 value를 통해 값을 획득하지 않고 record key에 다시 추출해야하는 이유가 뭘지 궁금합니다!
=> record key에서 다시 추출한다는 의미가 뭔지요? 해당 질문을 좀 더 자세하게 부탁드립니다.
감사합니다.
sink connector 입장에서 topic의 value(payload)만으로도 조회하여 key 값을 획득할 수 있을 것 같은데 왜 source에서 토픽에 보낼 때 topic key에 pk 값을 올려야 하는 지가 궁금하다는 질문이었습니다.
=> Sink Connector는 Source Connector의 환경을 볼 수가 없습니다. 서로 분리되어 관리 됩니다. 그리고 source에서 토픽에 보낼 때 사용되는 topic key는 pk값을 사용하지 않아도 됩니다. 하지만 카프카 토픽의 key로 pk를 사용하면 효과적으로 hashing이 되므로 유용합니다. 또한 sink connector의 pk.mode를 record_key로 설정하면 sink 입력할 때도 명확하게 적용될 수 있어서 좋습니다. 일반적으로 테이블의 pk를 카프카 토픽의 key로 사용합니다.
그리고 pk.fields는 명확성을 위해서 있다고 보시면 될 것 같습니다. 함축적으로 record_key 값이 pk 값으로 설정되는 것 보다 pk.fields로 명확하게 표현하는 게 설정상 맞다고 생각합니다.
네 안녕하세요,
source connector에서 SMT를 통해 pk 값을 topic key로 올렸는데요,
sink connector 입장에서 topic의 value(payload)만으로도 조회하여 key 값을 획득할 수 있을 것 같은데 왜 source에서 토픽에 보낼 때 topic key에 pk 값을 올려야 하는 지가 궁금하다는 질문이었습니다.
sink connector config에도 pk 칼럼이 무엇인지 명시가 되어있으니 value에서 조회하면 되는 것이 아닌지 왜 SMT를 적용하여 key로 올려주는 전처리를 해줘야하는지가 궁금합니다.