Dharma

조금 광오한 제목을 썼지만 제자들과 같이 일하는 동료들에게 설명하기 위해서 만든 자료라 조금 거창하게 만들었습니다. 사진이나 그림들도 돌아다니는 것을 그냥 썼기에 저작권 이슈가 있을 수도 있습니다. 고발이 들어오면 바로 내리겠으니 양해해 주세요. 자료는 지금까지 제가 만들어 온 것과 마찬가지로 KeyNote 로 작성됐습니다. 원본이 필요하시면 메일 남겨주시면 보내드립니다. 

IT 쪽과 산업군과 심지어 경영쪽에서도 말이 많은 BigData 입니다. 최근의 핫한 이슈라서 어디서나 BigData를 말하고 있습니다. 저는 실제로 이 기술을 접한지는 오래됐습니다. 선배 (저에게 기술을 알려주신 사부님 되십니다.)의 회사에 놀러가서 최근에 나온 기술중에 BigData 란 것에 관심 있다고 하니 말  없이 책을 한권 주시더군요. 그러면서 하시는 말씀이 '벌써 적용해서 사용하고 있다' 라는 말이였습니다. 괴물 같으니라고.. 

그래서 어느정도 공부하고 실전에 적용해보면서 느낀 소감은 아직 멀었다는 것이였습니다. 이 기술을 준비한다는 업체는 절대 데이타가  Big 하게 많지가 않더군요. 그래서 잠시 다른일을 하느라 1년정도 손을 놨더니만 세상이 바꼈더군요. 제가 알던 시절하고 인프라도 많이 바뀌고 그 당시는 준비 단계의 프로젝트가 상위 프로젝트로 많이 올라왔더군요. 이번에 다른곳에 적용하기 위해서 POC 를 준비하면서 느끼게 된 것을 교육차원 으로 정리하는 것입니다. 

빅 데이타 입니다. 워드 클라우드 형태로 표현되고 있는데 사실은 저 표현되고 있는 말들의 대부분이 연관되는 것입니다. 일단은 Storage 라는 말과 Analytics 라는 글이 눈에 들어오는 군요. 뗄레야 뗄 수 없는 관계라고 볼 수 있습니다. 쉽게 생각해도 빅데이타라는 말은 일반적으로 많은 데이타를 처리하는 것이지.. 라고 막연하게들 생각하고 있습니다. 그러면 어떤 일을 하는 것일까요? 빅데이타란? 

이게 과연 완전히 새로운 기술이냐? 하는 것입니다. 인프라적으로 봐도 적용 형태로도 봐도 완전히 새로운 기술이라고 볼 수가 없습니다. 아니 세상에 완전히 새로운 기술이 있기는 한가? 라고 묻고 싶기도 합니다. 그렇다면 이 기술은 어떤 기술과 유사한 것인지? 

넵 바로 Business Intelligence 입니다. 바로 빅데이타 기술은 본인이 생각하기에 이 분야와 아주 유사합니다. 그렇다면 어떤점이 유사한 것인가? 라고 묻기 전에 과연 이 Business Intelligence 가 무엇인지 아주 아주 간단하게 살펴볼 필요가 있겠습니다. 

보통 Business Intelligenc 는 BI 라고 줄여서들 많이 이야기 합니다. BI 는 무엇을 지칭하는 것일까요?

한 BI 업체의 BI 가 할수 있는 일들 입니다. 여러가지를 할 수 있다고 자랑스럽게 이야기 하고 있습니다. 물론 저러한 일들을 할 수가 있겠죠. 나가는 돈은 별도로 하고 말이죠. 그렇다면 BI 가 하는 가장 본질적인 일이 무엇이냐? 이것만 이해하면 저런 것들은 그런 일의 연장이라고 볼 수가 있습니다. 

이게 바로 핵심이라고 볼 수가 있겠습니다. 뭐 속된말로 데이터 분석입니다. 이게 돈이 되느냐고 묻는 분들은 BI 업체의 존립 이유를 부정하시는 거라고 볼 수가 있습니다 ㅋㅋ. 게다가 생각보다 쉽지도 않습니다. 머리만 가지고 되는 일도 아닙니다. 저런 유의미한 데이터를 이끌어 내기 위해서 무지 많은 준비 작업을 거쳐야 하며 왜 그게 유의미한 데이타가 되는지 설명도 해야 합니다. 비싼 돈을 주기에 충분한 행위입니다. 

