[Cloudera 블로그 번역] 왜 우리들은 HDFS상에 플랫폼을 구축하는가

 

일어 원문 : http://www.cloudera.co.jp/blog/why-we-build-our-platform-on-hdfs.html - 일본 Cloudera Blog

영어 원문 : http://blog.cloudera.com/blog/2012/07/why-we-build-our-platform-on-hdfs/ - 미국 Cloudera Blog

 

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

- 일어 원문 글은 위 영어 원문 글을 번역한 글입니다.

 


 

 

 본 글은 Cloudera Cloudera 프로덕트 바이스 프레지던트인 Charles Zedlewski가 쓴 글을 번역한 것입니다.

 

 Hortonworks의 E14와 같은 의견을 가질 기회는 좀처럼 없습니다만, 그의 최근 블로그 글은 그 절호의 기회를 가져다 주었습니다. 저는 E14가 지적한 부분 중 몇 가지를 토대로 저의 의견을 추가하려 합니다.

 

 최근 GigaOm의 기사에서 HDFS를 대체하는 8개의 제품이 소개 되었습니다. 그들은 실제로는 그 외에도 적어도 4개 제품을 소개하지 않았습니다. 1년 이상에 걸쳐 ParaScale은 HDFS의 대체로 자사제품을 판매하였습니다. (Hitachi(히타치)에 자산을 매각하기 전까지). Appistry는 HDFS의 대체품을 계속 판매하고 있습니다. 아직 릴리즈 되었는지 안되었는지는 모르겠지만, Symantec(시만텍)의 Veritas 부문도 HDFS를 대체하는 클러스터 파일 시스템(CFS)를 제안하고 있는 것은 명백합니다. HP Ibrix는 여러 해 전부터 HDFS API를 지원하고 있습니다.

 

 GigaOm의 기사가 의미하고 있는 것은, 대체물을 추진하고 있는 12개의 다른 벤더의 존재는 HDFS의 어떤 결함을 지적해야만 한다는 것입니다. 그 외에 누가 그런 지적을 하겠습니까. 이건 정말 틀린 결론입니다. 저는 이 일에 대해 묻고 싶습니다.

 

 우리들은 아래의 사실에서 어떤 결론을 끌어낼 수 있을까요.

  • 12종류의 파일 시스템은 HDFS의 대체로써 자기자신을 홍보하고 있습니다.
  • 12개의 대체품 대부분은 HDFS보다도 6~14년 더 긴 역사를 가지고 있습니다. (시장에 오래 남아있다는 것은 그것들에 우세한 부분이 있다는 것을 의미하는 것이겠지요)
  • 하지만 HDFS는 다른 대체품을 압도할 정도의 엔터프라이즈 데이터(수백 페타바이트)를 저장하고 있습니다.
  • HDFS는 대규모 벤더 지원 (Cisco, Dell, HP, IBM, NetApp, Oracle, SAP, SGI, SuperMicro)의 광범위한 기반을 가지고 있습니다.

 저희 Cloudera는 HDFS가 데이터 매니지먼트 업계 표준으로써 이들 레거시 파일 시스템을 한창 압도하고 있다고 결론 내렸습니다.

 

 실제로 저희는 전에도 비슷한 스토리를 봐왔습니다. 20년전으로 돌아갈 수 있다면, 우린 비슷한 상황을 떠올릴 수 있겠죠. 그 때의 시장에는,

 

  • 12 이상의 선택지가 있었습니다. 그것들은, AIX, HP-UX, Solaris, Seequent, Darwin, BSD, SCO, Unixware 등으로 불리고 있었습니다.
  • 모든 대체품은 아주 먼 옛날에 기능 포화 상태에 이르렀고, 엔터프라이즈 마케팅 담당자는 이를 감추려고 고심하고 있었죠. 쓸데없는 질문일 수 있겠습니다만, SCO와 OpenBSD 사이의 기능적 차이를 기억하고 계십니까?
  • 그들은 종종 독자적인 고가의 하드웨어에 밀접하게 결합 시켰습니다.
  • 그런 단편화는 한 번의 R&D 사이클로 폭넓은 시장을 타겟으로 하는 어플리케이션 개발자와 하드웨어 제조업자에게 있어서는 악몽이었습니다.

 이 상황은 Linux의 점화를 기다리는 화약 창고와 같은 것이었습니다. Linux가 성숙해 지고 인기가 늘어남에 따라 많은 Unix 벤더가 유행과 맞서 싸우려고 했습니다. 많은 마케팅과 PR 비용은 운영 시스템의 새로운 것에 대한 공포, 불확실성, 의문을 만들어 내기 위해 쓰여졌습니다. 하지만 이 일은 헛되이 끝났고, 시간이 지남에 따라 Linux는 IT 업계에 매우 큰 임팩트를 주게 되었습니다. Linux가 모든 하드웨어 벤더에게 공평한 경쟁의 장을 만들어줌에 따라 하드웨어 비용 절감으로 이어지게 되었습니다. Linux가 플랫폼의 단편화를 줄여줌에 따라 보다 많은 어플리케이션 도입으로 이어졌습니다. 그리고 또 Linux는 호환성을 확보하기 위해 소프트웨어, 하드웨어, 디바이스 제조업자가 Linux에 공헌하게 되는 공유 R&D 시스템으로 이어져 나갔습니다.

 

 HDFS 단편화, 과도한 마진, 수상한 도구의 불필요한 기능에 대한 답답한 마케팅에 지쳐 있던 고객들의 시장에 Linux 같은 역할로 뛰어 나갈 준비가 되어 있습니다. 오늘날도 아직 독점적인 Unix 운영 시스템은 넓게 사용되어 오고 있습니다. 독점적인 파일 시스템에 대해서도 분명 같은 얘기를 있을 것입니다. 오래된 제품은 죽지 않습니다, 단지 관련성을 잃을 뿐인 것입니다.

 

 Eric HDFS 경제성, 데이터 처리의 대역폭과 신뢰성을 강조하였습니다. 기능 레벨에서는 우수한 보안, 내장애성, 고가용성 (그렇습니다, 이것은 SPOF 문제를 해결해 줍니다. CDH4 다운로드는 여기서!) 추가합니다. HDFS 제공하는 엔터프라이즈 고객용 기능보다도 아마 중요한 것은,

  • 선택 - 고객은 임의의 거대 하드웨어 벤더와 협력하여 가능한 한 최적의 비용으로 손에 넣을 수 있습니다. 결정권은 고객에게 있는 것으로, 벤더가 번들로 하기로 결정한 것이 아닙니다.
  • 이식성 - 고객은 클러스터 재포맷이나 대량 데이터를 복사할 필요 없이 HDFS 기반의 Hadoop 분산에서 다른 HDFS 기반의 분산으로 옮길 수 있습니다. 만약 페타바이트 데이터를 가지고 있을 경우, 이런 이식성은 매우 중요합니다. 만약 이식성이 없다면, 다음 리뉴얼 교섭 때, 벤더는 믿기 어려울 정도의 힘을 가지게 됩니다.
  • 공유의 업계 R&D - 저희는 Cloudera에서 개개인의 사원에 의한, HDFS에 대한 개별 공헌을 자랑스럽게 생각합니다. 우리는 모두 Hortonworks의 동업자들과 협력하고 있습니다. 하지만 오늘날에는 IBM, 마이크로소프트, VMWare가 각 회사의 제품을 향상시키기 위해 HDFS에 공헌하고 있는 것을 발견할 수 있겠죠. 이 후에는 하드 드라이브, 네트워크, 서버 등의 벤더도 자사의 제품이 HDFS에 최적화 가능하도록 HDFS에 패치를 추가할 것으로 저는 예상하고 있습니다.

 역사가 완전 같은 방식으로 반복되는 일은 매우 드문 일로, 이건 HDFS에 대해서도 마찬가지 입니다. 오늘날 HDFS는 컨텐츠용 스토리지(Content Addressable Storage)나 니어 라인 아카이브(nearline archive)로써는 최적의 파일 시스템이 아닐지도 모릅니다. 하지만 Linux가 노트북이나 라우터(네트워크에서 데이터의 전달을 촉진하는 중계 장치), 휴대폰이나 공항의 키오스크 단말에 사용되는 등의 일을 15년전에 누가 상상이나 했을까요?

 

 Linux는 우리에게 지도를 그려주었습니다. 현명한 투자가는 이미 뒤따라오고 있습니다.

 

