Hadoop의 미래는 “실시간 처리”이다.

지인의 트윗을 보다가 재미있는 주제여서 번역을 해보았습니다.
의역이라 오역이 있을 수 있으니 너그러운 지적 부탁드립니다.

빅데이터가 화두가 되면서, 덩달아 Hadoop이 화두가 되었습니다.
Hadoop이 빅데이터의 전부는 아니지만,
현재로서는 빅데이터의 Key Technology입니다.
하지만, Hadoop 관련 기술들은 아직 미성숙된 기술이어서 여러가지 불편합니다.

그러면 Hadoop 은 앞으로 어떻게 발전할까?
아래 글은 이 주제에 대해 잘 정리한 글인 것 같아 번역해보았습니다.

---

※ 원문 : 5 reasons why the future of Hadoop is real-time (relatively speaking)
※ 저자 : Derrick Harris 3. 7, 2013

몇 가지 측면에서 Hadoop 은 좋은 와인 같다.

첫째, 나이를 먹을수록 날카로운 맛이 무뎌지면서 풍미가 더 좋아진다.
그래서, 사람들은 점점 더 좋은 경험을 얻고 있다.

문제점은 Hadoop이 고급와인이 많은 세상보다 저렴한 와인이 많은 세상에 존재한다는 것이다.
Hadoop으로 많은 회사들이 빅데이터에 빠르게 빠져서 더 많은 것 또는 더 강한 것을 가지고 싶어하게 되었다.

그러나, 데이터는 기술과 다르게 오래된 것이 더 좋은 것이 아니다.
현재 Hadoop 에 Plugin되어 있는 기술들과 2,3년 내에 변화할 방향을 들여다 보고서 내린 결론이다.

Batch 업무의 필수 기술이 MapReduce 가 되어버린 것처럼,
Distribution 레벨에서는 “클라우데라”나 “호튼웍스” 같은 회사가 중요해졌다.

매일 Hadoop을 관리할 만큼 여유를 가진 회사는 없다.
모든 업무가 MapReduce 와 어울린다고 보기도 힘들다.

Hadoop 에 대한 4개 파트 중 “파트 1″에서 우리는 이 기술이 어떻게 탄생되었고 어떻게 성장했는지 살펴보았다.
“파트2″에서는 우리는 Hadoop Ecosystem을 형성하는 현재의 제품과 프로젝트를 나열. 지도를 만들어보았다.

이번 “파트 3″에서 우리는 그들 중 일부를 좀 더 자세히 살펴볼 것이다.
그 제품과 회사들이 중요한 플레이어가 되기 위해 어떻게 자신을 포지셔닝시키고 있는지 살펴볼 것이다.
“파트 4″에서는 최고의 Hadoop 어플리케이션과 (GigaOM 보고서를 보면서) Hadoop 역사의 중요한 순간들을 조명해볼 것이다.

3/20~21일에 벌어진 뉴욕의 Structure: Data conference 에서, 만일 Big Hadoop이라는 주제가 있었다고 가정해보자.

이제는 사람들이 “Hadoop의 다음은 뭐야?”라고 묻지 않고, 이렇게 물어볼 수준이 되었다.

“앞으로 Hadoop이 어떻게 되어야 하는거야?”

요즘 벌어지는 일들에 기반해서 그 질문에 대한 답을 해보자면 이렇다.

“Hadoop은 모든 면에서 더 빨라질 것이고, 결과는 더 유용해질 것이다.”

01. 대화식 조작법, 빅데이터 스타일

(출처: Shutterstock user hauhu.)

몇주 전에 설명했듯이, SQL 은 Hadoop의 다음 주제이다.
SQL 이 익숙하다거나, RDB상에서 SQL이 많이 사용되기 때문은 아니다.
몇년간 관계형 데이터를 분석하기 위해 개발된 여러 개의 대용량 병렬 처리 엔진들이 이미 매우 빠르기 때문이다.

이것은 “데이터 사이언티스트”들이 데이터를 쉽게 조회할 수 있게 되었다는 뜻이다.
Map Reduce를 사용하여 전체 데이터를 조회하는 것보다, RDB로도 직관적인 속도로 빠르게 결과를 받을 수 있다는 뜻이다.
RDB의 SQL과 Processing 기술이 Hadoop으로 넘어오면서, Hadoop 에도 Table 이 들어왔다.

이것은 전통적 데이터웨어하우스에 존재하지 않는 “대규모 확장성”과 “유연성”을 가져다 주었다.
옛날에는 하드웨어나 솔루션 라이센스가 비싸서, 미리 정의된 구조로만 데이터를 저장하고 조회했다.

