IT의 중심에서

기술은 사람을 행복하게 할 때 가장 가치가 크다.

Hadoop의 미래가 리얼타임인 이유 5가지

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

빅데이터가 화두가 되면서, 덩달아 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이 Relentless Napa Valley 2008(비싼 와인)가 많은 세상보다 MD 20/20(싼 와인)가 많은 세상에 존재한다는 것이다.

Hadoop으로 인해 많은 회사들이 빠르게 빅데이터에 빠지고 취해서, 더 많은 것 또는 더 강한 것을 가지고 싶어하게 되었다.
그러나, 데이터는 기술과 다르게 오래된 것이 더 좋은 것이 아니다.
이것은, 현재 Hadoop 에 Plugin되어 있는 기술들과 2,3년 내에 변화할 방향을 들여다 봄으로써 얻은 결론이다.

특정 Batch 업무의 필수 프레임워크가 MapReduce 가 되어버린 것처럼, Distribution 레벨에서 Cloudera나 Hortonworks와 같은 회사가 하는 일들은 매우 중요하다.
매일 매일 Hadoop을 관리할 만큼 여유를 가진 회사는 없다. 그리고, 모든 분석 업무들이 MapReduce 와 잘 어울린다고 보기도 힘들다.

Hadoop에 대한 4개 파트 시리즈 중, 파트 1에서 우리는 기술이 어떻게 탄생되었고 어떻게 오늘과 같이 성장했는지를 살펴보았다.
파트2에서는 우리는 Hadoop ecosystem을 형성하는 현재의 제품과 프로젝트를 나열해서 지도를 만들어보았다.
여기에서(파트 3) 우리는 그들 중 일부를 좀 더 자세히 살펴볼 것이다.
그리고, 그 제품과 회사들이 중요한 플레이어가 되기 위해 어떻게 자신을 포지셔닝시키고 있는지 살펴볼 것이다.
파트 4에서는 최고의 Hadoop 어플리케이션과 (GigaOM 보고서를 보면서) Hadoop 역사의 중요한 순간들을 조명해볼 것이다.

3/20~21일에 벌어진 뉴욕의 Structure: Data conference 에서, 만일 Big Hadoop이라는 주제가 있었다고 가정해보자.
이제는 사람들이 “Hadoop의 다음은 뭐야?”라고 묻지 않고, “Hadoop이 어떻게 되어야 되는거야?” 라고 물을 수 있는 수준이 되었다.

요즘 벌어지는 일들에 기반해서 그 질문에 대한 답을 해보자면,
“Hadoop은 모든 면에서 더 빨라질 것이고, 결과는 더 유용useful해질 것이다.” 라는 것이다.

1) 조작성이 좋아지고 있다.
Interactivity, big-data-style

(출처: Shutterstock user hauhu.)

(출처: Shutterstock user hauhu.)

몇주 전에 설명했듯이, SQL 은 Hadoop의 다음 주제이다.

SQL이 단지 익숙하기 때문이거나, RDB상의 SQL로 사용되어지는 여러 타입의 질의형식들 때문은 아니다.
몇년간 관계형 데이터를 분석하기 위해 개발된 여러 개의 대용량 병렬 처리 엔진들이 이미 매우 빠르기 때문이다.

이것은 (개발자가 아닌) 분석전문가들이 질문을 하고 답을 받을 수 있다는 것을 의미한다.
표준 MapReduce를 사용해서 전체 데이터를 쿼리하는 것보다, 직관적 속도에 가까울 정도로 더 빠르게 결과를 받을 수 있다.

SQL과 processing 기술이 Hadoop으로 들어오면서 , Table에도 Hadoop 이 들어왔다.
이것은 전통적 데이터웨어하우스에 존재하지 않는 “대규모 확장성scales”과 “유연성flexibility”을 가져다 주었다.
전통적으로 하드웨어나 라이센스가 비싸서, 사전에 정의된 구조로만 가치 있는 데이터를 추출하였다.

그러나, Hadoop은 가상의 공간에, 무한하게, 자유로운 스키마로 저장할 수 있다.
그래서 어떤 포맷이든, 얼마나 많은 데이터든, Hadoop에 저장할 수 있게 되었다.
이제는 많은 회사들은 현실적으로 좀 더 잘 활용할 수 있는 방안에 대해 고민하게 되었다.

하지만, 아직 Hadoop 은 실행을 위해서는 간단한 몇가지 구조를 가지고 있어야 한다.
Hadoop 창시자 중 한 명인 Mike Cafarella는, 이 문제를 해결하기 위해 어떤 데이터 타입이 들어오더라도 프로세스를 자동화할 수 있는 RecordBreaker라는 프로젝트를 수행하고 있다.

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

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

2) HDFS에 DB가 올라갔다.
This is your database. This is your database on HDFS

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

즉, 이런 질문을 할 수 있는 것이다 :
– 만일 내가 HDFS에 비정형 데이터를 이미 가지고 있고, 그것으로 데이터웨어하우스를 만들고 싶어한다고 하자
– 그렇다면, 왜 나는 별도의 Data Store를 필요로 하는 서로 다른 DB들을 실행시켜야 하지? (Hadoop은 이미 DB를 가지고 있는데?)

이것이 HBase가 – Cassandra 같은 NoSQL DB와 비교해서 기술적, 상업적으로 부족함에도 불구하고, – 많이 쓰여지고 있는 이유이다. (역자주.HBase는 Hadoop 위에 바로 올라가는 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 프로젝트도 있다.

3) 실시간 처리의 의미가 넓어지고 있다.
Whatever “real-time” means to you

“실시간”이란 서로 다른 사람과 다른 어플리케이션에 대한 서로 다른 것을 의미하는 용어 중의 하나이다.
“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를 의미했는지 생각해본다면, 이런 유연성flexibility은 분명히 큰 장점이다.
figure1

물론 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초 이하의 미세한 차이는 큰 의미가 없다.

4) 적절한 인사이트는 계획단계부터 시작된다.
Time to insight starts at the planning phase

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 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은 더욱 매력적이 될 것이다.

5) 구글(과 마이크로소프트)가 앞서 가고 있다.
Google (and Microsoft): A guiding light

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이 단지 한 번 반짝하는 기술일지 모른다고 생각한다. 하지만, 그들이 놓치는게 있다. 나는 내년에는 그것들이 사람들에게 증명되어질 것이라고 생각한다.”

Advertisements

Hadoop의 미래가 리얼타임인 이유 5가지”에 대한 5개의 댓글

  1. 김기범
    2013년 8월 13일

    잘 읽었습니다.
    Hadoop이 실시간으로 처리된다면 쓰임새가 많을 것 같습니다.
    구조상 실시간이 될지 안될지는 잘 모르겠지만
    다른 방법이든 뭐든 무조건 기대하고 있습니다!! ㅎㅎ

    • subokim
      2013년 8월 14일

      그런 요구사항이 많으니 곧 여러가지 처리방안들이 올라오지 않을까요? 저도 기대해 봅니다.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

정보

이 엔트리는 2013년 6월 26일에 님이 API와 기술, 번역글에 게시하였으며 , , , , 태그가 지정되었습니다.

내비게이션

%d 블로거가 이것을 좋아합니다: