빅데이터 표준 플랫폼으로 통하는 하둡 생태계가 중대기로에 놓였다. 하둡과 빅데이터의 엔터프라이즈 시장 진입이 계속 늦어지고 있기 때문이다. 하둡 진영은 SQL 쿼리 분석을 하둡에서 빠르게 수행할 수 있느냐를 열쇠로 보고 관련 기술을 개발하기 위해 경쟁중이다.

 

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

 

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

 

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

 

■아파치 하이브, 살릴까 버릴까

 

진영은 두 갈래로 나뉜다. 하이브를 완전히 대체하는 새 기술을 쓸 것이냐, 하이브를 개선해 속도를 높일 것이냐 등이다. 하지만, 하이브는 사실상 시한부 판정을 받았다는 쪽으로 여론이 흐르고 있다. 하이브를 만든 페이스북조차 '프레스토'란 새로운 DW엔진을 만들었다.

 

하이브를 살려야한다는 입장을 가장 강력하게 내세운 회사는 호튼웍스다. 호튼웍스는 하이브를 최적화하고, 파일포맷 작업을 통해 하이브 쿼리속도를 100배 끌어올리겠다는 비전을 내놨다.

 

호튼웍스는 하이브야말로 SQL온하둡을 위한 최고의 선택이라며, 3단계에 걸친 개선계획을 발표했다. 이것이 스팅거다.

 

▲ 호튼웍스 스팅거 이니셔티브

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

 

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

 

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

 

▲ 임팔라 다이어그램

구도상 하이브에 주요 회사 중에선 호튼웍스만 전력을 기울이는 것처럼 보인다. 하지만, 호튼웍스도 장기적으로 하이브를 유지하자는 입장으로 단정짓긴 어렵다. 바로, 스팅거의 핵심인 테즈 때문이다.

 

테즈는 SQL처리 시 맵리듀스를 대신하는 새 기술이다. 다수 개발자들은 ‘맵리듀스를 사용하지 않는 하이브는 하이브가 아니다’라고 반문한다. 맵리듀스-하이브 조합을 버리는 순간하이브라 부를 수 없다는 것이다.

 

호튼웍스의 입장을 십분 받아들인다고 해도, 하이브의 한계는 뚜렷하다. 호튼웍스가 최근 올린 블로그가 그 한계를 스스로 보여준다.

 

▲ 호튼웍스 하이브 TPC-DS 벤치마크 결과 비교표

TPC-DS 벤치마크에서 호튼웍스데이터플랫폼(HDP)2.0을 사용했을 때 44배의 속도개선을 보였다고 주장했다. 그런데 그 비교대상이 최근 버전인 하이브0.11이 아니라 하이브1.0 버전이다.

 

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

 

하이브의 미래에 대한 징후는 현재 개발되는 하이브0.12 버전의 코드 기여도 통계에서도 나타난다. 호튼웍스가 공개한 자료에 의하면, 하이브0.12 코드라인 기여자 소속회사 통계(8월30일 기준)에서 호튼웍스는 8만3천742라인으로 절반을 훌쩍 넘긴 비중을 차지한다.

 

다음으로 페이스북이 3만148라인을 차지한다. 세번째로 많은 기여자는 한국의 KT넥스알이다. KT넥스알은 1만2천103라인을 기여했다. 다음은 4천244라인의 클라우데라, 3천528라인의 그리드다이나믹스 순이다. 기타는 8천920라인이다.

 

▲ 하이브0.12 코드라인 기여수

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

 

하이브를 개발해야겠다는 오픈소스 개발자들의 의지가 줄고, 호튼웍스란 회사만 의욕을 보이고 있다는 증거다.

 

■왜 하이브와 맵리듀스인가

하둡 생태계는 왜 하이브와 SQL온하둡에 이토록 열을 올리는 것일까. 그는 SQL을 쓸 수 있느냐가 엔터프라이즈 시장에서 하둡을 사용하느냐로 직결되기 때문이다.

 

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

 

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

 

▲ 아파치 타조 프로젝트 로고

하이브의 탄생을 되새겨볼 필요가 있다. 하이브를 만들어낸 회사는 인터넷서비스 회사인 페이스북이다. 하이브를 가장 많이 활용하는 회사도 페이스북이다. 하둡과 하이브를 다양하게 사용하는 회사도 야후, 넷플릭스, 트위터, 페이스북 같은 인터넷 서비스업체다.

 

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

 

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

 

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

 

문을 여는 열쇠는 무엇인가. 엔터프라이즈 기업이 문에 채워놓은 잠금장치는 생각보다 굳건하다. 하둡 업계는 처음엔 하이브를 잠금장치를 여는 열쇠로 여겼지만, 문은 열리지 않았다.

 

일부는 문을 열려면 자물쇠 구멍에 맞는 열쇠모양으로 다듬어야 한다고 판단했고, 일부는 전통적인 열쇠가 아니라 자석이나 RFID 같은 새로운 방식의 도구를 사용해야 한다고 판단했다. 둘 중 어느 판단이 맞는가는 아직 결과가 나오지 않았다.