관련 글

 

 CDH4.1의 컬럼 베이스 저널링 (일어 원문사이트)

 

 MR2와 YARN에 대한 짧은 해설 (한국어 번역글)

 

 Cloudera 5주년! (일어 원문사이트)

 

 

Posted by 이슈타르네스
TAG cloudera, HDFS

[Cloudera 블로그 번역] 2014/03/07 Spark 활용하기 : 빅데이터 어플리케이션용 고속 인메모리 컴퓨팅

 

일어 원문 : http://www.cloudera.co.jp/blog/putting-spark-to-use-fast-in-memory-computing-for-your-big-data-applications.html - 일본 Cloudera Blog

영어 원문 : https://blog.cloudera.com/blog/2013/11/putting-spark-to-use-fast-in-memory-computing-for-your-big-data-applications/ - 미국 Cloudera Blog

 

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

- 일어 원문 글은 위 영어 원문 글을 번역한 글입니다.

 


 

 

 Apache Spark (incubating)을 서포트 하는 Databricks에서 아래와 같은 게스트 글을 기고 받았습니다. Cloudera와 Databricks는 최근에 CDH내에서 Spark를 제공하고 지원 하겠다고 발표 했습니다. 앞으로 Spark 내부 아키텍처나 Spark + CDH 사용법 등을 블로그 기사로 소개 해 드릴 예정입니다.

 

 Apache Hadoop은 매우 낮은 코스트로 방대한 양의 데이터를 저장하고 처리 할 수 있도록 하여 빅데이터 처리에 혁명을 가져 왔습니다. MapReduce가 시스템 로그 분석부터 ETL 실행, Web 인덱스 작성, 개인 추천 시스템의 실행 기반에 이르기까지 복잡한 배치 어플리케이션을 구현하기 위한 이상적인 플랫폼이라는 것은 이미 증명 되었습니다. 하지만, 내장애성과 단일 패스 계산 모델을 제공하기 위해 영속적 스토리지에 의존 하는 점 때문에, MapReduce는 로우 레이턴시(저 지연)의 어플리케이션이나 기계학습, 그래프 알고리즘 등에서 사용하는 반복적인 계산 처리에는 적합하지 않습니다. 


 Apache Spark는 성능과 편의성을 극적으로 향상시키면서, MapReduce의 계산 모델을 일반화 하여 이러한 제한 사항들에 대처 하고 있습니다.

 

