[Cloudera 블로그 번역] 2014/01/07 Impala 와 Hive 전략에 관해서

 

일어 원문 : http://www.cloudera.co.jp/blog/20140107-impala-v-hive.html - 일본 Cloudera Blog

영어 원문 : http://vision.cloudera.com/impala-v-hive/ - 미국 Cloudera Blog

 

- 본 글은 위 일어 원문 링크의 글을 번역하였습니다.

- 일어 원문 글은 위 영어 원문 글을 번역한 글입니다. 번역투가 많아 영어 원문도 살짝 참조하였습니다.

 


 


 새해 복 많이 받으세요. 여러분들 덕분에 올해도 무사히 새로운 한 해를 맞이할 수 있게 되었습니다.

 

 자 그럼, 올해 첫 블로그 기사는 작년말에 CSO (Chief Strategy Officer) Mike Olson(@mikeolson)이 공개한 블로그 포스트, Impala v Hive를 소개하려 합니다. 2014년도 잘 부탁 드립니다.

 

 


 

 저희 회사는 일 년여 전에 Cloudera Impala를 공개 했습니다. 회사에게 있어 좋은 런칭 이었죠. 플랫폼에서 고객들이 중요하게 여기는 몇 가지 점들이 더욱 좋아졌고, 사업면에서 큰 성과를 거둘 수 있게 되었습니다. 이전의 제품은 대화형 SQL 처리량에 대응하지 못 했거든요.

 

 Impala 공개의 영향으로 Apache Hadoop 에코시스템에서 SQL 시장의 공유를 바라는 벤더들 간의 격한 경쟁에 불을 붙여 여러 주장과 반론이 난무했습니다. 성능 면에서 과장된 말들이 자주 보이는데 (저희는 저희의 성능 평가 결과가 꽤 마음에 들었습니다만) 여기서는 다른 방향에서 이 문제에 대해 접근 하려 합니다.


 저는 기존 Apache Hive 프로젝트 개선에 의한 것이 아니라, 새로운 프로젝트로 처음부터 Impala를 개발하게 된 Cloudera의 결정에 대해 자주 질문을 받습니다. 사람들은 기존의 코드가 있다면 거기서부터 출발 하는 것이 최선이라고 생각하니까요.

 

 하지만 그것은 틀립니다. 저희는 그 문제에 대해 장기간 진지하게 생각 했고, 최선의 방법은 Hive와는 다른 원리를 기반으로 새로운 오픈소스 프로젝트를 설계하는 것이라고 결론 내렸습니다. 그게 바로 Impala 입니다. 작년 1년간 저희의 경험은 이 전략에 대한 확신을 강하게 만들었습니다.
 어떤 것인지 한 번 보시죠.

 

Pig와 Hive 의 기원

 

 Hadoop 초창기 버전은 데이터를 다루기 위한 방법으로는 오직 한가지, MapReduce만 지원 했습니다. 이 플랫폼은 대량 데이터를 저장, 처리, 분석 할 목적으로 Yahoo! 와 Facebook 에서 넓게 사용 되었습니다. 두 회사 모두 이 플랫폼의 가치를 잘 이해했지만, 시스템에서 유용한 성과를 얻기 위해 MapReduce에서 동작하는 Java 코드를 짜는데 많은 시간이 필요 했습니다.

 

 두 회사는 보다 빠르게 동작하고, 비개발자가 데이터를 직접 다룰 수 있기를 원했습니다. Yahoo!는 이를 위해 Apache Pig란 명칭의 독자 언어를 만들어 냈습니다. Facebook은 사람들에게 새로운 기술을 교육하는 것 보다 기존 기술을 활용하는 방안을 생각하여 Hive 라는 명칭의 SQL 시스템을 구축 했습니다.


 이 두 가지는 매우 흡사한 원리로 동작합니다. 유저는 Pig 나 Hive 중 하나로 쿼리를 날립니다. 파서(parser)는 쿼리를 읽어 들여 유저가 무엇을 바라는지를 이해하고, 일련의 MapReduce Job을 실행하여 동작하게 합니다. MapReduce를 사용함으로써, Pig와 Hive를 쉽게 구축 할 수 있었기 때문에 Yahoo! 와 Facebook의 엔지니어는 다른 새로운 기능에 시간을 쓸 수 있었습니다.


