본문 바로가기

오픈소스/hadoop

하둡 스트리밍을 통한 아파치 쿼리 로그 분석

하둡 커뮤니티 모임에서 Apache Log Analysis using Hadoop Streaming라는 제목으로 발표했던 내용을 블로그를 통해서 공개하고자 합니다. 진작 올렸어야 하는 건데 조금 실험을 더 해보려는 욕심에 시간이 지체되어 더 이상 있다가는 올리지도 못 할 것 같아 그냥 올리기만 해 봅니다.


저 또한 그랬으며 하둡 커뮤니티 모임에서 많으신 분들이 참석하고 계시지만, 현실적으로 하둡을 이용해서 실용적인 무언가 또는 실험을 하기는 쉽지만은 않은 것 같습니다.

하지만, 한재선 박사님께서 그러한 분산저장 및 처리에 필요한 하둡 플랫폼을 무료로 제공해 주시기로 하셨습니다. ^^ 현재 하둡 개발자 그룹을 통해서 혼자서 끙끙대면서 하둡을 겨우 설치하고 WordCount 한번 싱글노드에서 돌려보고 마는 것이 아니라 비록 VM위에서 이긴 하지만 수십대의 데이터노드를 통해서 M/R를 해볼 수 있는 플랫폼을 사용할 수 있다는 것이 상당히 멋진 일이라 생각합니다.

 최근 HOD(Hadoop On Demand)와 같은 오픈소스프로젝트들이 속속 등장하면서 부터 이제는 조금씩 조금씩 ' 나도 한번 대용량 분산처리나 분석을 M/R를 이용해 볼까?' 하고생각할 수 있게 된 것 같습니다.

이번에 발표한 내용은 하둡에서 Contribute된 모듈 중에서 streaming을 통해서 Java언어가 아닌 Python으로 작성된 Map Reduce 코드를 돌리는 예제를 발표했었습니다. 무엇보다도 In/Out interface만 stdout/stdin으로 작성해 둔다면, C/C++/Java/Python 어떠한 언어로도 간단히 Map Reduce 어플리케이션을 작성해서 돌려볼 수가 있습니다.

물론 성능이나 이후에 언급하고 있는 Partitioner 또는 Combiner 등을 사용하기 위해서는 Java로 구현된 Class만 사용할 수 있음을 미리 말씀드립니다.

 아래의 문장은 Hadoop user group uk 에 있는 분 중에 'KLAAS BOSTEELS'라는 분께서 Dumbo라는Python용 Map Reduce 프로젝트에 대해 언급하면서 얘기 했던 말인데요, 마음에 와 닿아서 포함시켜 보았습니다. 아무리일반화하고 잘 구현한 프로그램이라고 하더라도 실제로 재사용 될 확률은 솔직히 많이 희박하더군요...쩝 그렇다면 처음부터 너무 과도하게작성하지 말고 간단히 스크립트로 돌려보고, 그래도 '이거 괜찮네..'하는 생각이 든다면, 그제서야 성능과 재사용성에 대해서고민해 보는게 좋지 않을까 하는 것입니다.


다음 슬라이드는 가장 간단한 M/R 아키텍처 입니다. HDFS에 아파치 로그파일이 이미 저장된 것을 전제로 Map.py와Reduce.py 만을 구현하고 SQL문을 추출하는 과정입니다. 처음에는 Reduce Task에서 Database에 넣는 식으로구현했다가 Transaction에 의한 Bottle-Neck이 심해서 performance가 떨어지는 것을 보완하기 위해서 Bulk로 SQL문을 내리고 입력하는 방식으로 변경하였습니다.

이번에는 하둡 스트리밍이란 어떻게 구현되어 있고, 작동하는지에 대한 슬라이드 입니다. 간단하게 얘기하면 Java로 MapReduce를 표준입출력으로 변환하는 모듈을 추가한 것이라 보시면 됩니다. 즉, 전달된 Map.py 또는 Reduce.py를ProcessBuilder라는 클래스를 통해서 fork하고 해당 프로세스에게 표준 입출력을 제공 또는 받는 구조라고 보시면됩니다.


 아파치 로그 저장에서부터 데이터베이스에 통계정보를 넣는 데까지 한번에 처리하는 과정입니다.  일반적으로 많은 로그들이 서버 자체에 존재하고 있고, 실제 레거시 시스템에서는데이터베이스를 통해서 통계정보들을 확인하게 되는데요, 단순히 스트리밍을 통해서 맵리듀스만을 한다면 업무에 적용하기는 쉽지 않을것 같아서 실례를 생각해 보았습니다. 우선 각 아파치 서버에서 주기적으로 로그를 (날짜별로) HDFS로 저장하는 쉘을 크론에등록하고 HDFS에 날짜별로 모인 모든 로그를 맵리듀스를 통해서 처리하고 처리된 결과물로 SQL문이 나오는데 이를 레거시데이터베이스에 바로 입력하고 임시파일들을 제거하는 과정이 전부 입니다.

이제는 하둡에 대한 얘기는 그만하고 통계를 통한 그래프를 통해서 보기로 하겠습니다. 이러한 쿼리로그를 저장해서 도대체 뭘할건데.. 하시는 분들도 계실 겁니다.

 최근 안타깝게도 스스로 목숨을 끊었던 두 연애인이 있습니다. 다들 잘 알고 계시겠지만,'안재환'씨와 '최진실'씨입니다. 이러한 일련의 사건에 대한 검색 질의문을 9월부터 10월까지를 기준으로 살펴보고 그래프로표현해 보았습니다.


 번호를 기준으로 그래프를 간략히 설명드리면, [1] '안재환'씨가 자살을 하는 보도가 나가자 대략 1만까지 그래프가올라가고 있습니다. 많은 사람들이 소식을 확인하기 위한 '안재환'이라는 키워드를 검색하고 있습니다. 이때까지만 해도'최진실'씨에 대한 쿼리는 없습니다. 하지만 [2] '안재환'씨에게 사채와 더불어 '최진실'씨에 관한 소문이 돌기 시작하면서 '최진실'씨의 키워드가 한번 올라오면서 덩달아 '안재환'씨의 검색도 늘어나는 것이 보입니다.이러한 파도가 잠잠해 지려나 싶다가 [3] '최진실'씨의 자살 보도가 나오자 걷잡을 수 없이 파도가 치면서 작게나마 '안재환'씨에 대한 질의도 나오고 있습니다. 그래프의 높이는 상당히 차이가 나지만, 폭은 그다지 차이가 나지 않고있는 것으로 보아서 이슈성 키워드로 보이며, 그 높이의 차이는 인지도나 사회적 파장 정도로 해설할 수도 있겠습니다. 그 이후에는 [4]이런 저런 뉴스 보도가 나갈 때마다 두 키워드가 유사한 모양으로 검색이 되고 있는 것을 알 수 있는데요, 이후의 그래프도 이러한형태로 보여질 것을 예상할 수 있습니다.

이 외에도 예전에 스스로 목숨을 끊었던 연예인이나 스타들의 키워드도 같이 확인해본다면, 조금 더 의미있는 그래프가 나오지 않을까 싶기도 했습니다.


 개인적으로도 고등학교 시절에 아주 인기리에 방영된 드라마 등을 통해서 '최진실'씨를 접했는데요, 아이를 둔 엄마의 입장으로자살에 까지 이르게 된 것을 안타깝게 생각이 들고요, 제가 아이를 둔 부모의 입장이라 가슴이 많이 아팠습니다.