류프리

타조는 그루터에서 만든 하둡 기반의 차세대 빅데이터 분석 처리 엔진입니다. 기존 시스템과 통합을 하거나 이를 대체할 수 있도록 표준 SQL을 지원합니다. 또한 CPU와 메모리를 적절히 활용하여 높은 처리 성능을 보장합니다. 타조는 기존 하둡 빅데이터 처리엔진인 하이브(Hive)보다 10배에서 100배까지 빠르게 데이터를 처리할 수 있습니다. 타조와 같은 인터렉티브 분석(IA, Interactive Analysis) 기술과 하둡 생태계 기술들을 최적화할 경우, 관계형 데이터베이스에서 제품군에서 제공하는 뛰어난 성능의 상용 데이터웨어하우스(DW, Dataware house) 제품들을 대체할 수 있습니다.

타조는 하둡 기반의 대용량 데이터웨어하우스(DW) 시스템을 목표로 하는 솔루션으로 현재 아파치 인큐베이션 프로젝트(http://tajo.incubator.apache.org/)로 진행중인 오픈 소스 프로젝트이며, 그루터가 개발을 주도하고 있습니다. 타조는 분산된 저장소에 저장된 데이터를 SQL질의를 분산 실행시켜 빠르게 데이터를 처리하는 기능을 제공하는 플랫폼입니다.

기존 맵-리듀스 기반 분석 시스템

하둡(Hadoop)은 대규모 데이터의 분산처리를 위한 오픈 소스 프레임워크입니다. 하둡은 크게 데이터를 저장할 수 있는 하둡 분산 파일 시스템(HDFS, Hadoop Distributed File System)과 저장된 데이터를 처리하는 맵-리듀스(Map-Reduce)로 구성되어 있습니다. 하둡은 크게 3가지의 장점을 가지고 있습니다.

첫번째는 유연성입니다. 데이터베이스에 저장되어 있는 정형화된 데이터나, 트위터와 페이스북에서 생성되는 비정형화된 데이터등 여러 형태의 다양한 데이터 포맷을 지원해 주며, 자바(Java), 루비(Ruby), 파이썬(Python)등과 같은 범용 프로그래밍 언어를 이용하여 다양한 분석 알고리즘 적용이 가능합니다.

두번째는 확장성입니다. 하둡은 노드(Node)를 증가함에 따라서 성능과 용량이 선형적으로 증가합니다. 시스템의 성능을 높이기 위해서 프로그램과 리소스를 튜닝하는것보다 노드(Node)와 같은 장비를 확장함으로써 더 좋은 성능을 발휘할수 있습니다.

마지막으로 비용입니다. 하둡은 x86과 같은 저가의 노드(Node)들을 서로 연계시켜도 성능면에서 떨어지지 않는 장점을 가지고 있습니다. 또한 이러한 저가의 서버들을 수십대에서 수만대까지 연계시킬 수 있으므로 대용량의 데이터를 처리하는데 저 비용으로 시스템을 구축할 수 있습니다.

하이브(Hive)

하이브는 하둡 기반의 데이터웨어하우스(DW, Data warehouse)입니다. 하이브는 HiveQL(Hive Query Language)이라는 SQL과 유사한 언어로 만들어졌습니다. 하이브는 사용자가 HiveQL으로 명령어를 입력하면 하이브는 내부적으로 맵-리듀스 작업으로 변환하여 처리를 합니다. 초기에 하이브가 사용자들에게 사랑을 받은 이유가 맵-리듀스라는 프로그래밍 언어를 알지 못해도, HiveQL를 사용하여 쉽게 하둡 분산 파일 시스템에 저장되어 있는 데이터를 분석할 수 있습니다.

맵-리듀스의 문제점

맵-리듀스는 배치 처리(Batch processing)를 목적으로 만들어진 시스템으로 맵과 리듀스간의 셔플링(Shuffling) 작업에 많은 시간을 허비하여 실시간 분석에 적합하지 않은 문제점을 가지고 있습니다.

셔플링(Shuffling)이란 메모리에 저장되어 있는 맵 함수(Map function)의 출력 데이터를 파티셔닝과 정렬을 해서 로컬 디스크에 저장한 후에 네트워크를 통해 리듀서의 입력 데이터로 전달하는 과정을 말합니다.

문제는 분산된 수많은 노드(Node)에서 수집한 맵 함수에 대한 결과들을 하나의 리듀스 서버로 전달을 해야 합니다. 이 과정에서 네트워크에 많은 부하가 발생하게 되며, 맵 과정에서도 빈번하게 하둡 분산 파일 시스템(HDFS)에 데이터를 읽고 쓰는 작업을 반복해야 함으로써 분석 성능을 저하시키는 원인이 됩니다.

하이브의 문제점

하이브는 HiveQL이라는 언어를 통해서 맵-리듀스 언어로 변환이 되어서 맵-리듀스 처리를 해야합니다. 이러한 이유로 맵-리듀스의 모든 문제점을 가지고 있습니다. 맵-리듀스을 처리하기 위해서 수행되는 여러 개의 태스크(Task)들이 실행되어서 준비되는 시동시간이 5~15초에 달합니다. 그리고 HiveQL이 SQL과 유사한 언어이지만, 표준 SQL(Ansi SQL)과는 많은 차이가 있습니다.

SQL 온 하둡

하둡 기반의 차세대 분석 엔진을 의미합니다. 기존 하둡이 가지고 있는 맵-리듀스와 하이브(Hive)의 문제점을 개선하여 실시간 분석이 가능하도록 시스템을 개선한 것입니다. SQL 온 하둡의 특징은 다음과 같습니다.

① SQL 표준 지원

기존 관계형 데이터베이스에서 사용하던 SQL을 그대로 사용하도록 표준 SQL 문법을 준수합니다. 이를 통하여 SQL에 친숙한 분석가들과 사용자들을 하둡으로 전향할 때 발생할 수 있는 거부감을 줄여줄수 있습니다.

② 높은 처리 성능

기존의 맵-리듀스를 사용하지 않고 실시간 분석이 가능한 새로운 분산 처리 프레임워크를 사용하고 인-메모리(In-Memory) 기능의 활용과 CPU 사용을 극대화 시키는 기술을 도입하여 낮은 반응 시간(Low latency)이 나오도록 지원합니다.

③ 성능에 대한 보장

맵-리듀스는 프로그래밍 언어로서 개발자의 역량이 중요합니다. 같은 내용의 프로그램이라고 할지라도 누가 만들었는지 어떤 방식으로 설계했는지에 따라서 성능에 큰 차이가 나타날 수 있습니다. 또한 존재하는 버그를 찾는데 많은 시간과 노력을 필요로 합니다. 하이브(Hive)의 경우에도 사용자가 어떻게 질의를 했는가에 따라서 성능에 큰 영향을 미칩니다. SQL 온 하둡은 사용자에 의해서 발생할 소지가 있는 문제점들을 분석 시스템에서 자동적으로 보정해주는 작업을 진행하여 똑같은 성능이 나오도록 보장을 해 줍니다.

타조의 특징

타조는 하둡 기반의 데이터웨어하우스(DW, Data warehouse)이며, HDFS및 다양한 형태의 데이터를 추출하고 분석 시스템에 전송하여 집계 및 연산, 조인, 정렬 기능을 제공합니다.

① 호환성

표준 SQL을 지원하여 기존 사용자들이 사용하는데 거부감이 없으며, 사용자들이 함수를 작성하여 사용할수 있도록UDF(User Defined Function)를 지원합니다. 그리고 JDBC를 지원하고 있으며, ODBC는 추후 지원할 계획입니다.

② 고성능 및 낮은 반응 시간(Low latency)

맵-리듀스를 사용하지 않고 유연하고 효율적인 분산 처리 엔진을 자체 개발하여 사용하고 있으며, 비용 기반 최적화 엔진(cost-based optimization)과 JIT Query Compliation 및 Vectorized 질의 엔진을 사용하고 있습니다.

③ 오픈 소스 (http://tajo.incubator.apache.org)

클라우데라에서 만든 임팔라의 경우 오픈 소스이지만, 사용자들이 개발에 참여할 수 없지만, 타조는 오픈 소스이며 사용자 참여가 모두 가능합니다.

타조의 목표

① 잘못된 질의에 대한 최적화

맵-리듀스와 하이브의 경우에는 작성하는 개발자의 능력에 따라서 성능이 다르게 나오는 문제점을 가지고 있으며, 하이브에서는 ‘From’ 절의 배치 순서에 따라서 나오는 결과가 수분 또는 몇시간이 걸릴 수 있습니다. 타조에서는 사용자가 입력한 질의에 대해서 엔진에서 최적화가 될수 있도록 보정 작업을 진행합니다.

② 분산 처리 프레임워크

맵-리듀스의 경우 하나의 테스크를 시작하는데 걸리는 시간이 수십밀리 초에서 1초 정도 걸리고 맵과 리듀스 작업을 위해서 데이터를 네트워크를 통해서 전송하는데 많은 병목현상이 발생합니다. 이러한 문제점을 해결하여 실시간 분석이 가능한 분산 처리 프레임워크를 개발하였습니다.

Master-Worker 모델

전형적인 Master-Worker 모델입니다. 마스터(Master)가 존재하고 마스터가 발생하는 작업들을 하부에 있는 워커(Worker)들에게 할당하는 구조입니다. 네티(Netty)나 Protocol Buffer등을 이용하여 RPC(Remote Procedure Call)로 마스터와 워커간의 통신을 담당합니다.

① 마스터(Master)

타조 마스터는 쉘 커맨드나 프로그램에서 보내온 질의에 대한 처리를 담당하며, 카탈로그 서버(메타 서버)에서 테이블 스키마나 물리적인 정보와 각종 통계 자료들을 보유하고 있습니다. 마스터는 또한 쿼리를 파싱하고 최적화하여 동일한 성능을 보장을 해주며, 클러스터 자원들을 관리하는 역할를 수행합니다.

② 워커(Worker)

워커는 쿼리 마스터(Query Master)와 타조 워커(Tajo Worker)로 구성이 되어 있으며, 질의에 대한 처리를 담당합니다. 질의 하나당 쿼리 마스터 하나가 생성되며, 질의에 대한 수행 계획과 최적화 작업을 진행합니다. 쿼리 마스터가 여러 개의 타조 워커(Tajo Worker)를 띄워서 물리적인 데이터를 HDFS에 데이터를 쓰고, 읽는 작업을 진행합니다. 그리고 로컬에 질의 엔진을 가지고 있어서 할당 받은 작업을 수행합니다. 타조 워커는 기존에 자바로 구현이 되어 있는데, 속도 향상을 위해서 C++로 대체하는 작업을 진행중입니다.

다음 그림은 타조의 구조를 나타냅니다. 타조 클라이언트에서 질의가 들어오면 타조 마스터에서 질의에 대한 계획을 세우고 리소스를 받아서 쿼리 마스터를 띄워서 질의를 수행하기 위해서 타조 워커(Tajo Worker)에게 질의를 할당하는 작업을 진행합니다.

[ 타조의 구조 ]

질의 계획 및 최적화 엔진

① 비용 기반 최적화 (Cost-based optimization)

조인 순서를 사용자에게 의존하지 않고 최적의 성능이 나오도록 엔진이 스스로 조인 순서를 결정합니다.

② 확장 가능한 Rewrite Rule 엔진

기존에 상용 데이터베이스에서 지원하는 확장 가능한 Rewrite rule를 사용하여 튜닝이 가능하도록 지원합니다.

③ 적응형 최적화 (Progressive query reoptimization)

질의가 실행되는 시간에 통계 정보를 바탕으로 질의의 남은 부분들을 최적화할 수 있으며, 나쁜 질의에 대해서는 회피도 가능합니다.

④ 데이터 셔플(Shuffle) 방법

기존에 맵-리듀스에서 사용하던 해쉬(Hash) 뿐만 아니라 레인지 파티션(Range Partition)도 지원합니다. 레인지 파티션은 각각의 서버들에게 할당된 범위안에서 데이터 처리를 분배해주는 방법입니다.

⑤ 데이터 전송 방법

기존의 데이터 전송 방식은 풀(Pull) 방식입니다. 풀 방식이란 중간 데이터를  저장을 해 놓으면 필요한 워커들이 데이터를 끌어가는 방식을 말합니다. 지금은 푸쉬(Push) 방식을 사용하는데 중간 과정의 데이터를 디스크에 저장하지 않고 다른 워커에게 전송하는 방식입니다. 이 방식은 자원을 즉시 사용할 수 있어서 실시간 처리에 적합한 구조입니다.

⑥ Vectorized Engine

컬럼(Column) 방식으로 데이터를 처리합니다. 하나의 테이블이 있으면 컬럼 단위로 분할을 하며 분할된 컬럼들을 백터(Vector)라고 부릅니다. 벡터의 크기는 CPU 캐시 크기에 맞추어서, 행(row) 데이터 조회시 빠른 결과를 얻을 수 있습니다. 데이터 처리는 벡터 단위로 루프(Loop)를 반복해서 처리를 하며, 셀렉션 벡터(Selection vector)등과 같은 여러가지 기능들을 제공합니다.

[ Vectorized Engine ]

⑦ JIT (Just In Time) 코드 생성기

데이터 조회에 필요한 프리미티브(Primitive)를 미리 만들어 놓지 않고, LLVM(Low Level Virtual Machine)을 이용해서 런타임시에 실시간으로 생성합니다. LLVM은 프로그래밍 언어 컴파일러 집합으로 컴파일 시간이나 런타임 시간등 다양한 상황에서 최적화를 쉽게 구현할수 있도록 구성되어 있습니다.

NewSQL은 NoSQL처럼 높은 확장성과 성능을 갖춘 RDB를 일컫는다. SQL을 지원하고, SQL이 트랜잭션 데이터를 처리하기 위해 기업이 갖추고 있어야 할 4가지 속성인 ACID(Atomicity, Consistency, Isolation, Durability) 등록 정보를 준수합니다. 여기에 NoSQL의 특징인 확장성과 유연성을 데이터베이스 관리 시스템(DBMS)에 더했습니다. SQL과 NoSQL에서 장점만 뽑아 결합한 형태입니다.

하둡의 엔터프라이즈 시장 진입

빅데이터 표준 플랫폼은 하둡(Hadoop) 입니다. 하둡과 빅데이터의 엔터프라이즈 시장 진입이 계속 늦어지고 있습니다. 하둡 진영은 SQL 쿼리 분석을 하둡에서 보다 빠르게 수행할 수 있느냐를 열쇠로 보고 관련 기술을 개발하기 위해 노력중입니다.

SQL-온-하둡

‘SQL-온-하둡(SQL on Hadoop)” 혹은 ‘대화형(Interactive) 쿼리 엔진(Query Engine)’ 등으로 불리는 기술은 2012년부터 본격적인 개발경쟁 양상을 보였습니다. 클라우데라의 임팔라(Impala), 호튼웍스의 스팅거(Stinger), 맵R의 드릴(Drill)등이 대표적인 제품입니다. EMC 자회사 피보탈이니셔티브가 올해초 호크(HAWK)를 내 놓으며 엔터프라이즈 시장 진입에 출사표를 던졌습니다. 한국의 그루터도 ‘타조(Tajo)’ 개발에 박차를 가하고 있습니다.

아파치(Apache)의 하이브(Hive)

이 같은 움직임의 중심에 아파치 하이브(Hive)가 있습니다. 하이브는 하둡 분산 파일 시스템(HDFS, Hadoop Distributed File System)에 저장된 데이터를 SQL과 유사한 하이브QL(HiveQL)로 분석하게 해주는 기술입니다. 하지만 대용량 병렬처리(MPP, Massively Parallel Processing) 기반의 데이터웨어하우스(DW)에 비하면 하이브의 쿼리속도는 현저히 느립니다. 질의를 던질때마다 맵리듀스 작업을 매번 수행하기 때문입니다. 질의를 던지고 결과를 받기까지 수시간을 기다려야 합니다. 이 때문에 대화형 쿼리 분석엔 적합하지 않다는 평을 받고 있습니다..

빅데이터 관련업계는 하이브의 이 같은 한계를 극복해야 하둡이 엔터프라이즈 시장에 진입할 수 있을 것으로 보고 있습니다. 하이브가 SQL에 익숙한 사람들에게는 성에 차지 않습니다.

'SQL-온-하둡'의 두갈래 대처 방안

진영은 두갈래로 나뉩니다. 하이브를 완전히 대체하는 새 기술을 쓸 것인가? 아니면 하이브를 개선해 속도를 높일 것인가? 하지만, 하이브는 사실상 시한부 판정을 받았다는 쪽으로 여론이 흐르고 있습니다. 하이브를 만든 페이스북조차 ‘프레스토’란 새로운 데이터웨어하우스(DW) 엔진을 만들었습니다.

호튼웍스의 스팅어

하이브를 살려야 한다는 입장을 가장 강력하게 내세운 회사는 호튼웍스다. 호튼웍스는 하이브를 최적화하고 파일 포멧 작업을 통해 하이브 쿼리속도를 100배 끌어올리겠다는 비젼을 내놓았습니다. 호튼웍스는 하이브야말로 SQL-온-하둡을 위한 최고의 선택이라며 3단계에 걸친 개선계획을 발표했습니다. 이것이 바로 스팅어(Stinger)입니다.

호튼웍스는 하이브의 성능을 35~45배 끌어올리기로 했습니다. 다양한 쿼리 기능을 추가하고 ORCFile 같은 파일 포맷으로 성능을 끌어올리는 것이 2단계입니다. 그리고 맵-리듀스 대신 아파치 테즈(Tez)란 새 기술을 이용해 하이브에 접목합니다. 이를 통해 최종적으로 하이브의 SQL 쿼리 속도를 100배 향상시킨다는 것입니다.

그루터의 타조

하이브를 버리고 새로운 엔진을 찾아야 한다는 진영은 타조가 대표적이다. 타조는 하이브를 개선하는데 한계가 명확하기 때문에, 대용량 SQL 쿼리 분석에 적합하지 않다는 입장입니다. 애초 기획 단계부터 하이브를 대체하는 새로운 엔진으로 개발되고 있습니다.

클라우데라의 임팔라

클라우데라의 임팔라도 하이브를 대체하는 엔진입니다. 그러나 일정 규모 이상의 데이터는 임팔라로 분석할 수 없습니다. 임팔라가 메모리 기반 처리 엔진이어서, 일정 용량 이상에선 디스크 환경의 하이브를 사용해야 합니다. 그러나 SQL on Hadoop이란 전체 틀에선 하이브를 버리는 쪽으로 무게를 두고 있습니다.

하이브의 한계

구도상 하이브에 주요 회사중에서 호튼웍스만 전력을 기울이는 것처럼 보인다. 하지만, 호튼웍스도 장기적으로는 하이브를 유지하자는 입장으로 단정하기는 어렵다. 바로 스팅어의 핵심인 테즈 때문입니다. 테즈는 SQL 처리시 맵-리듀스를 대신하는 새 기술입니다. 다수 개발자들은 맵리듀스를 사용하지 않는 하이브는 하이브가 아니다라고 반문합니다. 맵-리듀스 와 하이브 조합을 버리는 순간 하이브라 부를수 없다는 것입니다.

호튼웍스의 입장을 십분 받아들인다고 해도 하이브의 한계는 뚜렷합니다. 호튼웍스가 최근 올린 블로그가 그 한계를 스스로 보여줍니다. TPC-DS 벤치마크에서 호튼웍스 데이터 플랫폼(HDP)2.0을 사용했을 때 44배의 속도개선을 보였다고 주장했습니다. 그런데 그 비교 대상이 최근버전인 하이브 0.11이 아니라 하이브 0.10버전입니다.

하이브는 0.10 버전에서 0.11버전으로 업데이트되면서 이미 32배의 속도 개선을 이루었습니다. 즉 호튼웍스의 주장은2007년에 만들어져 이제 거의 사용되지 않는 버전보다 44배 빠르다는 것이다. 직접 버전인 0.11과 비교하면 30% 가량 빨라졌을뿐입니다.

하이브의 미래

하이브의 미래에 대한 징후는 현재 개발되는 하이브 0.12버전의 코드 기여도 통계에서도 나타납니다. 호튼웍스가 공개한 자료에 의하면, 하이브 0.12 코드라인 기여자 소속회사 통계(8월 30일 기준)에서 호튼웍스는 8만 3천 742라인으로 절반을 훌쩍 넘긴 비중을 차지합니다. 다음으로 페이스북이 3만 148라인을 차지합니다. 세번째로 많은 기여자는 한국의KT 넥스알입니다. KT 넥스알은 1만2천 103라인을 기여했습니다. 다음은 4천244라인을 기부하였으며, 클라우데라는 3천528라인을 기부했습니다.

주목할 부분은 페이스북과 클라우데라 입니다. 페이스북은 하이브 0.10을 내 놓는데 가장 많은 비중을 차지했던 회사입니다. 그런 페이스북이 점차 하이브에 대한 관심을 줄여가고 있는 것입니다. 호튼웍스와 함께 아파치 하둡 프로젝트의 주요 기여자인 클라우데라의 기여도는 호튼웍스의 2%에 불과합니다. 주요 기여자의 참여축소와 기타 기여자의 비중도 확연히 줄었습니다.

하둡 진영이 ‘SQL-온-하둡’에 열을 올리는 이유

하둡 생태계는 왜 하이브와 SQL on Hadoop에 이토록 열을 올리고 있는가? 이는 SQL을 쓸수 있는냐가 엔터프라이즈 시장에서 하둡을 사용하느냐로 직결되기 때문입니다.

엔터프라이즈는 데이터웨어하우스(DW) 시스템과 고급 분석도구, 비즈니스 인텔리젼스(BI)를 사용하는 집단입니다. 기업의 분석가 집단이 주요 사용자입니다. 이들은 정형화된 데이터를 이용해 여러 분석을 시도하는데, 간단한 SQL 쿼리만 활용할 뿐 복잡한 프로그래밍 능력은 갖고 있지 않습니다. 프로그래밍은 IT 부서의 일이라 여깁니다. 분석가는 분석을 할 뿐 기술엔 관심이 없습니다.

기업 분석가 집단이 보기에 하둡은 생소하고 어려운 기술일 수밖에는 없습니다. 자신들은 잘 알지도 못하는 다양한 프로그래밍 작업을 요구하기 때문입니다. 현존 데이터 분석도 만족스러운데 굳이 본업도 아닌 프로그래망까지 하려니 당연히 필요성을 못 느낍니다. SQL과 유사한 도구인 하이브도 그 속도가 너무 느립니다.

하이브를 만들어낸 회사는 인터넷서비스 회사인 페이스북입니다. 하이브를 가장 많이 활용하는 회사도 페이스북입니다. 하둡과 하이브를 다양하게 사용하는 회사도 야후, 넷플릭스, 트위터, 페이스북과 같은 인터넷 서비스 회사들은 여러 사람이 사용하기 바라는 마음으로 하둡과 하이브를 만들지 않았습니다. 이 회사의 개발자들은 자사의 서비스를 개선하는 과정에서 SW를 만들고, 그를 외부에서도 쓸 수 있게 공개한 것 뿐입니다. 페이스북이 만든 하이브라면 페이스북 개발자가 활용하기 좋은 수준 정도로 만들어집니다. 엔터프라이즈 기업의 기대치와 당연히 거리가 있습니다.

개발자 입장에선 하둡과 하이브를 이용해 분석하는데 거리낌이 적습니다. 개발자로서 전문 분석가는 아니지만, 예전에 하지 못했던 분석을 할 수 있게 됐으니 그 정도 성능이면 충분하다고 느끼는 것입니다.

엔터프라이즈의 분석가와 인터넷 서비스 업체의 개발자 사이엔 높고 두터운 벽이 존재합니다. 빅데이터와 하둡이 엔터프라이즈 시장으로 진입하려면 기업 내 분석가를 설득해야 합니다. 데이터웨어하우스(DW)와 성능도 비슷하고 분석도 쉽다는 메시지를 앞세워야 합니다. SQL-온-하둡은 바로 이 벽을 지나는 문입니다.

드레멜은 데이터 분석에 적합한 기능을 가지고 있으며, 조 단위가 넘는 데이터를 가진 테이블에 대한 쿼리를 순식간에 처리할 수 있고, 수천 개의 CPU와 페타바이트급 데이터로 확장이 가능하며 SQL 쿼리(Query)를 지원하기 때문에 일반 사용자도 편리하게 사용할 수 있습니다.

드레멜은 2011년 공개된 구글 빅-쿼리(Big Query) 서비스에 사용된 분석 기술로 위키피디아를 수초만에 조회할 정도로 빠른 속도를 자랑합니다. 드레멜에서 아이디어를 얻은 오픈소스 하둡 진영이 새로 구현한게 클라우데라의 임팔라(Impala)와 호튼웍스의 스팅어(Stinger) 제품의 ‘SQL-온-하둡(SQL on Hadoop)’ 입니다.

구글 운영에 있어 수천 명의 사용자들은 웹 문서 분석, 안드로이드 앱을 위한 설치 데이터 추적, 충돌 보고, 수십만 디스크를 위한 디스크 I/O 통계 유지 등과같은 다양한 애플리케이션에서 드레멜을 사용합니다.

빅쿼리(BigQuery)는 드레멜에 기반한 호스트 기반 빅데이터 분석 서비스입니다. 막대한 양의 서버에 대한 로그 데이터를 준비하고, 지우고, 변형하고, 옮기기 위해서는 하둡의 맵리듀스 기술이 사용되고, 데이터 분석에 대해서는 드레멜이 사용됩니다. 

스팅어는 아파치 하이브(Apache Hive)의 쿼리 속도를 현재보다 100배 높인다는 프로젝트로, 대화형 쿼리 분석을 실현하기 위해 개발되고 있습니다. 클라우데라의 임팔라, 그루터의 타조 등이 맵리듀스와 하이브를 대체하는 새로운 쿼리엔진을 개발하는데 비해 스팅어는 하이브의 최적화와 포맷 변경으로 속도를 개선하는데 초점을 맞추고 있습니다.

호튼웍스는 하이브야말로 SQL-온-하둡(SQL on Hadoop)을 위한 최고의 선택이라고 생각하며, 3단계에 걸친 개선 계획을 발표했습니다.

스팅어 1단계(Stinger Phase One) – 하이브 0.11 (HDP 1.3)

HDP1.3에 포함된 스팅어 1단계는 하이브 0.11를 사용합니다. 스팅어 1단계에서는 SQL 호환성 개선(일반적인 분석 쿼리에 대해 35~45배 성능 향상)과 컬럼 스토어 기술, 압축, 인메모리 해시 조인 등이 개발되었습니다.

스팅어 2단계(Stinger Phase Two) – 하이브 0.12 (HDP 2.0)

HDP2.0에 포함된 스팅어 2단계는 하이브 0.12를 사용합니다. 하지만 맵리듀스 엔진은 그대로 사용해 얀(YARN, Yet Another Resource Negotiator) 아키텍처의 이점을 활용하지 못했습니다. VARCHAR 및 DATE 데이터 타입을 통해서 단순화된 SQL 상호 운영성을 지원하며, 여러가지 요인에 의해서 복잡한 쿼리(Query)의 속도를 향상시키는 새로운 쿼리 최적화 작업을 진행하여, 스팅어 2단계에서는 1단계보다 60~70배 정도의 성능개선이 있었습니다. 

[ 하이브의 데이터 유형 ]

스팅어 3단계(Stinger Phase Three)

현재 진행형인 스팅어 3단계는 맵-리듀스를 대체하는 테즈(Tez)엔진으로 데이터 처리부를 교체하는 작업이 주요 내용입니다. 호튼웍스는 HDP2.0을 통해 여러 하둡 스택도 최신 버전으로 업데이트했습니다. 

임팔라는 하둡상에서 맵-리듀스(Map-Reduce)를 이용하지 않고 SQL(Standard Query Language)을 처리하는 기능을 내장한 제품입니다. 임팔라를 이용하면 하둡(Hadoop)의 하이브(Hive) 기술을 사용하지 않고서도 SQL 분석이 가능함으로써 데이터 처리시간을 단축할 수 있습니다.

하이브(Hive) 구조의 문제점

하이브(Hive)는 유사 ANSI SQL을 사용할 수 있어 기존 분석가가 쉽게 사용할 수 있다는 장점을 가지고 있는 반면에, 대용량 병렬처리 기반 데이터 웨어하우스(DW, Data Warehouse) 시스템보다 SQL 실행 시간이 많이 소요된다는 단점이 있습니다.

이유는 하이브가 SQL을 맵-리듀스(Map-Reduce) 작업으로 변환하는 작업이 중간에 추가되었기 때문입니다. 맵-리듀스는 사용자들이 제어하기에는 불편한 점이 많고 처리 속도가 느리다는 태생적 단점이 있습니다.

피그(Pig)와 하이브(Hive)는 맵-리듀스 프레임워크의 사용 편의성을 높이기 위해서 2008년에 등장한 플랫폼이었습니다. Pig와 Hive 모두 하둡의 서브 프로젝트이며, 하이-레벨 언어(High-Level Language)입니다. 차이점은 Pig는 절차적인 언어임에 반해서 Hive는 SQL과 유사한 선언적인 언어입니다. Pig와 Hive의 등장으로 하둡 사용자들이 편리하게 대용량 데이터 분석작업을 수행할 수 있었습니다.

Pig나 Hive 모두가 사용자들에게 데이터를 쉽게 조회할 수 있는 수단을 제공한 반면에 데이터를 처리하기 위해서는 맵-리듀스 언어로 변환되어 처리가 되었습니다. 문제는 맵-리듀스는 분산 환경에서 대용량의 데이터를 배치(Batch) 형태로 처리되도록 설계가 되어서, 속도가 느린 단점을 가지고 있었고, 이로 인하여 Pig와 Hive 역시 맵-리듀스 위에서 동작하기 때문에 같은 문제점을 가지고 있는 것입니다.

[ 하이브와 맵-리듀스의 관계 ]

아파치 임팔라(Impala)

임팔라는 H베이스(HBase)나 맵-리듀스 같은 별도 계층을 거치지 않고 HDFS(Hadoop Distributed File System)와 직접 통신을 합니다. 그리고 하이브처럼 ‘하이브쿼리언어(HiveQL)’를 사용합니다.

클라우데라는 임팔라와 하이브의 최대 차이를 성능으로 꼽습니다. 하이브는 자바로 만들어졌지만 임팔라는 C++ 기반으로 만들어졌으며, 별도의 실행엔진을 사용하므로 맵-리듀스 프로그래밍을 할 필요가 없습니다.

임팔라는 맵-리듀스와는 달리 쿼리(Query)를 아주 낮은 지연속도로 처리할 수 있다고 합니다. 맵-리듀스에 있는 ‘셔플링(Shuffling)’ 단계를 거치지 않아 테이블간의 조인(Join) 작업도 반드시 맵-리듀스 처럼 다대다 커뮤니케이션을 요구하지 않습니다.

[ 임팔라 다이어그램 ]

2012년부터 하둡 분야의 주요 관심사 중에 하나가 임팔라와 타조 같은 ‘SQL 온 하둡(SQL on Hadoop)’ 기술이였습니다. 그 이유는 임팔라 같은 기술이 완성이 되면, 하둡이 실시간으로 대용량 데이터를 분석할 수 있는 기반이 마련이 된 것이며, 기존의 데이터웨어하우스(DW) 제품을 대체할 수 있는 가장 중요한 문제를 해결한 것이기 때문입니다.

기업들은 고가의 하드웨어를 사용하는 데이터웨어하우스(DW) 어플라이언스와 솔루션을 구매하지 않고, 저가의 하드웨어와 솔루션 업체에 종속되지 않는 오픈소스를 확보하게 되어 비용면에서도 큰 이익을 취할 수 있습니다. 

현재 빅데이터 시장에서 주로 사용하고 있는 데이터베이스(Database)는 NoSQL 계통의 데이터베이스입니다. H베이스(Hbase), 카산드라(Cassandra), 몽고DB(MongoDB), 레디스(Redis) 등이 여기에 속합니다. 빅데이터 등장 후에 대용량 데이터 처리 방식을 놓고 관계형 데이터베이스(RDB, Relational Database) 처리 도구로 써 왔던 SQL로 데이터 처리를 계속할 지, 아니면 데이터의 분산 처리가 가능한 NoSQL을 선택할 지는 지금까지도 데이터베이스 관리자(DBA)나 웹서비스 개발자들에게는 고민거리가 아닐 수 없습니다.

RDBMS은 비정형 데이터의 처리가 필요 없던 시절에는 최적의 기술로 인정을 받았습니다. 시간이 흐르고 사진, 동영상, 소셜네트워크서비스(SNS) 등과 같은 비정형 데이터의 출현으로 인하여 DB 관리 시스템에 변화가 생기기 시작합니다.

개발자들은 자연스럽게 비정형 데이터를 쉽게 처리하고 저장할 수 있는 NoSQL로 눈을 돌리기 시작했습니다. NoSQL은 ‘Not Only SQL’ 로서 우리말로 해석하자면 “SQL 뿐만 아니라” 이며, 정해진 틀이 잡혀 있는 SQL에서 벗어나 분산 아키텍처의 확장성, 유연성 등을 장점으로 내세우며 데이터 분산 처리 시 필요한 기술로 자리잡기 시작했습니다.

많은 종류의 NoSQL 데이터베이스가 존재하는 이유로는 부루어의 정리(Brewer’s Theorem)로 알려진 ‘CAP’ 정리를 들수가 있습니다. CAP 정리는 일관성(Consistency), 가용성(Availability), 파티션 수용성(Partition Tolerance) 이라는 세가지 요소들 중에서 모두 만족하기는 힘들고 최대 두 가지 사항에 대해서 만족하면 된다는 이론입니다. 이 때문에  NoSQL 데이터베이스가 많이 존재하는 것입니다. 

[ NoSQL 데이터베이스 선정 기준 ]

NoSQL은 뛰어난 확장성을 가지고 있는 반면에 스카마 변경이 불가능해 데이터에 문제가 발생하면 감지하는게 쉽지가 않고 처리속도에서도 문제가 발생하였습니다. 여기에 SQL과 같이 정해진 언어가 없는데다가 도큐먼트 스토리지 기반으로 되어 있어서 레코드를 개발해 본인이 직접 넣어야 하는 식이다 보니 개발자들로부터 ‘다루기 어렵다’라는 말이 나오기 시작합니다.

이러한 배경으로 현재는 기존의 SQL 기반의 RDB 장점을 수용하고, 확장성과 유연성등 NoSQL의 장점을 가미한 NewSQL이 등장하게 된 것입니다.