역사의 대상

 

 보통 Hadoop에 대한 비판은 MapReduce가 배치(batch) 데이터 처리 엔진이란 것입니다. Hadoop은 데이터 매니지먼트 업계를 근본적으로 변화 시키는, 굉장히 유용한 배치 데이터 처리 엔진임은 분명합니다. 하지만 설계상 MapReduce는 매우 무거운데다, 하이 레이턴시(high-latency) 실행 플레임워크입니다. 또, job 개시가 느리고 여러 종류의 오버헤드를 갖고 있다는 것은 공정한 비판이라고 생각합니다.
 Pig와 Hive는 이들 특성을 이어 받고 있습니다.

 

 초기에 이런 것들은 별 문제 되지 않았습니다. 분석이나 보고를 위해 자신의 BI 툴을 Hadoop과 연결하는 사람은 없었습니다. Yahoo!와 Facebook은 보다 많은 유저가 데이터를 직접 다룰 수 있기를 원했습니다. 그 유저들이 동작이 실행 되고 있는 사이에 컴퓨터 화면을 보면서 잠시 가만히 앉아 있어야 해도 그리 큰 문제는 아니었습니다. 느린 쿼리라도 쿼리가 없는 것 보다는 나으니까요. 이런 초기 워크로드의 대부분은 데이터 변환 처리일 뿐 쿼리도 분석도 아닙니다. 배치는 이 부분에 대해서는 문제 없었습니다.


 관계형 데이터 베이스에 데이터를 전송 하기 위해 ODBC나 JDBC를 이용하는 툴은 많은 벤더를 통해 입수 할 수 있습니다. 하지만 이런 툴을 Hadoop에서 동작 하도록 하는 것은 정말 큰 문제입니다. 데이터를 이런 방법으로 쉽게 다루고 싶어하는 비즈니스 유저는 굉장히 많습니다.


 이에 저희는 먼저 광범위하게 이용 가능한 Hive용 ODBC 드라이버를 릴리즈 했습니다. 대형 벤더들은 보고용 툴을 저희 플랫폼에 연결 하기 위해 그 드라이버를 사용하였습니다. 하지만 이런 툴을 사용하는 것은 정말 참기 힘든 일이었죠. 유저는 쿼리를 작성하고 버튼을 누른 후 기다리고, 기다리고, 또 기다립니다. 몇 십 년에 걸친 경험에 의해 사람들은 데이터베이스에 실시간 반응을 기대하게 되었습니다. MapReduce 상에 구축된 Hive는 기대에 따른 결과를 낼 수 없었습니다.

 

 실제로 Hive 성능은 일부 벤더의 툴이 전혀 동작하지 않는 것을 의미 했습니다. 툴은 응답이 빨리 오지 않았을 때에 데이터베이스가 고장 났다고 여겨 유저에게 에러를 보냈습니다.
 이에 많은 유저들이 화를 냈습니다.


