빅 데이터의 열쇠 하둡 총정리 3 RDBMS에서 하둡으로 가는 길

[대바륑]

2012.01.18  Brian Proffitt | ITWorld

하둡이 적합하다고 생각되는 관리자가 있으면 데이터 프레임워크로 구성된 오픈소스 소프트웨어를 다운로드받아 비교적 쉽게 시

험해볼 수 있다.
 
지금까지 하둡 총정리를 통해 하둡을 관리하기 위해 갖춰야 하는 것들, 그리고 하둡을 사용하는데 따른 이익과 문제점들을 알아보

았다.
 
이번 마지막 회에서는 기존의 RDBMS에서 하둡으로 옮겨가는데 따른 비용과 관계된 기술들을 살펴보고, 기업들이 현재 어떻게

하둡을 설치하는지, 하둡 데이터를 다른 어떤 RDBMS보다 훨씬 빠르고 저렴하게 분석하는데 사용할만한 툴 등을 살펴 볼 것이다.
  

새롭게 부상하는 기술들, 특히 오픈소스의 기술들이 그렇듯, 하둡 역시 원하는 IT 업체들이 직접 시험함으로써 이에 따른 이익을

누리고 있다.
 
현재 하둡은 기술 미디어와 컨퍼런스 등에서 더 많이 주목받았으며, 이에 따라 최고 경영진들이 하둡의 열풍에 덩달아 뛰어들어

하둡이 기업 비용을 얼마나 줄여 줄 수 있는지 직접 보고 싶어한다.
 
하둡의 도입에는 현장에서부터(Bottom up) 혹은 경영진으로부터(Top down) 시작되는 두 가지 방식이 있는데, 지금부터 도입 방

식에 대해 자세히 들여다보자.
 
바텀 업 방식, IT 부서가 주도
그림자 같은 IT는 기업에게 있어 하나의 축복이거나 혹은 골칫덩어리다. 하지만 종종 실험적인 구성 혹은 샌드박스(sandbox) 구

성이 결국에는 기업에게 엄청난 이익을 안겨주곤 했다. 한 예로 리눅스는 21세기 초에 이런 그림자 IT에 의해 성장한 수혜자다.
 
아파치 소프트웨어재단(Apache Software Foundation)의 아파치 하둡 부사장 아룬 머시는 "이제 하둡 차례"라고 주장했다.
 
머시는 "바텀 업 방식의 경우 보통 한두 명의 엔니지어들이 하둡을 다운로드받아 하나의 노드 혹은 4~5개의 노드로 구성된 조그만

클러스터에 하둡을 설치한다"고 설명했다.
 
이후에는 거의 같은 패턴이라고. 먼저 하둡 클러스터를 사용하는 직원들이 그 툴셋의 가치를 알기 시작한다. 그러면 기업의 다른

부서에서도 그들만의 하둡 클러스터를 설치할 것이다.
 
결국에는 하둡의 가치가 크게 늘어나고 그 아래 깔려있는 분산형 파일시스템의 확장성 덕분에 각각 분리되어 있는 하둡 클러스터

들이 대략 50~60 노드 정도로 이뤄진 커다란 단일 클러스터로 합쳐진다.
 
머시에 따르면 야후에서 처음 하둡을 받아들일 때에도 바로 이 과정들이 벌어졌다. 각 부서들과 애플리케이션에게 하둡의 가치가

명료해지기만 하면, 하나의 커다란 하둡 네트워크에 모든 것들을 결합시키는 것이 분명 이상적이다.
 
물론 페이스북이나 야후처럼 각각 1만 개 혹은 5만 개의 노드로 이뤄진 대규모 시스템을 배치해야 할 기업은 많지 않을 것이다. 그

러나 일반 원칙은 여전히 동일하다.

머시의 최근 고용주인 호튼웍스(Hortonworks, Inc)도 탑 다운 방식으로 도입했다. 호튼웍스는 2011년 6월 말 머시와 야후 하둡 팀

의 몇몇 직원들에 의해 설립됐으며 훈련, 지원, 배치 서비스 등과 오픈소스 하둡 제품들을 제공한다.
 
머시의 설명에 따르면, 호튼웍스는 새로운 잠재 고객과 일하게 될 것이며 고객들의 요구에 따른 몇 가지 권고사항들을 만들 수 있

다. 그들은 개념 증명을 위해 20 노드에서 100 노드 수준으로 소규모 하둡 클러스터를 어디든 배치해볼 것이며, 이를 통해 고객들

은 스스로 하둡의 가치를 볼 수 있을 것이다.
 
이런 공식적인 프로세스는 클라우데라(Cloudera)나 맵알(MapR) 등의 다른 하둡 업체들이 제공하는 것과 유사하며, 따라서 하둡

