소소하게 읽은 책이나 잡설등을 올리던 제 블로그에 작년말 빅데이터에 대한 글을 처음 올리고 나서 어느새 일년이 지났습니다. 그 사이에 제 신상에 작은(?) 변화도 있었구요. 하반기가 되면 한풀 꺽일 거라고 했던 제 예측과 다르게 아직도 빅데이터에 대한 얘기가 멈추질 않고 있습니다. 11월에도 다양한 빅데이터 컨퍼런스가 열리고 국내에 빅데이터 포럼도 생겼구요. 빅데이터와 관련된 컨퍼런스에 가보면 여전히 많은 분들이 참석해서 얘길나누고 정보를 찾아 다니고 있는 것 처럼 보입니다.
오늘은 기술적인 얘기보다는 빅데이터와 관련해서 그간 제가 보고 들은 얘기들을 편하게 써볼까 합니다.
솔직히 고백하자면 빅데이터와 관련해서 이제 별로 할말이 없답니다. 제 블로그 포스팅된 날짜를 자세히 보시면 아시겠지만 8월 이후에는 그다지 포스팅을 안했다는 … 아니 못했습니다. ^^
각설하고,
다들 아시다시피 빅데이터를 얘기할 때 하둡을 빼놓을 수가 없습니다. 그러니 하둡 얘기를 다시 해보죠.
기존의 관계형데이터베이스나 데이터웨어하우스 시스템들이 합리적인 가격으로 빅데이터를 처리할 수 없을 때 하둡은 혜성처럼 나타났습니다. 혹자는 리눅스에 빗대어 빅데이터의 커널과도 같다고 하고 혹자는 서비스 프레임워트에 빗대어 빅데이터의 EJB와 같다고 말하는 사람들도 있습니다.
불과 1-2년전까지만 해도 하둡이라는 것이 무엇인지도 잘 알려지지 않았는데 이제는 빅데이터를 얘기할 때 하둡을 얘기하고 맵리듀스(MapReduce) 에 대해서들 얘기하고 있습니다. 많은 프로그래머들도 최근에는 이에 대해서 큰 관심을 가지고 새로운 분야에서의 새로운 경력을 쌓을 수는 없을까 기웃거리는 것 같기도 하구요.
오라클, IBM, HP, 마이크로소프트, 아마존과 같은 IT업계에서는 어느새 하둡을 자신들의 솔루션과 결합을 하거나 클라우드 컴퓨팅의 데이터 플랫폼으로 제공을 하고 있습니다. 국내에서도 클라우드 서비스를 제공하고 있는 SKT, KT 등이 자신들의 클라우드 환경에서 하둡을 사용할 수 있도록 서비스를 제공하거나 준비를 하고 있습니다.
기억하시는 분들도 계시겠지만 마치 지난 90년대말 리눅스의 열풍을 보는 것 같습니다. 수십여가지 리눅스 배포판들이 해외뿐 아니라 국내에서 만들어지고 결국 레드햇이나 우분투와 같은 투자를 받아 그 자본을 바탕으로 상용 리눅스 배포판을 만드는 솔루션 업체들이 등장하기도 하고 웹서비스를 운영하거나, 어플라이언스를 만들거나, 임베디드시스템을 개발하고자 하는 사업자라면 매우 적은 비용을 가지고 자신들만의 시스템, 솔루션등을 만들 수 있게 된 기폭제가 된 것입니다. 아! 국내에서는 와우 리눅스가 기억나네요. 지난 주에 집에 있는 CD을 다 버릴려고 정리를 하는데 정말 수십개의 리눅스설치 CD가 나오더군요.
이제는 너무나도 많이 사용하고 있는 스마트폰 시장의 절반이상이 바로 리눅스 기반의 안드로이드가 없었다면 존재할 수도 없었을 것입니다. 사실상 유닉스에서 리눅스로 이어지면서 현재 우리가 보고 만지고 사용하는 대부분의 시스템, 장비에 리눅스가 사용되지 않는 곳이 없다고 해도 과언이 아닙니다. 맞아요 집에 한대씩은 있는 인터넷 공유기도 바로 리눅스를 사용하고 있죠.
이와 마찬가지로 데이터를 처리하는데 있어서 오라클, MSSQL, DB2와 같은 상용 RDBMS 그리고 오픈소스인 MySQL, PostgreSQL과 더불어 하둡은 필수적인 데이터 플랫폼의 핵심 컴포넌트로 자리잡았다고 생각하시면 됩니다. 이미 다양한 상용 데이터웨어 하우스, 분석 시스템, OLAP 솔루션들은 비록 MapReduce를 사용하지 않더라도 빅데이터 저장소로 HDFS을 사용할 수 있도록 인터페이스를 제공하고 있습니다.
흥미로운 것은 최근 하둡의 발전되는 모습을 보면 철저히 기업이 요구하는 기능으로 채워지기 시작 했고 이미 MapReduce가 가지고 있는 약점을 보완하고 강화시킬 수 있는 방향으로 데이터 프로세싱 프레임워크가 진화하고 있습니다. 전통적인 MPI기반의 고가의 상용 MPP 머신에 비하여 아직 그 성능이나 효율은 상대적으로 좀 떨어진다고 하지만 대용량의 데이터를 저렴한 비용으로 저장할 수 있는 분산스토리지(HDFS)와 함께 상대적으로 개발 용이성이 MPI에 비해서 간단한 MapReduce라는 프로그래밍 모델 그리고 자바라는 언어의 특성을 한층 활용해서 매우 빠르게 그 저변을 확대해나가고 있는 것입니다.
제가 MPI 에 대해서는 잘은 모르지만 아시는 분 얘기를 들어보면 프로그래밍이나 디버깅이 상대적으로 쉽지 않다고들 합니다. 반면에 하둡의 MapReduce 프로그래밍 모델은 MLDM(Machine Learning and Data Mining) 알고리즘을 구현하는데는 약점이 많기는 하지만 상대적으로 개발도 쉽고 잘 구현되기만 하면 장비를 추가할 때마다 선형적인 성능 개선 효과가 있다는 것은 매우 매력적이라고 할 수 있습니다.
[그림: YARN Architecture]
그런 측면에서 아직은 실서비스에서 쓰기에는 부족함이 많지만 하둡 2.0에 해당하는 YARN은 주목할 만하다고 봅니다. 개인적인 생각은 2013년에는 YARN기반의 다양한 분산 컴퓨팅 모델 , 예를 들어MapReduce, MPP, Graphic Processing 등, 이 개발되어 지고 나면 하나하나씩 기존에 연구되고 활용되어 지던 MLDM (Machine Learning and Data Mining) 알고리즘들이 포팅될 것이고 현재 Mahout 정도에 머물고 있는 빅데이터 마이닝 도구들이 크게 늘어나게 될 것으로 예상됩니다.
자연스럽게 싱글머신기반의 알고리즘들이 멀티머쉰, 멀티코어에서 돌아가는 알고리즘들로 포팅되고 개발될 것이기 때문에 아마도 이를 통해서 다양한 산업 분야에서의 활용사례들이 폭발적으로 늘어날 것으로 예상됩니다. 이 시점이 되면 우리는 비로소 빅데이터가 약속하고 있는 가치를 체험하기 시작할 것입니다. 2014년 초가 되면 YARN 기반의 하둡 2.0의 활용이 늘어나면서 더욱더 하둡은 빅데이터의 핵심 컴포넌트로 자리를 잡아나가지 않겠습니까?
그렇게 된다면 현재 구글, 마이크로소프트, 페이스북 같은 회사들만이 할 수 있을 것 같은 대용량 데이터의 저장이나 처리 그리고 데이터 마이닝 기술을 누구나 활용해서 다양한 과학분야, 바이오인포매틱, 의료, 기후예측, 경제 분야에서부터 기업의 인사관리에 이르기까지 매우 다양한 분야에서의 활용이 손쉽게 일어나게 될 것이고 더불어 그 사용이 편리해지고 비용이 내려가고 있는 클라우드 컴퓨팅을 통해서 더욱더 견인되어질 것은 너무나도 분명합니다.
더불어 점점 빅데이터를 다루는 도구들은 많이들 나올 것이고 점점 더 편리해지겠죠. 어느새 하둡을 활용하는 개발자들은 자바로 직접 MapReduce 프로그래밍을 하기보다는 pig 와 hive 을 많이 사용하기 시작했습니다. 이미 많은 사람들이 구글, 아마존, 마이크로소포트의 클라우드 환경에서 데이터를 저장하고 분석하고 있습니다. 클라우드 상에서 웹서비스를 런치해서 글로벌하게 서비스를 하고 이를 통해서 쌓이는 데이터의 저장과 분석 역시 클라우드에서 하기 시작했습니다.
덧붙여 말씀드리고 싶은 것은 이제는 소프트웨어의 개발의 방식과 환경이 크게 바뀌고 있는 것입니다. 저와 같은 사람들은 10년 20년전 기술과 개발 환경이 머리속에 있다보니 이러한 새로운 세대의 개발자들과 환경을 이해하기 힘들게 되었습니다. 이러한 세대들이 다루고 사용하는 데이터의 성격과 도구들이 달라짐에 따라 소프트웨어의 개발 프로세스나 배포의 방식이 더불어 바뀌고 있는 것입니다.
당연한 얘기지만 네트워크 대역폭의 증가와 모바일 네트워크가 점점 더 확대되어가면서 우리는 이제 클라우드 컴퓨팅이 당연히 되는 시대에 살고 있습니다. 전세계의 사람들이 만들어내는 각종 데이터들은 디지털화되어 전세계 어딘지도 모를 데이터 센터에 저장되될 것이고 바로바로 실시간으로 프로세싱되고 분석되어 우리가 의식하든 의식하지 않든 끓임없이 다양한 디바이스를 통해서 여러가지 모습으로 피드백을 주고 우리는 그것에 반응을 하는 하나의 센서처럼 행동하게 되는 시대가 온 것입니다. 이 문장을 쓰다보니 약간 섬찟! 해지기도 하지만 아무튼 우리는 이러한 시대에 성큼 들어서고 말았습니다.
내년에는 또 무엇이 우리를 놀래켜줄까 사뭇 기대됩니다만 … 이러한 시대에 이러한 기술의 끝자락을 잡고 힘겹게 살아가는 저는 운이 좋은 걸까요? 아닐까요? ^^;;;
우승이의 블로그 
핑백: 2012년의 하둡, 그리고 2013년의 하둡 | Tech IT! | All about IT Trend
좋은글 잘 읽었습니다
우연히 들어와 지난 1년 블로그를 밤 새도록 읽고 있습니다. 좋은 자료 공유해 주어서 고맙습니다. 나는 MapReduce에 대해 처음부터 퍽 비관적이었는데, 2003년 인가 구글 MapReduce 논문을 보고 멀티스레드로 간단히 시뮬레이터를 만들어 보았답니다. 당연히 검색에서 필요한 sorting, indexing에는 97년 즈음부터 발표된 구글 페이지랭킹/검색구조 만드는 데에는 “match made in heaven”이지만 그냥 보기엔 잘 어울릴 것 같던 Machine Learning 구현이 쉽지 않았습니다. Adaboost 같은 것도 어려웠었고요. 그래서 그동안 MapReduce로 잘 되나 보자 하고 있다가, 우승님의 이 글을 보고 하둡은 그래도 갈 것 같다는 생각이 들었습니다. Pig, Hive는 어떻게 된 것인지 궁금하네요.
안녕하세요 이현봉님.
제 블로그에 오랜만에 댓글이 올라와서 반가웠습니다.
말씀하신데로 MapReduce로 머신러닝 알고리즘을 구현하는 것은 그렇게 쉬운 것은 아닙니다. 일반적으로 머신러닝 관련 문제들은 최적화문제이고 결국 수렴을 하기 위한 반복적인 계산이 필요한데 MR은 이러한 알고리즘에 취약(?)한 부분이 있습니다. 물론 반복적인 MR을 실행함으로써 PageRank 나 기타 여러 알고리즘들이 구현되어 있기도 하고 이러한 것을 공유하기 위해서 글에서도 언급했듯이 마하웃(Mahout)이라는 오픈소스 프로젝트들도 활발히 진행되고 있습니다.
더불어 이러한 MR의 취약점을 개선하고자 Yarn 이라고 하는 사실상 다양한 컴퓨팅 모델을 지원하기 위한 분산 컴퓨팅 프레임워크로 진화하고 있다고 생각되어집니다. 사실 ML을 위해서는 더 효율적이고 빠른 프레임워크들이 다양한 분산 프레임워크들이 있지요. 예를들어 GraphLab (http://graphlab.org) 이라고 하는 그래프 프로세싱 프레임워크도 있고 이밖에도 찾아보시면 다양한 분산 컴퓨팅 프레임워크들이 있습니다.
이러한 것들이 아무래도 다양한 알고리즘을 MR 이나 Graph 프로세싱 특성에 맞게 알고리즘을 적용시키거나 개선하는 것이라고 본다면 Hive 나 Pig 는 직접 Native MapReduce 프로그래밍을 작성하는 수고를 덜어주기 위한 목적으로 만들어진 언어라고 보시면 됩니다.
Hive는 HQL 언어를 제공하고 있고 Pig 는 Pig Latin 이라는 고유의 프로세싱 언어를 제공하고 있지요. 하지만 내부적으로는 적절한 MapReduce 프로그램으로 전환되어 실제 하둡상에서는 네이티브한 MR 프로그램이 실행되게 됩니다
최근 몇년동안 이 두 언어의 옵티마이저가 상당히 개선되어서 sort,join,group by, count, filter 와 같은 작업은 왠만한 MR 프로그래밍을 직접 구현하는 것보다 더 잘 동작하고 빠르다고 알려져 있습니다. 물론 개발 생산성 역시 매우 뛰어나고 직관적입니다. 특히나 우리가 다루는 대부분의 데이터들이 트랜잭션 형태나 로그기반의 데이터들이 많기 때문에 이러한 데이터들에는 매우 손쉽게 적용하기 쉽고 그 결과를 빠르게 얻을 수 있는 장점들이 있습니다.
이미 하둡을 활용하는 곳에서는 Pig 나 Hive의 활용은 보편화되어 있다고 보셔도 됩니다. 물론 RDBMS가 훨씬 많이 쓰여지고 있고 여전히 RDBMS가 유용하고 간편합니다만 이러한 데이터베이스 시스템에서 다루기 힘든 대용량 데이터를 다루는데 하둡도 꽤 쓸만합니다.
문제는 이러한 분산 환경을 구성하고 최적화하는데 나름의 노하우와 엔지니어링 기술이 수반되기 때문에 어려움이 있다고 봅니다. 하지만 일단 환경이 구성이 되고 나면 그 위에서 사용할 수 있는 프로그래밍 도구나 개발 환경들은 상당 부분 갖추어져 있습니다.
쓰다보니 댓글이 본문처럼 길어져 버렸네요. ^^
조금이라도 도움이 되셨으면 합니다.
친절한 답변 감사합니다. 알려주신 GraphLab을 잠시 다녀왔고, “GraphLab: A New Framework For Parallel Machine Learning” 을 다운받았습니다. Abstract에 나오는 “asynchronous iterative algorithms with sparse computational dependencies while ensuring data consistency and achieving a high degree of parallel performance” 말이 딱 정확하네요. Ensemble Learning 중에는 iteration cycle마다 reducing해야 하는 것들이 있어 어려울 것 같았죠. Pig, Hive 외에 또 읽어 볼 만한 것이 생겼네요. 논문 저자들이 모두 CMU 사람들이네요. 거기서 컴퓨터과목을 좀 들었죠.
http://strataconf.com/stratany2012/public/schedule/detail/25092 에서 RevolutionR의 RevoScaleR 로 glm을 무척 빨리 돌렸다고 하네요. 자료를 보니 RevoscaleR이 R 코드를 하둡과 비슷하게 처리하면서도 stream 모드 형태도 보입니다. R과 다르게. 자료에 나온 것 같이 R+RevoScaleR이 하둡보다 그렇게 빠를 수 있는 것인가 좀 놀랬습니다. MR은 거의 까막눈이지만 자료에 있는 것이 그리 복잡한 것 같지도 않아 잘 못 만들었나 의심하기도 어렵구요.
많은 도움이 되었습니다. “개발능력을 상실한 개발자” 믿습니다. ㅋㅋ. 이 문장이 조금 더 나가면 oxymoron 이 되는 것 아시죠. 그런데요, 사실 요즘 개발자들이 내 때보다 훨씬 공부할 것도 많고 많이 알아요. K&R의 C가 300 페이지 정도였다고 생각되는데 지금은 뭐가 그리 많고, 알아야 하는 것도 많은지.. 80년대 초에 ADA로 숙제해야 하는데 도통 모르겠더구만 요즘 친구들은 안 그럴 거예요. 불쌍합니다. 그럼,
윗 댓글에 올려진 ReveScaleR 에 대한 자료 잘 보았습니다. 발표자료 앞부분에서 고생한 경험이 저에게는 와닿는군요. MapReduce라는 것의 핵심은 결국 각 프로세싱 노드들이 shared nothing 할 수 있는 병렬 알고리즘을 만들어내느냐가 핵심입니다. 즉 reducer 을 사용하지 않고 mapper 만으로 구현할 수 있는 알고리즘을 고안해내면 데이터가 늘어나도 클러스터 노드를 추가함으로써 linear 한 성능 개선을 가져올 수 있게 되는 것이죠. 불행히도 많은 ML 알고리즘들이 이렇게 된게 별로 없고 도구들도 많지 않다는게 문제인데. 발표자료를 보니 ReveScaleR 은 데이터를 파티셔닝할 수 있고 분산 처리가 가능한 GLM(전 이게 무엇인지 잘 모릅니다만. 회기분석에 쓰이는 것이겠죠?) 모듈이 있기 때문에 저렇게 성능 개선이 가능한것으로 보여집니다.
ADA 참 오랜만에 들어보네요. ^^
답변 고맙습니다. 대화 즐거웠습니다.