빅데이터 배치처리외에 실시간 대량데이터에 대한 처리요건도 늘어감에 따라 스터디를 진행하고 있다.

대표적으로 Storm이 있는데 Spout와 Bolt의 연결을 이용한 Stream 처리 엔진으로 보면 될 것 같다.

모든 책에서 대표적으로 소개되고 있는 로그파일처리부분을 살펴보면 

- 로그파일은 flume을 통해서 읽고

- kafka를 통해서 message 병렬분산 처리를 한다.

- storm과의 연결은 kafka spout를 통한다. (인터넷에 다양한 spout가 이미 존재한다.)

각 구성요소의 개념을 간단히 살펴보면

1. Spout
데이터를 입력받는 곳이다. 공식사이트에서 수도꼭지로 표현되며 단어의 의미는 주둥이,분출

데이터를 끌어오는 개념이며 현재 다양한 source로 부터 받을 수 있도록 spout이 존재한다.

spout과 spout간의 연결도 가능하다.

- open메소드 : 최초 한 번 수행되며 일반적으로 환경구성이 필요한 내용들이 들어간다.

- nextTuple 메소드 : 데이터가 넘어올 때 마다 수행되며, 실제 데이터를 분출시키는 부분이다.

SpoutOutputCollector를 통해서 데이터를 전달한다. (collector.emit메소드를 호출)

- declareOutputFields  : 보내는 데이터에 대해서는 key값을 정의해주어야 OutputFieldsFieldsDeclarer.declare메소드를 호출한다. 해당 Spout에 연결된 Spout/Bolt에서는 이 Key값을 통해서 Value를 가져올 수 있다.

전달 키값을 동일하게 쓰면 받는 쪽에서는 구분없이 하나의 데이터 처리가 가능하며 
전달 키값을 분리하면 분리 처리도 가능함

키값에 대해서는 Topology정의시 상수화 하는 것도 하나의 방법이 될 수 있다.

ack / fail은 필요에 따라 구현한다.

2. Bolt
실제 각 활용영역별로 커스터마이징이 이루어져야 하는 부분이다.

- prepare : 최초 한 번 수행되며 준비에 필요한 내용들이 들어간다. (ex, 환경, IP 등)

- execute : 실제 넘어온 Tuple을 가지고 로직을 수행한다. tuple.getValueByField 메소드를 호출하여 사전에 정의된 Key값을 통해서 value를 가지고 올 수 있다.

- declareOutputFields  : Spout와 동일함

3. Topology

만들어진 Spout와 Bolt를 서로 연결하여 망을 형성한다.

TopologyBuilder를 통해서 구성하고 subtmit한다.

이후 해당 Topology는  사전에 기동된 Storm 프로세스 ( Nimbus )에 전달되고 Nimbus는 각 Supervisor로 할당하여 작업을 수행한다.

작업이 수행되면 별도로 Worker 프로세스가 기동되며 Worker 프로세스내에 Topolog상의 component가 분배되어 Thread로 수행된다. 커스터마이징을 통해서 수동으로 component위치를 지정하여 자원사용량을 분산시키는 것도 가능한다. 

topology 별로 최소 worker 1개 이상이 필요하고 그 이상 지정도 가능하다.

4. Architecture

Nimbus : HDFS의 Namenode와 유사하여 마스터 노드의 역할을 한다. Topology를 받아서 각 Supervisor에게 배포하고 작업을 수행하며 추적한다.

Supervisor : Nimbus로부터 명령을 받아서 Worker 프로세스르 구동한다.

Worker : 실제 컴포넌트 (Bolt, Spout)가 할당되어 task를 수행한다.

5. 정리
분산 병렬처리를 위해서는 기본적으로 Key/Value형태의 데이터로 구성되어야 핞다. (ex, Map/Reduce, Spark 등)

Storm도 마찬가지로 데이터 전달시 Key/Value형태로 전달하도록 되어있다.

빅데이터를 이야기 할 때 항상 나오는 Iteration 과 Interactive를 좀더 공부할 필요가 있다.

6. Storm과 Spark 간단비교

 a. Storm
Apache에서 Storm을 보면 Distributed, real-time computation system으로 소개된다.

실제 Spout나 Bolt의 구현부를 보면 건단위의 흐르는 데이터 (Streaming...) 처리에 적합한 구조로 되어있다.

로그파일은 어쨌든 파일인데 왜 Storm으로 처리하는 예제가 나올까라는 의문을 가졌었는데 로그파일의 경우 실시간 row단위로 쌓이는 데이터이기 때문에 흘러가는 데이터로 보는게 맞다는 생각이 들었다.