그러면 BigData 는 BI 네? 라고 이야기 할수도 있겠지만, 거기에 나아가서 만약 그렇다면 현존하는 BI 업체는 거의 다 BigData 로 진화를 했겠네? 라고 생각도 할 수 있습니다. 그러나 모든 업체가 그렇지는 않습니다. (진화하는 업체도 있습니다) 그러면 무엇이 다른 것인가? 

바로 이 3V에서 차이점이 존재합니다. 이것에 관한 자세한 내용은 예전에 제가 쓴 HBR 관련 포스트 (Big Data Management Revolution ) 에서 언급한 적이 있습니다. 

기존 데이타베이스로는 감당이 안되는 수준으로 용량들이 큽니다. 기가단위를 넘어선 페타단위의 데이타도 다룰 수 있습니다. 데이타가 커지면 지금의 기법으로는 당연히 호환이 안됩니다. 큰 데이타 단위에 맞춰서 동작하는 방식을 배워야 합니다. 

속도 입니다. 제 예전 글에서는 실시간에 근접해야 한다고 썼지만, 절대 실시간에 근접할 수가 없습니다. 많은 사람들의 예상과는 다르게 하둡베이스는 절대 시간이 실시간에 가깝지는 않습니다. 맵 리듀스에 올리고 잡(Job)을 분배하는 시간까지 포함한다면 실시간은 되지 않습니다. 그렇다면 무엇이 속도냐? 라고 질문을 던질 수가 있을 것입니다. 3박4일 걸리는 것이 8시간으로 줄수가 있고 , 8주 걸리는 것이 1주로 줄 수가 있습니다. 즉 단위가 큰 시간대를 줄이는 것이지 실시간에 근접하는 것은 아니라고 할 수가 있겠습니다. 

정말 다양한 데이터를 처리할 수가 있습니다. 예전과는 다르게 최근에 추가된 데이터 타입이라면 gps 를 들 수가있습니다. 다양한 자료들 다양한 데이타베이스들 다양한 D/W 들과 전부 연관되서 다루는 분야기 때문에 정말 다양성이 핵심입니다. 그리고 이미지, 동영상.. 등등 여러가지 데이터 타입들이 있습니다. 

그렇다면 왜 이리 BigData 는 화두가 되는 것인가? 하는 것입니다. 경영인들이 즐겨보는 HBR 이라는 잡지가 있습니다. 여기에는 경영잡지 답게 최신 IT 기술중 경영에 도움이 되는 기술은 종종 소개하고는 합니다. 대표적인 예로 지금 주제인 BigData 와 클라우드(Cloud) 가 있습니다. 

클라우드는 HBR 에 실리기까지 5년이 걸렸습니다. 사실 비용절감 과 서비스의 인구 밀도가 급격하게 변하는 경우 말고는 딱히 경영자들한테 매력적인 포인트는 아니였다고 저는 개인적으로 생각합니다. 그러나 빅데이터(BigData)는 마케팅에 활용이 될수도 있고 기업에서 새로운 방향의 통찰력(insight) 를 얻을 수가 있습니다. 그래서인지 이례적으로 3년이라는 시간안에 실릴 수 있었을 것이라고 봅니다. 

그래서 HBR 에서 나왔던 사례를 소개합니다.  시어스 홀딩스(Sears Holdings) 에서 했던 프로젝트입니다. 보시다 시피 자회사가 많은 시어스 홀딩스는 마트계열의 회사들을 여러개 소유한 회사입니다. 개별 개별 데이타가 얼마나 쌓이는지 상상하기도 힘들 정도입니다. 

그래서 시어스 홀딩스는 자사의 데이타들을 이용해서 고객 맞춤 프로모션을 진행하고 싶어합니다. 그런데 현행 시스템으로는 아무리 빨라도 8주가 걸린다고 보고가 올라왔다고 합니다. 그래서 왜 그리 오래 걸리나 조사를 하니 각각의 자회사들이 소유한 정말 방대한 데이타와 그 데이타가 저장되어 있는 데이타베이스 그리고 구성되어 있는 D/W 가 형태들이 다른게 문제였습니다. 그런데 이러한 맞춤 프로모션이 8주가 걸린다면 그것은 이미 현행화에 뒤진다는 것이 경영진의 생각이였고 이것을 적어도 1주정도로 줄여야 겠다고 결심했습니다. 