Impala 개발

 

 저희 회사에서는 Hadoop 에코시스템에서 SQL의 활용성에 중점을 두었고 차분히 대체 방안에 대한 작업을 시작했습니다.


 데이터베이스 업계에서는 스케일아웃 분산쿼리 실행 엔진의 구축에 관해 수십 년의 경험이 있습니다. 이는 학술 및 상용 연구가 활발한 분야입니다. 매우 우수하고 빠른 분산 SQL 시스템이 다수 존재 하지만, 그 중 어느 것도 MapReduce형 아키텍처를 사용하지 않습니다.

 

 여기서 저희는 Hadoop 아키텍처를 처음 만들어 낸 Google에 눈을 돌렸습니다. Google은 빅데이터로의 SQL 액세스를 얻기 위해, MapReduce 를 기반으로 하지 않는 독자적인 새로운 분산 쿼리 실행 엔진을 개발하고 있었습니다.


 저희는 모든 선택지를 깊이 생각한 후, Google과 완전 똑같은 일을 해보기로 선택했습니다.  성능에 대해서는 낙관적이었기 때문에 Impala라고 명명했습니다.


 동시에 프로젝트 리더로 Marcel Kornacker를 고용했습니다. Marcel은 한 때 Google에서 일한 적이 있었고, 또 1990년대에 캘리포니아 대학 버클리 캠퍼스 대학원에서 데이터베이스 시스템에 대한 연구를 했던 인물입니다. Marcel은 분산 시스템 및 데이터베이스 커널에 관해 숙련된 엔지니어 팀을 편성하여 개발에 착수했습니다.


 Cloudera 클러스터 내의 모든 노드에는 Impala 코드가 들어가 있어 SQL 쿼리가 실행 되는 것을 기다립니다. 그 코드는 각 노드 상에서 바로 MapReduce 엔진과 함께 - 그리고 Apache HBase 엔진 (MapReduce 를 기반으로 하지 않는), 검색엔진 (MapReduce를 기반으로 하지 않는) 및 고객이 선택해서 디플로이(deploy) 할 수 있는 SAS 및 Apache Spark 와 같은 서드파티 제품 엔진과 함께 동작합니다. 이들 엔진은 모두 완전 동일한 데이터로 접근 가능하며, 유저는 해결하려는 문제에 따라, 그 중 어떤 것을 사용할지 선택 할 수 있습니다.


 Impala는 SQL 쿼리를 오늘날 Hive가 의존하고 있는 map/shuffle/reduce 등의 다른 처리 플레임워크로 번역할 필요가 없습니다. 이 때문에 Impala는 그들 단계에서 받는 레이턴시의 영향을 받지 않습니다. Impala 쿼리는 바로 결과를 돌려줍니다. Impala는 MapReduce와 같은 범용 분산 처리 시스템과는 달라, SQL 쿼리 실행에 관해서 처음부터 설계 되어 있기 때문에 그 특정 워크로드에 대해서는 굉장히 우수한 성능을 제공할 수가 있는 것입니다.

 

왜 Hive를 개선하지 않는가?

 

 

 단도직입적으로 말해, Hive는 리얼타임 분산 SQL 처리에 있어서는 틀린 아키텍처이기 때문에 저희는 Impala 개발을 선택했습니다. 병렬 SQL 데이터베이스 업계는 포화 상태입니다. 어느 전통적인 관계형 데이터베이스 벤더도 (즉 IBM, Oracle, Microsoft, ParAccel, Greenplum, Teradata, Netezza, Vertica) MapReduce와 같은 것은 사용하지 않습니다.

 

 shared nothing 으로 스케일 아웃 하는 시스템의 차세대 (지명도가 높은 것은 Google의 F1 이지만, 이 외에도 그렇게 알려지지는 않은 NuoDB 등의 선택지도 있습니다) 는 모두 MapReduce 기반이 아닌 네이티브 분산 쿼리 실행에 의존하고 있습니다.

 

 

 Facebook은 초기에 MapReduce 상에 Hive를 구축했지만, 그건 Hadoop SQL 로 최단의 길이었기 때문입니다. 시간 요건을 전제로 했을 때에 현명한 결단이었죠. 하지만 이 회사는 최근 SQL 을 통한 데이터로의 리얼 타임 접근을 위한 차세대 쿼리 실행 엔진인 Presto 를 발표 했습니다. Presto는 Impala와 같이 분산 쿼리 실행 엔진으로써 새로 처음부터 구축 되었습니다.

 

 

 Hive를 개선, MapReduce 튜닝 외 고속화 및 레이턴시 단축은 확실히 가능합니다. 하지만 Hive는 설계상 항상 오버헤드가 존재합니다. 또 네이티브 분산 SQL 엔진으로써 구축된 후속 시스템이 회피하는, 성능에 불리한 조건이 발생합니다.

 

 

 Hive를 잘 실행하기 위해 MapReduce를 튜닝 하는 것은 잘못된 일입니다. MapReduce는 범용 배치 처리 워크로드에 뛰어나며, MapReduce를 특정 쿼리 워크로드로 특수화 하는 대책은 SQL을 쓰지 않는 유저에게 있어 부담을 더하는 일이 될 수 있습니다. 초기에는 단일 엔진이 Hadoop상에서 모든 작업을 실행한다는 생각은 의미가 있었습니다. 오늘날에는 (Hbase, Apache Accumulo, Search, Myrrix, Spark 그 외의) 전용 엔진이 급증하고 있습니다. 이것은 대체로 각 엔진이 특별히 튜닝 되어 있는 다른 워크로드를 희생 시키는 일 없이 플랫폼 기능을 확장합니다.

 

