Skip to main
아파치 플룸을 사용한 데이터 파이프라인
- 개인적으로 여러가지 데이터를 처리하고 있다.
- 매일매일 책을 읽은 기록
- 카드 사용 내역 데이터
- 캘랜더에 기록된 내용
- 기타 등등
- 이런 데이터를 새롭게 처리할 때 마다, 새로운 서버를 만드는 것이 꽤나 번거롭다
- 따라서 파일이나 리눅스 네임드 파이프를 사용해서 처리했다.
- 가짓수가 늘어나면서 “어떤 파일이 어떤 데이터에 사용되는가"를 기억하기 어려워졌다
- 중앙화된 하나의 파이프라인 프레임워크가 필요해졌다
- 개인 용도로 사용할 것이기 때문에 처리량이나 안정성보다는 “사용하기 쉬운 것"을 주로 찾았다
- 아파치 flume은 “대용량 로그 전송"을 담당하는 오픈 소스
- source에서 가져와 channel을 통해서 sink에 전송하는 것이 주 목적이다.
- 이 과정에서 간단한 aggregation정도는 가능하나 사용하지 않고 있다.
- 비밀번호 필터링 정도만 가능한 것으로 이해하고 있다.
- source는 http listen부터 file tailing, kafka까지 폭 넓게 사용할 수 있다.
- java로 작성할 수 있다면 custom source도 사용할 수 있기 때문에 나쁘지 않다.
- 개인적으로 자바의 실력이 좋지 않아, 별개의 프로그램을 작성한 뒤 http나 file등을 통해서 flume에 넣도록 한다.
- flume과 해당 프로그램 모두 잘 동작하는 것을 확인해줘야 하기 때문에, 조금 불편한 느낌이 있다.
- channel의 경우 source에서 들어온 메시지가 sink에 내보내지기 전에 머무는 채널을 결정한다
- memory channel부터 kafka 채널, file 채널등을 사용할 수 있다.
- 개인적으로는 메시지가 많지 않기 때문에, memory 채널만 사용하고 있다.
- sink의 경우 메시지가 발송될 도착지를 의미한다.
- 안타깝게도 flume이 로그 처리를 주로 하다보니, sink의 갯수가 제한적이다.
- mysql, hdfs, hive등 db로 넣는 것들과 IRC, http, kafka 정도가 있다
- 물론 custom sink를 작성해서 사용할 수 가능하다.
- 이를 위해서 flume java 코드를 별도로 작성하는 것 보다, kafka나 http sink를 사용하고 있다.
- 사용하는 것은 세가지 종류의 source만 주로 사용하고 있다.
- Spooling Directory Source
- 폴더를 만들어 두고, 해당 폴더 내에 생성되는 파일들을 스풀링한다.
- 유니크한 파일(예컨대 유닉스 타임 스탬프로 이름이 구성된)을 읽고, 내용을 설정된 sink로 전송한다
- HTTP Source
- 특정 포트로 http post request를 보내면, 해당 내용을 파싱해서 sink로 전송한다.
- Taildir Source
- Spooling과 비슷하지만 하나의 파일을 감시한다.
- 파일이 rotating되어도 정상적으로 추적한다
- 단 텍스트 파일만 지원되며, 한 줄씩 메시지로 처리된다
- 현재는 flume을 제거하고, 다른 방식으로 구현할 생각을 하고 있다.
-
- 새로운 서버를 만들거나 여러가지 설정을 기억하는 것들이 번거로워서 시작 했으나 여전히 번거롭다.
- 매번 새로운 설정 파일을 만들어주어야 한다.
- file등을 사용했을때 여전히 “어떤 파일이 어떤 내용을 기록하는지” 설정 파일을 읽어봐야 한다.
- 마찬가지로 http의 경우 매번 포트 넘버를 확인해야 한다.
-
- 한번에 하나의 설정만 실행이 가능하다.
- 두개 이상 사용하기 위해서는 fluem을 두개 띄워주어야 한다.
- 크기가 커졌을 때는 이것이 이점이 있겠으나, 당장은 “하나만 띄워도 하나만 실행되게” 했으면 좋겠다,
- 두가지의 이유로 다른것을 찾고 있으나, 가려운 곳을 정확하게 긁어주는 프로젝트는 보이지 않는다
- Kafka에서 auto topic creation 설정을 쓰는것이 가장 가까운 해결책이 될 것으로 보인다.
- 반대로 “더 쉬운 Load Balancing"이 해결책일 것 같다는 느낌도 든다.
블로그,
Published