'진화하는 하둡 툴을 한눈에' 빅 데이터 처리를 위한 18가지 필수 도구

하둡(hadoop) 많은 사람들이 맵/리듀스 도구를 통틀어 하둡이라고 하지만, 실제로 하둡은 그 중앙에 존재하는 작은 코드 조각이다. 자바 기반 코드인 하둡은 로컬에 저장된 데이터에 대해 함수를 실행하면서 작업자 노드를 동기화하고, 이러한 작업자 노드의 결과가 집계 및 보고된다. 첫 번째 단계는 “맵”이고, 두 번째가 “리듀스”다. 하둡은 로컬 데이터 스토리지 및 동기화에 대한 추상화를 제공함으로써 프로그래머가 데이터 분석을 위한 코드를 작성하는 데 집중할 수 있게 해준다. 나머지는 하둡이 처리한다. 하둡이 작업을 분할하고 예약한다. 물론 오류 또는 결함도 발생하는데, 하둡은 개별 시스템별로 결함을 피해가도록 설계된다. 코드는 아파치 라이선스로 배포되며 hadoop.apache.org에서 받을 수 있다.

암바리(Ambari) 하둡 클러스터를 설정하려면 반복되는 작업이 상당히 많이 필요하다. 암바리는 표준 구성 요소로 클러스터를 설정하기 위한 웹 기반 GUI와 마법사 형식의 스크립트를 제공한다. 암브리를 구성하고 나면 하둡 작업 클러스터의 프로비저닝, 관리, 모니터링이 쉬워진다. 위 이미지는 클러스터를 시작한 후의 화면 중 하나다. 암바리는 아파치 인큐베이터 프로젝트이며 호튼웍스(Hortonworks)에서 지원한다. 코드는 이곳(http://incubator.apache.org/ambari/)에서 다운로드할 수 있다.

HDFS(하둡 분산 파일 시스템) 하둡 분산 파일 시스템은 여러 노드로 데이터 컬렉션을 분할하면서 복제를 사용해서 노드 장애를 복구하기 위한 기본적인 틀을 제공한다. 대용량 파일들은 블록으로 분할되고, 한 파일의 모든 블록을 여러 노드가 보유할 수 있다. 아파치 문서에서 발췌한 위 이미지는 여러 노드로 어떻게 블록이 분산되는지 보여준다. 이 파일 시스템은 내결함성과 높은 처리량을 결합하도록 설계됐다. 블록이 로드되면서 안정적인 스트리밍을 유지하는데, 일반적으로 지연을 최소화하기 위해 캐시는 되지 않는다. 기본 모델은 로컬에 저장된 대량의 데이터를 처리하는 긴 작업에 알맞다. 이는 “연산을 이동하는 것이 데이터를 이동하는 것보다 싸다"는 프로젝트 모토와도 잘 맞아떨어진다. HDFS도 아파치 라이선스에 따라 배포(http://hadoop.apache.org/)된다.

HBase 데이터가 큰 테이블로 떨어지면 HBase가 이 데이터를 저장하고 검색하고 여러 노드에 걸쳐 자동으로 테이블을 공유하여 맵리듀스 작업이 로컬에서 실행될 수 있도록 한다. 수십억 개의 데이터 행이 입력되고 나면 로컬 작업에서 이 행을 쿼리할 수 있다. 코드는 완전한 데이터베이스의 전체 ACID 보장을 제공하지 않지만 일부 로컬 변경 사항에 대한 제한적인 보장을 제공한다. 단일 행의 모든 변화는 함께 성공하거나 실패한다. 구글의 빅테이블(BigTable)과 자주 비교되는 이 시스템은 hbase.apache.org에서 찾을 수 있다. 위 이미지는 HBase에서 사용하기 위한 GUI 클라이언트인 HareDB의 스크린샷이다.

하이브(Hive) 데이터를 클러스터로 가지고 오는 것은 시작일 뿐이다. 하이브는 HBase의 모든 파일에서 비트를 추출하는 프로세스를 규칙화한다. 파일 속으로 들어가 코드에 필요한 조각을 끄집어내는, SQL과 비슷한 언어를 제공한다. 데이터는 표준 형식으로 도달하며, 하이브는 이 데이터를 쿼리를 위한 스태쉬로 바꾼다. 위 이미지는 테이블을 만들고 데이터를 추가하고 정보를 선택하기 위한 하이브 코드를 보여준다. 아파치 프로젝트(http://hive.apache.org/)에서 다운로드할 수 있다.

스쿠프(Sqoop) SQL 데이터베이스에 저장된 데이터에 묻혀 있는 것을 하둡으로 가져오려면 약간의 수작업이 필요하다. 스쿠프는 기존 데이터베이스에 있는 정보로 채워진 대용량 테이블을 꺼내 하이브 또는 HBase와 같은 도구에서 제어할 수 있게 해준다. 스쿠프는 테이블과 데이터 스토리지 계층 사이의 매핑을 제어하는 명령줄 도구로, 테이블을 HDFS, HBase 또는 하이브를 위한 구성 가능한 조합으로 변환한다. 아파치 문서에서 발췌한 위 이미지는 기존 리포지토리와 노드의 하둡 구조 사이에 위치하는 스쿠프를 보여 준다. 최신 안정화 버전은 1.4.4이며 버전 2.0이 원활하게 진행 중이다. 두 버전 모두 아파치 라이선스에 따라 sqoop.apache.org에서 받을 수 있다.

피그(Pig) 하둡이 찾을 수 있는 형태로 데이터가 노드에 저장되고 나면 그때부터 재미있는 부분이 시작된다. 아파치의 피그는 데이터를 훑고 지나가며 피그 라틴(Latin)이라는, 데이터 처리를 위한 추상화가 주축인 자체 언어로 작성된 코드를 실행한다. 이 구조는 클러스터에서 병렬로 실행하기 쉬운 알고리즘으로 사용자를 안내한다. 피그에는 데이터 애버리징, 날짜 처리 또는 문자열 간의 차이점 발견과 같은 일반적인 작업을 위한 표준 함수들이 있다. 이 함수들로 부족한 경우 직접 함수를 작성할 수 있다. 위 이미지는 아파치 문서에서 발췌한 세부적인 도표로, 사용자가 직접 만든 코드와 피그의 코드를 합쳐서 데이터를 마이닝하는 방법을 보여준다. 최신 버전은 pig.apache.org에서 받을 수 있다.

주키퍼(ZooKeeper) 하둡이 여러 대의 시스템에서 실행되는 경우 클러스터를 제대로 활용하기 위해서는, 특히 일부 시스템들이 체크아웃을 시작할 경우 질서가 필요하다. 주키퍼는 클러스터에 계층 구조와 같은 파일 시스템을 적용하고 시스템에 대한 모든 메타데이터를 저장해서 여러 시스템의 작업을 동기화할 수 있도록 한다. (위 이미지는 간단한 2계층 클러스터를 보여준다.) 이 문서는 프로듀서-컨슈머 큐와 같은, 데이터 처리를 위한 여러 표준 기법을 구현해서 올바른 순서대로 데이터를 자르고 정리하고 거르고 정렬하는 방법을 보여준다. 노드들은 주키퍼를 사용해서 서로에게 작업 완료 신호를 보내 다른 노드가 해당 데이터를 사용한 작업을 시작할 수 있도록 한다. 자세한 내용과 문서, 최신 빌드는 zookeeper.apache.org에서 볼 수 있다.

NoSQL 하둡 클러스터가 모두 HBase나 HDFS를 사용하지는 않는다. 일부는 노드 클러스터에 데이터를 저장하기 위한 자체 메커니즘을 구비한 NoSQL 데이터 스토어와 통합된다. 이로써 NoSQL 데이터베이스의 모든 기능을 사용하여 데이터를 저장하고 가져오고, 하둡을 사용해서 같은 클러스터에서 데이터 분석 작업을 예약할 수 있다. 대부분의 경우 이는 카산드라(Cassandra), 리아크(Riak) 또는 몽고DB(MongoDB)를 의미하는데, 사용자들은 이 두 개의 기술을 통합하기 위한 최선의 방법을 활발하게 찾고 있다. 예를 들어 몽고DB의 주 후원사 중 하나인 10Gen은 몽고DB가 웹에서 실시간으로 통계를 수집하는 동안 하둡을 오프라인 분석에 사용할 수 있는 방법을 제안한다. 위 도표는 커넥터가 둘 사이에서 어떻게 데이터를 이전하는지 보여준다.

머하웃(Mahout) 데이터 분석, 분류, 필터링을 위한 알고리즘은 무척 많은데, 머하웃은 이러한 알고리즘의 구현을 하둡 클러스터로 가져오기 위한 프로젝트다. K-Means, Dirichelet, 병렬 패턴, 베이즈 분류와 같은 표준 알고리즘의 상당수를 하둡 스타일의 맵/리듀스를 사용해서 데이터에 적용할 수 있다. 위 이미지는 점과 반경을 선택해서 점 집합을 덮는 캐노피 클러스터링 알고리즘의 결과를 보여준다. 이는 하둡에 구축된 다양한 데이터 분석 도구 중의 하나일 뿐이다. 머하웃은 아파치 프로젝트며 아파치 라이선스에 따라 배포(http://mahout.apache.org/)된다.

루신/솔(Lucene/Solr) 대용량 비구조적 텍스트 블록을 인덱싱하기 위한 도구가 하나 있다. 이 도구는 하둡과 아주 잘 어울리는 파트너다. 자바로 작성된 루신은 하둡과 손쉽게 통합되어 분산 텍스트 관리를 위한 하나의 큰 도구를 구성한다. 루신은 인덱싱을 처리하고, 하둡은 클러스터로 쿼리를 분산한다. 새로운 루신-하둡 기능들은 새로운 프로젝트 형태로 빠르게 발전하고 있다. 예를 들어 카타(Katta)는 클러스터로 자동으로 분산되는 루신의 한 버전이다. 솔은 XML과 같은 표준 파일 형식을 분석하는 기능으로 동적 클러스터링을 위한 더욱 통합된 솔루션을 제공한다. 그림은 루신 이미지 탐색을 위한 GUI인 루크(Luke)를 보여준다. 현재 루크는 하둡 클러스터의 인덱스를 탐색하기 위한 플러그인을 제공한다. 루신과 루신의 많은 파생 도구들은 아파치 프로젝트에 속하며 apache.org에서 받을 수 있다.

아브로(Avro) 하둡 작업에 데이터 공유가 필요하다면 데이터베이스를 사용할 수 있다. 아브로는 데이터와 데이터를 이해하기 위한 스키마를 하나로 묶는 직렬화 시스템이다. 각 패킷에는 데이터를 분석하는 방법을 설명하는 JSON 데이터 구조가 포함된다. 이 헤더는 데이터의 구조를 지정해서 필드를 표시하기 위해 데이터에 부가적인 태그를 쓸 필요가 없도록 한다. 데이터가 규칙적일 때 결과물은 XML, JSON과 같은 전통적인 형식에 비해 훨씬 더 간소하다. 그림은 3개의 필드(이름, 선호 번호 및 선호 색)가 있는 파일에 대한 아브로 스키마를 보여준다. 아브로는 자바 C++, 파이썬 및 avro.apache.org의 다른 언어들로 된 코드와 API가 있는 아파치 프로젝트다.

우지(Oozie) 하나의 작업을 여러 단계로 나누면 모든 일이 간단해진다. 프로젝트를 여러 하둡 작업으로 분할한다면 우지를 사용해서 분할된 작업을 올바른 순서에 따라 시작할 수 있다. 꼼짝없이 스택을 지켜보며 작업이 끝나기를 기다렸다가 다른 작업을 시작할 필요가 없다. 우지는 DAG(방향성 비사이클 그래프)로 지정된 워크플로우를 관리한다(순환 그래프는 무한 루프이며 컴퓨터에게는 함정이다). 이제 우지에게 DAG를 던져주고 점심 먹으러 나가도 된다. 우지 문서에서 발췌한 위 이미지는 흐름도를 보여준다. 코드는 아파치 라이선스로 보호되며, oozie.apache.org에서 찾을 수 있다.

GIS 도구 세계는 넓고, 그 세계의 지도를 다루는 일은 하둡을 실행하는 클러스터에게 큰 작업이다. 하둡 프로젝트용 GIS(지리 정보 시스템) 도구에는 하둡에서 다룰 지리 정보를 해석하기 위한 유용한 자바 기반 도구들이 있다. 데이터베이스는 문자열 대신 좌표를 사용해서 지리 쿼리를 처리할 수 있다. 코드는 GIS 도구를 배포해서 3차원을 계산할 수 있다. 가장 까다로운 부분은 “맵(map)”이라는 단어가 세계를 그려놓은 것을 의미할 때와 하둡 작업의 첫 단계를 의미할 때를 구분하는 것이다. 문서에서 발췌한 위 이미지는 여러 도구 계층을 보여준다. 도구들은 깃허브(GitHub)에서 받을(http://esri.github.io/gis-tools-for-hadoop/) 수 있다.

플룸(Flume) 모든 데이터를 수집하는 일은 데이터를 저장하거나 분석하는 일 못지 않게 어려운 경우가 많다. 플룸은 아파치 프로젝트로, 정보를 수집하는 “에이전트”를 파견한다. 이 에이전트는 HDFS에 저장된다. 에이전트는 로그 파일을 수집하고 트위터 API를 호출하거나 웹 사이트를 훑을 수 있다. 에이전트는 이벤트에 의해 트리거되며 상호 연계가 가능하다. 이렇게 해서 준비된 데이터를 바로 분석하면 된다. 코드는 아파치 라이선스에 따라 flume.apache.org에서 받을 수 있다.

하둡의 SQL 거대한 클러스터에 저장된 모든 데이터에 대해 신속하게 임시 쿼리를 실행하고자 한다면 새로운 하둡 작업을 만드는 방법이 있는데, 여기에는 다소 시간이 걸린다. 이런 경우에 자주 처하자 프로그래머들은 비교적 단순한 SQL 언어로 제기되는 질문에 답할 수 있는 구식 SQL 데이터베이스를 간절히 원하기 시작했다. 이제는 여러 회사들이 가려운 곳을 긁어주는 도구들을 내놓고 있다. 모두 신속하게 답변을 얻을 수 있는 방편을 제공한다. 가장 눈에 띄는 도구들로는 HAWQ, 임팔라(Impalla), 드릴(Drill), 스팅거(Stinger), 타조(Tajo) 등이 있다. 따로 슬라이드쇼를 하나 만들어도 될 정도로 많다.

클라우드 많은 클라우드 플랫폼들이 하둡 작업을 유인하기 위해 분주하게 움직이고 있다. 하둡 작업은 분 단위로 시스템을 임대하는 유연한 비즈니스 모델에 딱 맞기 때문이다. 기업들은 같은 계산을 수행하는 데 며칠, 심지어 몇 주씩 걸리는 시스템 랙을 영구적으로 구입하는 대신 수천 대의 시스템을 구동해서 빅 데이터 세트를 단시간 내에 처리할 수 있다. 아마존을 비롯한 일부 기업들은 소프트웨어 루틴으로 채워진 JAR 파일만 받는 방법으로 또 다른 추상화 계층을 더하고 있다. 다른 모든 것은 클라우드가 알아서 설정하고 일정을 조율한다. 위 이미지는 마틴 아베글렌의 플리커 피드에서 가져온 블레이드 컴퓨터 사진이다.

클라우드 많은 클라우드 플랫폼들이 하둡 작업을 유인하기 위해 분주하게 움직이고 있다. 하둡 작업은 분 단위로 시스템을 임대하는 유연한 비즈니스 모델에 딱 맞기 때문이다. 기업들은 같은 계산을 수행하는 데 며칠, 심지어 몇 주씩 걸리는 시스템 랙을 영구적으로 구입하는 대신 수천 대의 시스템을 구동해서 빅 데이터 세트를 단시간 내에 처리할 수 있다. 아마존을 비롯한 일부 기업들은 소프트웨어 루틴으로 채워진 JAR 파일만 받는 방법으로 또 다른 추상화 계층을 더하고 있다. 다른 모든 것은 클라우드가 알아서 설정하고 일정을 조율한다. 위 이미지는 마틴 아베글렌의 플리커 피드에서 가져온 블레이드 컴퓨터 사진이다.

스파크(Spark) 미래는 이미 다가오고 있다. 하둡은 일반적으로 디스크에 저장된 데이터에 의존하기 때문에 일부 알고리즘에서 속도가 느릴 수 있다. 한 번만 읽히는 로그 파일을 처리할 때는 속도가 별 문제가 되지 않지만 일부 인공 지능 프로그램에서 흔히 볼 수 있듯이 반복적으로 데이터에 접근하는 경우 그 부하가 커질 수 있다. 스파크는 차세대다. 하둡과 같이 작동하지만 메모리에 캐시된 데이터를 사용한다. 아파치 문서에서 발췌한 위 그림은 조건이 맞을 경우 스파크가 얼마나 빠른 속도로 실행이 가능한지 보여준다. 스파크는 아파치에서 인큐베이팅 중이며 spark.incubator.apache.org에서 받을 수 있다.