진화하는 빅데이터 실시간 분석 기술의 세계

빅데이터와 하둡 관련 업계에서 최근 실시간 분석에 대한 관심이 고조되는 모습이다.

실시간 혹은 리얼타임이란 수식어를 달고 거론되는 기술들은 'SQL온하둡(SQL on Hadoop)'과 스트리밍 데이터 처리엔진에 대한 부분이다.

얼핏보면 비슷한 듯 보이는 SQL온하둡과 스트리밍 데이터 처리 엔진은 디테일에선 차이가 있는 기술이다.

SQL온하둡은 하둡분산파일시스템(HDFS)에 저장된 데이터를 많은 이들에게 익숙한 표준SQL 언어로 빠르게 조회하게 해주는 기술이다. 기존 하둡 생태계에서 나타났던 문제점을 극복하려는 취지에서 고안됐다.

아파치 하이브는 HDFS 데이터를 SQL과 유사한 하이브QL로 조회하게 해준다. 하지만, 대용량병렬처리(MPP) 기반 데이터웨어하우스(DW)에 비하면 하이브 쿼리속도는 수십배에서 수백배까지 느리다.

질의를 던질 때마다 하이브QL을 맵리듀스로 변환하는 작업을 매번 수행하는 탓이다. 질의를 던지고 결과를 받기까지 몇시간을 기다려야 하는데다 표준SQL이 아니므로 기존 분석가의 입맛에도 맞지 않다.

SQL온하둡이 거론되게 된 계기는 구글 드레멜(Dremel)의 등장이다. 드레멜은 2011년 공개된 구글 빅쿼리 서비스에 사용된 분석기술로 위키피디아를 수초만에 조회할 정도로 빠른 속도를 자랑한다. 드레멜의 구체적인 내용은 베일에 가려져 있다. 이론적인 구현법만 논문으로 공개됐다. 드레멜에서 아이디어를 얻은 오픈소스 하둡 진영이 새로 구현한 게 SQL온하둡이다.

이 같은 흐름은 맵리듀스 외 다양한 데이터처리엔진을 구동하게 해주는 하둡2.0의 출현과 함께 올해부터 더 거세질 전망이다. 자칫 혼동을 줄 수 있는 SQL온하둡과 스트리밍 데이터 기술들에 대해 정리해 본다.■SQL온하둡 '단순한 쿼리 엔진'

SQL온하둡은 크게 두 종류로 나뉜다. 단순히 SQL을 지원하는 속도 빠른 SQL 쿼리 엔진이냐, 하둡 기반의 데이터웨어하우스(DW) 시스템이냐 여부다. 전자는 수초에서 수분 안에 끝나는 질의에 대한 것이고, 후자는 수시간씩 걸리는 질의에 대한 것이다.

일단 시간 순서대로 맵알 중심의 드릴(Drill)과 클라우데라의 ‘임팔라(Impala)’, 페이스북 ‘프레스토(Presto)’ 등이 대표적인 SQL 쿼리엔진이다. 이 기술들은 하이브를 완전히 대체한다기보다 맵리듀스를 사용하지 않는 또다른 데이터 처리 엔진으로 볼 수 있다. 수초에서 수분 가량 걸리는 질의에 초점을 맞춘다.

드릴은 가장 먼저 등장한 프로젝트다. 구글 출신 엔지니어들이 주축을 이루는 맵알테크놀로지스가 중심에 섰다. 드릴은 1.01버전까지 나와 있지만 2년째 답보상태로, 병렬환경에선 구동할 수 없다. 질의 계획과 최적화 계층은 외부 솔루션에 의존한다.

임팔라는 2012년 클라우데라가 처음 베타버전을 선보인 이래 작년 1.0버전이 나왔다. 디스크가 아닌 메모리에서 SQL쿼리를 처리하도록 하는 엔진으로 질의 처리 속도 개선에 초점이 맞춰졌다. 임팔라는 중간 데이터를 모두 메모리에 두기 때문에 메모리 용량을 넘어서는 질의를 실행할 수 없다. 하이브와 완전히 동일한 기능을 제공하지 않으며, 하이브와 병용해야 하는 보완재에 가깝다. 기본적으로 클라우데라하둡배포판(CDH) 환경에서만 사용가능하다.

페이스북의 프레스토는 작년 11월 공개됐다. 웹스케일 DW란 수식어가 붙었는데 페이스북 내부에 있는 300페타바이트(PB) 규모의 다양한 데이터 소스를 빠른 시간 안에 SQL문으로 분석하기 위해 만들어졌다. 다만, 프레스토는 복잡한 질의를 지원하지 않고 대략적인 통계치 정도를 알아볼 수 있는 수준이다. 페이스북 역시 여전히 하이브를 주요한 분석 플랫폼으로 사용중이며, 업무처리속도에 민감한 일부 영역에만 프레스토를 활용하고 있다.

이밖에 EMC 자회사인 피보탈에서 개발한 호크(Hawq)가 있다. 호크는 EMC 그린플럼 DW와 이 회사의 피보탈HD란 하둡 배포판에서 이용 가능한 SQL쿼리엔진이다. 대용량병렬처리(MPP)를 활용해 하둡의 데이터를 빠르게 조회할 수 있게 했다. 호크는 상용제품에 포함되므로 소스코드를 공개하지 않는다.

■SQL온하둡 '하둡 기반 DW 시스템'

