SQL-On-Hadoop이란?

SQL-On-Hadoop은 HDFS에 저장된 데이터를 SQL 혹은 SQL과 유사한 형태로 처리를 요청하고 분산 처리하는 시스템이다. 분석 로직에 따라 SQL 형태로 처리하면 더 복잡해지는 경우도 있지만, 일반적인 로직은 SQL 형태로 구현할 때 훨씬 간단하게 구현할 수 있다. SQL을 이용해 코드를 작성하면 크게 세 가지 장점이 있다.
첫째, 개발 시간이 단축된다. 맵리듀스보다 훨씬 짧고 간단하게 구현할 수 있으므로 버그 찾기도 쉽고 개발 시간을 단축할 수 있다. 또한 맵리듀스 코드를 작성할 수 있는 사람보다는 SQL에 익숙한 사람이 훨씬 많아서 프로젝트 수행 인력을 구하기도 수월하다.
둘째, 기존 프로그램의 상당수가 SQL로 돼 있다. DW(데이터 웨어하우스)와 같이 대용량 처리가 필요한 기존의 프로그램들의 상당수가 SQL 형식으로 돼 있으므로 처리로직을 이해하고 전환하는데 드는 자원이 크게 줄어든다.
셋째, 직관적이기 때문에 반복 과정을 통해 인사이트를 쉽게 얻을 수 있다. 요구사항이나 데이터가 복잡한 경우 데이터 분석을 위해서 모든 로직을 한 번에 생각해낼 수 없다. 특히 빅데이터와 같이 비정형 데이터가 많고 데이터 사이즈가 큰 경우에는 데이터 탐색 작업에 더 많은 시간을 투자해야 한다. 이때 복잡한 맵리듀스보다는 SQL을 이용해 빠르게 데이터 자체에 대한 탐색→ 분석→ 탐색→ 분석의 반복적인 과정을 통해 유용한 분석 방법과 분석 결과를 얻어 내는 것이 훨씬 유리하다.

하이브(Hive)는 가장 대표적인 SQL-On-Hadoop이다. 보는 관점에 따라서 뒤에서 소개할 Tez를 적용하지 않은 기존의 하이브는 SQL-On-Hadoop에 포함시키지 않기도 한다. 이때는 하이브를 제외한 나머지들을 차세대 SQL-On-Hadoop이라고 한다. 하이브는 하둡(HDFS) 위에서 동작하는 데이터 웨어하우스 시스템으로서 데이터 요약, 데이터 분석 등의 기능을 제공한다. 하이브는 콘솔이나 JDBC를 이용해 HiveQL이라는 하이브에서 사용되는 SQL로 처리를 요청하면 파서(Parser)를 통해 명령을 분석하고, 해당 명령을 맵리듀스 형태로 변환한 후, HDFS에 분산ㆍ저장된 데이터를 읽어와서 맵리듀스 프레임워크를 이용해 분산 처리한다.
그러나 하이브는 맵리듀스의 특성상 하드디스크를 많이 사용하고 불필요한 기록을 하는 경우가 많으며, Job을 준비하는 시간 등 속도 저하의 요인이 많다. 그러므로 결국 빠른 처리가 필요한 비정형 쿼리(ad-hoc query 혹은 Low Latency Query)나 OLTP 영역에서는 기존 RDBMS를 사용해야 한다.
최근에 나온 SQL-On-Hadoop은 맵리듀스를 이용하지 않고, 기존의 낮은 성능을 극복한 자체 엔진을 사용해 실시간 쿼리가 가능하다. 참고로 맵리듀스 엔진을 사용하지 않더라도 Yarn의 리소스 관리 기능이나 하둡 2.0(HDFS)의 라이브러리를 참조하는 경우가 많으므로 SQL-On-Hadoop을 사용하기 위해서는 가능한 하둡 2.0 이상의 시스템을 도입하는 것이 좋다.

차세대 SQL-On-Hadoop의 특징

하둡이 2004년 구글에서 발표한 GFS와 맵리듀스의 영향으로 탄생했다면, 최근에 나오고 있는 ‘차세대 SQL-On-Hadoop’은 2010년 구글에서 발표한 Dremel의 영향을 많이 받았다. 현재 Dremel을 기반으로 아파치의 Drill, Hive On Tez(이하 tez), 타조(Tajo), 샤크(Shark, 혹은 Spark SQL), 클라우데라(Cloudera)의 임팔라(Impala), 페이스북의 Presto 등 여러 회사 주도로 다양한 오픈소스가 나오고 있다. 여기서는 이 중에서 많이 쓰이거나 성장 가능성이 높은 하이브, 타조, 샤크, 임팔라를 비교해 보겠다. 각각의 SQL-On-Hadoop은 맵리듀스가 아닌 새로운 엔진을 사용해 비정형 쿼리(ad-hoc query)가 가능하고, 하이브와의 호환을 위한 Metastore(테이블 정보 저장소) 사용 등의 공통점이 있지만 몇 가지 차이 점이 있다.

