2015.09.15

하둡의 길을 밝히려면 스파크가 필요하다

Matt Asay | InfoWorld
지금 하둡에는 절대적으로 견인해 줄 무언가가 필요하다. 하둡은 오래 전부터 맵리듀스(MapReduce)와 동의어로 사용되고 있지만 클라우데라(Cloudera)와 같은 강력한 지지 세력조차 맵리듀스에 등을 돌리고 더 멋지고 섹시한 사촌인, 아파치 스파크(Apache Spark)를 맞이하고 있다.

스파크 1.5가 나온 지금 이미 빠른 처리 엔진은 더욱 좋아졌고, 대조적으로 갑갑한 맵리듀스는 매력이 더욱 떨어져 보인다.

하둡의 미래는 스파크의 존재에 달렸다고 해도 과언이 아니다. 아파치 카산드라(Apache Cassandra)의 최고 전도사인 패트릭 맥퍼딘이 데이터스택스(DataStax)에서 말한 것처럼 "스파크는 하둡이 없어도 성공할 수 있지만 하둡의 미래는 스파크에 달려 있다." 이는 하둡에게 유리하기도 하고 불리하기도 하다.

하둡을 쓸모있게 만들기
하둡이 맵리듀스와 동의어로 사용되는 상황은 과거엔 긍정적이었다. 클라우데라의 저스틴 키스텔린은 인터뷰에서 "하둡은 커널일 뿐이었으므로 HDFS와 맵리듀스로 구성된 '맵리듀스'와 '하둡'이라는 용어는 서로 바꿔서 사용할 수 있었다"고 말했다. 빅데이터의 초창기만 해도 느린 일괄 처리 지향의 맵리듀스만으로도 충분히 좋았다.

하지만 이젠 아니다. 몽고DB(MongoDB) 부사장 켈리 스터먼은 최근 필자에게 이렇게 말했다.

"하둡의 정의 자체가 아직 진행 중인 상태다. 하둡을 구성하는 기술은 매년 늘어난다. 시작은 맵리듀스와 HDFS였지만 지금은 20개가 넘는 프로젝트가 있고 각 프로젝트마다 종속성(dependencies)과 릴리스 일정, 프로젝트 팀, 로드맵, 인터페이스도 제각각이다."

스터먼이 말한 바와 같이 비대해진 하둡의 빅데이터 혁신은 빛과 그림자를 동시에 내포한다. 빛은 지속적인 손질로 인해 하둡의 적합성이 계속 유지된다는 것이며, 그림자는 기업이 기반으로 삼을 만한 안정적인 토대가 없다는 것이다.

하둡의 범위가 확장되는 만큼 하둡 서브 프로젝트의 수는 앞으로도 계속 증가하게 될 것이다. 지금까지는 기존에 있던 것을 계속 개선하기보다는 중요한 구성 요소를 다시 작성하는 패턴이 두드러지게 나타났다.

이런 복잡성(complexity)은 하둡 사용을 어렵게 만드는 요소다. 애플리케이션을 구축하는 개발자가 해야 할 일이 무척 많다. 운영 팀은 안정적이고 성능 기준을 충족하며 안전한 환경을 구축해야 하지만 빠르게 변화하는 구성 요소를 통합하는데 어려움을 겪고 있다.

생태계의 이 같은 복잡성은 하둡 도입이 비교적 지지부진한 상태로 유지되는 이유 가운데 하나다. 또 다른 이유는 맵리듀스의 복잡성이다. 이에 대해 맥퍼딘은 이렇게 말했다.

"그동안 대규모 하둡을 구축했고 많은 맵리듀스를 작성했지만 이제 그런 일은 그만 두고 싶다. map, reduce 명령만으로 유용한 분석을 작성하기는 어렵고 시간도 많이 걸린다. 작업 속도가 느린 것뿐만 아니라 이 프레임워크 자체가 많은 수의 고성능 서버를 필요로 한다."

따라서 업계 종사자들이 그 이상의 무언가를 요구하는 것은 당연한 일이다. 그렇게 원하던 것을 스파크에서 찾은 듯하다.