그래서 오라클에게 자문을 구했습니다. 이러 이러한 시스템을 구축해서 빠르게 고객 맞춤 프로모션을 진행하고 싶다. 오라클의 대답은 '가능하다' 였습니다. 다만 이 정도의 돈이 든다고 말을 했다고 합니다. 그 금액의 규모가 얼마인지는 전해지지 않지만 '천문학적인 돈이였다' 라던지 '그 돈이면 목적에 맞는 새로운 데이타베이스 시스템을 만들겠다' 라는 말로 보아 장난이 아닌 수준이였다는 것만 짐작할 수가 있습니다. 

그래서 시어스 홀딩스의 CTO 였던 필 쉘리(Phill Shelley) 는 2010년에 그 당시 거의 초창기 수준이던 하둡(Hadoop)을 이용해서 이 문제를 해결했습니다. 처음에는 이 일을 할 수 있는 사람을 찾을 수가 없어서 외주를 줬지만 그 다음에는 자사의 인력들이 배워서 충분히 해결할 수 있는 수준이 됐으며, 점점 더 분석 시간이 짧아지고 있다고 합니다. 게다가 오픈소스이기 때문에 시스템 구축비용은 거의 들지 않았으며 , 하둡은 로그(Log) 기반이기 때문에 데이타베이스의 포맷이 맞지 않는 것은 의미가 없었습니다. 모든 데이타를 로그로 변환해서 분석하면 그만이기 때문입니다. 

시어스 홀딩스 사례에서 잠깐 언급됐던 하둡(Hadoop)! 요즘 빅데이타 하면 빠지지 않고 등장하는 이름입니다. 그 이름에 대해서 언급하기 전에 구글이 빅데이타에 끼친 영향에 대해서 이야기를 하고 넘어가야 할 것입니다. 

바로 이 논문입니다. 구글에서 자신들이 쓰고 있는 검색 엔진의 인덱스를 저장하고 있는 시스템에 관한 논문을 발표했습니다. 2006년으로 알고 있는데요. 여기에는 정말 방대한 인덱스를 저장하기 위해서 어떻게 분산을 써서 내용을 나누고 그것을 어떻게 관리하는지 어떤 방식으로 구조화 시켜서 저장하는지에 관한 설명이 되어 있는 논문입니다. 여기에서 바로 모든 빅데이타(BigData) 플랫폼들이 시작됐습니다. 

구글의 논문을 보고 야후의 개발자가 생각해낸 개념이 바로 하둡입니다. 분산 저장방식에 관심을 가졌을 거라고 추측합니다. 그래서 야후에서 오픈소스 프로젝트로 시작하고 바로 아파치 재단으로 이동했습니다. 그리고 하둡은 2010년부터 꾸준히 빅데이타(BigData)를 논할 때 빠지지 않는 구성요소가 됐습니다. 그렇다면 대체 하둡의 핵심은 무엇일까? 

저는 그 핵심요소를 '분산'이라고 봅니다. 하둡은 핵심에 분산을 깔아놓구 있습니다. 데이타를 저장하는 방식에 분산을 적용한 것이 HDFS 고, 계산을 하는 방식에 분산을 적용한 것이 맵리듀스(Map Reduce) 입니다. 즉 다시 말하지만 '분산' 입니다. 핵심은 '분산' 

HDFS 는 하둡에서 데이타가 저장되는 핵심입니다. 자세한 부분에 관한 설명은 나중에 따로 할 예정이니 전체적인 레이아웃만 살펴보시면 됩니다. 한개의 네임노드(NameNode)와 그 네임노드가 다운됐을 때를 대비한 세컨드리 네임노드(Secondary Namenode) 가 존재하고 실제로 파일들이 일정 크기(Chunk)로 나뉘어서 저장되는 데이타노드(Datanode)가 다수개가 존재합니다. 이 데이타노드가 작게는 3개에서 많게는 수천개까지 늘어날 수가 있습니다. 어딘가에서 봤는데 (정확한 정보는 아닙니다) 페북은 4000여개의 노드를 사용하고 있다고 합니다. 

일반적인 파일시스템(FS:File Systems)에서 파일을 저장하는 방식과 너무 유사합니다. 파일이 저장되면 그 파일의 존재하는 OS 상의 위치와 실제로 하드디스크에 저장되는 물리적 위치로 나뉩니다. 그림에서 보이는 네임노드(Namenode) 가 OS 상의 위치에 해당한다고 보시면 편하고, 데이타노드(Datanode)에 쪼개서 저장되는 방식이 마치 하드디스크에서 물리적으로 데이타가 저장되는 모습에 해당한다고 보시면 됩니다. 안정성을 위해서 레플리케이션(Replication)을 둬서 물리적으로 2개 이상의 사본이 저장되서 비상상황 발생시 대응을 쉽게 할 수 있게 하지만 그 부분은 자세한 설명은 안하기로 하겠습니다. 

