행복한디벨로퍼

스파크와 맵리듀스  성능차이 그리고 엘라스틱서치

최근 업무하면서 경험했던 이슈들에 대해서 정리해볼까 한다.

Episode1. 스파크(Spark)와 하둡 스트리밍 MR작업의 성능 이슈

함께 업무를 하던 과장님께서 하둡 맵리듀스로 된 작업을 스파크로 변경하셨었다.

그런데 스파크로 코드를 작성하고 테스를 하시더니 맵리듀스 보다 1분 30초나 느리다는 것이다.

이 무슨 말이란 말인가??? 스파크가 하둡MR 보다 성능이안나온다니!

그래서 함께 코드를 봤더니 코드는 뭐 딱히 문제가 될 만한 부분도 없을만큼 단순한 코드였다.

단순히 파일을 rdd로 읽어서 parsing해서 결과파일을 쓰는....

그래서 다시 과장님이 스파크 어플리케이션을 돌리실동안 클라우데라에 들어가 잡이 돌아가는 상황을

Application Master로 보았더니 굉장히 많은 shuffle이 일어나고 있었고 순간 spark-submit할 때

어떤 옵션들이 들어있는지에 대한 의문이 들었다.

확인을 해보니….하둡 스트리밍 MR작업을 돌릴 때는

해당 옵션이 있었고 새로만든 스파크 작업에는 해당 옵션을 주지 않고 spark-submit이 이루어졌던 것이다.

결과적으로 하둡 스트리밍MR은 클러스터의 사용가능한 충분한 executor를 사용하여 작업이 이루어진 반면에

스파크작업은 10개 이내의 executor들을 사용해 작업이 진행되었던 것이다.

같은 옵션을 주고 다시 테스트를 해보니 당연히 스파크의 승리!!! 약 20초정도 더 빨랐던 것 같다. 

데이터가 커지고 로직이 더 복작해지면 질수록 이 성능은 더 차이가 많이 나지 않을까 생각한다.

Episode2. 엘라스틱서치(elastic search)와 키바나(cabana)

최근 데이터 유입쪽과 카프카-camus를 통해 hdfs 적재되는 데이터량을 쉽게 확인할 수 있는 시스템?을 개발하였다.

기존에는 데이터유입부분과 실제 hdfs에 데이터가 적재되는 양을 비교할 수 없어 데이터가 정상적으로 유입부터 적재까지

이루어지고 있는지 확인할 수 있는 방법이 없었다. 가 아니라 실제 데이터들을 다 까서 로그들의 개수를 읽어서 매칭시켜보는 방법이 있었다....(노가다...)

따라서 이부분에 대한 모니터링 작업이 필요한 상황이였다.

그래서 파이썬스크립트로 데이터유입서버와 hdfs에 적재되는 커맨드 서버에서 로그파일의 row수를 세서 시간별로 데이터 row count를 

엘라스틱서치(elastic search)에 적재하도록 하였다. 이렇게 쌓인 데이터는 키바나(kibana)를 통해 쉽게 시각화할 수 있게 함으로써 

편하게 확인할 수 있도록 작업을 진행하였다.

작업을 진행하면서 느낀것은 역시 써보지 않은 tool을 사용해 작업을 하는 것은 쉽지 않고 간단한 작업이라도 꽤나 시간을 많이 잡아 먹는다는 것이다.

하지만 새로운 도구를 경험하고 사용하면서 경험적인 측면에서 한 단계 성장해나가는 것 같은 기분이들어 좋았다.

생각보다 elasticsearch-kibana 를 사용하는데 많이 힘들진 않았지만 elastic search 인덱스를 만드는 부분과 kibana에서

index=true로 되어있지 않은 데이터들에 대해서는 그래프의 지표로 쓸수 없다는 부분을 깨닫는데까지 많은 삽질을 했던게 가장 기억에 남는다.

앞으로도 사용하고 있는 tool, framework에만 의존하기 보다는 다양한 도전과 시도를 통해 여러 문제에 대해 적합한 솔루션을 제공할 수 있도록

항상 여러 기술에 관심을 가지고 사용해볼 수 있도록 노력해야겠다는 생각이 들었다.

데이터 엔지니어로 살아가기 229일째(데이터야놀자 컨퍼런스 후기) 

