Spark관련 논문 Resilient Distributed Datasets 을 읽던 중 coarse-grained 와 fine-grained 의 내용이 있어서 간단히 정리를 해본다.

영어를 사용하는 문화권에서는 확실히 이해가 쉬울 듯 한데..

grain은 곡식을 하나하나의 낱알로 만드는 작업을 의미한다. 이 작업을 듬성듬성 크게 할지, 아니면 곱고 가늘게 할지에 따라서 coares와 fine으로 표현한다.

이를 소프트웨어 공학에서는 하나의 프로세스를 쪼개는 정도에 따라서 구분하는 정도로 사용한다.

1. Fine-Grained

잘게 쪼개는 것으로 예를 들면 다음과 같다.

타행이체의 경우 당행잔액조회 => 타행입금계좌 확인 => 타행으로송금 단계로 나눌 수 있고 이를 각각 메소드로 구성할 수 있다. 또한 이 기능들이 다양하게 활용된다면 메소드를 모아서 하나의 모듈로 만들 수 도 있어서 변경이 발생했을 때 보다 유연하게 개발할 수 있는 장점이 있다. 또한 유사하지만 다른 새로운 비지니스가 만들어 질 때 재사용을 통해서 보다 빠르게 구현할 수 있다.즉, Flexible System상에서 유용하다.

2. Coarse-Grained

덩어리로 작업한다.

타행이체의 경우 그냥 "타행이체" 하나 만들어서 사용한다. 일반적으로 EnterpriseApplicationDesign에서는 선호하지 않는 방식이지만 Distributed System상에서 유용하다.

그동안은 Java기반의 EnterpiseApplication을 주로 수행했기 때문에 1번이 많이 친숙하지만, 앞으로는 BigData를 위한 병렬처리쪽으로 구현이 필요한 경우(Spark,Akka등..) 가 생길 것 같아서 2번으로의 전환이 필요할 것 같다.

정리 및 첨언

최근 프로그래밍의 추세도 함수형 프로그래밍이라고 하는데 객체지향과 상반된다고 오해하는 경우가 있다. 

함수형 프로그래밍 = 순차적 프로그래밍 으로 보는 것은 옳지 않다.

내 생각에는 함수형 프로그래밍이라는 것은 수학적함수와 비슷한 개념으로 closure전달이 가능하다는 개념으로 보는 것이 더 낫지 않나 싶다. 대표적인 예를 scala로 볼 수 있다.

RDD논문을 보면 transformation에 대한 설명들이 나오는데 수학개념을 통해서 표현하면 매우 쉽게 이해할 수 있다. (ex, Map(a) => b ) 

Spark구현을 Scala로 한 것은 그 때문이 아닐까 혼자 생각해본다.

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

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가지의 특징이 있더라도 가공했을 때 비지니스적 가치를 주지 못한다면 빅데이터로 보기 어렵다는 의견도 있다.

빅데이터의 주도권

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

<개요>

volatile은 컴파일러가 특정변수에 대해서 옵티마이져에 대해서 캐슁을 하지 않고, 리오더링을 하지 않도록 해주는 키워드라고 한다.

그로 인해 멀티쓰레드 환경에서 동기화문제를 만날 때 사용하는 경우가 많다.

<내용>

예를 살펴보자

기본적으로 자바기본형은 thread-safe하지만 개발환경에 따라 특이한 경우가 발생할 수 있다.

32bit환경에서 long이나 double처럼 64bit 값을 처리할 때 assign이 두단계에 걸쳐서 일어나게 된다. 

(address의 한계때문에 발생한다.

volatile키워드를 사용할 경우 이에 대한 원자성을 보장하여 오류를 방지해준다.

그렇다면 synchronized 는 언제 사용할까? 위와 같이 volatile로 선언하더라도

와 같은 메소드를 수행하면 + 연산까지 원자성을 보장하지는 않기 때문에 마찬가지로 오류가 발생할 수 있다.

이때 add 메소드에 대해서 synchronized 키워드를 사용하여 동기화를 적용한다.

하지만 해보신분들은 알겠지만 synchronized를 사용하는 순간 엄청나게 느려진다. 어찌보면 당연한 결과이다...

<정리>

이를 보완하기 위해서 JDK 1.5이후에서는 Atomic 타입을 제공

 a. 예를 들면Long대신에 AtomictLong을 사용하고 제공되는 addAndGet메소드를 사용할 경우 멀티쓰레드 간의 값을 보장하면서 속도도 매우 빨라진다.

 b. 내부적으로 코드를 살펴보면 AtomicLong은 Number를 확장하며 Serializable을 impl한다 (어찌보면 당연하다..)

 c. 멤버변수로 private volatile long value를 가지고 있으며 addAndGet메소드는 final로 선언되어 무한루프를 반복한다.

 d. Unsafe class의 compareAndSwapLong 메소드를 활용한 compareAndSet메소드를 사용한다. 모든 연산메소드가 동일하다.

<참고사이트>

https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/package-summary.html