맵리듀스 입니다. 맵 리듀스는 분산 계산 플랫폼이라고 보시는게 가장 유력할 것입니다. HDFS 내에 존재하는 데이터를 맵-리듀스 어플리케이션을 만들어서 빠르게 계산하는 것이 그 목적입니다. 원래는 잡트래커(Job tracker) 와 태스크 트래커(Task Tracker) 였으나 YARN 에 들어오면서 그림과 같이 리소스 매니져 (Resource Manager)와 노드메니져(Nodemanager) 로 바꼈습니다.  

맵리듀스 프레임워크에 맞춰서 작성한 어플리케이션을 올리면 리소스 매니져가 몇개 노드에서 작업을 수행할지 나눠서 배포하고 노드매니져가 작업을 해서 그 결과가 출력되는 형식을 취합니다. 사실 더 자세하게 보자면 복잡하지만 핵심만을 설명한 것입니다. 결국 여기서도 알아야 할 것은 어플리케이션 = 잡 (Job) 을 '분산' 시켜서 처리한다는 것입니다.

그러면 빅데이타 계의 다른 이슈거리인 노에스큐엘(NoSQL) 입니다. SQL 과는 다르다는 정도로 받아들이면 될 것입니다. 일반적인 Row 기준적인 RDBMS 와는 다르게 대부분의 NoSQL 은 key-value 나 Column 베이스 입니다. 이런것의 차이는 추후에 설명하기로 하고요. 일반적인 RDBMS 와의 가장 큰 차이를 보이는 부분이 Relation 이 없기 때문에 NoRel (No Relation)으로 바꿔야 한다는 소리도 있습니다. 

대표적인 컨셉이자 제일 유명한 것인 하베(HBASE) 가 있습니다. 하둡의 서브 프로젝트에서 시작해서 지금은 당당하게 대표 프로젝트로 자리 잡았습니다. 

NoSQL 은 설명할때 제일 힘든 것이 그게 뭐냐라는 질문에 딱히 대답하기가 어렵다는 점입니다. 그래서 제가 제일 쉽게 설명하는 방법은 바로 거대한 구조화된 데이타 저장소 라는 개념입니다. HDFS 는 파일 시스템 개념이라서 밑바닥에 깔려있는 것이고 이것은 그 위에서 구조화된 데이타를 저장하는 저장소 개념입니다. 따라서 구글의 논문이자 구글에서 사용하고 있는 BigTable 에 가장 유사한 형태를 취하고 있습니다. 이 하베는 페이스북(FaceBook)의 메시징 서버를 구현하는데 사용되서 유명합니다. 페이스북이 투자하고 키워오던 카산드라(cassandra)를 대신해서 이용되었기 때문입니다. 

하베의 구조도 입니다. 역시 어디선가 가져왔습니다. 이 한장의 그림으로 정말 하베의 모든것이 설명되고 있다고 보시면 됩니다. 

하베는 분산의 마스터 노드에 해당하는 HMaster 와 분산의 슬레이브 노드에 해당하는 HRegionServer 로 나뉩니다. 이 마스터와 슬레이브 방식을 관리하는 것이 바로 주키퍼(ZooKeeper) 입니다. 그래서 사용자의 클라이언트는 주키퍼를 통해서 마스터(HMaster)에 접근해서 데이터를 추가(insert)하고 읽어오는 작업을 하면 그 작업의 내용을 마스터는 리젼서버(HRegionServer) 에 명령을 내려서 수행하는 방식입니다. 그리고 저장되는 내용은 실제로 Distributed File System 을 통해서 하둡(Hadoop) 에 저장됩니다. 하둡은 전통적으로 파일을 저장하는 방식대로 데이타노드(Datanode) 에 개별 개별의 조각으로 나누어서 저장합니다. 

하베에서 데이타를 저장하는 방식에 대한 설명입니다. 한개의 테이블이 있다면 그 안에 컬럼 패밀리가 다수가 존재하고 그 컬럼패밀리 '군'에 속하는 개별적인 컬럼들이 존재하는 형태 입니다. 상식적으로 RDBMS 방식에 익숙하다면 익숙하지 않은 방식이라고 보일 텐데요. 실제로 컬럼(Column) 방식이 어떤식으로 데이타가 저장되는지 보겠습니다. 