Impala 커뮤니티

 

 Cloudera에서는 2012년 후반 Apache 소프트웨어 라이센스에서 발표하기 전까지 거의 2년간 Impala에 몰두 해 왔습니다. 저희가 그렇게 한 것은 Hadoop 상에서의 리얼 타임 SQL이 중요한 문제라고 생각 했기 때문입니다. 그리고 저희는 실제로 제품을 전달 할 수 있기 전까진 저희의 의도를 나타내고 싶지 않았습니다. 저희 회사에는 Impala 개발에 전념하는 중요한 팀이 있습니다.


 Hive는 리얼타임 SQL용의 최신 분산 쿼리 엔진과 성능 면에서 경쟁할 수는 없습니다. 하지만 Hive 에코시스템에는 MapReduce에 의존하지 않는 구성요소가 있습니다. 저희 회사는 그것들을 Impala와 통합 하는 일에 전념 해 왔습니다. 그리고 이런 성과로 Hive 기능 강화에 계속 공헌하고 있습니다.

 


 예를 들면 메타데이터 레파지토리로써 HCatalog나 Hive 메타스토어 커뮤니티와 협력하고 있습니다. 다수의 다른 엔진 간에서 데이터를 공유하는 것은 그것을 기술하는 메타데이터 공유를 필요로 하며, HCatalog는 저희 회사의 엔터프라이즈 데이터 허브 전략의 핵심 부분을 이룹니다. 저희 회사에 따른 Hive 메타스토어나 HCatalog의 이용은 Hive, Impala, MapReduce, Pig 및 REST의 각 어플리케이션이 테이블을 공유 할 수 있는 것을 의미합니다.


 Twitter 사, Cloudera 및 Criteo 사는 Impala가 애널리틱스 데이터베이스 워크로드를 훨씬 빠르게 실행 할 수 있도록 하는 Columnar format 인 Parquet(파케이) 로 협력하고 있습니다. 기여하고 있는 사람들은 Parquet 를 Cascading, Pig, Hive 까지와도 통합하려 하고 있습니다.


 데이터베이스 어플리케이션에서 유저 베이스 및 롤 베이스 인가와 접근 제어는 중요합니다. Cloudera는 Impala를 위한 보안 정책을 정의하고 적용하기 위해 Sentry 프로젝트를 만들어 Oracle이나 그 외 벤더와 협력하고 있습니다. Sentry가 없으면 각 Hive 유저는 다른 여러 Hive 유저에 속하는 모든 테이블과 모든 레코드를 참조 해 버릴 수 있게 됩니다. 저희 회사는 Sentry를 Hive 에 통합하기 위한 코드에 기여 해 왔습니다. 하지만 아직 상용 배포에는 포함되어 있지 않습니다.

 