어쨌든 Storm은 데이터를 저장하는 것이 아니라 계속 흘려보내는 의도로 출발된 구조로 보면 되겠다.

번외로 Spout와 Bolt간의 특정데이터를 공유해야 할 필요가 있을때는 IMDG를 사용할 수 있을 듯 하다.

 b. Spark

Apache에서 Spark는 Fast and general engine for large-scale data processing 으로 소개된다.
내용과 실제 구현방법을 보면  배치성처리 컨셉이 강하며, 기본적으로는 Map/Reduce처리방식과 유사하다.

RDD개념을 도입하여 Disk I/O를 최소화 했기 때문에 iteration에 강하고, 결과를 다시 인풋으로 받는 (ex, kmeans) 알고리즘 구현시 강점이 있다. Stream처리를 위한 개념으로 Spark Streaming도 있지만 결국 간격이 짧은 배치를 수행하는 컨셉이다.
기본적으로 RDD생성은 파일 또는 다른 RDD에서만 가능하기 때문에 실시간 Stream에는 적합하지 않는 것으로 보인다.

위키백과사전에서 찾아보면 다음과 같은 내용으로 나온다.

CAP 정리, 또는 브루어의 정리(Brewer -)는, 다음과 같은 세 가지 조건을 모두 만족하는 분산 컴퓨터 시스템이 존재하지 않음을 증명한 정리이다.

• 일관성(Consistency): 모든 노드가 같은 순간에 같은 데이터를 볼 수 있다.
• 가용성(Availability): 모든 요청이 성공 또는 실패 결과를 반환할 수 있다.
• 분할내성(Partition tolerance): 메시지 전달이 실패하거나 시스템 일부가 망가져도 시스템이 계속 동작할 수 있다.

RDBMS로는 더이상 처리하기 힘든 대용량의 데이터를 어떻게 처리해야 하는가에 대해서 Hadoop 공부도 하고 NoSQL공부도 하던차에 찾은 자료이다.

과거 DBMS에서 이야기했던 ACID의 기본개념은 모두가 잘 알고 있다.

Atomic(원자성)

Consistent(일관성)

Isolated(고립성)

Durable(영속성)

그런데 QCon에서 구글에서 다음과 같은 의미가 될수도 있다고 발표했다.

Associative(결합) : 결합법칙이 적용되어야 한다. A+B+C = (A+B)+C = A+(B+C)

Commutative(교환) : 교환법칙이 적용되어야 한다.

Idempotent(멱등성) : 반복작업을 해도 결과는 변화하지 않아야 한다.

Distributed

이러한 내용은 클라우드 환경을 의미하는데, 이에 대한 또 다른 개념으로 BASE트랜잭션에 대한 소개가 있다.

Eric Brewer(UC Berkeley 교수)는 ACID와 대조적으로 가용성과 성능을 중시하는 특성을 가진 분산 시스템의 특성을 'BASE'라는 용어로 표현했다.

Basically Available
분산 시스템이기 때문에 항상 가용성을 중시한다. 반대로 말하면, 클라우드에서 분산되어있는 것은 필수이다.
클라우드의 Basically Availability의 실현은 친숙한 것들은 Optimistic Locking 및 큐 등이 있다. 

Soft-State
Soft-State는 '노드의 상태는 내부에 포함된 정보에 의해 결정되는 것이 아니라 외부에서 전송된 정보를 통해 결정된다는 상태의 사고 방식'이다.
중요한 것은 외부에서 보내진 정보에 의해 결정된다는 것이다. 즉, 떨어진 노드 간의 데이터 업데이트는 데이터가 노드에 도달한 시점에서 갱신된다. 
밖에서 받은 정보로 상태를 업데이트하므로 Soft-State하다고 생각한다는 사상이다.

Eventually Consistent
하지만 Soft-State 예제에서, 데이터를 해당 노드에 도달할 때까지는 데이터에 일관성이 없는 상태이다. 
그러나 데이터가 도착하기만 하면 또한 무결성을 보장 수 있으므로, 그 상황은 일시적이다. 그래서 일정 시간이 지나면, 다시 Consistency를 충족시킬 것이다. 
이것을 Eventually Consistent한다.
시스템상에서 일시적으로 Consistent하지 않은 상태가 되어도 일정 시간 후에는 Consistent 상태가 되는 성질을 우리는 Eventually Consistency한다.

참조