스파크의 부상
맵리듀스가 뒤늦게 문제를 깨달은 사이 스파크가 하둡에 신선한 공기를 불어넣었다. 데이터스택스(DataStax) 공동 창업자 조나단 엘리스는 "스파크는 맵리듀스에 비해 더 빠르고 사용하기 쉽고 유연하다"고 말했다.

맵리듀스 프로젝트를 시작한 장본인인 더그 커팅이 공동 창업자로 일하는 클라우데라조차 맵리듀스에서 멀어지고 있다.

빅데이터의 핵심이 볼륨과 속도, 다양성이라면 스파크는 일괄 처리 지향의 느리고 삐걱거리는 맵리듀스에 비해 훨씬 더 유리하다. 이는 스파크에 대한 큰 관심으로 이어졌고 스파크는 아파치 소프트웨어 재단 프로젝트 역사상 가장 활발히 개발되는 프로젝트가 되었다.

맵리듀스 대비 스파크의 뛰어난 유용성에 대해 엘리스는 다음과 같이 설명했다.

"기술적인 관점에서 가장 큰 이점은 비관적인 프레임워크가 아닌 낙관적인 프레임워크라는 것이다. 맵리듀스의 경우 파이프라인의 모든 결과는 분산 스토리지에 작성된 후 다음 단계에서 다시 읽힌다. 이는 이 과정에서 장애가 발생할 경우 중단 단계를 다시 계산할 필요없이 중단된 지점부터 다시 계산을 이어갈 수 있음을 의미한다."

반면 스파크는 입력에서 파이프라인을 다시 구축하는 데 필요한 명령만 기록한다. 장애가 발생할 경우 처음부터 다시 시작해야 하지만 파이프라인 중간에 장애가 발생하는 경우는 드물기 때문에 평균적으로 맵리듀스보다 더 빠르다.

스파크에 대한 기대는 하둡이 오랜 기간 동안 약속만 해왔던 사항들을 모두 실현해준다는 데 있다. 스터먼은 "많은 이들이 하둡이 실제보다 과대 포장됐다고 느낀다. 스파크는 이들이 기대했던 것을 제공할 것으로 기대를 모으고 있다"고 말했다.

스파크가 있어야 할 자리
스파크가 앞으로 빅데이터 시장을 독주할 것이라는 말은 아니다. 가트너의 빅데이터 도입 설문 조사를 보면 알 수 있듯이 빅데이터는 하둡(맵리듀스)보다 항상 더 컸다.


스파크의 입지를 확보하려면 스파크는 다른 요소들과의 원활한 상호운용 가능성을 촉진해야 한다. 호튼웍스(Hortonworks)의 기업 전략 부문 부사장 숀 코놀리는 "스파크는 유용하고, 다양한 기술에 내장할 수 있다는 장점으로 인기를 얻고 있다"고 말했다. 스터먼이 조언한 내용은 다음과 같다.

"하둡과 스파크가 분석 사용 사례에 계속 집중한다는 점을 간과하면 안 된다. 몽고DB, 포스트그리(Postgres), 카산드라(Cassandra), 레디스(Redis)와 같이 데이터가 생성되는 위치인 비즈니스를 움직이는 운영 애플리케이션을 실행하는 데 집중하는 다른 기술들이 있다. 이런 데이터베이스는 하둡, 스파크와 상호 보완적이다. 과거 데이터 아키텍처 세대에서 관계형 데이터베이스와 데이터웨어하우스의 관계와 거의 비슷하다."

엘리스는 "하둡의 환상을 현실로 구현하기 위해 스파크는 많은 것을 시도하고 있다"고 말했다. 그러나 스파크가 현재 개발 중인 분야인 처리 및 그래프 데이터베이스와 스트리밍, 기계 학습 등에서 최고가 될 수 있을 지는 불투명하다.

요약하면, 하둡의 미래가 스파크에 달려 있다면 스파크의 미래는 임무 변경을 제한하는 데 달려 있다. editor@itworld.co.kr


