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


Archive»


 
 




스팍에 대한 간단한 개념과 장점 소개


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



스팍의 개념과 주요 기능


요즘 주변에서 아파치 스팍을 공부하는 사람도 많고, 스팍을 기반으로한 Zeppelin을 이용하여 데이타 분석을 하는 경우도 많아서, 오늘부터 다시 Spark을 들여다 보기 시작했습니다.


스팍은 예전에도 몇번 관심을 가진적이 있는데, Storm과 같은 데이타 스트리밍 프레임웍에서 Storm과 같이 언급 되기도 하고, 머신 러닝 프레임웍을 볼때도  스팍 ML  라이브러리 기능이 언급 되기도 하고, 예전 모 회사의 데이타 분석 아키텍쳐를 보니, 카산드라에 저장된 데이타를 스팍/Shark라는 프레임웍으로 분석을 하더군요. 또 누구는 메모리 기반의 하둡이라고도 합니다.


스팍의 정의를 내려보면 한마디로

범용적 목적의 분산 고성능 클러스터링 플랫폼 (General purpose high performance distributed platform)

입니다 말이 정말 길고 모호한데, 달리 설명할만한 단어가 없습니다.


스팍은 범용 분산 플랫폼입니다. 하둡과 같이 Map & Reduce 만 돌리는 것도 아니고, Storm 과 같이 스트리밍 처리만 하는게 아니라, 그냥 분산된 여러대의 노드에서 연산을 할 수 있게 해주는 범용 분산 클러스터링 플랫폼으로, 이 위에, Map & Reduce나, 스트리밍 처리등의 모듈을 추가 올려서 그 기능을 수행하게 하는 기능을 제공합니다.


특히나, 메모리 하둡이라고도 불리는데, 이 스팍은 기존의 하둡이 MR(aka. Map & Reduce) 작업을 디스크 기반으로 수행하기 때문에 느려지는 성능을 메모리 기반으로 옮겨서 고속화 하고자 하는데서 출발하였습니다.


그 플랫폼 위에 SQL 기반으로 쿼리를 할 수 있는 기능이나, 스트리밍 기능등등을 확장하여 현재의 스팍과 같은 모습을 가지게 되었습니다.

스팍의 주요 기능은 앞에서 언급하였듯이 

  • Map & Reduce (cf. Hadoop)
  • Streaming 데이타 핸들링 (cf. Apache Storm)
  • SQL 기반의 데이타 쿼리 (cf. Hadoop의 Hive)
  • 머신 러닝 라이브러리 (cf. Apache Mahout)
등을 제공합니다.

스팍의 장점

빠른 속도라는 장점은 필수 이고, 왜 다들 스팍! 스팍 하는가 봤더니, 플랫폼으로써의 특성이 장점으로 작용합니다.
예를 들어 기존의 빅데이타 분석 플랫폼의 구현 구조를 보면, 배치 분석시 ETL 등을 써서 데이타를 로딩한 후에, Hadoop의 MR을 이용하여 데이타를 정재한후, 이 데이타를 OLAP 등의 데이타 베이스에 넣은 후에, 리포팅 툴로 그래프로 표현했습니다. 여기에 만약 실시간 분석을 요한다면 Storm을 연결해서 실시간 데이타 분석 내용을 더하는 일을 했습니다. 
사용되는 프레임웍만해도 몇가지가 되고, 이를 공부하는 시간과 시스템을 배포 운영하는데 여러가지 노력이 들어갔습니다만, 스팍은 하나로 이 모든것이 가능하다는 겁니다.

즉 한번 배워놓으면, 하나의 플랫폼내에서 여러가지가 가능한데다가 속도까지 빠릅니다.
그리고 한 플랫폼안에 배치,스트리밍, 머신 러닝등 다양한 처리를 제공하기 때문에, 하나의 데이타로 여러가지 형태로 데이타를 처리할 수 있는 기능을 가집니다.

연동성 부분에서도 장점을 볼 수 가 있는데, 스팍은 스칼라로 구현되었지만, 파이썬,자바,스칼라등 다양한 언어를 지원하기 위한 SDK를 가지고 있고, 데이타 저장단으로는 하둡, 아마존  S3, 카산드라등 다양한 데이트 스토리지를 지원합니다.
이런 연동성으로 다양한 언어로 다양한 데이타 저장소를 연동하여 데이타를 분석 및 처리할 수 있는 장점을 가지고 있습니다.


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

조대협 (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



Spring for Apache Hadoop Project #2

(Hive Integration)

Hive Apache 오픈 소스 프로젝트의 하나로, Hadoop 관련 프로젝트이다.

HDFS에 저장된 데이타를 마치 RDMS SQL처럼 쿼리하기 위한 솔루션으로, 복잡한 데이타 쿼리 연산에 있어서, Hadoop과 함께 사용하면 매우 유용하게 이용할 수 있다.

SHDP에서도 이 Hive를 지원한다. 크게 Hive의 기동과, Hive Script의 실행 그리고, Hive에서 제공하는 API를 수행할 수 있도록 지원하며, Hadoop 지원과 마찬가지로, Tasklet을 제공하여 Spring Batch와의 통합을 지원한다.

Hive Server의 기동

hive-server 엘리먼트로 정의하며, configuration file을 읽어서 기동할 수 있으며, 추가되는 configuration hive-server엘리먼트 안에 value로써 지정이 가능하다.

<hdp:hive-server host="some-other-host" port="10001" properties-location="classpath:hive-dev.properties" configuration-ref="hadoopConfiguration">
  someproperty=somevalue
  hive.exec.scratchdir=/tmp/mydir
</hdp:hive-server>

Thrift Client 를 이용한 Hive Script의 수행

Hive를 사용하기 위해서는 Hive Server에 접속하는 클라이언트를 생성해야 하는데, 첫번째 방법이 Thrift Client를 이용하는 방법이 있다. Thrift Client의 경우에는 Thread Safe 하지 않기 때문에, client factory를 리턴한다.

아래 설정을 보면 hive-client-factory hive서버의 ip,port를 지정하여 client를 생성하였다.

그리고, script 실행을 위해서 runner 를 지정한후에, 앞서 생성한 clientfactory reference하였다. 그리고 hive-runner에서 script location을 지정하여,password-analysis.hal 파일에 정의된 script가 실행되도록 정의하였다.

<hdp:hive-client-factory host="some-other-host" port="10001" />
<hdp:hive-runner id=”hiveRunner”hive-client-ref=”hiveClientFactory” run-at-startup=”false” pre-action=”hdfsScript”>
  <script location=”password-analysis.hal”/>
</hdp:/hiverunner>

실제 위의 Configuration을 가지고 수행하는 자바 코드를 보면 다음과 같다.

public class HiveAppWithApacheLogs {
 
         private static final Log log = LogFactory.getLog(HiveAppWithApacheLogs.class);
 
         public static void main(String[] args) throws Exception {
                 AbstractApplicationContext context = new ClassPathXmlApplicationContext(
                                   "/META-INF/spring/hive-apache-log-context.xml"
, HiveAppWithApacheLogs.class);
                 log.info("Hive Application Running");
                 context.registerShutdownHook();    
 
 
                 HiveRunner runner = context.getBean(HiveRunner.class);                
                 runner.call();
 
         }
}

Hive client를 만들때는 각 client가 생성될때마다 자동으로 initialize script를 실행할 수 있다.

<hive-client-factory host="some-host" port="some-port" xmlns="http://www.springframework.org/schema/hadoop">
   <hdp:script>
     DROP TABLE IF EXITS testHiveBatchTable; 
     CREATE TABLE testHiveBatchTable (key int, value string);
   </hdp:script>
   <hdp:script location="classpath:org/company/hive/script.q">
       <arguments>ignore-case=true</arguments>
   </hdp:script>
</hive-client-factory>

위의 설정은 client가 생성될때 마다 DROP TABLE xx 스크립트와, script.q에 지정된 스크립트 두개를 자동으로 수행하도록 한다.

마찬가지로, runner에서도 순차적으로 여러개의 쿼리가 수행되도록 설정할 수 있다.

JDBC 를 이용한 스크립트 수행

Hive Thrift 이외에도, RDBMS에 사용하는 JDBC 드라이버를 사용할 수 있다. Spring에서도 이 JDBC를 통한 Hive 통합을 지원한다.

사용 방법은 일반적인 JDBC Template을 사용하는 방법과 동일하다.

먼저 hive-driver Hive JDBC 드라이버를 지정한후, 이를 이용하여, hive data source를 정의한후, Jdbc template을 이 data source와 연결하여 사용한다. (아래 예제 참고)

<beans xmlns="http://www.springframework.org/schema/beans"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xmlns:c="http://www.springframework.org/schema/c"
         xmlns:context="http://www.springframework.org/schema/context"
         xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
         http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">
         
    <!-- basic Hive driver bean -->
    <bean id="hive-driver" class="org.apache.hadoop.hive.jdbc.HiveDriver"/>
 
    <!-- wrapping a basic datasource around the driver -->
    <!-- notice the 'c:' namespace (available in Spring 3.1+) for inlining constructor arguments, 
         in this case the url (default is 'jdbc:hive://localhost:10000/default') -->
    <bean id="hive-ds" class="org.springframework.jdbc.datasource.SimpleDriverDataSource"
       c:driver-ref="hive-driver" c:url="${hive.url}"/>
 
    <!-- standard JdbcTemplate declaration -->
    <bean id=" jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate" c:data-source-ref="hive-ds"/>
         
    <context:property-placeholder location="hive.properties"/>
</beans>

위의 Configuration을 수행하는 자바 코드는 다음과 같다.

Hive template을 이용한 Hive API 실행

JDBC Template과 유사하게 Hive 실행도 Template을 제공한다.

다음과 같이 context 파일에서, hive-template을 만든후에, 해당 template SomeClass라는 클래스에 someBean이란 이름으로 생성해서 weaving하였다.

<hdp:hive-client-factory ... />
<!-- Hive template wires automatically to 'hiveClientFactory'-->
<hdp:hive-template />
         
<!-- wire hive template into a bean -->
<bean id="someBean" class="org.SomeClass" p:hive-template-ref="hiveTemplate"/>

SomeClass에서는 template을 받아서, hivetemplate.execute() 메서드를 수행한다.

public class SomeClass {
 
private HiveTemplate template;
 
public void setHiveTemplate(HiveTemplate template) { this.template = template; }
 
public List<String> getDbs() {
    return hiveTemplate.execute(new HiveClientCallback<List<String>>() {
       @Override
       public List<String> doInHive(HiveClient hiveClient) throws Exception {
          return hiveClient.get_all_databases();
       }
    }));
}}

 