하지만, 이젠 가상의 공간에, 무한하게, 자유로운 스키마로 저장할 수 있게 되었다.
어떤 포맷이든, 얼마나 많은 데이터든 Hadoop 을 이용해 저장할 수 있게 되었다.
이걸로 어떻게 저장할 것인가 하는 고민은 쉽게 해결되어 버렸다.

이제는 많은 회사들은 오히려 이 데이터를 어떻게 잘 활용할지 고민하게 되었다.

하지만, 아직 Hadoop 은 “활용처리”을 잘 하기 위해서는, 몇개의 구조를 더 가지고 있어야 한다.
Hadoop 창시자 “Mike Cafarella”는 이 문제를 해결하기 위해 어떤 데이터 타입이 들어오더라도 프로세스를 자동화할 수 있는 RecordBreaker라는 프로젝트를 수행하고 있다.

그렇다면, SQL-on-Hadoop은 얼마나 핫이슈일까?
나는 지난 2/21일 관련 회사와 프로젝트들을 살펴보았다.

“Hadoop 에 분석DB를 붙이기 위해 완전히 Hadoop 을 다시 만들었다.”

EMC Greenplum이 이 발표를 한 후에, JethroData 라는 신생업체가 4.5백만 달러(약 500억원)를 펀딩받기도 했다.
앞으로 업계의 큰 변화와 구조조정이 있겠지만 (EMC Greenplum의 Scott Yara가 메인프레임의 종말과 맞먹을 정도로 중요하게 생각하는 “Data Gravity”에서) Hadoop 관련 비즈니스로 투자를 받는 행운의 업체가 적어도 몇 개 더 있을 걸로 생각된다.

02. HDFS에 DB가 올라가다.

SQL과 NoSQL 논쟁은 대부분의 회사와 개발자들이 둘다 원한다는 것을 깨달음으로써 끝날 것처럼 보였다.
그러나 Hadoop의 중심부에서 새로운 논쟁이 시작되었다.
“the concept of data gravity”
바로 크고 매력적인 물건인 “HDFS”가 있다.

즉, 이런 질문을 할 수 있다.

“내가 HDFS에 비정형 데이터를 이미 가지고 있고, 그것으로 데이터웨어하우스를 만들고 싶어한다고 가정하자.
그런데 그게 꼭 별도의 DB를 설치해서 구축해야만 하는가? Hadoop은 이미 DB를 가지고 있는데?”

이게 바로 HBase가 많이 쓰이고 있는 이유다.
Cassandra 같은 NoSQL DB 와 비교해서 기술적, 상업적으로 부족하지만 말이다.

Drawn to Scale, Splice Machine 과 같은 스타트업들은, RDB 를 사용하는 게 더 나은 서비스의 경우, HBase를 RDB 처럼 쓰고 있다.
Wibidata는 더 적극적으로 서비스 개발에 HBase를 이용하기 위해 Kiji라는 프레임워크를 만들고 있다.

만일 당신이 Cloudera 나 다른 플랫폼 벤더의 사람들과 이야기할 기회가 있다면, 이미 많은 고객들이 HBase를 사용하고 있다는 걸 알게될 것이다.

Bisciglia 는 “HBase를 사용하는 곳이 점점 더 많아지기를 원한다.” 고 말한다.
MapR도 그렇다.
이 Hadoop 벤더는 HBase의 엔터프라이즈 버전인 M7이라는 것을 팔아서 경쟁우위를 점하고 있다.

TempoDB나 Ayasdi 와 같은 핫 스타트업들은, HBase 관련 클라우드 서비스를 데이터센터에 도입하기로 결정했다.
그들 역시 Hadoop 클러스터에 뛰어들 것이다.

국가보안업체들은 HBase와 유사하지만, 잘 정리된 보안항목과 대용량 스케일을 지원할 수 있게 Key-Value DB인 Apache Accumulo 를 만들었는데 Sqrrl 이라는 업체가 이것을 사가기도 했다.

그리고, DB 레이어에서 HBase나 Accumulo에 기반한 그래프 처리를 위해 Giraph 프로젝트도 있다.

03. 실시간 처리의 의미가 넓어지고 있다.

“실시간”이란 서로 다른 사람과 다른 어플리케이션에 대해, 서로 다르게 처리한다는 걸 의미하는 용어이다.

“Hadoop-on-SQL 기술이 약속하는 Interactivity”라는 것은 Storm 같은 기술로 가능해진 Stream Processing 처럼 단진 하나의 정의Definition일 뿐이다.
혁신을 하면 많은 일이 생기는 것 처럼 YARN(Apache Hadoop NextGen MapReduce) 주변에도 수많은 흥미거리들이 있다.

