개발자 노트

Kafka Connect(이하 커넥트) 2.3.0 개선사항에 대한 두 번재 글이다. Logging 개선에 대해서 살펴본다. 기존 커넥트의 로그는 커넥트에 포함된 작업의 로그들이 구분되지 않고 뒤섞여서 확인하기 쉽지 않았다. 특히 리밸런스 과정이 일어나면 커넥트가 담당하는 파티션들이 변경되는데 로그가 구분이 안되니 어떤 작업이 진행중인지 명확하게 알 수 없었다. KIP-449: Add connector contexts to Connect worker logs을 통해서 커넥트에 포함된 작업들의 로그를 쉽게 분리해서 볼 수 있다. 적용하는 방법은 간단하다. 기존 connect log4j 설정의 패턴을 다음과 같이 바꾸면 된다. # 과거 버전 설정 log4j.appender.stdout.layout.Conver..

Kafka 2.3.0 버전에서는 Connect(이하 커넥트) 관련 개선사항이 많았다. 관련 내용을 계속 정리해 갈 예정인데, 첫 번째 글로 KIP-458: Connector Client Config Override Policy에 대해서 정리한다. KIP(Key Improvement Proposals) 문서 제목에서 알 수 있듯이 Connector에 포함된 Client(Producer, Consumer)의 설정을 override 할 수 있게 되었다. 필자가 해당 내용에 대해서 관심을 갖게 된 이유는 커넥트에 포함된 Sink Connector들의 Source 카프카 클러스터가 하나로만 유지할 수 있어 여러 카프카 클러스터를 보유했을 경우, 커넥트 클러스터도 여러개를 구축해야 했다. 그런데 커넥트의 컨슈머 설..

카프카 관리자 업무를 진행하면서 가장 많이 받는 질문 중 하나는 "파티션 개수는 몇 개가 적당합니까?"이다. 그래서 이번 글은 Confluent 공동 창업자 중 한명인 Jun Rao가 쓴 How to choose the number of topics/partitions in a Kafka cluster? 라는 블로그 글을 인용해서 파티션 숫자와 관련하여 정리한다. 필자의 글은 Jun Rao의 글을 바탕으로 이해한 부분들을 풀어서 썼기 때문에 해당 주제에 관심이 있는 분들은 Jun Rao의 원문을 다시 읽어보시길 추천한다. 많은 파티션은 높은 처리량을 이끈다. 카프카에 기본적인 지식을 가지고 계신 분이라면 카프카가 분산 처리의 목적으로 설계되었음을 안다. 카프카의 분산 처리를 가능하게 하는 핵심 개념이 토..

이번글은 Kafka Connect를 distributed mode로 사용할 때 필자가 실수했던 내용을 공유하는 목적이다. Kafka Connect는 Standalone, Distributed 2가지의 mode가 있다. 테스트나 로컬에서 데이터를 이동할 때는 Standalone을 사용하지만 대부분의 운영 상황에서는 Distributed mode를 사용하게 된다. 필자의 실수에 대한 내용을 간략히 기술하면 다음과 같다. Custom한 Connector를 개발한 이후, Connect에 plugin을 배포하고 실행했다. REST API로 하나의 Job을 실행했다. 정상적으로 동작했다. 여러개의 Job의 동작 유무를 확인하기 위해 추가로 Job을 실행했다. 에러가 발생 에러의 내용은 다음과 같다. org.apac..

이번 글은 하둡 생태계에서 많이 사용되는 파일 포맷인 Parquet (이하 파케이)에 대해 정리한다. 글의 포함된 설명 중 많은 부분은 하둡 완벽 가이드에서 발췌한 것임을 밝힌다. 파케이는 columnar 저장 포맷이다. 구글에서 발표한 논문 Dremel: Interactive Analysis of Web-Scale Datasets를 토대로 Twitter, Cloudera에서 같이 개발했다. columnar 포맷을 기존에 많이 사용하던 Row 기반 포맷과 비교하면 이해하는데 도움이 된다. 전통적인 row 기반 저장 방식은 A1, B1, C1과 같이 같은 row 값이 연속적으로 저장된다. 반면에 columnar 저장 방식은 A1, A2, A3과 같이 컬럼의 데이터가 연속된 구조로 저장한다. columnar..

이번 글에서는 카프카 Producer(이하 프로듀서)의 주요 설정 값이 프로듀서의 아키텍처에서 어떤 역할을 하는지 정리한다. 카프카 문서에서는 각 설정값이 설명으로만 나열되어 있어서 이해하기 어려울 수 있다. 그래서 프로듀서의 주요 컴포넌트를 그림으로 표현하고 각 컴포넌트에서 어떤 설정 값을 사용해서 무슨 역할을 하는지 정리할 필요가 있다. 설정을 정리함에 있어서 카프카 문서를 제일 먼저 참조했지만 참고 문서에 포함한 내용도 추가해서 이해를 높이고자 했다. 1. 프로듀서 설정을 분석하는 이유 프로듀서의 정의를 사전에서 찾아보면 '생산자, 제작자'로 나온다. 카프카에서 프로듀서는 말 그래도 데이터를 생산하는 역할을 한다. 프로듀서의 설정값들은 데이터를 브로커에 발송할 때, 발송하는 데이터의 양/ 주기 및 ..