Spring Batch Integration

마지막으로 Hadoop integration등과 마찬가지로 Spring Batch 통합을 위하여, tasklet을 제공한다.

<hdp:hive-tasklet id="hive-script">
   <hdp:script>
     DROP TABLE IF EXITS testHiveBatchTable; 
     CREATE TABLE testHiveBatchTable (key int, value string);
   </hdp:script>
   <hdp:script location="classpath:org/company/hive/script.q" />
</hdp:hive-tasklet>

 

 

 

 

Spring for Apache Hadoop Project


얼마전에, Spring에서 Hadoop과 통합을 지원하는 프로젝트를 발표하였습니다. Hadoop 자체뿐만 아니라, Hadoop echo system Hive, Pig, Cascade등을 함께 지원하며, 기존 Spring Spring Batch(배치 작업 수행 및 워크 플로우 관리)와의 통합을 지원합니다.

이번 글에서는 Spring Data Apache Hadoop (이하 SHDP-Spring for Apache Hadoop Project)에 대해 설명한다 ( Spring Hadoop에 대한 기본적인 이해가 선행되어야 한다. )

전체적으로의 느낌은 Spring을 컨테이너의 개념으로 보고, Hadoop을 그 컨테이너 안에서 실행 시키는 것과 같은 느낌을 준다. Hadoop 자체와 아주 Tight하게 통합 된것은 아니면서, 외부 명령어나 Library invoke 하듯이 Hadoop을 실행하며, 단순히 Map & Reduce Job 뿐만 아니라, Job을 수행하기 위해서 통상적으로 Hadoop에서 수행하는 Shell Script 처리까지 프레임웍에서 지원하도록 했다. 또한 각 Job이나 이런 Script들을 순차적으로 batch처럼 수행하기 위해서 Tasklet을 제공함으로써 Spring Batch와의 통합을 지원한다. Hadoop job, tool,script들을 모두 spring configuration내의 element로 다 맵핑을 한후에, Spring batch와 통합을 통하여, hadoop을 수행하는데 모든 필요한 순차적인 작업을 shell command나 여타의 작업이 필요 없이 spring만 가지고도 수행할 수 있도록 지원한다.


현재 지원 버전 참고

Spring for Apache Hadoop requires JDK level 6.0 (just like Hadoop) and above, Spring Framework 3.0 (3.2 recommended) and above and Apache Hadoop0.20.2 (1.0.4 recommended) and above. SHDP supports and is tested daily against various Hadoop distributions, such as Cloudera CDH3 (CD3u5) and CDH4 (CDH4.1u3 MRv1) distributions and Greenplum HD (1.2). Any distro compatible with Apache Hadoop 1.0.x should be supported

 Job 기반의 기본적인 Hadoop Map & Reduce 실행

Hadoop Map & Reduce 에 대한 통합은 크게 3가지 관점으로 이루어 진다. Job,Tool 그리고 Hadoop jar 파일 자체

Job Map & Reduce의 단위로, 당연히 지원되어야 하고, Tool Hadoop이 지원하는 각종 유틸리티 들이다. 이 역시 Spring element로 지정이 되어 있다. 마지막으로 hadoop.jar 자체를 수행할 수 있는 기능을 지원한다. 3가지 기능을 모두 지원함으로써 hadoop으로 할 수 있는 거의 모든 것을 spring으로 mapping을 할 수 있다. 또한 이 각각에 대해서 Spring Batch 통합을 위하여 Tasklet을 제공한다.

Java 기반의 job 정의

<hdp:job id="mr-job"

  input-path="/input/" output-path="/ouput/"

  mapper="org.apache.hadoop.examples.WordCount.TokenizerMapper"

  reducer="org.apache.hadoop.examples.WordCount.IntSumReducer"/>

 

위의 예제는 default configuration을 사용하는 것으로 되어 있는데, 별도로 hadoop configuration을 명시적으로 지정할 수 도 있고, 아울러, Job 마다 custom property 를 이용하여, configuration을 명시적으로 지정할 수 있음. 아래 예제는 특정 job에 대해서 configuration property 파일로 지정한 형태. 또한 아래에서 볼 것중 하나는 jar 파일을 명시적으로 지정할 수 있다. spring load되는 classloader가 아니라, 별도의 class loader를 이용하여 job에 이용되는 클래스들을 로딩함으로써, 같은 클래스가 있을때 중복이나 충돌이 발생함을 방지해준다.

<hdp:job id="mr-job" 
  input-path="/input/" output-path="/ouput/"
  mapper="mapper class" reducer="reducer class"
  jar-by-class="class used for jar detection"
  properties-location="classpath:special-job.properties">
    electric=sea
</hdp:job>

 

Streaming job 정의

Streaming Job (일반 Command 명령어 방식)은 다음과 같이 정의한다.

<hdp:streaming id="streaming-env" 
  input-path="/input/" output-path="/ouput/"
  mapper="${path.cat}" reducer="${path.wc}">
  <hdp:cmd-env>
     EXAMPLE_DIR=/home/example/dictionaries/
     ...
  </hdp:cmd-env>
</hdp:streaming>

mapperreducer에 직접 command를 정의한다.

그리고 만약에, command에 넘겨야 하는 parameter들이 있다면 <hdp:cmd-env> 엘리먼트에 지정해서 넘긴다.

 Running a Hadoop Job

앞서와 같이 Hadoop Job의 정의가 끝나면, Spring에서는 “job-runner” 엘리먼트를 이용해서 특정 Job을 구동 시킬 수 있다.

<hdp:job-runner id="myjob-runner" pre-action="cleanup-script" post-action="export-results" job="myjob" run-at-startup="true"/>
 
<hdp:job id="myjob"  input-path="/input/" output-path="/output/"
         mapper="org.apache.hadoop.examples.WordCount.TokenizerMapper"
         reducer="org.apache.hadoop.examples.WordCount.IntSumReducer" />

위의 예제는 구동과 동시에 TokenizerMappe라는 java mapper InitSumReducer라는 java reducer를 가지고 있는 “myjob”이라는 job을 구동 시키는 설정이다. “myjob”을 구동하기 전에 “cleanup-script” 를 수행하고, job 실행이 끝나면 “export-results”라는 스크립트를 자동으로 수행한다.

또한 <hdp:job-runner> 엘리먼트에 job=”” 속성에, 순차적으로 1개 이상의 job id를 적으면, 여러개의 job을 순차적으로 수행하게 된다.

Job 실행의 Spring Batch와 통합

SHDPHadoop job 실행을 Spring Batch와 통합하기 위해서 hadoop job을 실행 시키는 tasklet을 제공한다.

<hdp:job-tasklet id="hadoop-tasklet" job-ref="mr-job" wait-for-completion="true" />