오늘은 이틀전(20171013, 금요일)에 다녀온 '데이터야놀자' 컨퍼런스에 다녀온 후기에 대해서 작성하려고 한다.

먼저 '데이터야놀자' 컨퍼런스를 통해 크게 느낀점 네가지를 정리하자면 다음과 같다.

하루 종일 30분 정도로 진행되는 11개의 세션들을 들으며 많은 생각이 들었지만 그 중 핵심적인 생각은 위의 4가지로 요약할 수 있을 것 같다.

먼저 '데이터야놀자'라는 컨퍼런스는 데이터를 다루는 사람들의 소통의 장을 마련하고 축제의 분위기를 만들고 싶어하는 것 같았다.

그에 따라 세션이후에는 공연도 준비가 되어있었고 다양한 종류의 간식거리 및 맥주를 무료 제공하였다.

내가 들은 11개의 세션 중 가장 기억에 남았던 3개의 세션에 대해서 얘기해보려고 한다.

먼저 첫 번째 세션은 라인게임즈의 '백정상'님이 발표했던 "쌓는다고 다 데이터인가? (로그 맛깔나게 쌓는 방법)" 이다.

세션의 주제를 잘 정해서인지 많은 수의 인원들이 해당 세션을 듣기 위해 자리를 빈틈없이 꽉꽉 채웠다.

역시 주제 선정이 중요성에 대해서 다시 한 번 느끼게 되었다.

해당 세션에서 그 동안 경험했던 타부서팀들과의 경험담을 유쾌하게 잘 설명해주셨고 무작정 쌓은 데이터들과 잘 선별해 쌓은 데이터의 차이를

쓰레기수거장과 분리수거통의 사진으로 비유해 설명해주신게 특히 맘에 와닿았다. 

한 마디로 요약하자면 '데이터를 쌓을 때 어떤 데이터를 어떻게 활용할 것인지에 대해 생각해보는 것이 중요하다'는 내용이 주를 이루었다.

인상깊었던 두 번째 세션은 카카오 선물하기 팀의 '전수현'님이 발표해준 "커머스 로그 통합 시스템"이였다.

여자 발표자 분이라서 그런지 발표하는 내내 상당히 부드러운 느낌을 많이 받았고 중간중간 떠는 모습, 거기에 대해 솔직하게 토로하시는 부분에 

대해 굉장히 인간적인 면모를 많이 느꼈고 유쾌한 웃음과 솔직한 모습은 세션공간의 개발자들간의 경계를 많이 허물어 주셨다.

그리고 현재 내가 하고 있는 업무의 내용과 가장 비슷한 내용들이라서 더 집중하며 들었던 것 같다.

해당 세션에서 새롭게 알게 된 내용으로는 Apache Nifi가 있었는데 현재 우리 시스템에서 kafka to hdfs, monitoring을 담당해주는 새로운 대안

이 될 수 있을 것 같다는 생각이들었다. 

마지막 세번째 세션으로는 현재 구글에 계시는 조대협님의 '머신러닝 무엇이 중요한가?'라는 주제의 세션이였다.

솔직히 해당 세션에 대한 궁금증보다는 '조대협'님 자체가 너무 궁금했다. 개발을 하는 분이라면 한번쯤은 그의 블로그를 접해봤을거라는 생각이 

든다. 나 또한 하루에도 여러번 조대협 님의 블로그를 방문하고 글을 읽어 왔기 때문에 그 분의 말하는 방식 생각이 너무 궁금해 묻지도 따지지도 

않고 해당 세션을 들었다. 블로그 글들만 봤을 때는 기술에만 관심있는 기술쟁이라는 생각이 들었지만 의외로 말씀도 굉장히 유쾌하게 하시고 

ppt구성이나 발표능력도 상당히 수준급이라는 느낌을 받았다. 그리고 항상 말에는 자신감이 있었고 질문을 하기 힘든 답변에는 시원하게 

'그건 해봐야 안다. 잘모르겠다'라는 말을 서스럼 없이 하는 모습에  신뢰감이 들었다...보통은 연사자가 저런 답을 하면 신뢰감이 떨어지기 

마련인데 그 동안 접해왔던 조대협님의 여러 기술을 주제로한 글들로 인해 '저 사람은 대단한 사람'이라는 생각이 이미 스며들었는지도 모른다.  