하둡 기반의 DW 시스템으로 분류되는 SQL온하둡 기술은 그루터의 ‘타조(Tajo)’와 호튼웍스의 스팅거(Stinger)’다. 두 기술은 맵리듀스를 대체하는 별도의 SQL처리엔진을 내장하며, 데이터추출변환적재(ETL) 기능을 제공한다. 수시간씩 걸리는 질의를 위한 롱텀쿼리도 지원한다.

그루터 개발자들이 주축을 이뤄 개발중인 타조는 아파치 하이브를 완전히 대체하는 플랫폼으로 고안됐다. 롱텀쿼리를 위해 필요한 장애내구성(폴트톨로런스), 다이내믹스케줄링 등을 지원한다.

장애내구성은 질의 수행 중 일부 노드의 장애발생에도 처리를 멈추지 않는 것이다. 클러스터 규모가 커지면 장애발생 확률도 커지기 때문에 긴 시간 멈추지 않고 질의를 처리하려면 반드시 필요하다. 이 기능을 구현하지 않은 임팔라나 프레스토는 장애 발생 시 질의를 처음부터 다시 수행해야 한다.

다이내믹스케줄링은 쿼리작업 분산 시 노드별 하드웨어 성능에 따라 작업을 최적화해 분배하는 기능이다. 동시에 최대한 처리할 수 있는 양만 나눠준 다음, 먼저 처리를 마친 노드에 추가 작업을 부여한다.

아파치 인큐베이터 프로젝트인 타조는 현재 0.2버전까지 나온 상태이며, 이달 중 0.8버전, 상반기 중 1.0버전이 공개될 예정이다.

호튼웍스가 주도하는 스팅거 프로젝트는 전혀 새로운 기술은 아니다. 스팅거는 기존 하이브의 성능과 속도를 높이려는 ‘이니셔티브’로 불린다.

스팅거는 하이브의 실행계획을 개선하고(1단계), 컬럼압축스토어 파일포맷인 ORCfile을 지원하면서(2단계), 맵리듀스 대신 테즈(Tez)란 별도의 엔진을 사용(3단계)해 속도를 높인다. 호튼웍스는 스팅거 이니셔티브를 통해 하이브가 1.0 버전 대비 100배빠른 쿼리 속도를 보이게 될 것이라 강조한다.

스팅거 지지자들은 하이브에서 속도와 용량 문제를 해결하면 임팔라나 드릴 같은 별도의 엔진을 굳이 사용하지 않아도 된다는 입장이다. 하이브의 광범위한 기능을 살리자는 취지다. 그러나 맵리듀스 대체 엔진인 테즈가 하이브의 모든 기능을 지원하기까지 상당한 시간이 필요할 것으로 전망된다.

■데이터 마이닝을 위한 기술

SQL온하둡에 일부 포함되는 기술도 존재한다. 스파크(Spark)와 샤크(Shark)란 기술이다.

스파크는UC버클리의 앰프랩(Amplab)에서 개발했으며, HDFS 데이터를 한번만 읽어들인 다음 분석 질의 시 메모리에서 처리하게 하는 엔진이다. 스파크는 DW보다 데이터 마이닝을 위해 고안됐다. 샤크는 스파크 위에서 하이브QL을 사용할 수 있게 해주는 기술이며 DW의 역할을 수행하게 해준다. 현재 스트리밍 데이터의 분석을 위한 스트리밍 스파크도 개발되고 있다.

■또다른 실시간 분석? '스트리밍 데이터'

스트리밍 데이터 처리는 콤플렉스이벤트프로세싱(CEP)으로 볼 수 있는 기술이다. 스트리밍 데이터 처리기술로는 트위터에서 만든 아파치 스톰(Storm)이 대표적이다.

SQL온하둡은 데이터 수집과 전처리 후 저장 단계를 거친 다음 대용량으로 빠르게 분석하는 것을 말한다. 반면 스트리밍 데이터는 저장단계를 거치지 않고 데이터를 바로 분석하게 하는 점이 다르다.

다양한 데이터소스에서 들어오는 현재의 데이터 흐름 속에서 바로 분석한다는 점에서 실시간 플랫폼이라 불리기도 한다. 어떤 돌출된 이벤트를 찾아내는 모니터링에서 주로 활용된다.

스톰은 단순하면서도 강력한 기능을 제공한다는 점에서 인기를 끌고 있다. 하둡처럼 다양한 경로를 통해 유입되는 데이터를 분산시켜 대규모로 처리하게 해준다. 분산처리 설계구조로 주컴퓨터에서 실행되는 '님버스(Nimbus)'와 그 명령을 따르는 하위컴퓨터에서 돌아가는 '수퍼바이저(Supervisor)', 둘 사이의 최적화를 맡는 클러스터 기술 '주키퍼(Zookeeper)'를 둔다. 장애내구성과 예비자원 제공 기능이 구현된다.

스톰 같은 기술로 가장 최근에 나와 주목을 끈 기술이 아마존웹서비스(AWS)의 키네시스다. 키네시스는 스톰과 유사한 기능을 제공하면서, 클라우드 컴퓨팅 상에서 활용가능한 서비스다. 스톰이 인프라를 직접 구축해야 하는 반면, 별도 인프라 구축없이 스트리밍 데이터 분석을 빠르게 적용할 수 있다는 차이를 갖는다. 그러나 키네시스에서 처리된 데이터를 저장할 경우 AWS의 저장플랫폼을 활용해야 한다.