데브원영님 로그데이터를 실시간 스트리밍으로 스파크를 통해 가져오려하는데요 로그데이터를 프로듀서로 보내는 방법을 모르겠습니다. 1. 다른 서버에 있는 데이터를 가져오려면 어떤방법을 사용해야하나요 2. 프로듀서에 데이터를 넣는방법은 무엇인가요 3. 다른서버의 데이터를 보낼려면 그 서버에 그때마다 프로듀서를 만들어야하는건가요?
1. 서버에 로그파일을 남겨서 에이전트로 프로듀싱 하거나 해당 애플리케이션이 카프카로 데이터를 프로듀스 하셔도 좋습니다. 2. KafkaProducer 라이브러리에서 send()메서드로 데이터를 전송하시면 됩니다. 3. 각기 다른 서버에서 데이터(파일 이든)를 보내시려면 각각 프로듀서를 배포, 운영하셔야 합니다.
안녕하세요! 금일 책 구입하고 다시금 살피다가 궁금한점이 있어서 이렇게 글 남깁니다. min.insync.replicas와 ack에 관한 내용인데요 acks=all 이고 replication factor가 3이고, broker가 3대일에 대한 내용입니다. ack=all이고,min.insync.replicas가 1이면 결국 ack 1 처럼 leader만 체크하기에 동일하게 ack 1처럼 동작하는 것으로 알고 있습니다. ack = all + min.insync.replicas =1 조합이 ack =1 과 전혀 차이가 없는지가 궁금합니다! 내부적인 로직이 다르지 않을까 싶기도 하구요..
강의 정말 진심으로 감사드립니다. 작성하신 서적도 구입하였습니다. 어디 봐도 없어서 ... 토픽을 키를 사용하여 컨슈머가 구분하여 다른 로직을 구현할수 있지만 토픽이 A00이 있고 이 토픽이 상위로 하여 그 하부 토픽 A01이 있고 또 이 토픽A01밑에 A010이라는 토픽으로 구조적 토픽을 정의 할수 있나요?
@최윤호 님, 서적 구입 감사합니다!!! 그리고 질문에 답변드리겠습니다. 구조적 토픽이라는 것을 문의주셨는데요. 토픽들이 있고 부모 토픽에서 일부 처리한 데이터를 자식 토픽으로 넘기는 과정을 뜻하시는 것이라면 부모와 자식에 해당하는 토픽들을 만들고 카프카 스트림즈를 통해 처리하는 방식이 있습니다~!
안녕하세요 강의 너무 잘 듣고 있습니다! 관련하여 질문사항이 있어요 ^^; ProducerRecord 객체 생성할때 여러가지 파라미터를 사용하잖아요. 이때, key 파라미터 값을 지정하면 partitioner를 통해서 리턴값으로 파티션 번호를 받게되고, partition 파라미터의 값이 있다면 이 경우 이미 파티션을 지정한 것이기에 별도로 파티셔너를 통해 파티션 번호를 리턴받을 필요가 없다고 이해했습니다.(맞으려나 모르겠네요ㅠ) 그런데 exact partition쪽 코드를 보니 ProducerRecord 객체 선언 시에 key도 있고 partition 번호도 모두 정의 되었더라구요. 그래서 이해하기를 key로도 특정파티션을 매핑하고, 한번 더 안전하게 partition을 선언한건가(?) 했는데 한가지 궁금한게 생겼습니다. 만약 최초에 test란 토픽을 만들고 처음에는 partition 파라미터 null, key는 특정 값을 지정하여 전송 했다고 가정을 한다면요. 이때 파티셔너로 부터 연결된 파티션이 1번이라 하면 향후에는 동일 key의 경우 연결된 파티션이 계속 1번일텐데. 이때 만약 partition 파라미터 값으로 2를 넣고 이전과 똑같은 key도 똑같이 넣는다고 하면 어떻게 되나요? key로는 1번에 연결되었지만 partition 파라미터 값이 있어서 2번에 넣어야하는 그런 충돌이 발생하지 않나 싶어서 여쭤봅니다!
안녕하세요 구스톡님, 몇가지 질문주셨는데요. 답변드리겠습니다. 1) 메시지 키로 특정 파티션을 매핑하고 더 안전하게 파티션에 보내기 위해 partition값을 producerRecord에 지정하였는지? > ProducerRecord에 메시지 키를 넣고 파티션 번호를 넣은 이유는 파티션 번호를 지정하기 위해서는 반드시 메시지 키와 메지시 값을 파라미터로 넣어야 했기 때문입니다. 이렇게 ProducerRecord에 파티션 번호를 넣었을 경우에는 파티셔너가 무엇인지, 메시지 키가 무엇인지에 상관없이 레코드가 무조건 해당 파티션으로 보내집니다. 2) ProducerRecord에 partition파라미터를 2로 넣으면 어떻게 동작하나요? > 1에서 드린 답변처럼 파티셔너가 무엇인지, 메시지 키가 무엇인지에 관계없이 무조건 2번 파티션으로만 보내집니다! 영상 잘봐주셔서 감사합니다^^
안녕하세요! 카프카 강의 감사합니다. 레코드 키 설명시 질문이 있는데요. 동일키, 동일 파티션 적재 by default partitioner 이라는 것은, 동일키 1,1,1로 넣는것은 자동으로 같은 파티션에 들어가는건가요? 그리고, 순서 보장하므로, 상태머신으로 사용가능하다는게, 무슨의미인지가 잘이해가 안갑니다.. 마지막으로, 해쉬값으로 중복처리 방지 가능은, 어떤 옵션을 틀면 가능해지는건가요? 위에 말씀하신건 동일키 동일 파티션 적재 가능하다고 하셔서, 중복처리 방지가 안되는거 같아서요.
데브원영님! 다수의 파티션 중 가장 lag이 적은 파티션에 메세지를 보내고 싶습니다. 파티션마다 속도차가 커서 lag이 0이 된 파티션은 일을 하지 않는 경우가 있습니다. 현재는 KafkaAdmin과 Consumer를 활용해 lag을 직접 계산하는 방법만 떠오르는데, 혹시 lag이 가장 적은 파티션에 메세지를 보내는 방법이 있을까요? 원영님께서 추천해주실만한 접근법이 있으시면 공유해주시면 감사하겠습니다!
안녕하세요, 컨슈머 랙이 많은 파티션에 메시지를 프로듀스 해서 데이터를 처리하면 어떻겠냐 라고 질문주셨는데요. 지금 사용하시는 프로듀서의 파티셔너를 어떤 것을 사용하시는 지, 메시지 키를 사용하는지 여부에 따라 다를 것 같습니다. 언급하신 바로는 메시지 키를 사용하지 않는 것으로 이해되는데요. 메시지 키를 사용하지 않으신다면 컨슈머 랙이 적은 파티션에 메시지를 보내는 건 큰 노력이 따를 것 같습니다. 차라리 파티션개수와 컨슈머 개수를 더 늘려서 처리하는 방안은 어떨까요? 좀 더 분산되어서 컨슈머의 처리량을 더 늘림으로서 컨슈머 랙을 줄이는 방안으로 가는것이 좋다고 생각되네요.
![[마틴 파울러] 리팩토링의 중요성 feat.테스트 코드를 짜는 이유(한글 자막)](http://i.ytimg.com/vi/mNPpfB8JSIU/mqdefault.jpg)
데브원영님 로그데이터를 실시간 스트리밍으로 스파크를 통해 가져오려하는데요 로그데이터를 프로듀서로 보내는 방법을 모르겠습니다.
1. 다른 서버에 있는 데이터를 가져오려면 어떤방법을 사용해야하나요
2. 프로듀서에 데이터를 넣는방법은 무엇인가요
3. 다른서버의 데이터를 보낼려면 그 서버에 그때마다 프로듀서를 만들어야하는건가요?
1. 서버에 로그파일을 남겨서 에이전트로 프로듀싱 하거나 해당 애플리케이션이 카프카로 데이터를 프로듀스 하셔도 좋습니다.
2. KafkaProducer 라이브러리에서 send()메서드로 데이터를 전송하시면 됩니다.
3. 각기 다른 서버에서 데이터(파일 이든)를 보내시려면 각각 프로듀서를 배포, 운영하셔야 합니다.
감사합니다!
보기만해서 그런지 너무 재밌네요
티아카데미 강의를 보는데 정말 명료하게 설명을 해주시더라구요 해당 부분들 혹시 제 개인블로그에 정리할 겸해서 출처를 다 남기고, 부분 인용을 해가도 될까요?
넵, 출처남기고 정리하셔도 좋습니다😉
안녕하세요!
금일 책 구입하고 다시금 살피다가 궁금한점이 있어서 이렇게 글 남깁니다.
min.insync.replicas와 ack에 관한 내용인데요
acks=all 이고 replication factor가 3이고, broker가 3대일에 대한 내용입니다.
ack=all이고,min.insync.replicas가 1이면 결국 ack 1 처럼 leader만 체크하기에
동일하게 ack 1처럼 동작하는 것으로 알고 있습니다.
ack = all + min.insync.replicas =1 조합이 ack =1 과 전혀 차이가 없는지가 궁금합니다!
내부적인 로직이 다르지 않을까 싶기도 하구요..
안녕하세요 kim deans님, ack=all + min.insync.replicas=1 조합과 ack=1는 전혀 동작에 차이가 없습니다~!
강의 정말 진심으로 감사드립니다.
작성하신 서적도 구입하였습니다.
어디 봐도 없어서 ...
토픽을 키를 사용하여 컨슈머가 구분하여
다른 로직을 구현할수 있지만
토픽이 A00이 있고 이 토픽이 상위로 하여
그 하부 토픽 A01이 있고
또 이 토픽A01밑에 A010이라는 토픽으로
구조적 토픽을 정의 할수 있나요?
@최윤호 님, 서적 구입 감사합니다!!! 그리고 질문에 답변드리겠습니다.
구조적 토픽이라는 것을 문의주셨는데요. 토픽들이 있고 부모 토픽에서 일부 처리한 데이터를 자식 토픽으로 넘기는 과정을 뜻하시는 것이라면 부모와 자식에 해당하는 토픽들을 만들고 카프카 스트림즈를 통해 처리하는 방식이 있습니다~!
안녕하세요? 영상 잘보고있습니다.
이해하기 쉽게 설명해주셔서 감사합니다.
원영님 영상보며 공부하다보니까 kafka에 인증모드가 있는데 현업에서 사용하시나요?
혹시 사용했다면 어떤 인증모드를 사용하셨는지 궁금합니다.
안녕하세요~
저는 인증모드를 사용해본적이 없네요. 컨플루언트 클라우드에서는 기본 SASL 인증을 제공했던것 같아요~
안녕하세요 강의 너무 잘 듣고 있습니다!
관련하여 질문사항이 있어요 ^^;
ProducerRecord 객체 생성할때 여러가지 파라미터를 사용하잖아요.
이때, key 파라미터 값을 지정하면 partitioner를 통해서 리턴값으로 파티션 번호를 받게되고, partition 파라미터의 값이 있다면 이 경우 이미 파티션을 지정한 것이기에
별도로 파티셔너를 통해 파티션 번호를 리턴받을 필요가 없다고 이해했습니다.(맞으려나 모르겠네요ㅠ)
그런데 exact partition쪽 코드를 보니 ProducerRecord 객체 선언 시에 key도 있고 partition 번호도 모두 정의 되었더라구요.
그래서 이해하기를 key로도 특정파티션을 매핑하고, 한번 더 안전하게 partition을 선언한건가(?) 했는데 한가지 궁금한게 생겼습니다.
만약 최초에 test란 토픽을 만들고 처음에는 partition 파라미터 null, key는 특정 값을 지정하여 전송 했다고 가정을 한다면요. 이때 파티셔너로 부터 연결된 파티션이 1번이라 하면
향후에는 동일 key의 경우 연결된 파티션이 계속 1번일텐데. 이때 만약 partition 파라미터 값으로 2를 넣고 이전과 똑같은 key도 똑같이 넣는다고 하면 어떻게 되나요?
key로는 1번에 연결되었지만 partition 파라미터 값이 있어서 2번에 넣어야하는 그런 충돌이 발생하지 않나 싶어서 여쭤봅니다!
안녕하세요 구스톡님, 몇가지 질문주셨는데요. 답변드리겠습니다.
1) 메시지 키로 특정 파티션을 매핑하고 더 안전하게 파티션에 보내기 위해 partition값을 producerRecord에 지정하였는지?
> ProducerRecord에 메시지 키를 넣고 파티션 번호를 넣은 이유는 파티션 번호를 지정하기 위해서는 반드시 메시지 키와 메지시 값을 파라미터로 넣어야 했기 때문입니다. 이렇게 ProducerRecord에 파티션 번호를 넣었을 경우에는 파티셔너가 무엇인지, 메시지 키가 무엇인지에 상관없이 레코드가 무조건 해당 파티션으로 보내집니다.
2) ProducerRecord에 partition파라미터를 2로 넣으면 어떻게 동작하나요?
> 1에서 드린 답변처럼 파티셔너가 무엇인지, 메시지 키가 무엇인지에 관계없이 무조건 2번 파티션으로만 보내집니다!
영상 잘봐주셔서 감사합니다^^
아하 그렇군요 감사합니다!!!
안녕하세요! 카프카 강의 감사합니다. 레코드 키 설명시 질문이 있는데요.
동일키, 동일 파티션 적재 by default partitioner 이라는 것은, 동일키 1,1,1로 넣는것은 자동으로 같은 파티션에 들어가는건가요?
그리고, 순서 보장하므로, 상태머신으로 사용가능하다는게, 무슨의미인지가 잘이해가 안갑니다..
마지막으로, 해쉬값으로 중복처리 방지 가능은, 어떤 옵션을 틀면 가능해지는건가요?
위에 말씀하신건 동일키 동일 파티션 적재 가능하다고 하셔서, 중복처리 방지가 안되는거 같아서요.
동일 메시지 키를 가진 레코드를 넣을 경우에 동일 파티션으로 들어가게 됩니다. 그렇게 할 경우 특정 데이터에 대해 순서를 보장할 수 있습니다. 예를 들어 '원영'이라는 고객의 데이터는 순서를 보장하는 것이죠.
데브원영님! 다수의 파티션 중 가장 lag이 적은 파티션에 메세지를 보내고 싶습니다. 파티션마다 속도차가 커서 lag이 0이 된 파티션은 일을 하지 않는 경우가 있습니다.
현재는 KafkaAdmin과 Consumer를 활용해 lag을 직접 계산하는 방법만 떠오르는데, 혹시 lag이 가장 적은 파티션에 메세지를 보내는 방법이 있을까요?
원영님께서 추천해주실만한 접근법이 있으시면 공유해주시면 감사하겠습니다!
안녕하세요, 컨슈머 랙이 많은 파티션에 메시지를 프로듀스 해서 데이터를 처리하면 어떻겠냐 라고 질문주셨는데요. 지금 사용하시는 프로듀서의 파티셔너를 어떤 것을 사용하시는 지, 메시지 키를 사용하는지 여부에 따라 다를 것 같습니다. 언급하신 바로는 메시지 키를 사용하지 않는 것으로 이해되는데요. 메시지 키를 사용하지 않으신다면 컨슈머 랙이 적은 파티션에 메시지를 보내는 건 큰 노력이 따를 것 같습니다. 차라리 파티션개수와 컨슈머 개수를 더 늘려서 처리하는 방안은 어떨까요? 좀 더 분산되어서 컨슈머의 처리량을 더 늘림으로서 컨슈머 랙을 줄이는 방안으로 가는것이 좋다고 생각되네요.