폴트톨러런스

분산 처리시스템은 예전 메인프레임에 비해 상대적으로 낮은 성능을 가진 서버 여러 대를 모아서 처리하는 것을 의미한다. 그러다 보니 네트워크 설정이 복잡해지고 디스크도 여러 개를 사용해 장애가 발생할 확률이 높아진다. 또한 애플리케이션도 더 복잡해져서 작업도중 실패하는 경우도 있다.
맵리듀스에서는 분산 처리하는 작업들 중에 일부가 실패하더라도 처음부터 작업할 필요 없이 오류가 발생한 태스크나 장애가 발생한 서버에 할당된 태스크만 다시 시작해 작업을 마칠 수 있도록 구현됐다. 이것을 폴트톨러런스라고 한다. 그런데 폴트톨러런스가 가능하기 위해서는 중간에 데이터를 어딘가에 저장해 놓아야 하는데 대부분 하드디스크를 이용하기 때문에 하드디스크에서 성능 저하가 현상이 발생한다. 이러한 이유 때문에 폴트톨러런스 기능은 스루풋과 트레이드오프 관계를 가진다. 오류가 발생할 가능성이 낮고 처리할 데이터가 적을 때, 폴트톨러런스 기능을 사용하지 않으면 중간 데이터 기록을 하지 않아도 되므로 빠른 응답속도를 기대할 수 있다. 그러나 데이터가 큰 경우에 폴트톨러런스 기능이 없으면 오류가 발생했을 때 처음부터 다시 작업을 해야 하므로 작업 소요시간이 더 길어질 수 있다.
따라서 각각의 오픈소스가 추구하는 목표에 따라 폴트톨러런스 기능 도입 여부를 달리하고 있다. 예를 들어 하이브나 타조, 샤크의 경우 데이터가 큰 작업(Long Time Query)을 지원하기 위해 폴트톨러런스 기능을 제공하고 있고, 임팔라는 빠른 응답속도가 가능하지만 폴트톨러런스 측면에서 상대적으로 취약하다. 지원 여부는 솔루션들의 장단점이라기보다는 사용 목적에 따른 선택을 하기 위한 특징 중 하나다.

다이내믹 스케줄링

분산환경에서 큰 데이터를 처리하기 위해서는 폴트톨러런스 뿐만 아니라 다이내믹 스케줄링(Dynamic Scheduling) 기능 또한 중요하다. 다이내믹 스케줄링은 고정 스케줄링(Fixed Scheduling)과 반대되는 의미로, 각 노드에서 한 번에 실행할 수 있는 태스크를 할당 받고 해당 태스크가 완료되면, 다시 태스크를 할당 받는 것을 의미한다. 고정 스케줄링은 작업이 시작될 때, 각각 균등하게 분할하므로 훨씬 간결하지만, 특정 노드에서 작업 시간이 더 걸릴 수도 있다. 하이브, 타조, 샤크(Shark)는 다이내믹 스케줄링을 지원하고, 임팔라는 고정 스케줄링을 지원한다.

인메모리 지원여부

데이터 처리에 있어서 병목 현상이 발생하기 쉬운 지점이 하드디스크다. 그런데 HDFS의 모든 데이터는 하드디스크에 저장돼 있으므로 SQL-On-Hadoop들은 최대한 불필요한 쓰기/읽기를 지양한다. 그리고 거기에서 한발 더 나아가서 전부 혹은 일부 데이터를 메인 메모리에 올려서 고속 처리가 가능하도록 만든 오픈소스들도 있다.
하이브와 타조는 메모리를 사용하지만, 상대적으로 하드디스크 위주로 사용하면서 가능한 불필요한 쓰기/읽기를 피하도록 설계됐다. 임팔라는 하드디스크도 사용하지만, 상당수의 데이터를 메모리에 올려서 고속 처리를 한다. 그러므로 다른 오픈소스보다 빠른 응답 속도를 기대할 수 있지만, 큰 데이터를 처리할 경우 Out of Memory(OOM)가 발생하는 경우가 많다. 또한 엄밀히 말해서 메모리를 스토리지로 사용하는 것도 아니다. 샤크는 캐시 기능을 제공해서 빈번히 사용되는 데이터는 캐싱을 통해 미리 메모리에 전부 올릴 수 있다. 이 경우 수 배에서 수십 배 빠르게 조회가 가능하며, 설정에 따라서 데이터의 일부만 혹은 전부를 캐싱할 수도 있다. 물론 디스크에만 저장해 처리하는 것도 가능하다.

구현 언어