http://eincs.com/2013/07/misleading-and-truth-of-cap-theorem/

http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

NoSQL은 분산데이터베이스로 CAP중 P에 집중하는 것이며, RDBMS의 기본사상에는 P가 빠져있다라고 보는 것이었다.

(2016-05-09 추가) 그러나 CAP이론으로는 설명이 부족한 부분도 있고, 한국 Wiki에서는 P에 대한 개념이 잘못되어 있는 부분이 있다. P는 C,A와는 약간 다르게 네트워크에 대한 속성이기 때문에 어느정도의 지연은 감내할 수 밖에 없다.

간단히 보자면 NoSQL역시 네트워크 장애상황에서는 C와 A중 많아도 하나밖에 선택할 수 없다.

결국 정상상황에 대한 분산시스템 동작을 설명할 수 없고, PACELC을 살펴보면 보완이 된다.

이 부분에 대해서는 추후 정리해야겠다!

Scale Up vs Scale Out

빅데이터를 이야기하면 빼놓을 수 없는 아키텍처이다. 간단하게 단일서버내에서 용량을 추가하는 방식을 Scale Up, 노드를 추가하여 확장하는 방식을 Scale Out으로 볼 수 있다. 서버급 장비는 비싸기도 엄청 비싸다. 하지만 데스크탑 서버급을 하나 붙이는 정도라면? 그렇게 부담스럽지 않다. 이렇게 Scale Out방식을 선택해서 출발하게 된것이 바로 빅데이터 처리기술의 대명사 분산파일시스템과 맵리듀스 이다.

Hadoop

과거에는 기가, 테라급의 데이터면 빅데이터라고 볼 수 있었지만 이제는 아니다. 페타바이트를 처리해야하는 상황이다. 하둡은 이론상 6000대 이상 클러스터 구성이 가능하다고 한다. 1테라 하드를 가진 컴퓨터 6000대를 연결하면 6페타바이트 확보가 가능하다. 또한 6000대의 컴퓨터가 병렬로 연산한다면? 슈퍼컴퓨터 뺨치는 성능이 나온다. 야후는 최근 4000노드를 이용하여 단일클러스터를 구상했고 디스크공간이 16페타라고 한다. -_-;; 대단하다

1. HDFS

구글분산파일시스템을 보고 구현한 오픈소스가 바로 HDFS이다. 기존 대용량 파일시스템과의 가장 큰 차이점은 저사양서버를 이용해 스토리지를 구성할 수 있다. HDFS에 저장하는 데이터는 물리적으로 분산된 서버의 로컬디스크에 저장되며 HDFS에서 제공하는 API를 이용해서 처리한다.

HDFS는 다음의 네 가지 목표를 가지고 설계되었다.

장애복구

데이터를 저장할 때 복제 데이터를 같이 저장

스트리밍 방식의 데이터 접근

데이터처리량 중점의 배치작업에 적합하게 설계됨

대용량 데이터 저장

하나의 파일이 테라바이트 이상의 크기를 저장할 수 있음

데이터 무결성

저장데이터는 수정이 불가능하고 읽기만 가능

HDFS가 기존의 모든 대용량 파일시스템을 완전히 대체할 수는 없다. 트랜잭션 처리가 중요한 경우에는 적합하지 않으며, 대용량 데이터 저장 및 배치처리시 권장된다.

또한 HDFS의 경우 데이터 복재와 분산저장이 이루어지기 때문에 저장공간에 대해서 별도 RAID구성이 필요없다.

2. Map Reduce

분석로직에 대해서 Map과 Reduce만 개발자가 적절히 개발하면, 데이터에 대한 분산과 병렬처리는 프레임워크가 처리하게 된다. 네임노드에서 신규 잡이 제출되면 Job Tracker에 의해서 작업이 추적되며 이는 다시 태스크로 잘게 쪼개져서 각 데이터노드로 전달된다. 데이터노드에서는 입력데이터를 스플릿으로 나누어 각 맵퍼가 실행되며, 맵퍼출력결과는 정렬과 병합을 거쳐서 리듀서로 전달된다. 리듀서는 특별히 지정되지 않으면 1개가 동작하며 출력데이터가 다시 HDFS에 저장이 된다. 이러한 방식의 네임노드가 모든 잡을 추적해야한다는 부담이 생겨서 2.0 에서는 YARN을 통해 개선된 아키텍처가 적용된다.

3. Common, YARN, 기타

Hadoop Common의 경우 공통성 유틸리티를 모은 것이라고 생각하면 편리하다.