위와 같이 job tasklet으로 지정하여 spring batch work flow에 통합할 수 있다.

Hadoop Tool 실행

Hadoop에는 내부적으로 Map & reduce job을 수행 시키는 것 이외에도, 여러가지 툴(유틸리티)들이 포함되어 있는데, SHDP에서는 이러한 유틸리티를 수행할 수 있도록, “tool-runner” element를 지원한다.

<hdp:tool-runner id="someTool" tool-class="org.foo.SomeTool" run-at-startup="true">
   <hdp:arg value="data/in.txt"/>
   <hdp:arg value="data/out.txt"/>
   
   property=value
</hdp:tool-runner>

위와 같이 tool-runner element에서 수행하고자 하는 클래스를 tool-class로 지정하고, 필요한 parameter hdp:arg 엘리먼트로 정의하면 된다.

또한 하나의 tool만 실행하는 것이 아니라, 순차적으로 여러개의 tool tool-runner를 이용해서 수행할 수 있다.

<hdp:tool-runner id="job1" tool-class="job1.Tool" jar="job1.jar" files="fullpath:props.properties" properties-location="config.properties"/>
<hdp:tool-runner id="job2" jar="job2.jar">
   <hdp:arg value="arg1"/>
   <hdp:arg value="arg2"/>
</hdp:tool-runner>
<hdp:tool-runner id="job3" jar="job3.jar"/>
...

위와 같이 job1,job2,job3의 툴을 순차적으로 수행함으로써, hadoop 수행시 shell script에서 여러 도구를 수행하는 절차를 모두 Spring으로 통합할 수 있다.

Hadoop ToolSpring Batch 통합

Job과 마찬가지로 Tool 실행 역시 tasklet을 제공하여, Spring Batch과 통합 될 수 있도록 지원한다.

<hdp:tool-tasklet id="tool-tasklet" tool-ref="some-tool" />

 

Hadoop jar의 실행

마지막으로, hadoop.jar 자체를 수행할 수 있도록 지원한다.

<hdp:jar-runner id="wordcount" jar="hadoop-examples.jar" run-at-startup="true">
    <hdp:arg value="wordcount"/>
    <hdp:arg value="/wordcount/input"/>
    <hdp:arg value="/wordcount/output"/>
</hdp:jar-runner>

위의 예제는 아래 shell command를 그대로 수행하는 기능을 한다.

bin/hadoop jar hadoop-examples.jar wordcount /wordcount/input /wordcount/output

 

Hadoop jar 실행과 Spring Batch의 통합

Job이나 Hadoop tool과 마찬가지로 Spring 통합을 위해서 tasklet을 제공한다.

<hdp:jar-tasklet id="jar-tasklet" jar="some-jar.jar" />

 

다음 글에서는 Hive, Pig, Cascading, HDFS에 대한 SHDP 지원에 대해서 소개하고자 한다.

참고 자료 : http://static.springsource.org/spring-hadoop/docs/current/reference/html/hadoop.html

 

데이타 분석 계층 아키텍쳐

아키텍쳐 /BI | 2012.10.14 01:52 | Posted by 조대협

Data Analysis Layer Architecture


데이타 분석 계층에 대한 아키텍쳐를 공부하면서 간단하게 정리해서 올리기는 했습니다만, 이쪽 분야에서는 전문성이 상대적으로 떨어져서 아래 글에 잘못된 설명이 다소 있을겁니다. 특히 OLAP이나 BI 전문가 분들이 보시면 아주 초보적인 수준일텐데.. 혹시 잘못된 부분이 있다면 피드백 주시면 매우 감사하겠습니다.

일반적인 시스템들은 application server들을 중심으로 하여 클라이언트가 요청한 request에 대한 처리를 위한 구조이고, 지금 부터 설명하는 Analysis Layer는 트렌젝션 처리에 의한 결과와 로그를 분석하는 Layer이다. Anlysis Layer 또는 BSS(Business Support System) 그리고 은행에서는 정보계라는 용어를 사용한다.



전통적인 Analytics 계층은 위와 같은 모습을 갖는다.

Transaction Processing 계층에서 생성된 각종 로그와 비지니스 데이타를 Gathering 컴포넌트에서 수집한 후에, Transform 컴포넌트에서 이를 분석을 위한 저장소에 저장하기 위해서 포맷을 변경한다. 예를 들어 웹서버의 텍스트 로그를 수집해서 RDBMS에 저장한다.

분석을 위한 데이타는 이 Store 컴포넌트에 정제된 형태로 저장된 후에, 사용자가 보고 싶은 리포트 형태로 VIEW 컴포넌트에 의해서 리포트나 dash board 형태로 출력 한다.

이러한 개념적인 분석을 실제 소프트웨어 컴포넌트로 어떻게 구현할까? 여러가지 방법이 있겠지만 트렌드에 따라서 크게 아래와 같이 3가지 정도로 분리해볼 수 있다.


1. 전통적인 OLAP 방식의 분석 시스템

전통적인 기업형 업무에서는 RDBMS 기반의 분석 시스템을 사용해왔다. OLAP (OnLine Analytics Processing) 이라는 형태의 분석에 최적화된 데이타 베이스를 사용하여 데이타를 분석하여 리포트를 생성한다. 구조는 다음과 같다



  (1) ETL

ETL(Extract Transform Loading) 여러 데이타 소스로 부터 수집해서 변환 및 저장하는 역할을 한다.

E Extract의 약자로, 다양한 데이타 소스로 부터 데이타를 추출한다. 텍스트 기반의 로그 파일에서 데이타를 추출하거나, 다른 RDBMS로부터 데이타를 추출하는 기능등을 수행한다.

T Transform은 추출된 데이타를 수신 변환하는 역할을 수행하는데, 필요한 데이타만 선별 추출하거나, 필드를 합치거나 특정 룰에 따라서 데이타를 변환한다.

L Loading의 약자로, 이렇게 변환된 데이타는 수신쪽 데이타 베이스에 저장된다.


  (2) Data ware house & data mart

이렇게 데이타를 저장하는 장소를 OLAP (OnLine Analytics Processing) 형태의 데이타 베이스에 저장된다. 기업내의 모든 OLTP 시스템에서 수집된 모든 데이타는 먼저 data ware house 라는 중앙 집중화된 데이타 베이스에 저장된다. 이렇게 저장된 데이타는 리포트를 보고자하는 각 부서에 따라 다시 정제 되서 저장된다. 이렇게 각 부서별로 데이타가 저장되는 장소를 data mart라고 한다.

Data mart를 사용하는 이유가 몇가지가 있다.

부서의 업무 성격에 따라서, 테이블 구조나 데이타 베이스 구조 변경이 필요하고 이러한 구조 변경은 타 부서 업무에 영향을 줄 수 있다. 그래서 데이타베이스에 대한 변경을 자유롭게 하기 위해서 부서간에 공유되는 data ware house가 별도의 분리된 data mart를 사용한다.

또한 data warehouse에서 직접 데이타를 분석하게 되면, 부서간 리포팅 성격에 따라서 시스템에 부하를 주기 때문에 부서간의 분석 업무의 성능에 영향을 받을 수 있다.

서마다 분석 데이타에 대해서 유지해야 하는 주기가 다르다. 물론 data ware house에 데이타 저장 기간을 가장 긴 기간으로 하향 평준화하여 맞추는 방법도 있지만, 문제는 data ware house machine data mart보다 비싸다각 부서별로 데이타 저장 기간과 정책을 자유롭게 정할 수 있다.

마지막으로, 부서의 데이타 분석 스타일에 따라서 원하는 데이타 리포팅 도구를 사용할 수 있다.

물론 기업의 크기가 크지 않고, 데이타 분석을 필요로 하는 부서의 수가 그리 많지 않다면 별도의 data mart를 사용하지 않고 data ware house 하나로 데이타 저장소를 대신할 수 있다.

Data mart에 저장된 데이타는 Reporting 도구를 이용하여 업무의 특성에 맞게 적절한 분석을 통해서 가시화된 리포트로 제공된다. Reporting RBMS Join Query 등의 기능을 이용하여 구현되며, 저장된 데이타에 대해서 다차원 분석 수행한다. 다 차원 분석이란 우리가 흔히 보는 그래프 형태인데, 흔히 X,Y 값 기반의 2차원 분석이나 X,Y,Z 값 기반의 3차원등 다차원 분석을 사용한다.


2. Map & Reduce 기반의 분석 시스템