Row 방식과 Column 방식의 차이입니다. 여러값이 들어가지는 않고 각각의 값하고 Column 방식으로 정렬되어 있다는 느낌을 주지요? 거기다가 각각의 Column 과 매칭되는 id 값이 전부다 존재합니다. 이래서 NoSQL 은 보통 Key-Value 방식이라는 이야기를 합니다. 그림에 보다 시피 Key(id 값) 과 그것에 해당하는 각각의 값들이 존재합니다. 

여기까지가 대략적으로 빅데이타라고 말해지는 것들의 개략적인 설명입니다. 개략적인 설명만 듣고 잘난척은 가능하지만 실제 적용하고는 오만년 광년쯤 떨어진 이야기라는 것을 알 수가 있을 것입니다. 그러면 실제로 준비하는 것에 관한 이야기를 들어보기로 합니다. 정말 필요한 순서상으로 따라하기식 설치는 따로 매뉴얼로 작성할 예정입니다.

그럼 일단 하드웨어 준비사항입니다. 첫 항목은 최근에 유명한 라즈베리 파이로 설치해서 하둡을 해볼까 라는 소리를 들어서 입니다. 물론 설치는 가능합니다. 대신 제가 항상 주장하는 '설치를 해서 뭘 해볼껀데?' 라는 질문에 대한 대답하기가 힘듭니다. 물론 각각의 노드매니져나 데이타노드 구동 메모리를 256 메가나 128 메가로 낮추면 돌릴 수 있지 않을까 하는 분들도 계실지 모릅니다. (라즈베리 파이는 256메가나 512메가 메모리를 가지고 있습니다) CDH5 의 기본 설정을 데이타노드에 1기가 노드매니져에 1기가 입니다. 그래서 최소 2기가 이상의 메인메모리가 필요합니다. 2 코어가 필요하다는 이유도 어찌보면 당연합니다. 물리적 노드 한대에 데이타노드와 노드매니져가 함께 있으니 효율성을 극대화 하기 위해서 필요합니다. 

주키퍼(Zookeeper) 권장 사항은 홀수대입니다. 홀수인 이유는 노드중에 한대가 죽었을 때의 대처가 좋기 위해서라는데 (사실 그 이유는 자세히 살펴보지는 않았습니다) 시키는대로 하는 것이 좋겠죠? 

그리고 실제로 클러스터(Cluster)를 구현하기 위해서는 최소 복수개의 노드가 필요하니 (거기에 주키퍼 권장사항) 3대 정도가 필요합니다. 

리눅스가 하둡을 돌리는 최고의 OS 라는것은 이미 다 알려져 있는 내용입니다. CentOS 나 우분투(Ubuntu) 어떠한 것도 가능합니다. 그런데 저는 우분투를 추천합니다. 단 CDH5 를 설치할려고 하면 우분투 14.04 버젼은 주키퍼 설치에 실패하기 때문에 13.04 나 12.04를 추천합니다. 참고로 저는 14.04를 설치했기 때문에 주키퍼를 직접 설치해줬습니다. 자바는 1.7 버젼을 추천하더군요. 저는 혹시나 몰라서 Oracle 용 자바 (Java)를 설치해줬습니다. 찾아보면 우분투에서 apt-get 으로 자바를 설치하는 방법이 있으니 참고하셔서 설치하면 됩니다. 

하드웨어와 기본적인 OS가 준비가 됐다면 어떤 하둡 구현체를 쓸것인가? 하는 문제가 남아 있습니다. 

최근 빅데이타 컨설팅 업계의 삼대장이라고 하면 클라우데라 (Cloudera), 맵알(MapR), 호톤웍스(Hortonworks) 마지막 업체는 잘 모르니 차치하고라서도 , 각각은 많이 발전했으면서도 확연히 차이점이 존재합니다. 

클라우데라는 자신들이 생각하는 방식으로 하둡과 그에 딸려오는 제반 인프라를 설치하기 쉽게 만들어 뒀습니다. 각각을 전용 계정들도 만들게 하며 서비스 방식으로 띄울 수 있게 모든 것을 체계화 했습니다. 게다가 환상적으로 쉬운 (그렇지만 영어입니다) 매뉴얼을 제공해서 열심히 따라하면 손쉽게 (그나마) 거의 모든 빅데이타 인프라를 설치해 볼수가 있습니다. 게다가 아파치 라이센스기 때문에 상업용으로도 이용할 수가 있습니다. 다만 자신들의 입맛에 바꿔놓은 부분이 많기 때문에 클라우데라가 지원하지 않는 솔루션을 설치해 볼려고 하면 한방에 안 깔리는 경우가있습니다. (예를 들면 타조- Tajo ) 