YARN, aka MapReduce 2.0은, Hadoop 유저가 MapReduce 와는 다른 패러다임의 프로세싱을 실행시킬 수 있느 리소스 스케쥴러이면서, 분산형 어플리케이션 프레임워크 이다.
즉, 그래프처리를 위해서 MPI와 같은 전통적인 병렬처리 프로세싱 방식에서 Storm이나 S4와 같은 Stream Processing으로의 이전을 의미한다.
얼마나 오랫동안 Hadoop이 HDFS와 MapReduce를 의미했는지 생각해본다면, 이런 유연성은 분명히 큰 장점이다.

Stream Processing은 Hadoop 상에서 널리 사용되어지는 “Batch 프로세싱”의 반대개념이다.
그리고, Batch 프로세스는 실시간 광고나 센서데이터를 모니터링하는 부하를 처리하기에는 원천적으로 부적합하다.

비록, Storm이나 다른 Stream Processing 플랫폼이 Hadoop 클러스터 위에서 운영될 수 있는 방법을 찾지는 못했지만, HStreaming이라는 스타트업은 Hadoop에 Stream Processing을 전달할 수 있도록 미션을 완수해서, 다른 회사들이 많은 관심을 가지고 있다.

(역자주. Stream Processing이 Hadoop 내에 통합되어 있지는 않다. 별도로 구현을 해야 한다. 즉, Hadoop 으로 실시간 처리 Stream Processing를 한다는 건 꽤 어려운 일이라는 뜻이다.)

도움이 될지 모르겠지만, VertiCloud 설립자이자 CEO이면서, 전임 Yahoo CTO인 Raymie Stata 는
배치, 실시간, 인터랙티브라는 용어를 모두 버려야 한다고 생각한다.
그는 “동기방식”, “비동기 방식”이냐 하는 용어를 더 좋아한다.

“동기방식”이냐, “비동기방식”이냐 하는 것은 데이터를 처리하는 속도나 시간에 대한 것이 아니라, 데이터에 대한 사람의 경험을 묘사하고 있기 때문이다.

“동기방식”이란 사람 행동의 속도(예를 들면 말하기)에 기반한다.
반면 “비동기방식”이란 컴퓨터 앞에서 응답을 기다리는 사람을 해방시키기 위한 것이다.
용어상의 차이는 어플리케이션에 대해 SLA을 어떻게 관리하는가 하는 변화와 관련이 있다.

예를 들어보자.

– 플리커에 사진을 올리는 것: 동기방식
– MapReduce Job을 실행하는 것 : 대부분 비동기 방식

아이러니하게도 Stada에 따르면, Storm과 같은 Stream Processing 데이터는 거의 비동기 방식이다.
즉, 업데이트할 페이지를 기다리거나, 쿼리하다 받아야할 결과값을 기다리는 사람들이 없기 때문이다.

그리고, 실시간 즉시응답을 보장해야 하는 경우가 없다면,
1밀리세컨드나 1초 이하의 미세한 차이는 큰 의미가 없다.

04. 적절한 인사이트는 계획단계부터 시작된다.

MapReduce가 비록 답이긴 하지만, 워크플로우나 어플리케이션을 만들고 사용을 구분하기 위한 컨설팅 의존적인 Hadoop deployment process가 모두에게 즐거운 것은 아니다.

때로는, 당신은 소프트웨어를 사기도 해야 하고, 계속 가지고 가기도 해야 한다.

Wibidata와 Continuuity와 같은 회사들은, 이미 그들의 Needs에 맞는 Hadoop 어플리케이션들을 쉽게 만들기 위해 무언가를 하기 시작했다.

Wibidata의 Biscigila 는 “그들이 더욱 더 적게 커스터마이징할수록, 같은 시장 내의 고객들과 계약이 더 많아질 수 있다.”고 이야기한다.

※ 역자주. 즉, 아직 Hadoop은 사용하기 어렵고 복잡하다. 개발인력이 필수적으로 동반된다. 좀 더 사용하기 쉽도록 제품화될 필요가 있다.

그는 이렇게 이야기한다.
“나는 아직 Hadoop 위에서 돌아가는 일반적인 어플리케이션을 사기 위해서는 몇년 더 기다려야 할 것이라고 생각한다.”

그리고, 이 레벨에서 수억 달러의 비즈니스 기회가 있다고 생각한다.
아마도 ERP나 CRM 어플리케이션 처럼 Hadoop을 팔 수 있다면 말이다.