2015.09.15

하둡의 길을 밝히려면 스파크가 필요하다

Matt Asay | InfoWorld
지금 하둡에는 절대적으로 견인해 줄 무언가가 필요하다. 하둡은 오래 전부터 맵리듀스(MapReduce)와 동의어로 사용되고 있지만 클라우데라(Cloudera)와 같은 강력한 지지 세력조차 맵리듀스에 등을 돌리고 더 멋지고 섹시한 사촌인, 아파치 스파크(Apache Spark)를 맞이하고 있다.

스파크 1.5가 나온 지금 이미 빠른 처리 엔진은 더욱 좋아졌고, 대조적으로 갑갑한 맵리듀스는 매력이 더욱 떨어져 보인다.

하둡의 미래는 스파크의 존재에 달렸다고 해도 과언이 아니다. 아파치 카산드라(Apache Cassandra)의 최고 전도사인 패트릭 맥퍼딘이 데이터스택스(DataStax)에서 말한 것처럼 "스파크는 하둡이 없어도 성공할 수 있지만 하둡의 미래는 스파크에 달려 있다." 이는 하둡에게 유리하기도 하고 불리하기도 하다.

하둡을 쓸모있게 만들기
하둡이 맵리듀스와 동의어로 사용되는 상황은 과거엔 긍정적이었다. 클라우데라의 저스틴 키스텔린은 인터뷰에서 "하둡은 커널일 뿐이었으므로 HDFS와 맵리듀스로 구성된 '맵리듀스'와 '하둡'이라는 용어는 서로 바꿔서 사용할 수 있었다"고 말했다. 빅데이터의 초창기만 해도 느린 일괄 처리 지향의 맵리듀스만으로도 충분히 좋았다.

하지만 이젠 아니다. 몽고DB(MongoDB) 부사장 켈리 스터먼은 최근 필자에게 이렇게 말했다.

"하둡의 정의 자체가 아직 진행 중인 상태다. 하둡을 구성하는 기술은 매년 늘어난다. 시작은 맵리듀스와 HDFS였지만 지금은 20개가 넘는 프로젝트가 있고 각 프로젝트마다 종속성(dependencies)과 릴리스 일정, 프로젝트 팀, 로드맵, 인터페이스도 제각각이다."

스터먼이 말한 바와 같이 비대해진 하둡의 빅데이터 혁신은 빛과 그림자를 동시에 내포한다. 빛은 지속적인 손질로 인해 하둡의 적합성이 계속 유지된다는 것이며, 그림자는 기업이 기반으로 삼을 만한 안정적인 토대가 없다는 것이다.

하둡의 범위가 확장되는 만큼 하둡 서브 프로젝트의 수는 앞으로도 계속 증가하게 될 것이다. 지금까지는 기존에 있던 것을 계속 개선하기보다는 중요한 구성 요소를 다시 작성하는 패턴이 두드러지게 나타났다.

이런 복잡성(complexity)은 하둡 사용을 어렵게 만드는 요소다. 애플리케이션을 구축하는 개발자가 해야 할 일이 무척 많다. 운영 팀은 안정적이고 성능 기준을 충족하며 안전한 환경을 구축해야 하지만 빠르게 변화하는 구성 요소를 통합하는데 어려움을 겪고 있다.

생태계의 이 같은 복잡성은 하둡 도입이 비교적 지지부진한 상태로 유지되는 이유 가운데 하나다. 또 다른 이유는 맵리듀스의 복잡성이다. 이에 대해 맥퍼딘은 이렇게 말했다.

"그동안 대규모 하둡을 구축했고 많은 맵리듀스를 작성했지만 이제 그런 일은 그만 두고 싶다. map, reduce 명령만으로 유용한 분석을 작성하기는 어렵고 시간도 많이 걸린다. 작업 속도가 느린 것뿐만 아니라 이 프레임워크 자체가 많은 수의 고성능 서버를 필요로 한다."

따라서 업계 종사자들이 그 이상의 무언가를 요구하는 것은 당연한 일이다. 그렇게 원하던 것을 스파크에서 찾은 듯하다.