지난 글에서는 Semaphore(이하 세마포어)를 알아봤다. 이번에는 Thread의 동시 실행과 관련된 기능을 하지만 차이가 있어 헷갈리는 CountDownLatch(이하 래치)를 정리한다. 세마포어는 동시에 실행할 수 있는 스레드 수를 조절해서 고정된 리소스의 사용을 제한할 수 있었다. 이해하기 쉽게 예를 들자면, 어떤 공연의 좌석이 정해져 있는데 입구에서 관리자가 좌석 만큼의 인원만 수용하도록 체크하는 것과 같다. 그에 비해 래치는 경마장에서 출발 선상에 있는 말들이 모두 오기를 기다리는 것과 같다. 모든 말이 출발 준비를 마치고 출발선에 오면 경주가 시작되듯 그 시점까지 기다리게 한다. 래치를 생성할 때 수행할 스레드 수를 지정한다. 그리고 await 메서드를 실행하는데, 이 지점에서 모든 스레드가..

이전에 java.util.concurrent에 포함된 유용한 동기화 클래스들을 정리한 적이 있다. 해당 글은 다음 링크에서 확인할 수 있다. 동기화 클래스들이 더 있는데 이번 글에서는 Semaphore(이하 세마포어)에 대해서 정리한다. 세마포어는 특정 자원이나 특정 연산을 동시에 사용하거나 호출할 수 있는 스레드의 수를 제한하고자 할 때 사용한다. 자원 풀이나 컬렉션의 크기에 제한을 두고자 할 때 유용하다. 세마포어는 생성자에 퍼밋의 숫자를 받아서 해당 수 만큼 동시 사용을 허용한다. 더보기 permit을 사전에서 찾아보면 다음과 같은데 특정 수 만큼 허가증을 발급한다고 이해하자. [불][가]〔…의〕 인가(서), 허가(증), 면허(장) (※특히 여행·노동·수출 등 기한이 있는 것을 말함), 감찰〔for..

오랜만에 책과 관련된 글을 쓰고자 한다. 책을 꾸준히 읽으려고 노력하고 있으나 읽고 생각한 바를 글로 남기지 않으니 생각이 남지 않고 사라져 버려 아쉬울 때가 많다. 개인적으로 자주는 가지 못하지만 여행을 좋아하고 여행기를 쓴 책도 좋아한다. 여행이란 일상에서 벗어나서 새로운 경험을 하게 되니 새로운 생각과 관점도 생기게 된다. 내가 가지는 못하지만 다른 사람의 여행기에서 나의 예전 여행의 기억도 살아나고 기분전환도 된다. 최근에 여행과 관련한 책 2권을 읽었다. '김영하' 작가의 책 「여행의 이유」 그리고 「오래 준비해온 대답」 이다. TV에 출연을 많이 하는 작가라서 그의 삶을 본인에게 들을 수 있는 기회가 있었는데 여행을 많이 다녔다고 했다. 기회가 되면 여행을 다니고 책도 해외에서 쓰기고 한단다...

이번 글에서는 hadoop 3 & hive 3 버전에서 동작하는 spark 환경 구축을 설명한다. 최근 hadoop 3 cluster를 구축하는 작업에 참여하고 있는데 spark도 기존과 변경되는 부분이 있어 정리했다. hadoop과 hive의 설치 버전은 다음과 같다. 해당 버전들이 현재 시점(2020-05-25)의 안정화 버전이다. hadoop 3.1.3 hive 3.1.2 spark의 배포버전을 빌드할 때, hadoop/ hive 3 버전으로 변경 되더라도 큰 차이가 없다. spark에서 hive 1.2.1 버전을 default로 해서 빌드되기 때문에 추가 설정 작업이 필요하다. 그래서 spark 빌드 및 배포, hive 관련 옵션 설정을 나누어서 설명을 한다. 1. spark 빌드 및 배포 Bui..

Kafka Cluster를 관리하다 보면 필요에 의해 Topic을 생성했지만 현재는 사용하지 않아서 삭제할 Topic들을 찾아야 할 때가 있다. Broker 설정 중에 자동으로 Topic을 생성해 주는 auto.create.topics.enable 옵션이 있는데 default 값이 true 이다. auto.create.topics.enable=true의 의미는 Producer에 의해서 메세지를 Broker에 전송했는데, 존재하지 않는 topic에 메세지를 전송한 것이라면 해당 Topic을 자동으로 생성하는 것이다. 그래서 테스트를 위해서 여러 Topic에 무분별하게 계속 메세지를 발송했다면 사용하지 않는 Topic들이 늘어나게 된다. 이런 질문을 할 수 있다. 사용하지 않더라도 그냥 Topic을 남겨둬도..

이번 글에서는 scala의 evaluation strategy에 대해서 정리한다. 해당 글은 Evaluation strategies in scala 글의 내용을 토대로 샘플 코드를 달리해서 작성했다. 먼저 evaluation strategy의 개념부터 살펴보고 종류별로 구분해 보자. evaluation strategy evaluation strategy(이하 평가전략)이란 함수에 전달한 인자값을 함수가 실행될 때, 언제 어떻게 결정하는지 평가함을 말한다. Java에 익숙했던 필자로서는 당연히 함수에 값을 전달해 주는거 아닌가?라고 생각이 들었지만, 개념상 크게 2가지가 존재하며 큰 차이가 있다. 평가 전략의 2가지는 다음과 같다. Strict evaluation 함수에 인자값을 전달하기 전에 인자값을 평..