누가 Impala를 제공하는가?

 

 오픈 소스는 엔터프라이즈 유저가 소프트웨어와 서비스의 최고의 조합을 최선의 가격으로 제공하는 기업과 함께 일할 수 있는 것을 의미 하는 것으로 훌륭한 일입니다. 엔터프라이즈 유저는 단일 벤더에게 구애받지 않습니다.


 Impala가 성공하기 위해선 다수의 기업이 제공하고 지원 해야만 합니다.

 


 물론 여러분은 Impala를 Cloudera에서 받을 수 있습니다. Impala는 저희 회사 플랫폼의 중요 핵심이자, 저희 회사 엔터프라이즈 데이터 허브 전략의 중요 부분입니다. Impala는 저희 회사의 재판매업자로부터도 구입 가능합니다. Oracle은 Big Data Appliance에 있어서 Impala를 포함하는 Cloudera의 완전한 엔터프라이즈 데이터 허브 소프트웨어 세트를 제공하고 있습니다. IBM의 Softlayer 자회사 Verizon Business Systems, CenturyLink Savvis, T-Systems 그 외를 포함하는 클라우드 벤더가, 각 회사가 관리하는 클라우드 내에서의 '서비스형 엔터프라이즈 데이터 허브'를 제공하고 있으며 그 안에는 Impala가 포함되어 있습니다.


 Amazon은 Elastic MapReduce 또는 EMR 이라 불리는 독자적인 빅데이터 서비스를 제공하고 있습니다. 마침 지난주 Amazon은 MapReduce 및 HBase와 함께 그 회사의 EMR 제품의 일부로써 포함되는 서드파티 제품 엔진으로 Impala 제공을 발표 했습니다. Amazon의 지지는 저희 회사에겐 정말 멋진 일이었습니다. 이는 저희 회사의 아키텍쳐를 신뢰하고 있다고 여기는 증거이며, 잠재 유저를 새로 얻을 수 있는 일입니다. 마찬가지로 보다 많은 어플리케이션 및 툴 벤더가 Impala와 통합할 것을 의미합니다.


 제 견해로 가장 흥미 깊은 것은 Cloudera의 경쟁 상대가 지금은 고객에게 Impala를 제공하고 있다는 사실입니다. MapR의 고객은 그 회사의 상용 제품으로 Impala를 이용할 수 있습니다.


 5년 이상에 걸쳐 Cloudera는 Hadoop 에코시스템에 있어서 새로운 오픈 소스 코드를 구축하고 서비스하고 있습니다. 저희 회사는 아주 광범위한 프로젝트에 걸쳐 일하고 있는 공헌자와 커미터를 거느리고 있습니다. 저희 회사는 경쟁 상대에게 그 제품의 일부로 거론된 프로젝트 - Apache Flume, Apache Sqoop, Hue, Apache Bigtop - 을 생산 해 왔습니다.


 Impala는 그 리스트에 이어진 새로운 하나의 예에 지나지 않습니다. 또, 저희 회사 오픈 소스 플랫폼과의 관계가 깊고, 진짜라는 증거의 한 측면에 지나지 않습니다. 말로만 그런 것이 아니라, 저희는 초창기 때부터 스스로의 발언에 따라 살아 왔습니다. 여러분이 오늘날 저희 회사의 파트너와 경쟁 상대 양 쪽을 포함하는 8개 이상의 서로 다른 벤더로부터 Impala를 손에 넣을 수 있다는 사실은 저희 회사 오픈 소스 전략을 틀림없이 증명 하고 있습니다.

 

왜 이렇게 많은 SQL 엔진이 있는가?

 

 이 업계를 잘 보세요. 시장에 존재하는 벤더 수와 적어도 같은 수의 Hadoop에서 동작하는 SQL 엔진이 존재하고 있다는 걸 알게 될 겁니다. Cloudera는 Impala를 제공합니다. IBM은 그 회사의 BigSQL 제품을 좋아 하겠죠. Pivotal은 오로지 HAWQ에 커밋하고 있습니다. Hortonworks는 Hive에 충성을 선언 했습니다. 초기 참가자인 Hadapt은 NoSQL 워크로드도 받아 들이는 방향으로 야심을 확대 하였지만, 여전히 Hadoop 플레임워크 상의 SQL을 제공하고 있습니다. 이 외에도 아직 더 있습니다.


 이것은 기존의 관계형 데이터베이스 기업을 수십 년에 걸쳐 내몰아 온 것과 같은 원동력입니다. 모두가 표준 언어 구조를 구현하고 모든 벤더가 성능과 서비스 확대 면에서 경쟁합니다. 시장에는 이들 제품을 뭉개고 단일 제품으로 만들 수 있는 수 보다도 훨씬 많은 수의 기존 제품이 존재 합니다. 솔직히 말해서 너무 많은 액수의 자금을 벌어 들이고 있어 투자 공유를 내모는 것까지는 다다르지 않았습니다.

 


 그렇다고는 해도 좋은 소식이 있습니다. 이들 SQL, JDBC 및 ODBC 엔진에 데이터를 전송하는 어플리케이션은 이식 가능하며, 유저에게 어려운 일이 아닙니다. 저희는 오픈 소스는 기본 원칙이며 Impala가 승리한다고 믿고 있습니다. 그럼에도 언어 표준의 존재에 따라 자사제품과 연계하는 서드파티 제품에 의한 최고의 에코시스템과 결합된 성능 및 순수한 계산 능력, 이 두 관점에서 경쟁을 하지 않을 수 없다고 인식하고 있습니다. 이 경쟁의 원동력은 저희 회사의 고객에게 있어서도, 시장 전체에 있어서도 최선일 것입니다.

 

