블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

대충보는 Storm #6-Apache Storm 그룹핑 개념 이해하기

 조대협 (http://bcho.tistory.com)



지금까지 컴포넌트간의 경로 라우팅, 즉 Spout 에서 Bolt간, Bolt에서 Bolt간 경로를 설정하는 방법에 대해서 알아보왔다.

그렇다면 각 컴포넌트간 라우팅을 할때 그 안에 있는 Task간에는 어떻게 상세하게 라우팅이 될까? Storm에서는 이 Task간의 라우팅을 정의하기 위해서 Grouping이라는 개념을 사용한다.


Shuffling

가장 간단한 라우팅 방법으로 Bolt A에서 Bolt B로 라우팅을 한다고 했을때, Bolt A내의 있는 Task가 Bolt B에 있는 Task중 아무 Task로 임의로(랜덤하게) 라우팅 하는 방식이다.




Field

Bolt A에 있는 Task에서 Bolt B에 있는 Task로 라우팅을 할때, 규칙성을 갖는 것중 하나인데, 보내고자 하는 데이타의 특정 필드에 있는 값을 기준으로 Bolt B에 있는 특정 Task로 라우팅 하는 방식이다. 라우팅 기준은 지정한 필드의 값을 가지고 해쉬를 계산해서 해쉬에 따라서 Bolt B에 있는 Task로 라우팅 시키는 방식이다.

예를 들어, Bolt B에 Task가 3개가 있다고 가정할때, 나이라는 필드로 “Field Grouping”을 한다고 하면, 나이/3으로 나눈 나머지 값에 따라서 Task A,B,C로 라우팅 하는 방식이다. (나눗셈은 설명을 쉽게 하기 위해 예를 들었지만 비슷한 원리로 해쉬를 계산하여 라우팅을 한다.)

Bolt에서 로컬 캐쉬를 사용하거나 할때, 같은 해쉬의 데이타가 같은 Task로 라우팅이 되게 해서 캐쉬 히트율을 높이는 것등에 유용하게 사용될 수 있다.



Global 

Global 그룹핑은 모으는 개념(Aggregation)의 개념이다. Bolt A의 어느 Task에서 메세지를 보내더라도 항상Bolt B똑같은 하나의 Task로 라우팅이 되는 방식으로, Bolt B에 있는 Task중에서 Task ID가 가장 작은 특정 Task로만 라우팅을 한다.

분산해서 연산한 값을 모두 모아서 합산을 한다던가등에 사용할 수 있다.



All

All 그룹핑은 일종의 브로드 캐스트 개념으로 Bolt A의 하나의 Task가 메세지를 전송하면 Bolt B의 모든 Task가 메세지를 받는 형태이다.

각 Task들에 설정 변경등을 넘길때 유용하게 사용될 수 있다.





Direct

당연히 있을 것으로 생각했겠지만 당연히 있는 기능이다. Bolt A의 Task에서 Bolt B의 특정 Task로 명시적으로 라우팅을 지정하는 기능이다. 이때 주의할점이 Bolt B의 Task를 지정할때,  Task Id가 아니라 Task의 Index로 타겟을 지정한다. 예를 들어 Bolt B에 Task가 5개가 있을때, 0번, 1번식으로 타켓을 지정하게 된다.





Custom

Custom 그룹핑은 라우팅 로직을 개발자가 직접 작성해서 넣는 방식이다.


Local or Shuffle

다소 주의 깊게 볼 필요가 있는 그룹핑 방식이다. 기본적인 동작 방식은 Shuffle과 다르지 않으나,

Bolt A에서 Bolt B의 Task로 라우팅을 할때, Bolt A에서 메세지를 보내는 Task와 같은 JVM 인스턴스 (Woker)에 Bolt B의 Task가 있을 경우 같은 JVM 인스턴스에 있는 Task로 우선 라우팅을 한다. 이는 네트워크를 이용한 리모트 호출을 줄이기 위한 방법이다.

그러면 Bolt의 Task들은 각 Worker에 어떻게 배치 될것인가에 대한 질문이 올 수 있는데, 이렇게 Task를 Worker에 배치하는 행위를Scheduling(스케줄러)라고 하고, 배치를 하는 주체를 Scheduler라고 한다. 자료를 몇개 찾아봤지만 Scheduling 정책에 대해서는 명확하게 나와 있지 않고, 무작위 적으로 배치하는 것으로 보이는데, 조금 더 research가 필요할듯. 


참고 :Pluggable Scheduler

애플리케이션 성격에 맞게 스케쥴링 정책을 구현해서 사용할 수 있는데, 이를 Pluggable Scheduler라고 한다.

http://xumingming.sinaapp.com/885/twitter-storm-how-to-develop-a-pluggable-scheduler/ 의 예에 나와 있는 시나리오를 보면, 특정 Spout의 경우에는 상용 소프트웨어를 사용하는데, 이 상용 소프트웨어는 Machine당 라이센스를 가지고 있기 때문에 이 Spout은 반드시 라이센스가 설치된 서버에 스케쥴링(배포)되어야 한다. 그래서 특정 스케쥴링 정책이 필요한데, 첨부 링크에 있는 내용은 Pluggable scheduler를 구현하는 방법에 대해서 설명하고 있다.





Storm을 이용한 실시간 데이타 처리 #1-데이타 스트림 개념 이해하기

조대협(http://bcho.tistory.com)

 


Apache Storm 은 실시간 데이타 처리를 위한 시스템이다.. 나온지는 꽤 오래됬지만 요즘 빅데이타와 실시간 분석과 함께 다시 화두가 되고 있는데, Apache Storm에 대해서 알아보도록 하자.


 

스트리밍 처리에 대한 개념

Storm을 이해하기 위해서는 먼저 데이타 스트리밍9(Data Streaming) 에 대한 개념을 이해 해야 한다. 비유를 하자면 데이타가 흘러가는 강(river)와 같은 의미라고나 할까?

예를 들어보면, 트위터에서 생성되는 데이타 피드들은 일종의 데이타 스트림이다, 시간이 지나감에 따라서 끊임 없이 데이타 들이 생성된다.



<그림. 트위터의 트윗 데이타 스트림>

또는 공장의 팬베이어 벨트의 센서를 통해서 생성되는 각종 계측 값들도 데이타 스트림으로 볼 수 있다. 신용카드 트랜젝션, 전자 상거래 사이트의 구매 트렌젝션등. 이러한 데이타는 시간을 축으로 하여, 계속해서 생성되는 데이타 이다.

그렇다면 이런 스트림 데이타로 무엇을 할 수 있는가? 다시 트위터를 예를 들어보자


트위터 스트림을 이용한 소셜 마케팅 반응 분석

트위터 데이타 피드 스트림을 모니러링 하면서, 스마트폰과 관련된 키워드가 나오면 A社와 B社에 대한 스트림만을 수집하여, 각사별로 피드의 내용이 긍정적인지 부정적인지를 판단하는 시스템이 있다고 하자

이를 데이타 스트림 분석 개념으로 표현하면 다음과 같다.



<그림. 트위터 데이타 스트림 분석을 통한 제품 반응 분석>

먼저 스마트폰 관련 데이타 스트림을 모두 수집한다.

그 중에서, A사가 언급된 피드와, B사가 언급된 피드를 분리한다.

각 피드에 대해서, 문자의 구문이 긍정인지 부정인지를 판단한다. 예를 들어, Good,Awesome 등의 긍정적인 단어가 들어가 있으면 긍정적인 것으로 판단하고, Bad,fuck 등 부정적인 단어가 들어가 있으면 부정적인 반응으로 판단한다.

그후에, 각각의 반응에 대해서 카운트를 한다음에, 시계열(Time series) 그래프로 대쉬 보드에 표현한다.

정리해보면, 계속해서 들어오는 데이타들의 흐름을 여러 방향으로 분류하고 처리해서 계속해서 결과를 업데이트해주는 일종의 work flow와 같은 개념을 가지는 것이 데이타 스트림 처리이다.

이러한 데이타 스트림 처리는 일종의 중첩 함수의 개념으로도 볼수 있는데,

A사 제품에 대한 긍정적인 반응 = [“긍정적인 단어 필터 함수”(
[“A
사 제품에 대한 필터 함수”](“트위터의 스마트폰 관련 피드”)
);

와 같은 형태로 나타내어 줄 수 있다. (결국 실시간 데이타 스트림 처리는 실시간으로 들어오는 데이타 에 대해서 중첩으로 여러개의 함수 처리를 순차적으로 하는 것이다.)

물론 이러한 작업들은 데이타를 모두 모아서 수집해놓고 데이타 베이스에 저장해놓고 주기적으로 배치르 통해서 분석하는 것도 가능하다. 그러나 선거나 마케팅과 같이 실시간 대응이 중요한 경우에는 실시간 데이타 분석이 중요하기 때문에, 데이타 스트림을 실시간으로 분석하는 것이 필요하다.


이벤트 감지를 통한 신용 카드 이상 거래 감지

이번에는 데이타 스트림 처리에 이벤트 처리라는 개념을 추가해보자.

신용 카드 결재시, 결재 내용을 저장하는 것 뿐만 아니라, 사용자의 결재 내역이 문제가 없는지를 검출하는 시나리오이다.

이상거래 검출 요건은, 사용자가 평상시 결재 액보다 많은 금액이 결재되거나, 사용자가 결재할때, 물리적으로 이상한 곳에서 결재가 이루어 졌을때, 여를 들어 서울에서 카드 결재 후에, 10분 후에 부산에서 같은 카드로 결재가 이루어진 경우는 이상 거래로 검출하는 시스템이다.

다음 플로우를 보자



<그림. 실시간 신용 카드 이상 거래 검출>

신용 카드 결재 정보 데이타 스트림이 들어오면 결재 내용을 저장하는 스트림과 이상 거래를 검출하는 스트림 두가지로 분리되서 스트림이 처리된다.

이상 거래 검출 스트림에서는, 사용자의 구매 패턴을 분석하고 계속해서 학습한 후에, 이를 통해서 사용자 구매 패턴 검증단계에서 구매 금액이 일상적인 구매 패턴인지를 판단한다.

판단의 기준은 머신 러닝을 이용하여, 해당 사용자의 구매 패턴을 알고리즘화 해놓을 수 있다.

다음으로 결재 위치를 저장한 다음에 사용자 결재 위치 검증단계에서 지난 결재 가맹점 정보를 기반으로 이번 결재의 가맹점의 위치가 시간상으로 이동이 가능한 곳인지를 판단한다.

서울 강남에서 결재 한 후에, 30분후 서울 잠실에서 결재한 것은 정상 거래로 보지만 서울에서 결재했다가 10분후에 부산에서 결재 하는 것등은 이상거래로 취급한다.

이러한 시나리오는 결재가 이루지는 동시에 같이 실행되어야 하기 때문에 데이타 베이스 기반의 배치 처리로는 불가능하면 실시간 데이타 스트림을 분석해야 한다.

이외에도 시스템의 로그 스트림을 이용한 분석이라던지, 이벤트 처리, 데이타 가공, 머신러닝등 아주 다양한 부분의 실시간 처리에 데이타 스트리밍 처리는 사용될 수 있다.


데이타 스트림 처리를 이루는 기술들

앞의 신용카드 이상 거래 검출 시나리오를 보면 데이타 스트림을 분석하는데, 몇가지 추가적인 기술일 사용되었음을 볼 수 있다.


스트리밍 처리

먼저 데이타 스트림을 처리하기 위한 스트리밍 시스템이 필요하다, 데이타 스트림을 여러가지 경로로 분산하여, 각각의 단계별로 처리(사용자 구매 패턴 분석, 구매 패턴 검증,…)하는 워크 플로우 기능이 필요하다.

이러한 프레임웍은 앞으로 살펴보고자 하는 Apache Storm이 대표적이고 근래에는 Apache Spark도 많이 사용되고 있다.


대용량 분산 큐

다음으로 대용량으로 여러 경로를 통해서 들어오는 데이타를 수집하기 위한 터널(수집용 깔때기)이 필요한데, 비동기 처리를 위한 큐가 적절하다 그중에서도, 많은 데이타를 동시에 처리하기 위한 대용량 지원성이 필수적인데, 이를 위해서는 Kafka와 같은 대용량 분산 큐 솔루션이 적절하다.


머신러닝

사용자의 거래 패턴을 분석하여, 이상거래인지 검출을 하려면, 컴퓨터에서 사용자의 거래 패턴을 알려줄 필요가 있는데 이는 기존의 사용자 거래 내역을 학습하여 하여 패턴을 분석해내는 머신러닝 기술이 필요하며, 이는 Apache Mahout, Microsoft Azure ML (Machine Learning), Spark ML등이 있다.


이벤트 처리

마지막으로 이벤트 처리 부분이 있는데

카드 결재 장소가 지난 장소에 비해서 시간*20km 이상이면 이상거래로 판단해라”. 라는 이벤트를 정의할 수 있다. (※ 한시간에 20km를 이동할 수 있다고 가정)

특정 조건에 대해서 이벤트를 발생 시키는 것을 이벤트 처리라고 이런 처리를 CEP (Complex Event Processing) 라고 부르고, 이를 구현한 아키텍쳐를 EDA (Event Driven Architecture)라고 한다.

이러한 이벤트 처리 프레임웍으로는 JBoss Drool이나, Esper와 같은 프레임웍이 있다.


이외에도 데이타 스트림 분석을 위해서는 시나리오에 따라 더 많은 기술이 사용된다. 추가 사용되는 기술은 기회가 되면 향후에 추가로 소개하도록 한다. (아직도 공부 中)

지금까지 간략하게 나마 데이타 스트림의 개념과 이를 처리 하는 방법에 대해서 알아보았다.

그러면 다음에는 이런 데이타 스트림을 처리하기 위한 대표적인 프레임웍중의 하나인 apache storm에 대해서 소개해도록 한다.


람다 아키텍쳐의 소개와 해석

조대협 (http://bcho.tistory.com)


람다 아키텍쳐란

람다 아키텍쳐는 트위터에서 스트리밍 컴퓨팅에 있었던Nathan Marz에 의해서 소개된 아키텍쳐로, 실시간 분석을 지원하는 빅데이타 아키텍쳐이다.

아키텍쳐에 대한 자세한 내용은 http://lambda-architecture.net/ 에 소개되어 있다.


문제의 정의

아키텍쳐에 대한 이해를 돕기 위해서 예를 들어 설명해보자.

 페이스북과 SNS 애플리케이션 SNS가 있다고 가정하자. 이 애플리케이션은 모바일 애플리케이션이며, 글쓰기, 읽기, 댓글 달기, 스크롤 하기, 페이지 넘기기등 약 1000여개의 사용자 이벤트가 있다고 가정하자.

 사용자 수는 대략 1억명이며, 매일 이 각 사용자의 행동 패턴을 서버에 저장하여, 일별로, 사용자 이벤트의 개수를 통계로 추출한다고 하자.

클라이언트 디바이스로 부터 올라오는 데이타는 다음과 같다

  • 사용자 : 조대협

  • 날짜 : 2015년 1월 5일



<그림 1. 클라이언트에서 올라오는 데이타 포맷>

이런 환경에서, 기간별 특정 이벤트 추이, 가장 많이 활용되는 이벤트 TOP5 등의 통계 정보를 실시간으로 보고 싶다고 가정하자

가장 단순한 접근은 RDBMS에 저장하고 쿼리를 수행하는 방법이다.


<그림 2. 로그 데이타를 RDBMS에 저장한 포맷>

RDBM에 저장하고 SQL 쿼리문을 돌리면 되겠지만, 문제는 간단하지 않다. 1000개의 컬럼에, 1억명이 사용하는 시스템이다. 즉. 하루에 최대 1000개의 컬럼 짜리, 1억개의 레코드가 생성이 된다것이다.한달이면 30억개의 레코드이다.

이런 많은 데이타를 동적 SQL로 실행하였을때 그 수행시간이 많이 걸린다.


배치를 활용

그러면 이런 시간이 많이 걸리는 문제를 어떻게 해결하면 좋을까? 이를 위한 전통적인 접근 방식은 배치(BATCH)를 활용하는 것이다. 배치는, 어떤 특정 정해진 시간에, 계산을 미리 해놓는 것이다.

즉 데이타를 모아 놓았다가.밤마다.그날짜의 사용자들의 이벤트들의 합을 매일 계산해놓은 테이블을 만들어 놓으면 된다.



<그림 3. 일별 배치로 생성된 이벤트 데이타 테이블>

자아, 이렇게 배치로 테이블을 만들어 놓으면, 특정 기간에 각 이벤트별 통계를 내기가 쉬워 진다. 1년분의 데이타라하더라도 365 행 밖에 되지 않기 때문에, 속도 문제가 해결이 된다.

실시간 데이타의 반영

테이블 조인

이렇게 배치 테이블을 생성하면, 성능에 대한 문제는 해결이 되지만, 데이타가 배치 주기에 따라 최대 1일의 편차를 두게 된다. 즉 실시간 반영에 대한 문제가 발생한다.

그렇다면 어떻게 해결을 해야 할까? 해결은 배치 테이블과 그날의 데이타 테이블을 두개를 같이 사용하면 된다.

즉 어제까지의 데이타는 일별 배치로 생성된 테이블을 사용하고, 오늘 데이타 부분은 사용자별로 기록된 로그 테이블을 사용하여 두 테이블을 조인 하면, 오늘의 지금 순간의 통계값까지 볼 수 있다.

 


<그림 4. 테이블 조인을 이용한 실시간 데이타 통계 추출 >


실시간 집계 테이블의 활용

하루에 쌓이는 데이타량이 얼마 되지 않는다면 문제가 되지 않겠지만, 이 시나리오에서 하루에 쌓이는 데이타는 일 최대 1억건이 된다. 즉, 오늘 쌓이는 데이타 테이블을 조인 하면 1억개의 행에 대한 연산이 발생하여 적절한 성능을 기대하기 어렵다. 

그렇다면, 배치는 매일 돌리되, 오늘 데이타에 대한 통계 값을 실시간으로 업데이트 하는 방법을 생각해볼 수 있다. 

아래 그림과 같이 로그서버에서 클라이언트에서 받은 로그를 원본 데이타 테이블에 계속 저장을 하고, 오늘 통계에 대한 실시간 집계 테이블에, 글쓰기, 글 읽기 등 개별 이벤트의 값을 계산해서 더해 주면 된다.

 


<그림 5. 실시간 집계 테이블>

이렇게 하면, 실시간 집계 테이블과, 배치 테이블을 조인하여 빠르게 실시간 통계를 볼 수 있다.

즉 일별 실시간 통계는 다음 그림과 같이 당일전의 배치뷰와 당일의 실시간뷰를 합쳐서 통계를 낸 형태가 된다.

 


<그림 6. 실시간 통계를 뽑기 위한 테이블들의 관계>


람다 아키텍쳐를 활용

이 개념을 람다 아키텍쳐로 해석해보자. 데이타 흐름을 도식화 해보면 다음과 같다.

 


<그림 7. 람다 아키텍쳐의 개념>


먼저 배치 처리를 위해서, 로그 서버는 모든 로그 데이타를 저장소에 저장하고, 배치 처리 계층에서 일일 또는 일정한 시간을 주기로 배치 처리로 계산을 해서 배치 뷰(배치 테이블)을 만든다.

그리고 다른 흐름으로 실시간 처리쪽에 데이타를 전송해서 실시간 집계를 해서 실시간 집계 테이블을 만든다.

마지막으로, 이 두개의 뷰를 합쳐서 통계를 만든다.

배치뷰는 배치로 돌때만 쓰기가 가능하고 평상시에는 데이타를 읽기만 가능하게 한다. 이를 통해서 데이타가 변경되거나 오염(Corrupt)되는 것을 막을 수 있다.

실시간 뷰는 실시간으로 데이타를 쓰고, 읽을 수 있는 시스템을 사용한다.

위의 문제 정의 예제에서는 컬럼의 개수를 카운트 정도하는 간단한 예를 들었지만, 실제 빅데이타 분석에서는 단순 통계뿐 아니라 복잡한 수식이나 다단계를 거쳐야 하는 데이타 파일의 가공이 필요하기 때문에 복잡한 프로그래밍이 가능한 처리(배치/실시간)이 필요한데, 이 처리 계층에는 프로그램을 이용하려 알고리즘을 삽입할 수 있어야 한다.

이러한 특성에 맞춰서 각 데이타 처리 흐름에 솔루션을 맵핑 해보면 다음과 같다.



<그림 8. 람다 아키텍쳐에 대한 솔루션 맵핑> 


저장소는 대량의 데이타를 저비용으로, 안정성 있게 (유실이 없게) 저장할 수 있는 것이 필요하다. 그리고 이런 대량의 데이타를 배치로 처리할 때 되도록이면 빠른 시간내에 복잡한 알고리즘을 적용해서 계산할 수 있는 계층이 필요한데, 이러한 솔루션으로 제시되는 솔루션이 하둡의 HDFS(Hadoop File System)과 하둡의 MR (Map & Reduce)이다.

이렇게 계산된 배치 데이타를 저장할 장소가 필요한데, 하둡에서는 이런 데이타를 저장하고 고속으로 액세스할 수 있도록 HBase라는 NoSQL을 제공한다.

실시간 처리는 복잡한 알고지즘을 빠르게 데이타를 처리할 수 있는 솔루션이 필요한데, 대표적으로 Apache Storm등이 있으며, 빠른 읽기와 쓰기를 지원해야 하기 때문에, Redis와 같은 In-memory 기반의 NoSQL이 적절하게 추천되고 있다.

일반적으로 람다 아키텍쳐를 소개할때, 제안되는 솔루션의 형태이기는 하나, 람다 아키텍쳐는 특정 솔루션을 제안하는 아키텍쳐이기 보다는 데이타의 처리 기법을 소개하는 솔루션에 종속성이 없는 레퍼런스 아키텍쳐이다.

그래서 다른 솔루션 조합을 고려해볼 수 있는데, Dr.dobbs (http://www.drdobbs.com/database/applying-the-big-data-lambda-architectur/240162604)

에 소개된 솔루션 조합과 필자가 추천하는 조합을 추가해서 보면 다음과 같다.


<그림 9. 람다 아키텍쳐의 솔루션 조합>


여기서,필자가 Dr.Dobbs의 추천 솔루션 이외에, 배치 뷰와 실시간 뷰 쪽에, RDBMS를 추가하였는데, 배치뷰에 추가한 Amazon RedShift의 경우 아마존 클라우드 서비스에서 제공되는 Postgres 기반이 서비스로, 최대 16PB(페타바이트)까지의 용량을 지원한다. 이미 빅데이타라고 부를만큼의 충분한 데이타 사이즈를 지원할 뿐더라, RDBMS 기반의 SQL을 이용하여 유연한 데이타 조회가 가능하며, 리포트를 출력하기 위한 기존의 BI 툴과도 호환이 잘되서 많은 개발에 관련된 부분을 덜 수 있다. 실제로 통계 리포팅에서 가장 많은 시간이 소요되는 작업이, 비즈니스쪽 요구에 맞는 리포트를 만드는 작업이다.어떤 테이블과 그래프를 이용해서 데이터에 대한 의미를 보여줄 지는 단순한 리포팅 작업이라고 치부하기에는 매우 중요한 작업이며, 다양한 비즈니스 요건에 맞는 뷰를 보여 주기 위해서는 BI툴과의 연동은 많은 장점을 제공한다.

위에서 설명한 람다 아키텍쳐를 계층(Layer)로 나눠서 소개 하면 다음 그림과 같다.

실시간 데이터를 처리하는 부분을 스피드 레이어라고 부르며, 배치 처리는 배치 저장소와 배치 처리 부분을 배치 레이어라고 명명하고, 배치에 의해서 처리된 요약 데이터를 제공하는 부분을 서빙 레이어(Serving Layer)라고 한다.

 


<그림 10. 계층별로 추상화된 람다 아키텍쳐>

배치 레이어의 의미

배치 레이어의 저장소에는 가공전의 원본 데이터를 모두 저장한다. 데이터가 처리된 후에도 저장소에 데이터를 삭제 하지 않는다.

이렇게 원본 데이터를 저장함으로써, 배치 뷰의 데이터가 잘못 계산되었거나, 유실 되었을때, 복구가 가능하고, 현재 데이터 분석에서 없었던 새로운 뷰(통계)를 제공하고자 할 때 기존의 원본 데이터를 가지고 있음으로써, 기존 데이터에 대해서도 새로운 뷰의 통계 분석이 가능하다.


람다 아키텍쳐의 재구성

RDBMS를 활용한 유연성 증대 방안

이러한 람다 아키텍쳐는 대용량 데이터 처리와 실시간 정보 제공을 위한 장점을 가지고 있음에도 불구하고 대부분 하둡이나 NOSQL등의 솔루션을 조합해서 구현하는 경우가 대부분이기 때문에, 유연성 측면에서 문제점을 가지고 있다.

예를 들어 배치 뷰를 HBase를 사용하고, 실시간 뷰를 Redis를 사용할 경우, 상호 솔루션간 데이터 조인이 불가능할 뿐더러, 인덱스나 조인,그룹핑, 소팅 등이 어렵다. 이러한 기능이 필요하다면 각각 배치 처리와 실시간 처리 단계에 추가적으로 로직을 추가해서 새로운 뷰를 만들어야 한다.

쉽게 설명하면, 일반적인 NoSQL은 키-밸류 스토어의 개념을 가지고 있다.

그래서, 위의 그림3과 같은 테이블이 생성되었다 하더라도, 특정 컬럼 별로 데이터를 소팅해서 보여줄수 가 없다. 만약 소팅된 데이터를 표현하고자 한다면, 소팅이 된 테이블 뷰를 별도로 생성해야 한다.

참고 : NoSQL 데이터 모델링 패턴

http://bcho.tistory.com/665 , http://bcho.tistory.com/666

그래서 이런 문제점을 보강하기 위해서는 위에서도 잠깐 언급하였듯이 실시간 뷰와 배치 뷰 부분을 RDBMS를 사용하는 것을 고려해볼 수 있다. 쿼리에 특화된 OLAP 데이터 베이스를 활용하는 방법도 있고, 또는 HP Vertica 등을 활용할 수 있다. (HP Vertica는 SQL을 지원하지만, 전통적인RDBMS가 데이터를 행 단위로 처리하는데 반하여, Vertica는 데이터를 열 단위로 처리해서 통계나 쿼리에 성능이 매우 뛰어나다. 유료이지만 1테라까지는 무료로 사용할 수 있으니 뷰 테이블 용도 정도로 사용하는데는 크게 문제가 없다.)


데이터 분석 도구를 이용한 새로운 분석 모델 개발

분석 통계 데이터를 제공하다 보면, 저장소에 저장된 원본 데이터를 재 분석함으로써 추가적인 의미를 찾아낼 수 있는데, 이 영역은 데이터 과학자의 영역으로, 저장소에 있는 데이터를 통해서 새로운 데이터 모델을 추출해 내는 방식이다.

예를 들어, 글읽기 이벤트와 글쓰기 이벤트간의 상관 관계를 파악해내거나, 요일별 이벤트 변화량등을 분석해낼 수 있는데,

  1. 이 저장소에 R이나 MetLab과 같은 데이터 분석 도구를 이용하여, 샘플(표본) 데이터를 추출해서 데이터의 상관 관계를 파악해보고,

  2. 이러한 분석을 통해서 새로운 통계 모델을 설계하고 검증해볼 수 있다.

  3. 만약 이러한 모델이 적절하다면 알고리즘을 구현하고 이를 빅데이타 엔지니어에게 넘겨 준다.

  4. 빅데이타 엔지니어는 데이터 과학자에게서 받은 알고리즘을 람다 아키텍쳐의 각 레이어에 배치된 솔루션에 알맞은 형태로 구현한다.


 


<그림 11. 새로운 데이터 모델의 개발>

이러한 과정의 반복을 통해서, 분석 시스템은 지속적으로 발전되어가면서 데이터에 대한 더 많은 인사이트를 제공할 수 있게 된다.


결론

간단하게나마 람다 아키텍쳐에 대해서 알아보았다.

람다 아키텍쳐는 꼭 빅데이타에 적용하거나, 또는 하둡을 이용해야 하는 아키텍쳐가 아니다. RDBMS나 CSV 파일 등, 어떤 데이터 형태라도 기본은 배치를 이용한 집계 테이블과 실시간 뷰 테이블을 조인한다는 개념이기 때문에, 솔루션에 억메이지 말고, 적절한 시나리오를 찾아서 적용할 수 있도록 하면 좋겠다.


참고 : 

http://www.drdobbs.com/database/applying-the-big-data-lambda-architectur/240162604

http://www.infoq.com/articles/lambda-architecture-scalable-big-data-solutions