티스토리 뷰

Hadoop에 SQL로 Query한다 하면 Hive가 기본이지만, 비즈니스 니즈에 따라 Impala를 위시한 SQL on Hadoop 솔루션이 많이 나왔습니다. 오픈소스부터 상용, 상용 서브스크립션 제품까지 다양합니다.


Hive는 배치 잡에 걸맞는 질의 수단이기 때문에 여타의 SQL on Hadoop 솔루션은 질의결과를 바로(빨리) 받아야 하는 비즈니스 니즈를 충족하고자 나왔다고 해도 무리가 없겠습니다. Hive on Tez, Hive on Spark가 발전하는 중이지만 아직은 다른 SQL on Hadoop 솔루션들이 빠릅니다. Hive보다 빨라야 존재의의가 있다고도 하겠습니다. 민감하기도 하고, 변동이 빠르기도 한 분야라 상용 솔루션 이름은 굳이 언급하지 않겠습니다.[각주:1]


SQL on Hadoop을 구분하는 기준은 몇 가지가 있습니다.


우선 Hive와는 별개의 수단으로 Hadoop 파일에 접근하는지 여부입니다. 상용 DW나 federation 솔루션(혹은 Data virtualization 솔루션) 중에는 가상 테이블 류로서 Hive에 질의를 대행하는 기능을 제공하는 제품이 있습니다. 사전적 의미로는 SQL on Hadoop라고 할 수 밖에 없긴 한데, 성능을 감안하면 신규 도입할 이유가 없습니다.


본격적인 구분은 Hive metastore 공유 여부입니다. Impala와 같이 공유하는 솔루션을 도입하면 빠른 질의를 필요로 할 때는 Impala를, 대용량 데이터를 배치 잡으로 다룰 때는 Hive를 병용 가능합니다. 반면 공유하지 않는 솔루션은 Hive를 같이 쓰지 못합니다. 대개의 MPP 솔루션들이 Hive와는 별개로 파일 시스템만 Hadoop을 사용하는 방식으로 사용합니다. 빅데이터 플랫폼을 운영하다 보니 Hive를 써야만 할 때가 꼭 있더군요. 개발 면에서도 그렇고 다른 상용 솔루션들도 Hive만 지원할 때가 많긴 합니다. 반면에 두 가지를 다 지원하기보다는 한 가지만 지원하는 쪽이 더 안정적이기도 합니다. 취향에 따라 골라 쓰라는 말 밖에 드릴 수가 없네요.


부수적으로는 HBase 지원수준입니다. 아무래도 NoSQL DB가 필요한 때가 있으므로 HBase에도 SQL 질의를 할 수 있으면 좋긴 합니다. 자바 개발자라면 put/get을 잘 갖춰 쓰면 된다고도 할 수 있겠지만, 일반적인 SQL을 쉽게 활용 가능해도 유리합니다. HBase 또한 SQL on Hadoop 솔루션의 지원방식과 수준이 꽤 다른 편입니다. 기존에 도입한 솔루션이 HBase를 제대로 지원하지 않는다면 Phoenix 솔루션을 써도 무방합니다. 개발과 효율 면에서는 다소 손해를 보겠습니다만.


조직 내에 Linux를 비롯한 하둡 에코 시스템을 운영할 역량이 있다면, RDB에 SQL로 개발하던 인력들도 쉽게 적응하며 비즈니스에 필요한 성능을 뽑아냅니다. R이나 다른 분석 도구를 쓰는 인력들 또한 물 만난 고기가 됩니다. 고가의 MPP를 쓸 필요가 크게 줄어듭니다. 한국 엔터프라이즈 시장은 오래된 특정 제품에 대한 쏠림이 심한 편인데 SQL on Hadoop은 거리낌을 잠시 누르고 시도할 만합니다. 괜찮은 배포판도 많기 때문에[각주:2] 내부인력에게 시간을 박하지 않게 할당해 준다면 무난하게 도입 가능합니다.

  1. 궁금하시면 비밀 댓글로 문의해 주세요. [본문으로]
  2. 상용 수준인 SQL on Hadoop 솔루션이 딸린 배포판도 있음 [본문으로]
저작자 표시 동일 조건 변경 허락
신고
댓글
댓글쓰기 폼