Pig 와 Hive는 어디로 가는가?

 

 Yahoo!가 작성한 데이터 플로우형 언어인 Pig는 기존 벤더와의 경쟁이 없습니다. 그 언어는 강력하지만 그 유저 기반은 대체가 되는 구현을 제공할 수 있는 대형 벤더의 주목을 모으기에는 너무 작습니다. Pig 쿼리를 실행하는데에 MapReduce 보다 뛰어난 방법은 존재 하겠지만, 그것이 지원하는 워크로드 (거의 대부분은 변환입니다) 를 기본으로 했을 때에 그것은 중요하지 않습니다. 이 소프트웨어는 현행의 형식으로 충분히 좋으며, Pig 커뮤니티는 그 기능을 계속 강화하고 있습니다.


 다른 한 편으로 Hive는 SQL 이고, SQL은 우주에서 가장 사용되고 있는 데이터베이스 언어입니다. 모두가 그것을 알고 있죠. 모두가 Hive가 빨라지는 것을 기대하고 있고 많은 기업이 Hive를 지원하고 있습니다.

 


 따라서, Hive는 확실히 치열한 경쟁 압력 아래에 놓여지게 됩니다. 보다 많은 대형 벤더가 시장에 참가함에 따라 그것은 착실히 악화 되어 갈 겁니다 저희 회사는 Hive 구현이 높은 성능의 대화형 쿼리 및 애널리틱스의 수요에 따라 갈 수 있을 거라고는 생각하지 않습니다. 아무리 엄하게 채찍질을 가한대도 말은 그만큼 빨리 나아갈 수 없습니다. 유저나 툴이나 어플리케이션을 제공하는 벤더는 보다 좋은 제품으로 옮겨 가겠죠.


 Hive는 데이터 처리 job을 잘 다룹니다. 또한 그 목적으로만 Cloudera의 고객이 넓게 사용하고 있습니다. 무엇보다 Hive는 과거 5년간, Cloudera의 상용 제품의 일부가 되어 왔으므로, Hive는 인스톨 하면 그대로 쓸 수 있기 때문에 저희 회사는 계속해서 Hive를 지원 할 것입니다. 특히 Impala와의 중복 영역을 위에 기재한 Hive Sentry 및 Parquet과의 통합의 장으로 만들려고 생각하고 있습니다.


 하지만 저희는 저희 회사의 엔터프라이즈 데이터 허브에 최상급 리얼 타임 오픈 소스 SQL 엔진을 보유할 필요가 있습니다. 데이터 분석, 리얼타임 쿼리 및 높은 성능의 SQL 어플리케이션에 관한 저희 회사의 장래를 향한 확신은 틀림없이 Impala에 있습니다. 물론 편향된 측면이 있었을지 모르지만, 그래도 저희는 Impala는 이미 Hadoop 에코 시스템에서 이용 가능한 SQL 제품으로서는 실로 최고의 제품이 되었다고 확신하고 있습니다. 고객이나 시장에 있어서 다른 기업이 Impala를 도입하는 것은 매우 기쁜 일 입니다. 또 앞으로 몇 몇 릴리즈로 공개될 서비스나 신기능을 기대 해 주시기 바랍니다.


 


 

Posted by 이슈타르네스

댓글을 달아 주세요

  1. ㅇㅇ 2014.09.01 10:26  댓글주소  수정/삭제  댓글쓰기

    좋은내용입니다.

  2. 달취익쏴아 2014.10.17 11:50  댓글주소  수정/삭제  댓글쓰기

    와~ 멋지네요, 관련 블로그 번역 신청도 가능한가요? 주인장님, 아무튼 좋은 글 감사합니다.

  3. 어니언링 2014.12.16 11:38  댓글주소  수정/삭제  댓글쓰기

    저도 글 잘 읽고 갑니다. 앞으로도 좋은 번역 부탁드려요 ^^