스파크의 부상
맵리듀스가 뒤늦게 문제를 깨달은 사이 스파크가 하둡에 신선한 공기를 불어넣었다. 데이터스택스(DataStax) 공동 창업자 조나단 엘리스는 "스파크는 맵리듀스에 비해 더 빠르고 사용하기 쉽고 유연하다"고 말했다.

맵리듀스 프로젝트를 시작한 장본인인 더그 커팅이 공동 창업자로 일하는 클라우데라조차 맵리듀스에서 멀어지고 있다.

빅데이터의 핵심이 볼륨과 속도, 다양성이라면 스파크는 일괄 처리 지향의 느리고 삐걱거리는 맵리듀스에 비해 훨씬 더 유리하다. 이는 스파크에 대한 큰 관심으로 이어졌고 스파크는 아파치 소프트웨어 재단 프로젝트 역사상 가장 활발히 개발되는 프로젝트가 되었다.

맵리듀스 대비 스파크의 뛰어난 유용성에 대해 엘리스는 다음과 같이 설명했다.

"기술적인 관점에서 가장 큰 이점은 비관적인 프레임워크가 아닌 낙관적인 프레임워크라는 것이다. 맵리듀스의 경우 파이프라인의 모든 결과는 분산 스토리지에 작성된 후 다음 단계에서 다시 읽힌다. 이는 이 과정에서 장애가 발생할 경우 중단 단계를 다시 계산할 필요없이 중단된 지점부터 다시 계산을 이어갈 수 있음을 의미한다."

반면 스파크는 입력에서 파이프라인을 다시 구축하는 데 필요한 명령만 기록한다. 장애가 발생할 경우 처음부터 다시 시작해야 하지만 파이프라인 중간에 장애가 발생하는 경우는 드물기 때문에 평균적으로 맵리듀스보다 더 빠르다.

스파크에 대한 기대는 하둡이 오랜 기간 동안 약속만 해왔던 사항들을 모두 실현해준다는 데 있다. 스터먼은 "많은 이들이 하둡이 실제보다 과대 포장됐다고 느낀다. 스파크는 이들이 기대했던 것을 제공할 것으로 기대를 모으고 있다"고 말했다.

스파크가 있어야 할 자리
스파크가 앞으로 빅데이터 시장을 독주할 것이라는 말은 아니다. 가트너의 빅데이터 도입 설문 조사를 보면 알 수 있듯이 빅데이터는 하둡(맵리듀스)보다 항상 더 컸다.


스파크의 입지를 확보하려면 스파크는 다른 요소들과의 원활한 상호운용 가능성을 촉진해야 한다. 호튼웍스(Hortonworks)의 기업 전략 부문 부사장 숀 코놀리는 "스파크는 유용하고, 다양한 기술에 내장할 수 있다는 장점으로 인기를 얻고 있다"고 말했다. 스터먼이 조언한 내용은 다음과 같다.

"하둡과 스파크가 분석 사용 사례에 계속 집중한다는 점을 간과하면 안 된다. 몽고DB, 포스트그리(Postgres), 카산드라(Cassandra), 레디스(Redis)와 같이 데이터가 생성되는 위치인 비즈니스를 움직이는 운영 애플리케이션을 실행하는 데 집중하는 다른 기술들이 있다. 이런 데이터베이스는 하둡, 스파크와 상호 보완적이다. 과거 데이터 아키텍처 세대에서 관계형 데이터베이스와 데이터웨어하우스의 관계와 거의 비슷하다."

엘리스는 "하둡의 환상을 현실로 구현하기 위해 스파크는 많은 것을 시도하고 있다"고 말했다. 그러나 스파크가 현재 개발 중인 분야인 처리 및 그래프 데이터베이스와 스트리밍, 기계 학습 등에서 최고가 될 수 있을 지는 불투명하다.

요약하면, 하둡의 미래가 스파크에 달려 있다면 스파크의 미래는 임무 변경을 제한하는 데 달려 있다. editor@itworld.co.kr


X