Spark로 신속, 간단하게 빅데이터 처리

 

 기본적으로 Spark는 Mapper, Reducer, JOIN, GROUP BY, 필터 등의 임의의 연산자에 의해 어플리케이션을 쓸 수 있도록 하는 프로그래밍 모델입니다. 이 조합에 의해 반복되는 기계학습, 스트리밍, 복잡한 쿼리, 배치 등 넓은 영역을 간단히 표현 할 수 있습니다.

 

 또 Spark는 연산자 각각이 생성하는 데이터를 추적하여 어플리케이션이 확실히 메모리 내에 이 데이터를 보존 할 수 있게 합니다. 이로 인해 어플리케이션은 높은 코스트의 디스크 접근을 피할 수 있기 때문에, 이 점이 Spark 성능의 키 포인트라 할 수 있습니다. 아래 그림에 나타나는 바와 같이 이 기능에 의해 아래 항목들이 가능하게 됩니다.


 ・ 메모리내 작업 데이터셋을 캐시하여, 메모리 속도로 계산을 실행함으로써 로우 레이턴시 계산

 ・ 뒤에 따르는 반복 처리의 공유 데이터를 메모리상에 유지 하거나, 반복하여 같은 데이터셋으로 접근함에 따른 효율적인 반복 알고리즘

 

 

 Spark의 사용 편의성은 유저가 많은 Map과 Reduce 처리에 매이지 않고 어플리케이션을 구축할 수 있다는 일반적인 프로그래밍 모델로부터 유래 합니다. Spark의 병렬 프로그램은 순차 프로그램과 매우 닮아 있어, 그에 따라 개발과 리뷰를 간단히 할 수 있습니다. 마지막으로 Spark에 의해 유저는 단일 어플리케이션으로 배치 처리, 인터랙티브 처리, 스트리밍 잡을 간단하게 구성 할 수 있습니다. 그 결과, Spark 잡은 Hadoop 잡에 비해 1/2 부터 1/10의 코드 양으로 최대 100배까지의 속도로 실행 할 수 있습니다.


고도 데이터 분석과 데이터 사이언스를 위한 Spark 이용

 

인터랙티브한 데이터 분석

 

 Spark의 가장 편리한 기능 중 하나는 인터랙티브(대화형) 쉘 입니다. 이것으로 유저는 바로 Spark 성능을 시험 해 볼 수 있습니다. IDE도 코드 컴파일도 필요 없습니다. 쉘은 데이터를 인터랙티브하게 탐색하거나, 개발 중의 어플리케이션 중 일부를 테스트 하기 위한 주요한 툴로 사용 가능합니다.

 

 아래의 스크린샷은 유저가 파일을 로드하고, 'Holiday'를 포함하는 행 수를 카운트하는 Spark Python 쉘을 보여 줍니다.

 

 

 이 예에서 나타나듯이 Spark는 HDFS로부터 데이터를 읽고 쓸 수 있습니다. 이와 같이, Hadoop 이용자는 Spark를 인스톨 하면 바로 HDFS 데이터 분석을 시작 할 수 있습니다. 그리고, 메모리 내의 데이터셋을 캐시 해서 유저가 대화식으로 여러 종류의 복잡한 계산을 실행 할 수 있습니다!


 Spark는 스탠드얼론 어플리케이션을 위한 Scala 쉘 및 Java, Scala, Python으로 API를 제공 합니다.