근래에 Google, Facebook 과 같은 대규모 B2C 서비스를 중심으로, 대용량 데이타의 분석에 대한 요구 사항이 생기게 되었고, 기존의 전통적인 OLAP RDBMS를 이용한 데이타 분석이 용량상의 한계로 인하여 다른 접근 방법을 사용하게 되었다. 대표적인 방법으로 Map & Reduce라는 방법을 사용한 데이타 분석 방법이다.

Map & Reduce는 프로그래밍 아키텍쳐의 개념으로, Map & Reduce는 하나의 큰 데이타를 여러개의 조각으로 나눠서 처리 하는 단계(Map), 처리 결과를 모아서 하나로 합쳐서 결과를 내는 단계 (Reduce)로 나뉘어 진다.

 

 


예를 들어 한국에 사는 모든 사람의 수입의 합을 더한다고 하자우리한테는 한국에 있는 모든 사람의 수입이 적혀 있는 텍스트 파일이 하나 있다이 파일을 이용해서 각각 사람의 수입을 순차적으로 더해서할 수 도 있지만전체 파일을 10조각, 100조각으로 나눠서 각 조각의 수입합을 계산한후그 결과를 하나로 더하면조각을 나눈만큼의 계산을 병렬로 처리할 수 있기 때문에 조금 더 빠른 결과를 가질 수 있다이렇게 하나의 파일을 여러 조각으로 나눠서 계산 하는 것을 Map, 그리고 합치는 과정을 Reduce라고 한다.

이러한 Map & Reduce 아키텍쳐의 대표적인 구현체로는 Apache 오픈소스 커뮤니티의 Hadoop이 있다.  Map & Reduce는 저가의 일반적인 하드웨어로 대용량 분석 처리를 할 수 있다는 장점을 가지고 있으나, 데이타의 수집,변환 및 분석 리포팅의 전 과정을 직접 구현해야 하는 단점을 가지고 있다. 그래서 Map & Reduce를 사용해서 데이타를 분석하는 조직은 일반적인 개발자나 시스템 엔지니어 보다는 데이타 분석에 대한 알고리즘을 만들어낼 수 있는 data scientist와 같은 특화된 데이타 분석 역할을 필요로 한다.

3. Map & Reduce + OLAP 형태의 데이타 분석 시스템

B2C 서비스를 중심으로 Map & Reduce가 데이타 분석에 대한 주류로 자리 잡게 되었고, 점점 증가하는 고객의 데이타에 대한 분석 대응 능력이 고객에게 요구 되기 시작했다. 흔히 근래에 이야기 하는 빅데이타라는 이름이 이러한 데이타 분석의 이름인데, 일반적인 기업 입장에서는 다양한 형태의 데이타 분석과 리포팅 필요하고, 주로 개발과 시스템 엔지니어를 보유한 일반적인 기업 입장에서는 일반적인 기업에서는 data scientist와 같은 역할의 사람을 고용하기가 어렵다그래서 OLAP Reporting Tool과 같이 자동화된 도구를 사용해왔는데, 이러한 RDBMS 기반의 OLAP으로는 빅데이타 분석을 위한 충분한 용량을 확보하기 어렵고 더불어 근래에 생성되는 고객의 데이타는 기업 내부의 정형화된 데이타 뿐만 아니라 Face Book, Twitter등과 같은 SNS등에서 수집되는 비 정형화된 데이타에 대한 분석이 필요하게 되었다.

그래서 Map & Reduce의 장점과 OLAP 기반의 분석을 융합한 형태의 솔루션을 벤더에서 출시하고 있다.



기존의 OLAP의 앞단에 Hadoop과 같은 Map & Reduce Framework을 붙인 형태인데, Hadoop은 정형화되지 않은 형태의 대용량 데이타를 수집하여 Map & Reduce를 이용하여 정제하고 OLAP에 저장한다. 이렇게 저장된 OLAP의 데이타는 기존의 OLAP 인프라와 프로세스를 그대로 이용하기 때문에 기업의 입장에서는 기존 OLAP 기반의 데이타 분석 구조와 인력 구조를 변경하지 않고도 빅데이타에 대해서 대응이 가능하다. 같은 DBA, 같은 OLAP Reporting 툴들을 그대로 사용할 수 있다.

여기에 하나 더해서 데이타 분석 성능을 높이기 위해서 appliance 제품을 사용하는데, appliance 제품은 소프트웨어 솔루션 뿐만 아니라 소프트웨어에 최적화된 하드웨어와 함께 패키지된 형태의 제품이다. SQL 쿼리 엔진을 하드웨어 칩으로 만들어서 서버에 장착하거나, 해당 DBMS에 대한 쿼리를 최적화 하기 위해서 DISK 구조나 IO 구조등을 최적화 해놓은 제품들이다.

대표적인 제품으로는 Oracle ExaData IBM Nettiza와 같은 제품들이 있다.



'아키텍쳐  > BI' 카테고리의 다른 글

데이타 분석 계층 아키텍쳐  (0) 2012.10.14
OLAP 종류  (0) 2010.05.27
OLAP 튜토리얼  (0) 2010.05.26
데이타 웨어하우스 프로젝트 프로세스  (0) 2010.05.24
BI에 대한 링크 모음  (0) 2010.05.19

Google의 기술을 이해한다.

근래에 들어서 유행하는 IT 기술은 구글이나 페이스북등의 B2C 서비스 업체를 중심으로 하여 파생된 기술이 그를 이룬다.
클라우드 컴퓨팅, NoSQL, 빅데이타등의 최신기술들 역시 구글이나 페이스북을 원류로 한다.
'이 글에서는 대표적인 B2C 기업인 구글의 서비스의 구조를 통하여 구글의 기술을 이해하고 현재 주류를 이루는 기술에 대한 배경을 이해함으로써 향후 유사 솔루션에 대한 적용 시나리오를 찾는데 도움을 주기 위해서 작성되었다.'

검색엔진의 일반적인 구조
구글은 기본적으로 검색 서비스를 바탕으로 유입자를 통한 광고 수입을 주요 비지니스 모델로 하고 있다.
이메일이나 개인 스토리지 서비스등 많은 서비스들을 가지고는 있지만, 아무래도 그 뿌리는 검색이다.
일반적인 검색 엔진의 구조는 다음과 같다. 
※ 아래 구조는 일반적인 기술을 바탕으로 추론한 내용으로, 실제 구글의 검색 엔진 구조와는 상의할 수 있다.



크게 3 부분으로 구성되는데, 주요 컴포넌트는 다음과 같다.
1. Crawler 
Crawler는 인터넷의 웹 페이지들을 샅샅이 뒤져서 모든 페이지 문서를 읽어와서 저장하는 역할을 한다.
2. Index Engine
Index Engine은 저장된 페이지를 분석하여 단어별로 색인(Index) 을 만드는 역할을 한다.
3. Search Engine
Search Engine은 사용자에 의해서 입력된 검색어를 가지고, Index를 검색하여 검색어가 들어있는 페이지를 찾아내서 그 결과를 리턴한다. 
이 컴포넌트의 유기적은 흐름을 보면 다음과 같다.




1) Crawler는 수집해야되는 URL 리스트를 가지고 여러개의 BOT을 기동하여, 각 페이지의 HTML 페이지를 읽어서 저장한다.
2) Index 서버는 저장된 페이지들을 읽어서 Index를 추출한다.
Index는 단어와 페이지 URL을 맵핑한 일종의 테이블이다.
저장시에는 실제 문서 URL을 저장하지 않고, 일종의 Hash 등을 이용하여 문서 ID를 추출하여 저장한다.
아래 저장 구조는 일종의 예로, 실제로 저장되는 구조는 이보다 훨씬 복잡하다.



3) 사용자에 의해 들어온 검색어는 위의 Index 테이블을 검색하여, 문서 ID 리스트를 추출하고 랭킹 알고리즘등을 적용하여 소팅된 형태로 사용자에게 출력된다.


필요 기술

위의 시나리오를 구현하기 위해서 어떤 기술들이 필요할까?

1) Crawler에서 필요한 기술
Crawling은 Crawling Bot들이 여러 웹사이트를 돌아다니면서 그 페이지를 저장한다.
수백만 사이트에서 페이지를 읽어와서 저장해야 하기 때문에, 다음과 같은 조건의 대규모 파일 시스템이 필요하다.
파일 시스템
- 많은 수의 파일을 저장할 수 있을 것
- Crawling Bot은 오직 읽은 페이지를 저장 즉 Write만 하기 때문에, write에 최적화 되어 있어야 한다.
- 저장된 파일에 대한 update는 발생하지 않는다.

2) Index에서 필요한 기술
파일 시스템
- 하나의 파일을 동시에 여러 Index가 처리할 수 있어야 한다. 파일을 여러개로 나눠서 처리 하기 때문에, Random Access가 지원되어야 한다. 이런 요구 사항에서 나온 파일 시스템이 Google의 파일 시스템인 GFS 이다. 