우리나라에서 로그가 많이 나오기로 유명한 카카오에서 분석용 기반 플랫폼으로 사용한다고 합니다. 

제가 사용해본것은 클라우데라지만 MapR 에 관한 이야기는 많이 들었습니다. 하둡에서 시간이 걸리는 부분을  C/C++ 로 변경을 해서 속도 향상을 가지고 왔다고 합니다. JVM 의 한계를 넘어섰는지는 잘 모르겠습니다. 다만 인터페이스가 여전히 자바 기반이기 때문에 기존의 다른 하둡 기반 인프라와 궁합이 잘 맞는다고 합니다. 

그러나 이러한 최적화는 가장 시간이 걸리는 부분은 결국 잡을 나눠서 어떻게 할 것인지에 영향을 미칠 가능성이 매우 크기 때문에 속도향상은 어느정도 있겠지만 그 부분이 절대적이라고 볼 수는 없을 것 같습니다. 게다가 하둡이 어느정도 버젼이 안정화 된 이후에 C/C++ 작업이 들어가는지 (어떻게 보면 당연한 것이라 볼 수가 있을 것입니다) 버젼업이 생각보다 빠르지가 않다고 합니다. 

게다가 유료!! 라고 합니다. 자세한 스펙은 조사하지 않았으나 영업자료에 그리 써 있었다고 합니다. 머신 노드 1기당 800만원이라는 소리가 있으니 보통 작은 은행권에서는 보통 15-20대 가량을 쓰니 소프트웨어 가격만으로도 돈이 적당히 들어갈 것으로 보입니다. 

왜 호톤웍스가 없는지는 묻지 말기로 하고.. 어떤 방식을 추천할 것인가? 에 관해서는 지금 나와 있는 빅데이타 플랫폼을 다 이해하가면서 설치해보고 싶다면 당연히 각각의 컴포넌트를 아파치 재단에서 받아서 설치하는 것을 추천합니다. 지금 속도가 괜찮다고 평가되는 타조(Tajo)는 CDH 와 뭔가 안맞는지 설치가 안됩니다. - 가장 손쉽게 생각하자면 하이브(Hive)의 개량방식이라고 평가받는 솔루션이 타조 (Tajo)와 임팔라(Impala)가 있습니다. 둘다 빠른 동물을 형상화 했지요? 그런데 타조는 국내의 오픈소스 개발이 주력으로 개발됐습니다. 임팔라는 CDH 가 밀고 있습니다. SKT 빅데이터 팀에서 여러 오차를 겪고 나서 타조를 선택했다는 글을 본적이 있는데 그 논리대로라면 타조가 좋을꺼 같아서 설치할려고 했더니 CDH 는 임팔라를 민단 말이죠.. 그러니 타조를 지원할 일이 없는 것입니다 ㅎㅎ. 

그렇다고 CDH 가 나쁘다는 것은 절대 아닙니다. 귀찮은 설치과정을 쉽게 만든 것만으로도 CDH 는 쓸만합니다. 일일이 설치하는 것을 공부라고 여길 필요가 없는 분들! 설치하고 난 뒤에 데이타를 만지작 거리는 것이 진정한 빅 데이타다!! 라고 생각하시는 분들 (열렬하게 공감합니다) 은 CDH5 를 강력추천합니다. 

그렇다면 빅데이타라는 것을 써봤다고 말할려면 무엇을 설치해야 하는 것인가? 이것이 궁금할 수가 있습니다. 항상 남에게 해봤다고 말해볼 수 있을만큼만 하면 됩니다. 

