데이터 엔지니어로 살아가기 269일째(데이터 작업관련 이야기, spark, hadoop, elasticsearch, kibana)

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

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

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

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

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

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

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

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

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

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

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

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

--conf "spark.dynamicAllocation.enabled=true"

--conf "spark.shuffle.service.enabled=true"

해당 옵션이 있었고 새로만든 스파크 작업에는 해당 옵션을 주지 않고 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에만 의존하기 보다는 다양한 도전과 시도를 통해 여러 문제에 대해 적합한 솔루션을 제공할 수 있도록

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