Hadoop YARN 은 클러스터상에서 자원관리와 Job 스케쥴링을 위한 프레임워크다.

그외에 provisioning을 위한 Ambari나 Hadoop Data처리를 빠르게 할 수 있는 Spark, 쿼리형태로 분산처리를 위한 Hive등이 Hadoop 연관 프로젝트로 등록되어 있다.

Hadoop 의 성능

이러한 구조를 바탕으로 놀라운 대용량 처리성능을 보여주고 있다. 2009년에 1TB를 62초에 정렬했다고 한다.. (3800클러스터로) DBMS에서 1TB 정렬조회하면 아마 다운될거다;;

Hadoop 의 단점

굉장히 멋지고 훌륭한 기술이지만 단점도 있다. ScaleOut의 단점은 복잡성이라고 이야기를 하는데, 하둡 역시 복잡하다. EndUser는 MapReduce에 접근하기 어렵고 설령 개발자라 해도 설계/개발에 상당한 시간을 투자해야 한다. 그런데 또 이러한 단점을 극복하기 위해서 MapReduce를 쉽게 할 수 있도록 Pig, Hive가 나타나서 이제는 단점이라고 보기도 어렵다.

또 하나의 단점은 오픈소스기반이다. 발전속도도 빠르고 구성하는 컴포넌트도 다양하다. 이 말은 바꿔보면 하나로 조합하기가 힘들다는 점이다. 각 컴포넌트마다 설정해야할 내용도 많고 컴포넌트간의 호환성도 검토해야 한다. 간신히 검토해서 한 세트를 맞춰놓으면 다음버전이 나온다.-_-;; 0.01 의 마이너 버전 업데이트임에도 불구하고 꽤나 많은 내용이 바뀌기 때문에 따라가기가 매우 버겁다는 점이다.

BigData

최근 BigData가 주목받고 있다. 출현배경에 대해서 다양한 IT용어들이 난무하며 설명하고 있는데 나만의 생각으로 쉬운단어를 사용해서 이해한 바를 정리해보는 게 목표이다.

빅데이터 출현배경

예측하기를 원한다.

과거 IT시스템의 목표는 사람이 하던 일을 보다 정확하고 빠르게 수행할 수 있도록 도와주는 것이었다.물론 CRM 이라는 것이 있었지만 그저 개념이었을 뿐 크게 효과가 있었는지는 의문으로 남아있다. 하지만 최근에는 보다 더 빠른 움직임(고객대응, 상품출시등)을 통해서 경쟁 속에서 살아남기 위한 필수도구로 IT가 지원을 하고 있다. 이를 위해서 사용자 정보, 소비행위 등에 대해서 보다 적극적으로 수집하고 싶어한다.

SNS

전 세계에서 불고있는 SNS열풍이다. 특히 스마트폰의 발전으로 인해서 개인시 컨텐츠를 소비할 뿐만 아니라 적극적으로 생산하는 시대속에서 살고 있다. 이러한 데이터를 처리하기 위해서는 기존의 RDBMS로 한계가 있다.

통신기술의 발전

스마트폰 뿐만 아니라 이제는 사물간 통신이 점차 증가함에 따라서 데이터가 증가하고 있다. 각종 센서데이터를 통해서 수집되는 데이터들이 늘어나고 있다. SNS에서 개인이 컨텐츠를 생산했다면 이제는 온갖사물로부터 데이터가 생성되고 있다.

빅데이터의 3가지특징

Volume

과거에는 Giga단위의 데이터였지만 이제는 Tera, Peta에 이른다

Velocity

배치성 대량 데이터외에도 실시간, 준실시간으로 데량데이터가 발생한다.

Variety

비정형, 반정형의 데이터가 발생한다. 과거에는 정형데이터를 중심으로 모델링을 통해서 데이터를 적재했다면 이제는 비정형,반정형의 데이터를 구조없이 일단 수집한 뒤 나중에 처리하는 방식이 고려되고 있다.

Value

기존3가지의 특징이 있더라도 가공했을 때 비지니스적 가치를 주지 못한다면 빅데이터로 보기 어렵다는 의견도 있다.

빅데이터의 주도권

현재 주목받고 있는 구글, 야후, 페이스북, 아마존등은 모두 기술을 이용한 서비스로 비지니스를 하는 서비스업체로, 이러한 회사들은 다양한 빅데이터를 운영한 경험과 각종 오픈소스를 통해서 기술력을 축적해왔으며 현재 빅데이터에서 주도권을 가지고 있다.