이 세가지가 기본입니다. 사실 가장 왼쪽의 주키퍼(ZooKeeper)는 설치가 안되면 하둡도 설치가 안되는 것이니 필수요소이기도 합니다. <-- 이건 클라우데라 매뉴얼에 있는 내용이고, 실제로 소스를 직접 받아다 설치할 경우에는 주키퍼와 하둡은 상관 관계가 없다고 판명되었습니다. 그리고 하둡이 설치가 되지 않으면 처음이자 끝도 없는 것이지요. 그리고 하이브 입니다. 하이브는 사실 초창기때에는 알기도 쉽지 않았습니다. 그 당시는 피그(Pig)라는 것만 있었습니다. 게다가 왠만하면 전부 맵리듀스 프로그램을 직접 짜서 분석을 하는 것이 일반적이였습니다. 그러다가 일일이 할 때마다 프로그램을 짜는 것이 너무 불편하다는 이야기가 나와서 등장한 것이 하이브(Hive) 입니다. 하이브는 쉽게 말하면 sql 로 분석 구문을 만들면 자동으로 그 내용을 맵-리듀스로 변경해서 하둡의 맵-리듀스 프레임워크에 태워서 분석을 가능하게 해주는 괜찮은 솔루션입니다. 귀찮은 프로그램을 일일이 짤 필요 없이 탑재된 로그 데이타를 분석할 때 강력함을 발휘합니다. 

자 그러면 실제 사례를 보기로 합니다. 

그러면 왜 하이브(Hive)를 쓰는 것인지는 저번에 설명했지만 다시 설명하자면 매번 반복되는 불편함을 제거하기 위해서 시작한 것으로 알고 있습니다. MySQL 의 문법과 기본적인 것은 호환이 되지만 100% 는 아닙니다. 예를 들면 자료형 자체가 많지 않습니다. 자주쓰는것은 INT 와 STRING 입니다. 한가지 여러가지 쿼리를 돌리다가 알아낸 사실입니다. 하둡 관련 플랫폼의 특징은 결국 자바 환경이라는 것인데, 자바의 약점을 그대로 가지고 있습니다. 바로 정해진 힙의 크기를 넘어가면 속된말로 '터진다'는 점입니다. 예를 들면 Group by 키워드를 사용하면 Map 의 영역입니다. 그래서 Map 을 돌리다가 멈추면서 힙(heap)이 터집니다. (자주 보던 그 키워드가 나옵니다. 터졌다고 ㅎㅎ) 그리고 Join 은 reduce 의 영역이라  reduce 에서 힙(heap)이 터집니다. (무식하게 10억건 이상되는 데이타를selfJoin 걸었기 때문이죠 ㅎㅎ) 게다가 이게 가능해야 분석가가 한발을 거칠 수가 있습니다. 분석할때마다 코딩하셔야 합니다. 라고 하면 분석 전문으로 하시는 분중에서 가능한 분이 몇명이나 있겠습니까? 

실제로 POC 를 준비했던 사례를 설명하겠습니다. 어떤 회사인지 말을 못합니다. (뭐 당연하겠죠? ㅎㅎ) 준비 과정에서 CDH5 버젼으로 각각 설치했습니다. 우분투( Ubuntu 14.04 ) 버젼으로 설치했기 때문에 주키퍼 (ZooKeeper)설치에 문제가 있었지만 직접 설치하는 것으로 해결하고 나머지 부분은 CDH 부분이 무난하게 설치 됐습니다. (하둡, 하이브, 하베 세개 다 설치했지만 하베는 사용안해서 지웠습니다) 물론 하드웨어는 제각각의 스펙을 가지고 있었고 그중 제일 괜찮은 서버에 네임노드(Namenode)를 설치해줬습니다. 증권사에서 준 데이타는 10개월치 13억건의 데이타 총 용량 300기가에 해당했습니다. (진짜 BigData 였습니다 ㅋㅋㅋ) 내준 숙제는 과거 데이타 중에 부정한 거래가 일어난 것을 잡는 케이스 였습니다. 샘플 600건을 POC 전날 제공받고 , 당일에는 300기가의 데이타를 제공해서 주어진 5시간 안에 전 데이타를 올리고 그중에서 분석해서 부정사례를 발견하는 것이 숙제였습니다. 이것을 제대로 했는지의 여부는 비밀입니다 ㅋㅋ 

데이타가 담겨 있는 USB 하드는 exFat 형태로 제공됩니다. 이걸 착각해서 ext 타입(ext3, ext4)으로 착각해서 드라이버 설치하는데만 한시간 걸렸습니다. 인터넷이 되면 한줄로 받는 명령을 인터넷이 안되는 환경이라 노트북에 프락시를 설치하고 핸드폰으로 테더링 걸고.. 난리도 아니였습니다. ㅜ.ㅜ 이게 첫번째 실수였습니다. 