INDEX 기반의 저장 시스템
- 검색어를 KEY WORD로 하고, 문서를 저장하는 대규모 Key/Value Store가 필요하다. 
대용량 분산 Key/Value 스토어를 구현한 것이 Google BigTable로, 현재 대용량 NoSQL에서 Amazon Dynamo 계열과 함께 크게 양대 산맥을 이루는 기반 기술이다.

3) 분산 Locking, 공유 정보

이런 대규모 분산 시스템 처리에서 필요한 점 중 하나가, 분산되어 있는 리소스(파일)에 대한 억세스를 진행할때, 다른 프로세스가 해당 리소스를 동시에 억세스할 수 없도록 배타적(Exclusive)한 접근을 보장해야 한다.
일반적인 방법이 Locking을 이용하는 방법인데, 분산되어 있는 노드와 클라이언트가 억세스 되고 있는 리소스에 대한 Lock 정보를 공유할 수 있어야 하며, 빠른 속도를 보장해야 한다.

4) 분산 처리 기술

이 시스템의 구조가 주목 받는 점중의 하나는 대규모의 데이타를 저장한다는 점이외에도, 대규모 데이타에 대한 처리(연산)이 가능하다는 것인데, 대표적으로 사용되는 기술이 Map & Reduce  라는 기술이다.
Map & Reduce 기술의 개념은 간단하다
 " 큰 데이타를 여러개의 조각으로 나눠서 여러대의 컴퓨터가 각 조각을 처리하고, 처리된 결과를 모아서 하나의 단일 결과를 낸다."

※ Map & Reduce에 대한 자세한 개념은 - http://bcho.tistory.com/650 글을 참고

실제 구현화된 기술과 레퍼런스 구현

이러한 기술들을 실제로 구현화해 놓은 시스템의 스택 구조와 이 개념을 바탕으로 구현된 오픈 소스들을 살펴보면 다음과 같다.




종류Google오픈소스
분산파일 시스템Google File System (GFS)Apache Hadoop File System (HDFS)
Key/Value 저장Google Big TableApache HBase
분산 처리Google Map & ReduceApache Hadoop
분산 LockingGoogle ChubbyN/A

구글에서 해당 솔루션 구축에 대한 논문을 발표했고, 이 원리를 바탕으로 뛰어난 개발자들이 오프소스에 기여하여, Apache Hadoop 을 필두로 하여, Google 의 시스템 Stack과 유사한 오픈소스가 나왔고, 현재 빅데이타 분석 및 비동기 처리용으로 많이 사용되고 있다. 아쉽지만 아직까지 분산 Locking을 지원하기 위한 Chubby와 같은 솔루션에 대응 되는 솔루션은 없다. ZooKeeper등을 이용하여 분산 Lock 처리를 하거나 애플리케이션에서 이를 구현 및 제어하는 실정이다.

자세하지는 않지만, 
1) 이러한 기술들이 왜 필요하며
2) 어떤 이유에서 만들어 졌으며
3) 어떤 용도로 사용되고 있는지
에 대해서 간단하게 살펴보았다.

앞서 서문에서도 요약하였지만, 이 글의 목적은 구글 기술 자체를 깊이 있게 이해하는 것이 아니라, 너무나 유행이 되버린 분산 처리나, 빅데이타, Hadoop 기술들에 대한 맹신을 없애고, 기술에 대한 제대로된 이해를 바탕으로 적절한 곳에 적절한 기술을 활용하고자 하는데 있다.

참고
1. 분산 파일 저장 시스템 - Apache HDFS 에 대한 소개 : http://bcho.tistory.com/650
2. BigTable 기반의 Key Value Store 구조 - http://bcho.tistory.com/657 (Apache Cassandra의  Local Node당 데이타를 저장하는 구조는 Google의 BigTable과 원리가 같다)





클라우드 컴퓨팅, Hadoop, NoSQL 새로운 기술이고 구글이나 FaceBook과 같은 B2C의 선두 업체들이 주로 사용하는 기술이다.


그런데, 왜 우리도 이 기술에 열광하는가?

재미는 있고, 쓸모는 있는 기술이다. 그런데 필요가 있나? 한번 더 생각해볼 필요가 있다.


첫번째 Hadoop

Hadoop의 경우 대용량 데이타를 배치성으로 처리하기 위한 분산 처리 프레임웍이다.

여러가지 사용 용도가 있을 수 있겠지만, 주로 대용량 데이타를 분석하기 위해서 사용된다.

이런 형태의 데이타 분석은 이미 OLAP이나 BI형태로 솔루션들이 제공되고 있고, 기업에서는 이미 구축되어 있다. 구글이나 페이스북과 같은  대규모 서비스를 한다면 모를까? 5000만 인구의 대한민국에서는 그만한 데이타 분석이 필요할까 과연 의문이다.

물론 비정형 데이타 분석에는 충분히 활용할만하다. 이런 시나리오를 바탕으로 오라클,Microsoft,IBM등은 Hadoop과 융합한 솔루션을 출시하는데, 데이타를 수집 및 정재 변환하고, 이 데이타를 Hadoop 클러스터에 넣는 시나리오이다.

국내에서도 한정된 시나리오에는 사용될만은 하지만, 이게 과연 이렇게 열광할만한 솔루션인가는 사실 반문이 든다. 차라리 memcached나 redis 같은 솔루션들이 훨씬 더 도움이 될거 같다.


두번째 NoSQL

NoSQL은 대용량 데이타 저장, 성능 등에 목적을 가지고 있는 특수목적 데이타 베이스로

각 NoSQL 솔루션에 따라서 그 사용 용도가 모두 틀리다.

오픈소스 RDBMS의 대명사인 MySQL 의 경우에도 10억개 정도의 레코드를 처리할 수 있으며, Query Off Loading이나 Sharding등을 통해서 확장성과 성능을 모두 보장할 수 있다. 페이스북도 몇년전까지만 해도 실제로 MySQL과 memcached의 조합으로 운영을 해왔다.


사실 요즘 유행하는 대부분의 기술들은 기업(Enterprise)성의 기술들이 아니다. IT의 주도권이 Oracle,IBM,Microsoft등의 대형 벤더에서 Google,FaceBook,Twitter로 넘어오면서 이들이 사용하는 기술들이 주목 받게 되었다. 그러나 이들이 만들어낸 기술 (NoSQL, Map & Reduce 기반의 분산 처리)는 철저하게 이들의 서비스 시나리오에 최적화 되어 있다.

 그런데 이것을 가져다가 적용하려하니, 엔터프라이즈에서는 안맞는 부분이 생기고, 국내 B2C에서도 활용 시나리오가 모호해진다.


첫번째로, 국내 시장 상황에서는 이정도의 빅데이타가 없고

두번째로, 이러한 기업들은 자체적으로 해당 기술에 대한 엔지니어를 보유하고 끊임 없이 공부하고 업그레이드 해 나간다. 특히 국내 SI기업에서는 인력 기반 장사 시장에서 어려운 이야기고 테스트랩이라도 하나 세팅하려고 하고 연구팀을 꾸리면 1~2년이면 SI 시장으로 나가야 한다.


기술 자체가 의미가 없는 것은 아니다. 그러나!! 왜 생긴 기술이고 내 업무에 적용할만한지를 판단해봐야 할것이며, 기존에 다른 솔루션들을 사용하고 있었을 경우, 이런 신기술로 변환했을 경우 장단점을 꼼꼼하게 따져 봐야 한다. 더 이상 기술 유행에 휩쓸리지 말고 기술 자체를 이해하는 노력이 필요하다.


그리고 이런 기술을 쓰려면 반드시 개발자나 기술자들이 중요한 것을 인식하고 충분한 기술 습득의 시간과 환경을 제공함으로써 내재화를 진행해야 한다. 예전처럼 외주 개발자를 밀어붙이고, 솔루션 벤더 불러다가 욕을 한다고 해결될게 아니다. 욕을 하고 싶으면 그 오픈소스를 만들고 있는 개발자들에게 월급을 주시던가... 

E-tailing

  • Recommendation engines — increase average order size by recommending complementary products based on predictive analysis for cross-selling.
  • Cross-channel analytics — sales attribution, average order value, lifetime value (e.g., how many in-store purchases resulted from a particular recommendation, advertisement or promotion).
  • Event analytics — what series of steps (golden path) led to a desired outcome (e.g., purchase, registration).

Financial Services

  • Compliance and regulatory reporting.
  • Risk analysis and management.
  • Fraud detection and security analytics.
  • CRM and customer loyalty programs.
  • Credit scoring and analysis.
  • Trade surveillance.