어찌되었든 조대협님의 세션을 들으며 나도 그와 같이 추후에는 다른 기업에 '컨설팅'도 다니고 기술적인 부분에도 연사로 서있는 나의 모습을 

상상하게 되었다. 그러기 위해 꾸준히 학습하고 배우는 것들에 대한 블로깅, 끊임없이 배우려는 노력, 지속적인 목표 설정과 실천이 

가장 중요하다는 생각이 든다.

마지막으로 이번 '데이터야놀자' 컨퍼런스의 세션들을 들으며 기술적으로 더 학습해야겠다고 느낀 항목들을 적어본다.

항상 이런 컨퍼런스들에 관심을 가지고 참여할 수 있도록 하자. 일상에 큰 활력을 불어넣어준 하루였다.

아! 그리고 마지막으로 '데이터야놀자' 세션을 들으며 스스로 다짐했던 내가 듣는 세션에 '질문 꼭 하나씩 하기' 목표를 실천해서 뿌듯하다:)

데이터 엔지니어로 살아가기 143일째(커스텀타겟팅) - 0721금요일

광고주 태그매니저에서 들어오는 데이터들을 orc로 적재하는 작업을 마무리하였다.

camus를 통해 kafka에서 데이터를 가져와 매시간 데이터를 적재하고 있지만

커스텀타겟팅에 사용하기에는 부적합하다는 판단에 orc로 적재하기로 결정하였다.

작업을 완료하기까지 많은 수행착오를 겪었다. 인입되는 로그에서 실제 bid별 관심사를

추출해 적재하기로 사전에 얘기가 되었지만 실제로 작업을 완료하고 확인해보니 

생각보다 관심사를 추출하는 부분에서 처리시간이 많이 소모되었다. 

관심사 추출 후 date, action별로 partitioning하여 적재하는 시간이 단순 컬럼으로만 분리해서

적재했을 때의 시간보다 15배정도의 시간이 더 걸렸다.t.t

결국에는 일단 orc로 적재한 후 관심사 데이터가 필요할 경우 bid별 관심사 추출데이터와

join해서 사용하는 편이 리소스 활용측면이나 확장성 측면에서 더 효율적이겠다는 결정을 내렸고 

scala spark으로 다시 orc 적재하도록 마무리하였다.

orc적재 작업을 진행하면서 java-spark에 어느정도 더 익숙해졌고 관심사 추출로직에 대해

심도있게 파악할 수 있었다는 점에서 삽질도 많이했지만 좋은 기회가 되었던 것 같다.

이제 실제 커스텀타겟팅 메인 프로젝트 작업에 슬슬 시동을 걸어봐야겠다~

아! 그리고 틈틈히 scala공부를 하도록하자~scala 와 spark는 뗄래야 뗄 수 없는 관계

데이터 엔지니어로 살아가기 135일째(카산드라) - 0713목요일

역시 꾸준한게 제일 어려운 것 같다...못해도 3일에 한번씩은 기록하고자 마음먹었는데 생각보다 쉽지 않다.

그래도 잊지말고 앞으로라도 꾸준히 써나가도록 하자.

최근에는 알파 환경에서 리얼환경처럼 데이터가 유입되도록 하는 작업을 진행했었다.

실제 데이터 파이프라인은 구축이 되어있었지만 알파환경에서는 작동하는 태그매니저들이 없기 때문에

데이터가 실제로 유입이되지 않고 있었고 데이터가 없어 spark job들에 대해서도 매번 테스트하기가 너무 힘들었다.

이럴거면 알파환경을 도대체 왜쓰는가? 서버비 아깝게...

그래서 실제 리얼 태그매니저들을 통해 들어오는 데이터의 일부를 rsync로 알파서버에 daily로 받아오게 하여

알파 수집서버로 api를 호출하도록 작업하였다.

요즘은 CustomTargeting 프로젝트를 진행하고 있다.

기획부터 시스템설계까지 진행을 하고 있고 구글의 빅쿼리를 모티베이션 삼아 진행하고 있다.

관심사 추출하는 로직과 기존 클러스터 환경상 java7로 스파크작업을 하는데 삽질을 많이 하고 있긴 하지만

스칼라로 작업을 할 때보다 map, flatmap 등 연산작업들의 내부 구현에 대해 좀더 자세히 배우고 있는 느낌이든다.

요즘은 일하는게 너무 재밌어서 시간가는 줄 모르고 일하는 것 같다.