보다 빠른 배치

 

 Spark 초기 구현 중에는 기존의 MapReduce 어플리케이션의 성능을 개선 할 방법에 초점을 맞춘 것도 있었습니다. MapReduce는 실제로는 범용적인 처리 플레임 워크로, 코어 Hadoop에서 가장 잘 알려진 구현에만 한하는 것은 아니라는것을 기억 해 주세요. Spark도 MapReduce를 제공하며 Spark는 메모리를 효율 좋게 쓸 수 있기 때문에 (필요하다면 장애를 복구하기 위한 계통을 사용한다고 해도), 반복 처리 프로그램에서 캐시를 쓰지 않아도 Spark의 MapReduce 구현 중 몇 가지는 Hadoop의 MapReduce와 비교해서 정말 빠릅니다.


 아래 예는 MapReduce의 가장 유명한 예인 워드 카운트의 Spark 구현을 보여줍니다. 여기서 Spark는 연산자 체인을 지원하고 있는 것을 알 수 있습니다. 이것은 데이터 필터링을 복잡한 MapReduce 잡 실행 전에 행하는 등, 데이터 전처리나 후처리를 행할 때 매우 편리합니다.

 

 

 

 Spark의 배치 처리 능력은 현실 세계의 시나리오에서 증명 되었습니다. 한 매우 거대한 실리콘 벨리의 인터넷 기업은 모델의 트레이닝 파이프라인에 있어서 특징량 추출을 구현한 하나의 MR 잡을 그대로 이식한 것 만으로 3배의 속도 개선을 꾀할 수 있었습니다.


반복 알고리즘

 

 Spark는 유저나 어플리케이션이 명시적으로 cache() 오퍼레이션을 호출 하는 것으로 데이터 셋을 캐시 할 수 있습니다. 이것은 어플리케이션이 디스크가 아닌, RAM에서 데이터로 접근 할 수 있다는 것을 의미 하는 것으로, 이에 따라 같은 데이터셋에 반복해서 접근하는 반복 알고리즘 성능을 극적으로 개선 할 수 있습니다. 모든 기계학습과 그래프 알고리즘은 본질적으로 반복적이도록, 이 유즈케이스는 어플리케이션의 중요한 영역을 커버 하고 있습니다.

 

 

 세계 최대급의 인터넷 기업 두 곳이 광고 타겟팅과 컨텐츠 추천을 제공하기 위해 Spark의 효율적인 반복 실행을 활용하고 있습니다. 로지스틱 회귀와 같은 기계학습 알고리즘은 기존 Hadoop 기반의 구현과 비교하여 100배 빠르게 실행 할 수 있습니다. (오른쪽 그림을 봐 주세요). 한편 협조 필터링이나 ADMM(alternating direction method of multipliers) 과 같은 알고리즘에서는 15배 고속화에 머물렀습니다.

 

 

 아래의 예는 다차원 특징 공간내의 점의 두 부분을 분리하는 가장 좋은 초평면을 찾아내기 위해 로지스틱 회귀를 사용하고 있습니다. MapReduce 중 각 이터레이션에서는 디스크로부터 데이터를 읽어 들여 거대한 오버헤드가 발생하는 한편, Spark에서는 캐시된 데이터 셋을 'points'가 메모리로부터 반복 접근 하고 있는 점에 주의 해 주세요.

 

 