Government

  • Fraud detection and cybersecurity.
  • Compliance and regulatory analysis.
  • Energy consumption and carbon footprint management.

Health & Life Sciences

  • Campaign and sales program optimization.
  • Brand management.
  • Patient care quality and program analysis.
  • Supply-chain management.
  • Drug discovery and development analysis.

Retail/CPG

  • Merchandizing and market basket analysis.
  • Campaign management and customer loyalty programs.
  • Supply-chain management and analytics.
  • Event- and behavior-based targeting.
  • Market and consumer segmentations.

Telecommunications

  • Revenue assurance and price optimization.
  • Customer churn prevention.
  • Campaign management and customer loyalty.
  • Call Detail Record (CDR) analysis.
  • Network performance and optimization.

Web & Digital Media Services

  • Large-scale clickstream analytics.
  • Ad targeting, analysis, forecasting and optimization.
  • Abuse and click-fraud prevention.
  • Social graph analysis and profile segmentation.
  • Campaign management and loyalty programs.

From http://www.cloudera.com/why-hadoop/

 

Hadoop Architecture Overview

요즘 클라우드와 빅데이타 그리고 분산 컴퓨팅이 유행하면서 가장 많은 언급 되는 솔루션중하나가 Hadoop이다. Hadoop 이 무엇이길래 이렇게 여기저기서 언급될까? 본 글에서는 Hadoop에 대한 소개와 함께, Hadoop의 내부 동작 아키텍쳐에 대해서 간략하게 소개 한다.

What is Hadoop?

Hadoop의 공식 소개를 홈페이지에서 찾아보면 다음과 같다.

The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using a simple programming model. ’

정의를 요약하면, Hadoop은 여러 컴퓨터로 구성된 클러스터를 이용하여 큰 사이즈의 데이타를 처리하기 위한 분산 처리 프레임웍이다.

구조를 보면 엔진 형태로 되어 있는 미들웨어와 소프트웨어 개발 프레임웍의 형태를 띄고 있고, 대용량 데이타를 분산처리를 통해서 처리할 수 있는 솔루션으로, OLTP성의 트렌젝션 처리 (웹과 같이 즉시 응답이 필요한 시스템)보다는 OLAP성의 처리 (데이타를 모아서 처리 후 일정 시간 이후에 응답을 주는 형태)를 위해 디자인된 시스템으로 수분~수일이 소요되는  대규모 데이타 처리에 적합한 프레임웍이다.

Hadoop을 기반으로 한 여러가지 솔루션이 있으나 본 글에서는 Hadoop 자체에 대해서만 설명하도록 하겠다.

Map & Reduce의 기본

Hadoop의 분산 처리 방식은 기본적으로 “Map & Reduce”라는 아키텍쳐를 이용한다. Map & Reduce는 하나의 큰 데이타를 여러개의 조각으로 나눠서 처리 하는 단계 (Map), 처리 결과를 모아서 하나로 합쳐서 결과를 내는 단계 (Reduce)로 나뉘어 진다.

 

 

<그림 Map & Reduce의 기본 개념 >

예를 들어 한국에 사는 모든 사람의 수입의 합을 더한다고 하자. 우리한테는 한국에 있는 모든 사람의 수입이 적혀 있는 텍스트 파일이 하나 있다. 이 파일을 이용해서 각각 사람의 수입을 순차적으로 더해서할 수 도 있지만, 전체 파일을 10조각, 100조각으로 나눠서 각 조각의 수입합을 계산한후, 그 결과를 하나로 더하면, 조각을 나눈만큼의 계산을 병렬로 처리할 수 있기 때문에 조금 더 빠른 결과를 가질 수 있다. 이렇게 하나의 파일을 여러 조각으로 나눠서 계산 하는 것을 Map, 그리고 합치는 과정을 Reduce라고 한다.

이러한 Map & Reduce를 하기 위해서는 Input 데이타를 저장하고, 이 데이타를 조각으로 나눠서 저장하고, 조각에서 처리된 임시 결과를 저장 그리고 합쳐서 저장할 각각의 저장 공간이 필요하다. 이 공간은 전체 분산 처리 시스템에 걸쳐서 접근이 가능해야 하고, 대용량의 데이타를 저장할 수 있어야 하는데, Hadoop에서는 이 공간으로 분산 파일 시스템 (Distributed File System)을 사용하며, 이를 HDFS (Hadoop Distributed File System)이라고 한다. 그리고 위에서 설명한 것 처럼 MR을 위해서 데이타를 처리하는 부분을 Map & Reduce 모듈이라고 한다.

사용 시나리오

Hadoop Map & Reduce는 대용량 데이타에 대한 분석에 대해서 최적화 되어 있다.

즉 웹 시스템이나 OLTP (Online Transaction Processing)과 같은 1~5초내에 응답이 오는 형태의 Request/Response 방식의 Synchronous 형식의 시나리오에는 적합하지 않고, Input을 넣은 다음 수분 후에 결과를 받아서 보는 비동기 (Asynchronous) Deferred 형태의 시스템에 적절하다.

 수학적 계산을 위한 연산 처리, 대규모 저장 및 분석, BI (Business Intelligence)와 같은 데이타 분석과 같은 후처리(지연처리) 중심의 분석 시나리오에 적합하다.

Hadoop 구성

앞에서 설명한 것과 같이 Hadoop은 크게 분산 데이타 처리를 하기 위한 Map & Reduce 모듈(이하 MR) MR Input/Output 데이타를 저장하는 파일시스템인 HDFS (Hadoop Distributed File System)으로 구성되어 있다.

HDFS (Hadoop Distributed File System)

HDFS는 분산 데이타 처리를 위해서 데이타를 저장하기 위한 파일 시스템으로, 다음과 같은 특징을 가지고 있다.

  • 대용량의 파일 (페타 바이트)을 저장할 수 있다.

  • 많은 수의 파일을 저장할 수 있다.

  •  Streaming Data Access

  •  Commodity Hardware

  • Multiple writers, arbitrary file modifications

HDFS의 구성 컴포넌트는 크게 두가지로 나뉘어 진다. (Namenodes, Datanodes).

Namenodes

Namenodes는 일종의 Master node로 파일에 대한 메타 데이타를 저장하는 노드로, 디렉토리 구조, 파일에 대한 각종 메타 데이타, 그리고 물리적 파일이 저장되어 있는 위치등을 저장한다.

Datanodes

Datanodes는 실제 파일을 저장하고 읽어온다. 하나의 파일을 블록이라는 단위로 나눠서 저장하는 역할을 수행한다. 그리고 Namenodes와 주기적으로 통신하여 저장하고 있는 블록에 대한 정보를 Namenodes에 저장하도록 한다.

Namenodes에는 모든 블록에 대한 메타정보가 들어와 있기 때문에, Namenodes가 장애가 나면 전체 HDFS 이 장애가 나는 SFP ( Single Failure Point )가 된다. Namenodes에 대한 이중화가 필요하다. Namenodes에 대한 이중화 방안에 대해서는 추후에 설명하도록 한다. Namenodes SFP로 작용하는 것은 Hadoop 운영상에 아주 중요한 운영 포인트로 존재한다. 근래에는 HDFS의 약점을 보완하기 위해서 GlusterFS Hadoop을 지원하면서, 파일 시스템으로 HDFS를 사용하는 대신 GlusterFS로 대처할 수 있다.

블럭 (Block)

블럭은 HDFS에서 Read Write를 하는 최소 단위이다. 하나의 파일을 여러개의 블럭으로 나눠서 저장된다. Hadoop의 블럭 사이즈는 일반적인 파일 시스템의 블럭사이즈 ( Kilobytes – 일반적으로 파일시스템에서는 512 KB )에 비해서 큰 블럭사이즈를 사용한다. Hadoop에서는 디폴트로 64MB를 사용하고, 보통 128MB를 사용한다.

클 블럭사이즈를 사용하는 이유는, MR 처리에 있어서 Map Task가 하나의 파일 사이즈 단위로 처리하기 때문에, 작은 파일 억세스 보다는 Map Task 단위로 처리할 수 있는 단위가 필요하다. (이것이 블럭) 이를 위해서 큰 사이즈 단위로 파일 처리를 할 수 있는 블럭을 지정하는 것이다.

또한 블럭 크기를 크게 함으로써, 해당 파일에 대한 Seeking Time을 줄일 수 있고, 블럭 사이즈를 적게 하면 Master Node에서 저장 및 처리해야 하는 데이타의 양이 많아지기 때문에 Master Node에 많은 부하가 걸리기 때문에 큰 블럭 사이즈를 사용한다. 이런 이유로 반대로 블럭 사이즈가 작거나 사이즈가 작은 데이타 처리의 경우 Hadoop에서는 충분한 분산 처리 성능을 기대하기 어렵다.