하이브와 타조(Tajo)는 자바, 임팔라는 C++, 샤크는 스칼라(Scala)로 구현됐다. 모두가 하나의 언어로 구현된 것은 아니다. 여러 가지 언어가 같이 쓰이지만, 50퍼센트 이상 사용된 언어를 기준으로 한 것이다. 자바는 가장 많이 사용되는 언어이고 상대적으로 쉬우므로 오픈소스의 최대 장점인 코드를 통해 내부 로직을 이해하고 필요 시 코드를 수정할 수 있다는 측면에서 유리하다. C++은 임팔라에서 속도를 위해서 선택한 언어다. 자바 다음으로 범용적으로 사용되고 있고, 자바에 비해서 훨씬 빠른 속도로 작동할 수 있다. 스칼라는 최근에 해외에서 각광 받는 언어 중 하나다. 함수형 언어의 특징과 객체지향 언어의 특징을 모두 갖고 있다. 또한 자바의 자바 가상 머신에서 실행할 수 있으며, 자바 API를 약간 수정해 사용할 수도 있다.

속도

처리 속도는 논쟁이 많은 부분이다. 각 오픈소스를 주도하는 단체 혹은 업체에서 각자의 장점을 부각하는 테스트를 많이 하기 때문이다. 또한 설정 방법이나 쿼리 종류에 따라서도 결과가 다르게 나오기 때문에 명확히 어떤 것이 좋다고 말하기는 어렵다. 물론 TPC 벤치마크와 같이 어느 정도 공인된 테스트 방법이 있지만, 이것 또한 명확히 판단하기에는 무리가 있다. 아래와 같이 테스트 환경이나 방법, 버전 등이 조금씩 다르고 성능 측정 결과도 다르게 나타난 공개 자료를 볼 수 있다.

[그림 Ⅲ-2-1] 임팔라를 내놓은 클라우데라 블로그에서 공개한 자료

[그림 Ⅲ-2-2] 스파크를 만든 Berkeley amplab에서 공개한 속도 비교자료

[그림 Ⅲ-2-3] 타조를 주도하고 있는 그루터에서 테스트한 비교자료

어떤 오픈소스가 무조건 빠르다고 하기보다는 본인의 환경과 비즈니스 요건에 맞게 선택해야 하기 때문에 여기서는 각 오픈소스의 설계 방향에 따른 특징으로 구분하고자 한다.

• 하이브는 상대적으로 Long Time Query를 처리하는 데 용이하다. 하이브가 기존의 DW를 빅데이터용으로 대체하기 위해 만들어졌고, 나온 지도 오래됐기 때문에 가장 안정적인 기능을 지원한다고 볼 수 있다.
• 임팔라는 작은 데이터에 대해서는 다른 오픈소스에 비해 더 빠른 결과를 지원한다. 그러나 Long Time Query를 제대로 수행하지 못하거나 데이터 크기가 커질수록 성능이 떨어지는 경향이 있다.
• 타조의 설계 목표는 Long Time Query와 Online Query(Low latency) 모두를 지원하는 것이다. 실제로 테스트 해보아도 두 가지가 다 가능하고 성능도 우수하지만, 상대적으로 역사가 짧기 때문에 안정성 문제나 Long Time Query는 하이브에 비해 느린 경우도 있다. 또한 임팔라에 비해 Online Query가 느린 경우도 있다.
• 샤크는 타조와 비슷하게 두 가지 방식이 모두를 지원하며, 메모리에 데이터를 올려 놓으면 확실히 좋은 성능을 지원한다.

이제부터는 위에서 언급한 SQL-On-Hadoop 중에 대표적인 하이브와 타조, 샤크에 대해 알아보자. 선정 기준은 오픈소스이면서 무료이고, 가장 활발하게 코드가 업데이트되는 프로젝트를 우선으로 선정했다. 구글의 BigQuery나 아마존(Amazon)의 키네시스는 충분히 좋은 성능에 편리함을 지원하지만, 유료이다. 구글 논문을 통해 SQL-On-Hadoop(일반적인 오픈소스)의 시초가 됐던 아파치 드릴은 업데이트가 잘 안되고 있다. 또한 클라우데라의 임팔라는 오픈소스이지만 일반인의 코드 기여 기회가 제한돼 있고, 스파크를 선두에 내세우면서 업데이트가 제대로 이뤄지지는 않고 있다. 마지막으로 페이스북의 프레스토 또한 일반인의 코드 기여 기회가 제한된 편이고 범용적으로 사용한다기보다는 페이스북 내부에서 사용하기 알맞게 구성돼 있어서 제외했다.
SQL로 사용할 수 있지만, 기존 RDBMS와는 다른 점이 많으므로 하이브를 설명할 때는 내부 작동방법이나 세부적인 사용법 위주로 단계별로 자세히 설명하겠다. 그리고 타조와 샤크는 하이브와 RDBMS에 비해 크게 다른 점이 없으므로 설정방법이나 하이브와 다른 점 위주로 설명한다. 추가로 오픈소스들의 버전의 자주 바뀌면서 기능이나 다운로드 경로 등이 바뀌는 경우가 많이 있으니 참고하도록 하자. (자료사용을 허락해주신 Spark Committers(Spark-Apache), 최종욱(Hive-Hortonworks), 최현식(타조 창안자, Gruter), 조현종님(Tadpole DB Hub)께 감사드립니다.)