실시간 스트림 처리

 

 자유롭게 쓸 수 있는 로우 레이턴시 데이터 분석 시스템이 손에 있을 때, 그 엔진을 라이브 데이터 스트림 처리로 확장하는 것은 당연한 일입니다. Spark에는 스트림 조작을 위한 API가 있어 정확히 한 번 뿐인 시멘틱과 stateful(상태유지) 연산자의 완전 복구를 제공합니다. 스트림 처리에 같은 Spark API를 제공하고 있어 보통의 Spark 어플리케이션 코드를 재이용 할 수 있다는 명확한 이점도 있습니다.


 아래의 코드는 해쉬태그로 시작하는 단어의 워드 카운트를 10초마다 데이터에 대해 필터 처리하도록 하는 심플한 네트워크 스트림 처리 잡을 보여 주고 있습니다. 전의 워드 카운트 예와 비교 해 보면 거의 같은 코드가 사용되어 있다는 것을 알 수 있지만 이번에는 라이브 데이터 스트림을 처리하고 있습니다.

 

 

 Spark Streaming API가 릴리즈 되고 나서 아직 1년도 지나지 않았지만, 유저는 그 API를 사용한 어플리케이션을 실제 환경에 도입함으로써 시스템 로그를 집약한 stateful 데이터에 대해 감시와 알림을 제공하고, 불과 몇 초의 레이턴시 만으로 매우 빠른 처리를 달성하고 있습니다.

 

의사 결정의 신속화

 

 많은 기업은 추천 시스템, 광고 타겟 설정 혹은 예측 분석의 형태로 유저의 의사결정 혹은 의사결정의 촉진을 위해 빅데이터를 사용하고 있습니다. 어떤 의사결정에 있어서든 중요한 요소는 레이턴시입니다. 즉, 입력 데이터가 이용 가능하게 되고 나서부터 의사결정을 실행하기 까지 걸리는 시간을 말합니다. 의사결정의 기다리는 시간을 줄이는 것은 폭넓게 그 유효성을 높여 최종적으로는 기업의 투자대효과(ROI)를 늘릴 수 있습니다. 이런 결정들의 대부분은 (예를 들어 기계학습이나 통계적 알고리즘 등의) 복잡한 계산에 기반하고 있기 때문에 Spark가 의사결정을 스피드업 하기 위해 이상적이라는 것을 알 수 있습니다.


 당연한 얘기겠지만, Spark는 기다리는 시간을 절감하기 위한 것 뿐만 아니라 결정의 질을 향상 시키기 위하여 이용 되고 있습니다. 예를 들면, 광고 타겟팅에서 인터넷 상에서의 영상 전송의 품질을 향상 시키기 까지의 폭넓은 범위에 적용되고 있습니다.

 

통일된 파이프라인

 

 오늘날 빅데이터의 대부분은 MapReduce뿐 아니라 스트리밍, 배치, 인터랙티브 처리 플레임워크를 통합함에 따라 전개 되고 있습니다. 많은 시스템을 Spark로 바꿈으로써 유저는 데이터 처리 파이프라인의 복잡함을 극적으로 절감 시킬 수 있습니다.


 예를 들면, 오늘날 많은 기업은 MapReduce를 사용하여 리포트를 생성하고 이력 쿼리에 대해 답하고 별도의 시스템을 구축하여 리얼타임으로 중요한 메트릭스를 추적하기 위한 스트림 처리를 실행 하고 있습니다. 이 방법은 2가지의 다른 계산 모델 어플리케이션을 개발하는 것 뿐 아니라, 2개의 다른 시스템의 유지 관리도 필요로 합니다. 또, 2개의 스택으로 생성되는 결과에 일관성이 있다는 것을 보증할 필요성도 생기겠죠 (예를 들어, 스트리밍 어플리케이션과 MapReduce에 의해 계산된 카운터가 같은지 어떤지).


 최근에는 유저가 이력 리포트를 제공하기 위한 배치 처리 뿐 아니라, 스트림 처리를 구현하기 위해 Spark를 이용하고 있습니다. 이에 따라 디플로이와 보수를 간소화 할 뿐만 아니라, 어플리케이션 개발을 극적으로 심플하게 할 수 있습니다. 같은 코드로 처리하고 있는 것이라면, 리얼타임과 이력 메트릭스의 일관성을 유지 하는 것은 문제가 되지 않습니다. 통일화의 마지막 이점은, 다른 시스템 간에서의 데이터 이동이 불필요 하게 됨에 따른 성능 향상입니다. 일단 메모리 상에 보존 되면 그 데이터는 스트리밍 처리와 이력 (혹은 인터랙티브한) 쿼리 사이에서 공유 할 수 있습니다.

 

당신의 차례 : 시작합시다

 

 Spark로 파워풀한 빅데이터 어플리케이션을 만드는 일이 매우 간단 해 집니다. 당신이 이미 가지고 있는 Hadoop과 프로그래밍 스킬에 의해 몇 분만에 생산적으로 데이터를 활용 할 수 있겠죠. 시작 한다면 지금입니다


 다운로드 : http://spark.incubator.apache.org/downloads.html

 퀵스타트 : http://spark.incubator.apache.org/docs/latest/quick-start.html

 

Posted by 이슈타르네스

[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 이슈타르네스