HDFS는 대규모 분산 처리에 필요한 대용량 input 데이타를 저장하고 output 데이타를 저장할 대용량 파일 시스템을 지원한다. HDFS 시절 이전에는 고가의 SAN (Storage Area Network)장비나 NFS 장비를 사용했어야 했는데, Hadoop은 일반 x86 서버에 Disk를 붙인 형태의 저가의 서버 여러개를 연결하여 대규모 분산 파일 시스템을 구축할 수 있게 해줌으로써, 값비싼 파일 시스템 장비 없이 분산 처리를 가능하게 해주는 것이다

Read/Write Operation

1) Read Operation

Client에서 Read를 수행하면, 먼저 Client SDK Namenode에 해당 파일의 데이타 블럭들이 어디에 있는지 블록의 위치를 먼저 물어온 다음에, 순차적으로 해당 데이타 블록이 저장되어 있는 datanodes로 부터 데이타를 블록을 읽어온다.

 

<그림. HDFS Read Operation >

이 과정에서 Namenode라는 놈이 아주 기특한 일을 하는데, 기본적으로 HDFS는 하나의 파일 블록을 저장할때 하나의 datanode에 저장하는 것이 아니라 N개의 datanode에 복제해서 저장한다. (장애 대응을 위하여). Namenode가 블록의 위치를 리턴할때, Hadoop Client로 부터 가까운 곳에 있는 datanode (같은 서버, 같은 Rack, 같은 데이타 센터 순서로..)를 우선으로 리턴하여 효율적인 Read Operation을 할 수 있도록 한다.

2) Write Operation

 

<그림. HDFS Write Operation>

파일 블록 저장은 약간 더 복잡한 과정을 거치는데

파일을 Write를 요청하면,

     먼저 Namenode에서 File Write에 대한 권한 체크등을 수행한다.

     Namenode에서 파일이 Writing Block의 위치한 Datanode를 리턴한다. (1)
파일을 쓰다가 해당 블록이 다 차면, Namenode에 다음 Block이 저장되는 Datanode의 위치를 물어본다.

     Client Stream을 통하여 해당 Datanode Block에 파일을 Write한다. (2)

     Write된 파일을 복제 Datanodes (※ 여기서는 복제노드와 원본 노드를 포함하여 총 3개의 노드가 있다고 가정하자)로 복제(복사)한다. (3,4)

     복제되는 Datanodes들 쌍을 pipeline이라고 하는데, 내부 정책에 따라서 서로 복제할 Datanodes들을 미리 정해놓고 이를 통해서 복제한다. (pipeline Datanode의 물리적 위치 – Rack, 데이타 센터 등을 고려해서 자동으로 결정된다.)

     복제가 모두 끝나면 ACK를 보낸다. (5,6,7)

     파일 Writing을 완료한다.

 

이번 글에서는 간단하게 Hadoop에 대한 개념 소개와 Hadoop의 하부 파일 시스템인 HDFS에 대해서 알아보았다. 다음 글에서는 Hadoop의 Map & Reduce Framework에 대해서 살펴보기로 한다.

 

요즘 잘나간다는 SNS 서비스 (텀블러, PInterest)등의 내부 서비스 아키텍쳐나 운영 구조를 공개된 글을 보면 SNS 시스템들의 기술 트렌드를 읽을 수 있다.

 

1. 소규모 조직이다.

얼마전에 FB에 인수된 Instantgram이나 다른 잘나가는 SNS서비스 업체들을 보면 대부분 인력이 20명이내이다.

영업 조직이 있는 솔루션 업체의 경우는 영업이나 Director들을 포함하더라도 40명이 안넘는 것이 대부분이다.

 

이는 빠른 의사 결정을 가능하게 하기 때문에, 상당히 빠른 서비스 개선을 가능하게 한다.

기술적이나 기획적으로 대단한게 아니라, 하나의 기능을 편하게 만들고 사용자 경험에 상당한 노력을 쏟는다.

 

2. 오픈 소스로 치덕치덕. & Don't invent wheel again

이런 서비스들 치고, 대형 벤더 솔루션 쓰는 곳을 못봤다.

- 대부분 오픈 소스를 사용한다.

- 여러가지 언어를 사용한다. 우리가 한국에서 익숙한 자바나 C는 일부에 사용되지 전체를 자바나 C로만 구현하지는 않는다. 오히려 Erlang, Python, Ruby같은 언어들이 급격하게 올라온다.

- 기존의 오픈 소스를 활용을 하지 새롭게 솔루션을 만드는 경우가 없다.

 

3. Devops
Devops는 Development와 Operaion (개발과 운영)을 합친 말로, 이 두팀을 분리하지 않고 개발팀이 개발과 운영을 모두 맏는 개발 운영 모델이다. 요즘 들어 상당히 유행하는데, 운영에서 얻어지는 노하우나 문제를 개발팀에서 처리하는데 비용을 덜고, 고객으로부터의 요청에 빠르게 대응하기 위한 구조로, 운영 팀을 별도로 두지 않는다.

이 것이 가능한것은 클라우드를 사용하면서 하드웨어 인프라에 대한 운영을 클라우드 업체가 담당하기 때문에, 거창한 운영 조직이 필요없고, 클라우드 상에 배포 구조만 잘 잡으면 되기 때문에 가능해진 일이라고 본다.

 

4. Cloud

앞에서도 이야기 했지만, 잘나가는 서비스들은 AWS (Amazon Web Service)를 사용한다.

초기 투자 비용 (Capex)가 들지 않고, 전 세계 커버리지가 가능하며, HA (High Availibility) 구성이 가능하고, 서비스 부하에 따라서 탄력적으로 컴퓨팅 자원을 늘리거나 줄일 수 있기 때문이다.

 

5. 하나씩 차근차근

놀라운 것중 하나는 수백만명을 대상으로 서비스하는 시스템이라도, 처음부터 수백만명을 지원하기 위한 설계를 하는 것이 아니라 기존에 익숙한 기술을 사용하고, 사용자가 늘어감에 따라 아키텍쳐나 기술셋을 점차적으로 바꿔 나가는 구조를 사용한다.

 

주요 아키텍쳐 구조는

앞단에 Nginx나 Apache와 같은 웹서버

중간에 Redis나 memcached 같은 메모리 데이타 그리드

Tomcat,Django와 같은 WAS

Java 뿐만 아니라 Erlang, Python,RoR과 같은 스크립트 언어 또는 분산 처리 언어

MySQL 을 사용할 경우 Sharding, 또는 NoSQL을 백엔드에 사용

이 전체는 AWS 클라우드 위에 Deployment

아키텍쳐는 REST를 사용하는 구조를 갖는다.

필요에 따라 배치 처리나 분석 처리를 위해서 Hadoop등의 분산 처리 프레임웍을 사용

 

 

 

 


짧으나마 NoSQL 경험해보고 배운 내용을 정리해보면

1. RDB는 Entity를 정의하고 데이타 모델링을 정의한 후에, 쿼리와 APP을 개발한다. 반대로 NoSQL은 App을 먼저 디자인하고, 필요한 쿼리 결과를 먼저 정의 한후에, 그에 맞춰서 데이타 모델링을 해야 한다.

2. 절대 Normalization은 하지 말고, DeNormalization을 할것. 데이타 중복을 허용하여 성능을 높이고, 데이타안에 데이타를 넣는 (Composition) 모델등을 사용하여 Query 수를 줄여야 한다.

3. 내 애플리케이션의 서비스 특성과 이에 맞는 NoSQL을 선택한다. BigTable 계열, Cassandra 계열, Document DB 계열등 많은 계열의 NoSQL이 있고, 그 특성도 매우 다르다 (언뜻 보면 다 같아 보이지만). 서비스를 이해하고, 사용하고자 하는 NoSQL을 완전히 이해한 다음에 시작해야 실수를 막을 수 있다.

4. NoSQL 쿼리가 실제 몇개의 물리 노드에 걸쳐서 수행되는지에 대한 이해가 있어야 제대로된 쿼리 디자인이 가능하다.

5. NoSQL 디자인은 DB 와 APP 뿐만 아니라 인프라 (네트워크,디스크)에 대한 디자인을 함께 해야 한다.

6. 대부분의 NoSQL DB는 인증이나 인가 체계가 없어서 보안에 매우 취약하기 때문에 별도의 보안 체계를 마련해야 한다. (방화벽이나 Reverse Proxy 등)

http://bigdatalowlatency.com/

대용량 분산 데이타 처리에 대한 글이 많다.

