포커스 차세대실시간빅데이터분산시스템동향 - 스파크와스톰을중심으로 - 엄정호 * 김태홍 * 이승우 * 정창후 * 정한민 ** 최근빅데이터를이용한시스템들이여러분야에서활발히활용되기시작하였다. 이러한빅데이터시스템의중심에는하둡이라는빅데이터저장및처리플랫폼이있었으나, 애플리케이션이다양화되고, 사용자들은더빠르게분석결과를확인하고자하는요구가많아짐에따라실시간으로빅데이터를분석할수있는분산시스템들이제시되고있다. 따라서본고에서는실시간빅데이터분산시스템의동향에대해서대표적인시스템인스파크와스톰을중심으로살펴본다. Ⅰ. 개요 목차 Ⅱ. 하둡기술현황및한계 Ⅲ. 스파크소개 IV. 스톰소개 V. 빅데이터분산시스템비교및 분석 VI. 결론 * KISTI 컴퓨터지능연구실 / 선임연구원 ** KISTI 컴퓨터지능연구실 / 실장 I. 개요 최근성공적으로끝난 2014 년브라질월드컵우승국독일은빅데이터분석기술을기반으로선수들의기량을센서를통해운동량부터순간속도, 심박수, 슈팅동작등을분석함으로써팀을우승으로까지이끌었다 [1]. 또한, 트위터는하루에 10 억건이넘는트윗들을실시간으로분석하여트윗의안티스팸 (Anti-Spam) 정책에활용하고있으며, 국내의금호타이어는제품에 RFID 태그를부착해타이어의생산공정부터최종판매단계까지의제품이력을추적관리하고있다. 수백대의 RFID 기기에서수집되는태그데이터들은스트리밍데이터성격을갖고있기에해당데이터를실시간처 1
주간기술동향 2014. 9. 3. 리기술기반으로품질관리까지적용한것이다 [2]. 이와같은빅데이터기술은엄청난양의데이터가쏟아지고, 이들은데이터베이스에저장되는데이터처럼구조화가되어있지않기때문에분산병렬환경에서데이터를처리해야하는기술이필요하다. 이를위해하둡 (Hadoop)[3] 이대두되었다. 하둡은대용량의데이터를맵리듀스 [4] 라는병렬처리프레임워크를이용하여처리함으로써빅데이터분석을가능하게해준다. 하지만, 최근들어서는 RFID 데이터, 트윗데이터와같이실시간으로대량생산되는데이터가증가됨에따라, 하둡과같은일괄처리방식의시스템으로는이러한유형의데이터를처리하기에는그한계가나타나기시작하였다. 이러한문제를해결하기위해인메모리에서의데이터처리기술과대용량스트리밍데이터를처리하기위한기술들이제시되고있다. 따라서, 본고에서는 2 장에서기존의하둡이가지는특징및한계에대해서기술하고, 이를극복하기위해인메모리환경에서빅데이터를처리하는빅데이터분석엔진인스파크 (Spark)[5] 를 3 장에서소개하고, 스트리밍데이터를처리하기위한실시간빅데이터분석프로세싱프레임워크인스톰 (Storm)[6] 에대하여 4 장에서소개한다. 5 장에서는본고에서소개한분산시스템간기능및적용방안을비교하고, 6 장에서는결론을맺는다. II. 하둡기술현황및한계 하둡 [3] 은 2005 년처음개발되어현재널리사용되고있는빅데이터플랫폼으로야후, 페이스북, 아마존등이채택하였다. 하둡은분산환경에서서버장애의내구성, 분산병렬컴퓨팅의신뢰성및확장성을보장하면서수페타바이트의빅데이터를처리할수있는플랫폼으로개발되었다. 하둡은크게데이터분산저장을지원하는하둡파일시스템과빅데이터처리를지원하는맵리듀스프레임워크로나눌수있다. 먼저, 하둡파일시스템의특징으로는하드웨어장애에대비하는데이터복제및장애복구대책, 데이터의저장소와계산로직을분리한일괄처리의최적화, 다중사용자를효율적으로지원하는사용자와데이터저장서버간직접연결방식을지닌다. 맵리듀스프레임워크는빅데이터의일괄처리를효율화하기위한프로그래밍모델및분산병렬데이터처리방법이다. 맵리듀스프레임워크는 <Key, Value> 형태로데이터를표현하고, 데이터를변환하는맵단계와변환된데이터를키에따라모아주는리듀스단계로구성되는 2 단계프로세싱구조 2 www.iitp.kr
Input key*value pairs Input key*value pairs Data store 1 map Data store n map (key 1, values ) (key 2, values ) (key 3, values ) (key 1, (key 2, (key 3, values ) values ) values ) == Barrier == : Aggregates intermediate values by output key key 1, intermediate values key 2, intermediate values key 3, intermediate values reduce reduce reduce final key 1 values final key 2 values final key 3 values ( 그림 1) 맵리듀스프레임워크의데이터처리모습 [8] 를지닌다. ( 그림 1) 과같이맵단계에서는사용자정의맵함수에따라 <Key, Value> 형태로출력되며, 출력된데이터 (Intermediate Data) 는 Key 에따라각서버로전송되고, 서버에서는리듀스함수를통해데이터가통합된다. 아울러, 하둡의맵리듀스프레임워크는하둡 2.0 버전부터자원의관리를담당하고, 여러애플리케이션들이하둡내에서실행이용이할수있도록기능을제공하는 YARN[7] 과분리되었다. 하둡은일괄데이터처리에효율적인구조를지니고있으나, 현재와같이실시간적으로증가되는빅데이터를처리하기에는다음과같은몇가지문제점을가진다. 첫째, 맵리듀스프레임워크를사용함에있어서중간데이터전송단계에서상황에따라많은디스크 I/O 및네트워크트래픽을야기할수있다. 둘째, 맵리듀스프레임워크에서는맵- 리듀스로이어지는 2 단계구조로데이터를프로세싱하기때문에반복작업이많을경우에비효율적이다. 마지막으로, 비동기적산발적으로일어나는데이터연산또는처리작업에는적합하지않다. 따라서, 현재처럼실시간으로증가되는빅데이터를처리하기위해기존의하둡에서의일괄처리작업을빠르게하고, 사용자의많은반복적인연산을효율적으로처리하기위한스파크와스트리밍데이터와비동기적다중사용자의요청을효율적으로처리하기위한스톰이개발되고있다. 위두시스템의특징및장점은 3, 4 장에서소개한다. 3
주간기술동향 2014. 9. 3. III. 스파크소개 1. 개요스파크 [5] 는 UC Berkeley 의 AMP 랩에서개발하였으며, 하둡의맵리듀스작업에서성능의병목현상으로지목되던디스크 I/O 비용을효율화하고데이터분석작업에용이한인메모리컴퓨팅기반의데이터분산처리시스템이다. 스파크는 2013 년아파치의인큐베이터프로젝트로채택되고, 2014 년정식으로 1.0 버전을출시하였다. 스파크는하둡과같은일괄데이터처리에서반복적인데이터연산이필요한경우에대해서빠르게데이터를처리할수있는시스템구조와사용자친화적대화형의데이터마이닝툴을제공한다. 이를위해스파크에서는 RDD(Resilient Distribute DataSet)[9] 라는데이터집합의추상화객체개념을도입하여사용자가대용량데이터에대한다양한연산작업이용이할수있도록한다. 스파크는메모리부족등으로 RDD 가메모리에상주하지못할시에는하둡파일시스템과연동하여분산파일시스템으로저장된다. RDD 에대한사용자의다양한작업은 DAG(Data Acyclic Graph) 로표현되며, 작업스케줄링은 UC Berkeley 에서개발한 Mesos[10] 또는하둡의리소스관리를담당하는 YARN[7] 을통해관리된다. 스파크의장점으로는첫째, 기존의빅데이터플랫폼인하둡의파일시스템을사용할수있다. 둘째, 스칼라 (Scala)[11] 기반의 14,000 라인의최소화된코드로작성되었기때문에사용자가시스템을이해하기에더욱직관적이다. 셋째, 스파크는 RDD 단위로데이터연산을수행하기때문에대용량데이터를처리하기에용이하다. 2. 스파크구조및특징스파크는분산된다중서버에서메모리자원관리및 RDD 에대한연산을수행하는워커 (Worker) 와사용자의작업또는질의를수행하는드라이버프로그램으로구성된다. 시스템구조는 ( 그림 2) 와같다. - RDD(Resilient distributed dataset): 사용자의데이터집합을추상화하여하나의객체로표현한것으로 RDD 는여러서버에분산되어다수의파티션으로관리된다. RDD 는실제물리적인저장소에저장된데이터가아니기때문에다수의서버중에서한서버가장애를발생해도 RDD 를표현하는정보로복구가능하다. 따라서노드의장 4 www.iitp.kr
애에상당한내구성을지니고있다. - RDD 연산자 : 스파크에서는데이터 처리단위인 RDD 에대한다양한 병렬데이터처리연산을지원하기 위해다음과같은연산자를지원한 다. 연산자는 join, union, sort, filter 등데이터셋을관리하기위한 기본적인연산자를비롯하여하둡의 맵리듀스와유사한기능을하는 map, flatmap 연산자가있다. - 인터프리터결합 : 스파크는앞에서언급한바와같이스칼라로기술되었으며, 스칼 라쉘을제공하여사용자와대화형으로데이터를조작할수있다. 스칼라는자바의 Java Virtual Machine(JVM) 으로컴파일되어자바의클래스로변환된다. 이와같은 자바코드로의변환은하둡파일시스템으로저장하는등하둡연동및코드추적을 용이하게한다. - 작업스케줄링 : 사용자의작업은스파크에서데이터처리단위인 RDD 가변환되는 과정을그래프로표현하고, 실행단계를구성하여스케줄링된다. ( 그림 3) 과같이 사용자의작업은각각의단계로 구분되며, 각단계내에서는 RDD 가변환되는파이프라인을지니고 있다. 만일 RDD 의변환이맵리듀 스에서의셔플링단계와같이대 용량의데이터가서로교환되어야 한다면, 이는연산실패시복구를 위해 HDFS 등의물리적저장소에 저장된후, 다음연산을진행한다. 이와같은경우가아니라면, 대부 Driver Stage 1 분의연산은서버의인메모리에서동작한다. C: Stage 2 tasks results RAM Worker Input Data RAM Worker Input Data ( 그림 2) 스파크시스템구조 [9] A: B: D: Map E: groupby union RAM Worker Input Data G: Stage 3 ( 그림 3) 스파크의작업스케줄링예제 [9] F: join 5
주간기술동향 2014. 9. 3. 3. 스파크와하둡스파크는앞에서언급했듯이사용자의반복적인작업을효율화하고자분산컴퓨팅환경에서인메모리에 RDD 의형태로데이터를유지하는형태의구조를지닌다. 이는반복적연산이많은기계학습애플리케이션에더욱적합하다. ( 그림 4) 에서는기계학습의한애플리케이션인로지스틱회귀분석 (Logistic Regression) 알고리즘을수행했을때의속도성능을보여준다 [12]. 그림에서와같이반복횟수가많아짐에따라하둡과스파크는최대 10 배까지의성능차이를보여준다. 따라서스파크를이용할때는대량의데이터에대하여반복적작업이많을때수행하는것이효율적이다. 4,000 Running Time(s) 3,000 2,000 1,000 0 1 5 10 20 30 Number of Iterations Hadoop Spark ( 그림 4) 스파크와하둡의로지스틱회귀분석알고리즘성능평가결과 [15] IV. 스톰소개 스톰은초기 BackType(www.backtype.com) 에서개발되어 2011 년 7 월에트위터로인수되면서널리알려지게되었으며, 2013 년아파치의인큐베이터프로젝트로전환되어오픈소스로써지속적으로개발중에있다. 스톰은데이터의일괄처리를위해개발된하둡과달리, 데이터의실시간처리를위해개발된범용분산환경기반실시간데이터처리시스템이다 [13],[14]. 스톰은빠른데이터처리속도, 확장성, 내고장성, 신뢰성, 낮은운용난이도와같은장점을가진다. 스톰은트위터에서생산되는 30 테라바이트이상의데이터를실시간으로복합분석 (Complex Analytics) 할수있는플랫폼으로개발되었기때문에, 대용량데이터를빠르게처리할수있는새로운범용빅데이터플랫폼으로주목받고있다 [15]. 특히, 사물인터넷 (Internet of Things: IoT) 관련기술이더욱발전함에따라, 다양한센서데이터및디지털디바이스에서지속적으로발생되는스트리밍데이터를처리하기위한솔루션으로주목받고있다. 또한, 스톰은 JVM 의바이트코드를직접컴파 6 www.iitp.kr
일하는 Clojure[16] 로개발되어, 사용자는프로그래밍언어의종류에종속되지않고, 스톰의데이터처리모델인토폴로지 (Topology) 를구성할수있다 [15]. 일괄처리대상의데이터는디스크등의저장장치에저장되어있다가데이터처리엔진으로입력되는반면, 스트리밍데이터는데이터가생성된후, 데이터처리엔진으로입력되기까지의시간이짧다. 그렇기때문에데이터처리속도가수초이내이며, 스트리밍데이터처리엔진은무정지상태로지속적으로동작한다스톰의성능은호튼웍스의벤치마크 [17] 에서보여주듯이, 한개의노드에서초당 100 만개의메시지 ( 각 100byte) 처리가가능하다. 스톰의성능은다른분산처리시스템과같이네트워크의성능, CPU, 디스크 I/O 등다양한요소들의영향을받지만, 특히스톰은메시지계층의선택에따라성능차이가있다 [18]. 1. 스톰데이터모델스톰은스트리밍데이터를실시간으로처리하기위해서스파우트 (Spout) 와볼트로구성된토폴로지모델을사용한다. 토폴로지모델은데이터플로기반의계산그래프로서데이터처리로직과노드간데이터흐름을나타내는링크를가지고있다. 사용자는이러한토폴로지모델로데이터플로를사용자요구에따라자유롭게구성할수있다. 스파우트는토폴로지모델상에서데이터소스를처리하는시작노드로연속된튜플형태의스트리밍데이터를직접입력받는다. 입력된데이터는방향성을가진토폴로지위상에따라지정된볼트로전달되어사용자가정의한데이터처리로직을수행한다. 이러한토폴로지모델에서의데이터처리는하둡과같은일괄처리와달리사용자가명시적으로스톰을정지하기전까지지속적으로수행된다. 스톰의토폴로지모델을 ( 그림 5) 의예제로설명하면다음과같다. 그림에서스파우트는외부 API 또는아파치쓰리프트 (Apache Thrift)[19] 를지원하는 Kestel queue[20] 와같이이종프로그래밍언어가지원되는 RPC(Remote Procedure Call) 도구를이용하여스트리밍데이터를입력받는다. 아울러, 스파우트는파일, 데이터베이스등다양한데이터소스를입력으로사용할수있다. 스파우트를통해입력된데이터는사용자가구성한토폴로지에따라볼트로전달한다. 볼트는데이터처리로직에따라 Aggregation, Filtering, Transformation 등의처리 7
주간기술동향 2014. 9. 3. Bolt Spout Bolt Bolt Spout Bolt Bolt < 자료 >: http://www.slideshare.net/hadoop_summit/realtime-analytics-with-storm ( 그림 5) 스톰토폴로지예시를수행한결과를다른볼트에전달하며, 이때볼트는복수의노드로데이터를전달하거나복수의노드에서데이터를입력받을수있다. 이러한스톰의토폴로지모델은구성의유연성을가지고있어다양한분야의요구사항을비교적쉽게구성할수있는장점을가진다. 또한, 스톰은토폴로지구성을더욱쉽게구성할수있는 Trident 를제공한다. 2. 스톰아키텍처스톰아키텍처는 ( 그림 6) 과같이마스터노드인님버스 (Nimbus), 슬레이브노드를관리하는슈퍼바이저 (Supervisor), 작업을처리하는워커, 노드간통신및작업상태관리를하는분산코디네이터인쥬키퍼 (zookeeper) 로구성된다. 님버스는마스터노드의데몬으로하둡맵리듀스에서작업을분배하는잡트래커 (Job Tracker) 와같은개념이다. 님버스는워커노드에상주하는슈퍼바이저에작업을분배하고, 쥬키퍼를이용하여노드간의통신및작업의상태관리를통해장애에대비한다. 님버스는토폴로지를정의하고, 이를시작 / 정지하는역할과함께슈퍼바이저를등록하여현재활용가능한슈퍼바이저의현황을파악한다. 또한, 지속적으로상태를모니터링하여슬레이브노드에문제발생시워커를재분배하고, 신규노드증설시작업을재분배한다. 슈퍼바이저는슬레이브노드의데몬으로님버스에서할당받은작업을처리한다. 각 8 www.iitp.kr
워커는로컬노드에의해관리되며, 노드의성능에따라하나이상의워커가독립적으로슈퍼바이저의하위로실행된다. 슈퍼바이저와워커의통신은로컬노드내파일 I/O 를통해수행된다. 슈퍼바이저로할당된각워커는님버스로부터전달받은토폴로지의스파우트와볼트에따라하위레벨의복수의작업스레드를생성하고, 작업간에는독립적으로 ZeroMQ 와같은프로토콜을이용하여실행결과를전달하는구조를가진다. 이때스트리밍데이터의최소단위인튜플의 ID 를트리구조로관리하여각튜플이처리될때마다 ID 의자손노드에결과를저장하여모든입력튜플이처리되는것을보장한다. 쥬키퍼는클러스터설정과상태를저장하며, 님버스와슈퍼바이저는쥬키퍼를통해작업진행상황및클러스터의상태등의정보를제공받는다. 사용자인터페이스는쥬키퍼에저장된현재클러스터의상태및설정을 HTTP 를통해제공하며 UI 를통한클러스터의관리는지원하지않는다. 3. 스톰과하둡 스톰은분산환경의실시간데이터처리플랫폼으로서스트리밍데이터를고속으로처 Node 0 User Interface Zookeeper Nimbus Supervisor Node 1 Node 2 Node 3 Supervisor Worker Worker Worker ZeroMQ Zookeeper File I/O HTTP Thrift < 자료 >: ftp://ftp.tik.ee.ethz.ch/pub/students/2012-fs/ba-2012-14.pdf ( 그림 6) 스톰아키텍처 9
주간기술동향 2014. 9. 3. 리하기위해서명시적인사용자의종료이전에는지속적으로작업이수행되는구조를가지고있다. 이러한특성을지니는스톰은빠른처리가요구되는실시간데이터를정보의최신성을유지한상태에서사용자에게결과를제공해야하는네트워킹, 금융, 제조, 웹등의다양한분야의스트리밍데이터처리에더욱적합하다. 반면, 하둡은일괄처리를위한프레임워크이기때문에실시간처리가요구되는데이터처리와는용도가분명하게다르다. 최근에는이러한스톰과하둡의특성을융합하여실시간처리와일괄처리를위한데이터를구분해서대용량빅데이터를처리하고있는추세이다. 예를들어, 2014 년초 SK 텔레콤에서는이동통신망의네트워크관리시스템구성을위해로그수집에는풀럼 (Flume), 버퍼로레디스 (Redis), 실시간처리에는스톰, 통계저장에는 RDB 를사용하여과거수십분이소요되던분단위통계작업시간을획기적으로줄인사례를발표하며데이터특성에따른올바른처리의효율성을강조하였다 [21]. Ⅴ. 빅데이터분산시스템비교및분석 하둡은대중들에게빅데이터시장에관심을주목시킨매개체역할을하였다. 이러한 하둡은소셜데이터, 센싱데이터, 금융데이터등다양한빅데이터가쏟아져나오고이를 활용하고자하는애플리케이션들도다양해짐에따라하둡의차세대버전빅데이터플랫폼 에대한사용자의요구가높아지고있다. 이같은빅데이터시장의요구로, 스파크와스톰 이제시되었고, 대중의주목을받기시작하였다. 하둡, 스파크와스톰을제공하는기능에 < 표 1> 하둡, 스파크및스톰의기능비교 기능 하둡 스파크 스톰 데이터처리방법 일괄처리방식 일괄처리방식 실시간스트리밍처리방식 업데이트단위 레코드 파일또는테이블 스트림 ( 튜플 ) 컴퓨팅환경 디스크기반 인메모리기반 인메모리기반 반복연산 Weak Strong Medium 주프로그래밍언어 Java Scala Clojure SQL 지원여부 추천환경 연관프로젝트 Tajo 에서지원 데이터대비작업복잡도가크기않고작업의중간단계에서데이터교환이많은시스템에적합 스파크 SQL 에서지원 분할된데이터에대해반복또는많은연산작업이발생하고, 데이터간교환이적은시스템에적합 관련없음 사용자질의에대한응답시간이짧고, 동일한데이터에대하여다양한질의형태가존재하는시스템에적합 10 www.iitp.kr
따라 < 표 1> 과같이비교및분석하였으며, 응용분야또는시스템으로의적용방안을고려하면다음과같다. 첫째, 하둡은일괄작업에효율적인대용량데이터를처리할수있는맵리듀스프레임워크, 리소스를관리하는 YARN, 그리고대용량데이터를안정적으로저장할수있는분산파일시스템을제공하기때문에이를기반으로다양한빅데이터를처리하기위한오픈소스프로젝트들이개발되고있다. 한예로, Tajo 는하둡파일시스템위에서 SQL 을지원하는데이터웨어하우스를개발하는프로젝트이며, YARN 의한애플리케이션으로동작하는스파크, 스톰, HBase, JBoss 등의프로젝트가진행되고있다. 이처럼하둡은주로데이터를저장하는분산파일시스템과리소스를관리하는 YARN 을기타하둡기반프로젝트에제공하는기반인프라로써활용되고있다. 둘째, 스파크는일괄작업의빠른응답시간과사용자와의대화형 (Interactive) 질의를통한양방향분석이가능하기때문에, 클라우데라, 피보탈, IBM, 인텔, 맵알등의빅데이터전문업체에서제공하는하둡스펙에스파크를포함하여배포하고있다 [22]. 또한마이크로소프트스트레티지시스템은최근스파크를분석엔진으로채택하였으며, 미국 NASA 의일일분석시스템으로스파크를이용하고있다 [23]. 이와같이최근에스파크가주목을받는이유는대부분의빅데이터플랫폼데이터분석이분산환경에파티셔닝된데이터에서병렬적으로데이터분석이반복적으로이루어지며, 각분할된데이터간의교환은거의드물기때문이다. 한예로페이스북에서약 96% 정도의작업은위와같은특성을지닌다 [24]. 스파크는앞으로도실시간으로분석해야하는데이터가많아지고, 또한기존의데이터베이스에서사용하는 SQL 구문까지지원함에따라빅데이터플랫폼에서활용도및중요성은매우높아질전망이다. 마지막으로, 분산실시간데이터처리엔진인스톰은지속적으로생성되는스트리밍데이터처리분야에새로운대안으로주목받고있으며특히, 기업에서는스트리밍데이터로입력되는다양한이벤트를분석하여크게예방및프로세스최적화의두가지측면에서활용이가능할것으로보고있다. 금융, 통신, 판매, 유통, 웹관련분야에서는주로보안위험예측및재고예측, 장비고장예측및품질관리, 웹서버의오류예측을통한위험관리및경비감축이기대되며, 시장상황을고려한가격설정, 통신대역폭조정, 고객관리, 유통경로선정, 개인화서비스등에서활용되어기업의수익을극대화할수있을 11
주간기술동향 2014. 9. 3. 것으로예상된다. Ⅵ. 결론 빅데이터는반도체분야에서의무어의법칙과비견될만큼데이터의양이빠르게증가하고있는추세이다. 이러한데이터의홍수속에서하둡이라는빅데이터플랫폼이탄생하였고, 빅데이터처리의중요성을깨닫기시작한많은기업들이하둡시스템을채용하여빅데이터를처리하고있다. 하지만, 빅데이터는활용하는응용분야에따라데이터의특성및사용자작업의특성이있기때문에, 이러한특성들을잘분석하여다양한빅데이터플랫폼을적절히조합하는형태로빅데이터를분석할것으로예상된다. 예를들어, 본고에서기술한스파크와스톰은사용자의작업이연산집약적이고, 데이터의교환이적은병렬화된작업에는스파크가효율적이고, 데이터특성이실시간적으로데이터가생성되는스트리밍데이터인경우에는스톰이효율적이다. 하지만, 앞으로도더다양한데이터특성과작업특성이도출되면그에따른효율적인빅데이터플랫폼이개발될것으로예측된다. 또한, 빅데이터가계속생성되고주목을받는이상, 이러한빅데이터플랫폼기술의중요성은앞으로더욱높아질것이다. < 참고문헌 > [1] MBN, http://vip.mk.co.kr/news/view/21/31/33310.html [2] 디지털타임즈, http://www.dt.co.kr/contents.html?article_no=2013110502011860727002 [3] Hadoop, http://hadoop.apache.org/ [4] Jeffrey Dean and Sanjay Ghemawat, MapReduce: simplified data processing on large clusters, OSDI, 2004, pp 137-150. [5] Spark, http://spark.apache.org/ [6] Storm, https://storm.incubator.apache.org/ [7] YARN, http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/yarn.html [8] M. Zaharia, A. Konwinski, A. Joseph, R. Katz, and I. Stoica, Improving MapReduce Performance in Heterogeneous Environments, Proceedings of the 8th USENIX Symposium on Operating Systems Design and Implementation, 2008. [9] M. Zaharia, M. Chowdhury, T. Das, A. Dave, J. Ma, M. McCauley, M. Franklin, S. Shenker, and I. Stoica, Resilient distributed datasets: a fault-tolerant abstraction for in-memory cluster 12 www.iitp.kr
computing, Proceedings of the 9th USENIX conference on Networked Systems Design and Implementation, 2012. [10] Mesos, http://mesos.apache.org/ [11] Scala, http://www.scala-lang.org/ [12] M. Zaharia, M. Chowdhury, M. Franklin, S. Shenker, and I. Stoica, Spark: Cluster Computing with Working Sets, Proceedings of the 2nd USENIX conference on Hot topics in cloud computing, 2010. [13] IT briefcase, Twitter and Open Source: BackType Storm, 2011.8. 5, http://www.itbriefcase.net/twitter-and-open-source-backtype-storm [14] Khadilkar, Vaibhav V., Murat Kantarcioglu, and BhavaniThuraisingham, StormRider: harnessing storm for social networks, Proceedings of the 21st international conference companion on World Wide Web.ACM, 2012. [15] Storm Distributed and fault-tolerant realtime computation, http://storm.incubator.apache.org/documentation/home.html.accessed: 18 Jun 2012. [16] Clojure - home, http://clojure.org/ [17] Apache Strom-A system for processing streaming data in real time, http://hortonworks.com/hadoop/storm/ [18] Making Storm fly with Netty, http://yahooeng.tumblr.com/post/64758709722/making-stormfly-with-netty [19] Apache Thrift, https://thrift.apache.org/ [20] Storm-Kestrel, https://github.com/nathanmarz/storm-kestrel [21] SKT 빅데이터기반 NMS 뭐가달라졌나, Zdnet, http://www.zdnet.co.kr/news/news_view.asp?artice_id=20131202163614&type=det [22] ITworld, http://www.itworld.co.kr/news/87816 [23] IT daily, http://www.itdaily.kr/news/articleview.html?idxno=52950 [24] G. Ananthanarayanan, A. Ghodsi, S. Shenker, and I. Stoica, Disk-locality in datacenter computing considered irrelevant, Proceedings of Workshop on Hot Topics in Operating Systems, 2011. * 본내용은필자의주관적인의견이며 IITP 의공식적인입장이아님을밝힙니다. 13