Cloudera CEO Mike Olson at Structure: Data 2012
(c) 2012 Pinar Ozger pinar@pinarozger.com

Cloudera CEO인 Mike Olson은 작년 데이터 컨퍼런스에서 Hadoop 기반의 어플리케이션을 만드는 스타트업들을 펀딩하고 싶어한다고 발표했다.

실제로 Cloudera 백커 엑셀 파트너는 빅데이터를 어플리케이션 레벨에서 접근하는 스타트업들을 펀딩하기 위해
2011년 “빅데이터 펀드”를 런칭하기도 했다.

Cloudera (Oracle 처럼)는 어플리케이션 시장으로 나아갈 것이다.
Hadoop, Cloudera CTO인 Doug Cutting은 이렇게 이야기했다.

“당신이 Cloudera 와 같이 Stack을 만들고, 어플리케이션을 파는 다른 벤더를 본다고 해도 그닥 놀랍지 않다.
이전에 레드햇이나 오라클도 그렇게 했다.
RDB라는게 오라클을 위한 플랫폼이고, 관련된 수많은 어플리케이션이 팔렸다.
그런 현상은 시장이 성숙되면 자연스레 나타나는 현상이다.
우리는 아직 시장이 어리지만 잠재적 협력자들을 현재 시점에 밟아버리길 원하지 않는다.
우리는 플랫폼을 더 좋게하기 위해 다른 사람들에게 우리것을 오픈하기를 원한다.”

클라우드 컴퓨팅은, Hadoop 프로젝트를 순조롭게 시작하기 위해 매우 중요한 시스템이 되어가고 있다.
Amazon Elastic MapReduce와 같은 Low Level 서비스가 물리적 Hadoop cluster를 관리하는 어려움을 경감시키기도 한다.
그리고, 이미 Hadoop을 SaaS 어플리케이션으로 제공하는 클라우드 서비스도 있다.

클라우드에 저장하고, 처리하고, 분석하는 것이 더 쉬워질수록, 또다른 IT프로젝트에 투자하라고 괴롭힐 수 없는 잠재 유저들에게 Hadoop은 더욱 매력적이 될 것이다.

05. 구글과 MS가 앞서 가고 있다.

Hadoop은 구글에서 탄생된 기술이다.
그래서 그 미래가 구글이 하는 일들에 의해 영향을 받을 것처럼 보이기도 한다.
이미 HDFS에 대한 발전은 몇 해전에 구글 파일 시스템에 일어났던 변화를 똑같이 밟아가고 있다.

그리고, YARN은 구글의 새로운 Percolator 프레임워크와 비슷하게, 새로운 non-MapReduce 타입의 프로세싱 방식을 가능하게 한다.

구글은 Percolator 가 구글서치에서 documents의 평균수명이 50%씩 짧아지고 있음에도 불구하고, 매일 동일한 수의 documents를 처리하고 있다고 주장한다.
(역자주. Percolator는 웹 데이터를 계속 크롤링을 해올때, 변동분만 따로 처리할 수 있는 기술이다.)

Cutting은 트랜잭션 일관성을 유지하면서 데이터 지리학data geographies 을 아우를 수 있는 DB 시스템인 Google Spanner 에 특별히 관심이 많다.

– “Hadoop 시스템 내에 그것을 구현하는 것은 시간문제다.”
– “그리고, 그것은 거대한 변화이다.”

특히 Bing 검색인프라를 그동안 많이 이야기해오던 제품처럼 부상시킨다면, MS도 Hadoop 커뮤니티에 하나의 영감일 수 있다.

Bing 은 Cosmos, Tiger, Scope라 불리는 도구의 조합으로 실행된다.
그리고, 그것은 Yahoo VP와 Hadoop backer Qi Lu에 의해 운영되는 온라인 서비스본부의 한 부분이기도 하다.

Lu는 MS도 구글처럼 검색(Hadoop 본연의 기능) 이상의 것을 찾고 있다.
그는 데이터가 index 되고, 검색되고, 제공되어지는 방식을 변화시키는 정보흐름을 만드는 것을 주의깊게 조사하고 있다.
그것이 어떻게 진화하든, Hadoop은 이제 더이상 값싼 스토리지와 몇개의 MapReduce 프로세스를 위한 단순한 기술이 아니다.

Cutting이 이렇게 말했다.

“많은 사람들이 Hadoop이 단지 한 번 반짝하는 기술일지 모른다고 생각한다.
하지만, 그들이 놓치는게 있다.
나는 내년에는 그것들이 사람들에게 증명되어질 것이라고 생각한다.”

끝.