그리고 데이터 전송을 한달별로 그리고 일자별로 정리가 되어 있는 자료여서 이것을 멀티프로세싱을 이용해서 한꺼번에 올렸습니다. 무지하게 걸리더군요.. 한달에 40분가량씩? 답이 도저히 안나오는 시간대라 이거 정말 업로드 가능한건가? 고민하다가 개별 개별로 올리기 시작했습니다. 1일치 올라가는 시간이 3-4초 늦어봐야 10초가 걸리더군요.. 이건 정말 무식해서 발생한 일이였습니다. 어차피 하드에 쓰는 속도 차이가 있는 것인데 멀티 프로세싱으로 동작을 시키면 물리적 하드에 쓰기 위해서 헤드가 왔다리 갔다리 하면서 시간이 오히려 더 걸리는 것이였습니다. 그래서 멀티프로세싱이 만능이 아니라는 옛말을 이제야 실감하게 되더군요. 전부 다 올려서 마트를 구성하는 건 10분정도 걸리고 , 전체 카운트 계산은 20초가 안 걸리더군요. 

준비과정에서 있었던 일을 포함해서 설명을 드리자면, 네트워크의 속도가 아주 중요합니다. 일반적인 100M bps 스위치를 기가 스위치로 바꾸고 네트워크 카드가 2개 있는 것을 전부 1개로 본딩(Bonding: 물리적인 2개의 네트워크 카드를 마치 1개 인양 묶어주면 HDD 레이드하는 것처럼 속도가 빨라짐)으로 묶어주니 업로드 속도가 거의 9배 가까이 상승하고 , 쿼리 속도가 거의 4배 상승했습니다. 

그리고 자바환경이기 때문에 역시 튜닝포인트는 존재합니다. 데이타 건수가 너무 많아서 올라가지 않는 문제는 없었기 때문에 거의 쿼리를 던지면 힙이 터지는 문제가 대부분입니다. 그래서 그런 쿼리를 처리하는 것이 노드매니져(nodemanager)의 힙 메모리 사용량을 변경하는 것으로 튜닝이 가능합니다. 기본은 1기가로 되어 있기 때문에 4기가로 올린 것만으로 안돌아가던 쿼리들이 돌아가기 시작하더군요. 만약 8기가 단위의 서버들을 이용해서 클러스터(Cluster)를 구성한다면 노드매니져의 메모리 튜닝만으로도 150만개의 데이터의 셀프조인(self join) 계산인 대략 2조개의 데이터까지 처리가 가능할 것으로 보입니다. 

제가 지금 까지 빅데이타가 우리나라에 소개되기 시작한 초창기부터 스터디하고 실제로 적용해보면서 느꼈던 단상을 말하자면 빅데이타가 만능이 절대 아니라는 것입니다. 사람들은 절대 만능이 아니지라는 말에 격한 공감을 하지만 실제로 이야기 하는 것을 보면 만능인것처럼 기대한다는 것입니다. 그러나 힙도 터지기도 하고 아무리 분산이라고 하지만 처리할 수 있는 용량의 한계는 분명히 존재합니다. 그래서 확장도 해야하고 머신 노드 자체를 늘려야 할 필요도 존재합니다. 

그리고 기본적으로 데이타에서 통찰력을 이끌어 내야 하는 부류이기 때문에 BI 와 같이 컨설팅의 영역에 가깝습니다. 개별 개별 정리할려고 하는 로그가 일정하지 않기 때문입니다. 비정형 데이터를 정리할 필요가 있는 것이지요. 그렇기 때문에 분석가가 달려들려고 해도 이러한 부분이 장벽으로 존재합니다. 즉 인프라 (Infrastructure)에 대한 이해도 필요합니다. 그렇기 때문에 원론적으로 말하는 데이타 해커(Data Hacker: 데이터를 수집하고 분석에 알맞게 정리하고 편하게 분석할 수 있게 구성할 수 있는 사람)와 데이타 과학자(Data Scientist: 데이터를 분석하고 분석된 데이타로부터 통찰력을 가져올 수 있는 사람)이 같이 필요합니다. 그래서 적어도 빅데이타 업체라는 소리를 할려면 이 두가지 종류의 사람이 다 필요합니다. 

그렇기 때문에 빅데이타쪽은 인프라가 필수적입니다. 일단 인프라를 설치하고부터가 시작입니다. 설치하고 데이타를 올리고 분석을 시작하면 갖가지 문제점들이 마구 마구 튀어나올 것입니다. 하지만 그러한 것들이 터져준다면 또한 행복한(?) 일일것입니다. 그러한 것들을 잡아나가는 것이 바로 발전의 시작이기 때문입니다.