여기 이렇게 친절하고 훌륭한 스페셜리스트가 계셨는데, 그것도 모르고 지금까지 구글링하며, 영문 번역까지 해가며 눈알 뛰어나오게 삽질했었네요~ 진작 알았으면 좋았을 것을~ 한편으로 늦게 알아서 아쉽, 그래도 알게 돼서 다행~ 임다. 첨 뵙게된 기념으로 한 가지 여쭤 보았으면 합니다. 카프카 좀 안다고 하는 인간들이 종종 오프셋 관리 어쩌구저쩌구 하던데, 오프셋 관리는 어떻게 하는 것인가요? 컨슈머 쪽에서 예외 처리할 때 대응 방법인거 같긴 하던데,,, 어떨때 어떤 방법으로 대응하는지 가이드 좀 부탁드립니다.
문의 있습니다. Broker partition replication 장표(23page)에서 하단의 shell script를 사용하면 장표에 보이는 것처럼 브로커가 3개가 생성되는 건가요? 제가 보기에는 로컬 호스트 브로커 1대에 3개의 파티션이 생성되는 것 아닌가요? 이해가 잘 안되어서요...
@김명찬 님, 답변드리겠습니다. Broker partition replication 장표의 하단 shell script는 파티션 3개로 이루어진 토픽을 생성하는 명령어입니다. 만약 브로커가 3대인 카프카 클러스터에 명령어를 치면 각각의 개별 브로커에 파티션이 나누어 저장되는 것이죠. 이 장표는 브로커3대인 카프카 클러스터에 명령어를 치는 것을 가정한 것인점 참고해주세요. 감샇바니다.
안녕하세요. kafka 도입을 검토하고 있는 개발자 입니다. 강의를 듣다가 질문이 있어 댓글 남깁니다. 1. 하나의 토픽에 대해 여러개의 파티션으로 나누는 이유는 단순히 여러개의 컨슈머를 생성해서 병렬처리할수 있게끔하기 위한 용도인건가요? 2. 파티션으로 데이터가 들어갈때에는 라운드로빈으로 들어간다고 하는데 주식시세 같은 serialize한 데이터를 처리할때에는 파티션을 여러게 사용하는건 불가능한것인가요? 항상 좋은 내용으로 유튭 영상 올려주셔서 감사합니다.^^
@Kim Namkyung님, 몇가지 질문주셨는데요. 답변드리겠습니다. Q: 파티션으로 나누는 이유가 뭔가요? A: 컨슈머를 여러대로 연동하여 병렬처리 할 수 있는 것은 파티션을 나누는 이유중 하나입니다. 파티션을 나눔으로서 처리 속도를 향상시키기 위함이죠. 대규모 데이터 처리에 있어 컨슈머의 데이터 처리량을 늘리기 위한 방법으로 파티션을 늘립니다. 추가적인 이유는 메시지 키의 활용입니다. 메시지 키를 사용하게 되면 동일 메시지 키를 가진 데이터는 동일 파티션에 들어가게 되는데요. 이를 활용하여 데이터 처리 순서를 지킬 수 있습니다. 예를 들어 '주문'이라는 메시지 키를 가진 데이터는 동일한 파티션번호에 들어가게 되고 애플리케이션이 '주문'처리를 ordering하게 할 수 있는 것이죠. 만약 메시지 키를 활용하지 않는다면 컨슈머의 병렬 데이터 처리량의 향상을 목적으로 사용한다고 보시면 됩니다. Q: 주식시세같은 데이터를 처리할때 파티션을 여러개 사용못하나요? A: 이 질문은 정확한 needs를 파악하지 못해서 정확히 답변을 드리기 어렵네요 ㅠ.. 영상 잘봐주셔서 감사합니다.~!
안녕하세요! 카프카에서 사용되는 용어중 레코드에 대해서 질문드립니다. "객체를 프로듀서에서 컨슈머로 전달하기 위해 Kafka 내부에 byte형태로 저 장할 수 있도록 직렬화/역직렬화하여 사용" 이 개념을 보면서 => 제 생각엔 "레코드란 카프카에서 컨슈머와 프로듀서가 데이터를 카프카에게 주고/끌어오는 기본 단위" 라고 생각했는데... 이렇게 생각해도 될까요?? RDB에서 row를 record라고 하는데 카프카에서 record와는 많이 다른 개념일까요?? (추가) 파티션의 오프셋에 대해 설명해주시면서 "메세지"가 들어간 순서대로 나오는지에 대해서 말씀해주셨는데, 메세지와 레코드는 다른 개념일까요?? 정리하자면 파티션의 오프셋 번호당 1개의 레코드가 들어가는건지 궁금합니다.
안녕하세요. 강의 잘 봤습니다. 질문이 몇가지 있어서 남깁니다. 1.producer가 broker에게 message를 쏘면 broker에서는 message를 topic이라고 부르고 topic 안에 record라는 형태로 들고있는게 맞나요? 2.하나의 partition이 record 하나인 것인가요? 3.broker에서 record를 segment라는 형태로 파일시스템에 저장하는게 맞나요? 4.컨슈머가 topic을 읽어갈때는 broker에 저장된 segment를 읽어서 가져가는 것인가요?
@김도현님, 몇가지 질문 주셨는데요. 답변드립니다. 1. 프로듀서가 브로커에 메시지를 쏘면 브로커는 메시지를 레코드라고 부르고 토픽의 파티션에 레코드가 저장된다고 보시면 됩니다. 2. 토픽에는 1개 이상 파티션을 가질 수 있습니다 3. 브로커에 레코드는 세그먼트 단위의 파일 시스템에 저장됩니다. 4. 컨슈머는 브로커에 저장된 세그먼트의 레코드들을 가져갑니다. 영상 봐주셔서 감사합니다~!
좋은 자료 감사합니다. 아껴가며 보겠습니다.
카프카를 공부 중인데, 데브원영님 영상들이 정말 큰 도움이 됩니다 !! 감사합니다.
잘봐주셔서 감사합니다😃
와우 정말 너무 쉽게 설명해 주십니다.^^ 👌
토픽에 대해서도 뭔가 설명이 추가되었으면 좋을것같은데 좋은 영상 감사합니다.
카프카 좋은 강의 감사드립니다 ^_^
안녕하세요 여행일기님~ 좋게봐주셔서 감사합니다^^
궁금했는데 너무 감사합니다 !!
여기 이렇게 친절하고 훌륭한 스페셜리스트가 계셨는데, 그것도 모르고 지금까지 구글링하며, 영문 번역까지 해가며 눈알 뛰어나오게 삽질했었네요~ 진작 알았으면 좋았을 것을~ 한편으로 늦게 알아서 아쉽, 그래도 알게 돼서 다행~ 임다. 첨 뵙게된 기념으로 한 가지 여쭤 보았으면 합니다. 카프카 좀 안다고 하는 인간들이 종종 오프셋 관리 어쩌구저쩌구 하던데, 오프셋 관리는 어떻게 하는 것인가요? 컨슈머 쪽에서 예외 처리할 때 대응 방법인거 같긴 하던데,,, 어떨때 어떤 방법으로 대응하는지 가이드 좀 부탁드립니다.
안녕하세요 승현오님, 카프카에서 컨슈머가 데이터를 져가면 오프셋이 커밋됩니다. 오프셋에 대한 히스토리를 다양한 매니지먼트 툴을 이용해서 남기신다면 컨슈머의 정상/비정상 동작에 대한 대응이 될 수 있을 거라 생각됩니다!
강의 듣고 싶었는데,, 감사합니다 ㅋㅋㅋ
좋은 강의 감사드립니다.
문의 있습니다. Broker partition replication 장표(23page)에서 하단의 shell script를 사용하면 장표에 보이는 것처럼 브로커가 3개가 생성되는 건가요? 제가 보기에는 로컬 호스트 브로커 1대에 3개의 파티션이 생성되는 것 아닌가요? 이해가 잘 안되어서요...
@김명찬 님, 답변드리겠습니다. Broker partition replication 장표의 하단 shell script는 파티션 3개로 이루어진 토픽을 생성하는 명령어입니다. 만약 브로커가 3대인 카프카 클러스터에 명령어를 치면 각각의 개별 브로커에 파티션이 나누어 저장되는 것이죠. 이 장표는 브로커3대인 카프카 클러스터에 명령어를 치는 것을 가정한 것인점 참고해주세요.
감샇바니다.
너무 잘보았습니다!!!!!!
잘봐주셔서 감사합니다!!
강의 잘 봤습니다~ 도움됐어요! ㅎㅎ
@Jeongjin Park님, 잘봐주셔서감사합니다 ^^
안녕하세요. kafka 도입을 검토하고 있는 개발자 입니다. 강의를 듣다가 질문이 있어 댓글 남깁니다.
1. 하나의 토픽에 대해 여러개의 파티션으로 나누는 이유는 단순히 여러개의 컨슈머를 생성해서 병렬처리할수 있게끔하기 위한 용도인건가요?
2. 파티션으로 데이터가 들어갈때에는 라운드로빈으로 들어간다고 하는데 주식시세 같은 serialize한 데이터를 처리할때에는 파티션을 여러게 사용하는건 불가능한것인가요?
항상 좋은 내용으로 유튭 영상 올려주셔서 감사합니다.^^
@Kim Namkyung님, 몇가지 질문주셨는데요. 답변드리겠습니다.
Q: 파티션으로 나누는 이유가 뭔가요?
A: 컨슈머를 여러대로 연동하여 병렬처리 할 수 있는 것은 파티션을 나누는 이유중 하나입니다. 파티션을 나눔으로서 처리 속도를 향상시키기 위함이죠. 대규모 데이터 처리에 있어 컨슈머의 데이터 처리량을 늘리기 위한 방법으로 파티션을 늘립니다.
추가적인 이유는 메시지 키의 활용입니다. 메시지 키를 사용하게 되면 동일 메시지 키를 가진 데이터는 동일 파티션에 들어가게 되는데요. 이를 활용하여 데이터 처리 순서를 지킬 수 있습니다. 예를 들어 '주문'이라는 메시지 키를 가진 데이터는 동일한 파티션번호에 들어가게 되고 애플리케이션이 '주문'처리를 ordering하게 할 수 있는 것이죠.
만약 메시지 키를 활용하지 않는다면 컨슈머의 병렬 데이터 처리량의 향상을 목적으로 사용한다고 보시면 됩니다.
Q: 주식시세같은 데이터를 처리할때 파티션을 여러개 사용못하나요?
A: 이 질문은 정확한 needs를 파악하지 못해서 정확히 답변을 드리기 어렵네요 ㅠ..
영상 잘봐주셔서 감사합니다.~!
@@DevWonYoung 충분한 답변이 되었습니다. 감사합니다^^
안녕하세요!
카프카에서 사용되는 용어중 레코드에 대해서 질문드립니다.
"객체를 프로듀서에서 컨슈머로 전달하기 위해 Kafka 내부에 byte형태로 저 장할 수 있도록 직렬화/역직렬화하여 사용" 이 개념을 보면서
=> 제 생각엔 "레코드란 카프카에서 컨슈머와 프로듀서가 데이터를 카프카에게 주고/끌어오는 기본 단위" 라고 생각했는데... 이렇게 생각해도 될까요??
RDB에서 row를 record라고 하는데 카프카에서 record와는 많이 다른 개념일까요??
(추가)
파티션의 오프셋에 대해 설명해주시면서 "메세지"가 들어간 순서대로 나오는지에 대해서 말씀해주셨는데, 메세지와 레코드는 다른 개념일까요??
정리하자면 파티션의 오프셋 번호당 1개의 레코드가 들어가는건지 궁금합니다.
안녕하세요!
레코드란 전체 카프카 파이프라인에서 다루는 메시지의 최소단위라고 생각하시면 됩니다! RDB의 row와 비슷하다고 보면되요! 메시지 == 레코드, 그리고 오프셋당 레코드1개 맞아요~
안녕하세요. 강의 잘 봤습니다. 질문이 몇가지 있어서 남깁니다.
1.producer가 broker에게 message를 쏘면 broker에서는 message를 topic이라고 부르고 topic 안에 record라는 형태로 들고있는게 맞나요?
2.하나의 partition이 record 하나인 것인가요?
3.broker에서 record를 segment라는 형태로 파일시스템에 저장하는게 맞나요?
4.컨슈머가 topic을 읽어갈때는 broker에 저장된 segment를 읽어서 가져가는 것인가요?
@김도현님, 몇가지 질문 주셨는데요. 답변드립니다.
1. 프로듀서가 브로커에 메시지를 쏘면 브로커는 메시지를 레코드라고 부르고 토픽의 파티션에 레코드가 저장된다고 보시면 됩니다.
2. 토픽에는 1개 이상 파티션을 가질 수 있습니다
3. 브로커에 레코드는 세그먼트 단위의 파일 시스템에 저장됩니다.
4. 컨슈머는 브로커에 저장된 세그먼트의 레코드들을 가져갑니다.
영상 봐주셔서 감사합니다~!
굳