큐브리드에서도 NoSQL 벤치마크한 자료들이 많네요. 그것도 영어로..
http://blog.cubrid.org/dev-platform/nosql-benchmarking/

여기 Foursquare에서 MongoDB에 대한 장애 케이스가 있네요
http://monetary.egloos.com/3600459

결국은 메모리가 빵빵해야 하고, 용량 초과되기 전에 증설을 자알~~ 해야 한다는것.

Introduction of Cassandra

카산드라는 구글의 BigTable 컬럼 기반의 데이타 모델과 FaceBook에서 만든 Dynamo의 분산 모델을 기반으로 하여 제작되어 Facebook에 의해 2008년에 아파치 오픈소스로 공개된 분산 데이타 베이스 입니다. 기존의 관계형 데이타 베이스와 다르게 SQL을 사용하지 않는 NoSQL의 제품중의 하나이며, 대용량의 데이타 트렌젝션에 대해서 고성능 처리가 가능한 시스템이다.(High-Scale). 노드를 추가함으로써 성능을 낮추지 않고 횡적으로 용량을 확장할 수 있다.

 얼마전에 트위터도 MySQL에서 Cassandra로 데이타베이스를 전환하였다고 한다..

자바로 작성되었음에도 불구하고, 데이타베이스라는 명칭에 걸맞게 여러 프로그래밍 언어를 지원합니다. Ruby,Perl,Python,Scala,Java,PHP,C# 

데이타간의 복잡한 관계 정의(Foreign Key)등이 필요없고, 대용량과 고성능 트렌젝션을 요구하는 SNS (Social Networking Service)에 많이 사용되고 있습니다. 성능이나 확장성과 안정성이 뛰어나지만 안타깝게도 Global Scale (여러 국가에 데이타 센터를 분리 배치하여 배포하고, 데이타 센타간 데이타를 동기화 하는 요구사항) 은 지원하지 않습니다. Global Scale이 필요하다면, MySQL기반의 geo replication Sharding이 아직까지는 가장 널리 쓰이는 아키텍쳐 같습니다

Data Model

카산드라의 데이타 모델은 다음과 같다.

전통적인 관계형 데이타 베이스와 다른 구조를 가지고 있다.먼저 데이타 모델에 대한 개념을 잡아보면

Column
컬럼은 컬럼 이름과, 값으로 이루어진 데이타 구조체이다.

{name: “emailAddress”, value:”cassandra@apache.org”}
{name:”age” , value:”20”}

Column Family

컬럼 패밀리는 컬럼들의 집합이다. 관계형 데이타 베이스의 테이블을 생각하면 되는데, 약간 그 개념이 다르다. 차이점은 나중에 설명하기로 하고, 컬럼 패밀리는 하나의 ROW를 식별하기 위한 Key를 갖는다. 하나의 Key에 여러개의 컬럼이 달려 있는 형태가 컬럼 패밀리이다.

하나의 Row를 예를 들어보면

Cassandra = { emailAddress:”casandra@apache.org” , age:”20”}

과 같은 형태이다. Cassandra가 해당 Row에 대한 Key가 되고, emailAddress age라는 이름의 두개의 컬럼을 가지고 있으며 각 컬럼의 값은 “casandra@apache.org” “20”이다.

여러개의 Row를 가지고 UserProfile이라는 이름의 컬럼 패밀리를 보면

UserProfile={
  Cassandra={ emailAddress:”casandra@apache.org” , age:”20”}
  TerryCho= { emailAddress:”terry.cho@apache.org” , gender:”male”}
  Cath= { emailAddress:”cath@apache.org” , age:”20”,gender:”female”,address:”Seoul”}
}

과 같이 표현할 수 있다. 여기서 주목할만한 점이 각 Row의 데이타 스키마가 다르다는 것이다. Cassandra Row emaillAddress age라는 컬럼을 가지고 있고, Terry.Cho emaillAddress gender라는 컬럼을 가지고 있다. 이 처럼 카산드라는 각 Row마다 다른 형태의 데이타 스키마를 가질 수 있는데, 이러한 특징은 “Schemeless”라고 한다.(키에 바인딩되는 데이타 구조는 같은 컬럼 패밀리라도 각 키별로 다를 수 있다.)

KeySpace

KeySpace는 논리적으로 ColumnFamily를 묶어주는 개념입니다. 단지 묶어만 줄뿐 데이타 구조나 관계에서는 별다른 영향을 주지 않습니다.

Super Column & Supper Column Family

앞에서 설명드렸던 컬럼에서 컬럼의 Value String이나 Integer와 같은 Primitive형 뿐만 아니라 컬럼 자체가 다시 들어갈 수 있습니다. 예를 들어 이런 구조입니다.

{name:”username” 
 value: firstname{name:”firstname”,value=”Terry”} 
 value: lastname{name:”lastname”,value=”Cho”} 
}

username이라는 컬럼 안에 firstname lastname이라는 두개의 컬럼이 들어가 있는 구조입니다.

마찬가지 형태로 Column Family 안에도 Column Family가 들어가는 Super 구조가 가능합니다.

UserList={ 
   Cath:{ 
       username:{firstname:”Cath”,lastname:”Yoon”}
       address:{city:”Seoul”,postcode:”1234”}
           }
    Terry:{ 
       username:{firstname:”Terry”,lastname:”Cho”}
       account:{bank:”hana”,accounted:”1234”} 
           }
 }

UserList라는 Column Family 안에, 각각 Cath Key username address라는 Column Family를 가지고 있고, Terry라는 Key username account라는 Column Family를 가지고 있습니다.  

Data Model for Java Developer

간단하게 카산드라의 데이타 구조에 대해서 살펴보았는데, 자바 개발자분이시라면 HashTable이 떠오를겁니다. 데이타 모델을 HashTable과 비교해서 설명해보면 다음과 같은 형태가 됩니다.코드로 이야기 하면 대략 다음과 같은 형태가 되겠지요


앞서 들었던 Column Family의 데이타 구조를 자바 코드로 표현하면 다음과 같은 구조가 됩니다.

UserProfile={
  Cassandra={ emailAddress:”casandra@apache.org” , age:”20”}
  TerryCho= { emailAddress:”terry.cho@apache.org” , gender:”male”}
  Cath= { emailAddress:”cath@apache.org” , age:”20”,gender:”female”,address:”Seoul”}
}

자바 코드

class Keyspace{
           HashTable keyspaces = new HashTable();          

           createColumnFamily(String name){
                     keyspaces.put(name,new HashTable);
           }

           putValue(String columnFamily,String key,Object value){
                     Hashtable cf = keyspaces.get(columnFamily);
                     cf.put(key,value);
           }
}

 

class TerryVO{ // Terry is a Key
           String emailAddress; // each column
           String gender;
           // setter & getter
}

 class CathVO{ // Cath is a Key

           String emailAddress;
           String age;
           String gender;
           // setter & getter 
}

KeySpace myspace;
myspace.createColumnFamily("UserProfile");
myspace.putValue("UserProfile","TerryCho",new TerryVO("terry.cho@apache.org","male");
myspace.putValue("UserProfile","Cath",new CathVO("cath@apache.org","20","female")

 자바 개발자분들이시라면 쉽게 이해하실 수 있을것 같고
구조를 분석하다보니 오라클의 데이타 그리드 솔루션은 Coherence와 데이타 구조가 매우 유사합니다. 요즘 이게 유행인가 보네요

Cassandra Test

개념을 이해했으면 실제 테스트를 한번 해보도록 하겠습니다.

먼저 아파치 카산드라 프로젝트(http://incubator.apache.org/cassandra/) 에서 카산드라를 다운 받습니다. 압축을 푼후에 bin/cassandra.bat를 실행시킵니다. (클러스터로 기동할 수 도 있으나 여기서는 단순하게 하나의 노드만 뛰어보도록 합니다.)

이제 카산드라 커맨드 라인 인터페이스(CLI)를 시키고(/bin/cassandra-cli.bat) 다음 카산드라 노드에 연결합니다. 포트는 디폴트로 9160 포트가 지정되어 있으며 /conf/storage-conf.xml에서 Listen Address Port를 변경할 수 있습니다.  

/conf/storage-conf.xml 파일에는 default Keyspace1이라는 이름으로 Keyspace가 정의되어 있습니다. Keyspace1에 지정되어 있는 Column Family(CF) 형식은 다음과 같습니다.


Standard2 CF Terry이라는 Key Gender라는 Column Male이라는 값을 넣고 다시 조회해보겠습니다.


다음번에는 Java Code를 이용하여 카산드라에 접근하는 방법에 대해서 알아보도록 하겠습니다.

참고 할만한 자료

http://research.microsoft.com/en-us/people/sriram/raghuramakrishnan.pdf