일도 일이지만 데이터 처리하는 기술들에 대해 공부에 대한 욕심도 많이 생긴다.

너무 욕심부리지 말고 천천히 꾸준히 일도 공부도 운동도 열심히 하도록 하자~!

데이터 엔지니어로 살아가기 105일째

오늘은 어제 미처 다 끝내지 못한 프로젝트 로컬셋팅 및 배포 프로세스를 잡는데 대부분의 시간을 할애했다.

관심사 타겟팅의 프로젝트의 경우 submodule로 카산드라에 벌크업로드를 하는 프로젝트가 물려있어 생각보다 셋팅 후 배포 프로세스를 만드는데 까지 시간이 오래 걸렸다. 

submodule인 카산드라 벌크업로드 프로젝트의 경우 maven dependency에서 사용하는 하둡 라이브러리들이 알파와 리얼에 jar로 묶여 있어 로컬에서 빌드를 따로 수행하지 못하고 소스코드만 배포 시스템으로 그대로 서버로 옮겨놓은 후 해당 서버에서 직접 'mvn package'명령을 주어 빌드를 실행해주어야 했다.

간만에 젠킨스 셋팅부터 시작해서 사내 배포시스템을 사용하여 빌드 배포를 쉽게할 수 있도록 작업하였다.

그 후에 시간이 좀 남아 실시간 스트리밍 spark job중에 log4j가 프로젝트에 셋팅되어있는데 실제로 로그가 남지 않아 해당 이슈를 찾아보다가 해결을 하지 못하고 오늘 하루를 마무리 하였다. 내일 출근하자마자 관련 부분 확인해서 처리하고 알파에서도 데이터 파이프라인에 데이터들이 실시간으로 흘러다닐 수 있는 환경을 구축하도록 해야겠다.

갈수록 배움의 즐거움이 커진다.

데이터 엔지니어로 살아가기 104일째 (곰발바닥 뭔가 귀엽다...)

오늘 하루는 오전에는 브루클린이라는 키워드 타겟팅 시스템에서 사용하는 알파 RabbitMQ의 큐들을 모두 priority큐들로 바꿔서 테스트 하는 작업을 진행하였다. priority를 높게준 메세지들부터 정상적으로 consume 하는 것을 확인을 하며 RabbitMQ가 제공해주는 모니터링 관리 페이지부터 시작해서 꽤나 괜찮은 메세지큐라는 생각을 다시 한 번 했다. 기존에 ActiveMQ를 잠깐 사용했을 때는 별도의 관리 페이지를 제공해주지 않아 불편함이 있었는데 요즘은 지원해주려나???

오후즈음에는 실시간 관심사 타겟팅 로직에서 카산드라에 데이터를 넣을 때 에러 처리가 하나도 되어 있지 않아 실제로 데이터가 들어가지 않아도 관리자 입장에서는 알 수 있는 방법이 딱히 없다. 그래서 해당 부분에 에러처리를 해서 정상적으로 데이터가 upsert되지 않았을 경우 알림을 받도록 기능을 추가하고자 마음먹고 Git 에서 소스코드를 받아 로컬환경에 셋팅을 하기 시작하였다. 기존 작업을 하셨던 분이 repository를 잘관리하지 않으시고 실제로 배포 프로세스를 따르지 않고 실제 서버에서 수정해서 사용하기도 했던 것 같다. 따라서 소스코드를 다운받았을 때 메이븐 디펜던시며 소스코드들이 피를 토해내고 있었다...어쩜 이렇게 관리가 안될 수 있는지..왜 컴파일은 자바5버전으로 되도록 메이븐에 설정되어있는건지...왜 위키페이지에는 별도의 내용이 하나도 없는건지...답답함 투성이였다. 

실시간 관심사쪽과 실시간 리타겟팅쪽 코드를 같이 셋팅했는데 생각보다 리타겟팅쪽 코드들은 빠르게 셋팅하고 .gitignore도 등록해주었다. 기존에는 .gitignore도 없이 어떻게 사용하신건지...그냥 빌드되는 target 모든 jar파일과 class파일들을 서버에 반영하고 사용하셨던 것 같다....

이번 한 주는 관리하고 있는 프로젝트들에 대한 소스코드 및 배포 프로세스를 바로 잡는데 시간을 많이 보내야 할 것 같다.

그럼 오늘 하루도 안녕~