에 대한 자문과 지원을 얻고 싶다면 여기저기에서 강력한 옵션들을 찾을 수 있을 것이다.
 
스쿱(Sqoop)을 잡아라
스스로 하든 혹은 도와줄 누군가를 고용하든 간에 분명 어느 시점에서는 현재의 저장소에서 하둡으로 데이터를 옮겨가야 할 것이

다.
 
특히 RDBMS에서 옮길 경우 클라우데라의 스쿱(SQL-to-Hadoop)이야말로 최상의 툴이다. 스쿱은 명령어 애플리케이션으로 개별

테이블들이나 전체 데이터베이스들을 하둡 분산형 파일시스템(HDFS)으로 불러올 수 있다.
 
스쿱은 DB인풋포맷 자바 커넥터(DBInputFormat Java connector)를 사용하는데 이는 맵리듀스(MapReduce)가 마이에스큐엘

(MySQL)과 포스트그레스큐엘(Postgresql), 오라클 및 다른 인기 있는 데이터베이스들이 기반한 JDBC 인터페이스를 통해

RDBMS의 데이터를 불러올 수 있다.
 
스쿱도 맵리듀스에 필요한 자바 클래스들을 생성해, 테이블 행을 분리된 정보 영역들로 역직렬화(deserialize)함으로써, 데이터와

상호작용할 수 있다. 뿐만 아니라 스쿱을 이용해 RDBMS 데이터를 곧바로 하이브 데이터 웨어하우스(Hive data warehouse)로

불러올 수도 있다.
 
이런 기능 덕분에 사용자들이 하둡으로의 데이터 마이그레이션에 대비해 준비해야 할 일들은 거의 없으며, 데이터 중복제거나

RDBMS 유지보수 등 상식적인 일들만 해주면 된다.
 
하이브(Hive)를 살펴보라
이번 연재 기사의 첫 회에서도 설명했듯 하이브는 하둡 프레임워크의 일부분으로 분석가들은 이를 이용해 HDFS 내에서도 데이터

구조화 및 데이터 쿼리를 수행할 수 있다. 분석가들은 하이브 쿼리언어(Hive QL)을 이용해 데이터를 요약하고, 쿼리를 수행하고,

분석할 수 있으며 이 언어는 기존의 SQL과 매우 유사해 별로 어렵지 않게 사용할 수 있다.
 
하이브는 또한 하이브 쿼리언어가 필요한 정보를 제공할 수 없다고 판명된 경우, 맵리듀스 프로그래머들이 직접 그들이 만든 데이

터 매퍼(data mapper)와 데이터 리듀서(data reducer)를 불러오게 할 예정이다.
 
단 하이브를 고려할 때 다음의 한 가지를 주의해야 한다.
하둡은 일괄 처리 시스템(batch processing system)이기 때문에 매우 높은 지연시간을 가지는 하이브 쿼리들로 옮기는 과정에서

아주 높은 지연시간을 가진다(몇 초가 아니라 몇 분이 될 수도 있다).
 
따라서 하이브는 실시간 프로세싱에 적합한 시스템이 아니다. 실시간 프로세싱이 필요하다면 아파치 카산드라(Apache

Cassandra)를 이용하는 편이 좋다. 카산드라는 오픈소스 분산형 데이터베이스 관리 시스템으로 실시간 요구들을 처리하는데 훨

씬 적합하다.
 
하둡으로 가는 길
하둡으로 데이터 마이그레이션하는 경로는 기업의 필요에 따라 다양할 것이지만, 하둡은 분명 엄청난 가치를 제공할 것이다.
 
하둡은 엄밀한 의미에서 빅 데이터에 국한되지 않는다. 더 저렴한 저장공간을 필요로 하고 엄청난 양의 데이터를 효율적으로 분석

하고자 하는 기업이라면 어디든지 사용할 수 있다. 혹시 하둡이 필요하지 않나? editor@itworld.co.kr
 
*Brian Proffitt는 베테랑 리눅스 및 오픈소스 저널리스트이자 애널리스트로 클라우드, 가상화 및 소비자 IT에 대한 다년 간의 경력

을 가지고 있다.

출처 http://www.itworld.co.kr/news/73750/%EB%B9%85+%EB%8D%B0%EC%9D%B4%ED%84%B0%EC%9D%98+%EC%97%B4%EC%87%A0+%ED%95%98%EB%91%A1+%EC%B4%9D%EC%A0%95%EB%A6%AC+3+RDBMS%EC%97%90%EC%84%9C+%ED%95%98%EB%91%A1%EC%9C%BC%EB%A1%9C+%EA%B0%80%EB%8A%94+%EA%B8%B8