2016년 8월 9일 화요일

CEP 아키텍처 기반의 실시간(Real-time)처리



배치 처리가 아닌 실시간 처리가 필요할 경우, CEP(Complex Event Processing) 아키텍처를 활용한다. 데이터 수집 즉시, 전처리, 계산, 패턴 분석을 처리한다. 많이 사용되는 구성은 그림7과 같고, 각 레이어 별 대표적인 구성 요소는 표4와 같다.

<표4> CEP(Complex Event Processing)의 구성 요소

구성 요소
내용
Log Collector
  - 이벤트를 실시간으로 수집
  - 예) Apache Flume
Message Queue
  - 이벤트를 임시로 저장
  - 예) Apache Kafka
Real-time Pre-Processing
  - 실시간으로 전처리가 필요할 경우 사용
  - 예) (Real-time Hadoop이라 불리는 Twitter에서 만든) Apache Storm
Real-time Computing
  - 실시간 계산 및 실시간 패턴 분석
  - 예) (대표적인 CEP 엔진인) Esper


<그림7> CEP 아키텍처의 실시간(Real-time)처리


출처: http://hadoop.apache.org/


처리 방식에 따른 빅데이터 아키텍처의 두 가지 사례



빅데이터를 위해 배치 처리를 하는 하둡(Hadoop) 아키텍처 기반의 시스템과 실시간 처리를 하는 CEP(Complex Event Processing) 아키텍처가 존재한다. 데이터를 실시간 처리해야 하는 경우라면 CEP 아키텍처를, 그렇지 않은 경우는 하둡 아키텍처를 사용하면 되는데 워낙 많은 데이터를 처리해야 하는 빅데이터이기 때문에 하둡 아키텍처가 많이 사용된다.


(1) 하둡 아키텍처 기반의 배치(Batch)처리

배치 처리을 위한 하둡 아키텍처는 다양한 형태로 구성되는데 많이 사용되는 구성은 그림6과 같고, 각 레이어 별 대표적인 구성 요소는 표3과 같다.

<표3> 하둡 아키텍처의 구성 요소
구성 요소
내용
Log Collector
  - 로그 이벤트 수집기 레이어로 많이 사용
  - 예) Apache Flume
DB Collector
  - DB에 저장된 데이터를 수집
  - 예) Apache Sqoop
Message Queue
  - 로그,이벤트 내용을 Data Store에 넣기 전에 임시로 저장할 경우 사용
  - 예) Apache Kafka
Data Store
  - 분산 파일 시스템으로 구성
  - 예) Apache Hadoop
Data Analysis
  - 데이터 분석을 위한 
  - 예) Apache Pig, Hive, Map/Reduce
Workflow
  - Job 제어를 위함
  - 예) Apache Oozie, LinkedIn의 Azkaban 등


<그림6> 하둡 아키텍처의 배치 처리
출처: http://hadoop.apache.org/




교통안전공단의 “자동차운행정보 관리시스템” 사례



본 사례는 교통안전공단에서 구축한 시스템이다. 자동차의 운행정보를 수집하고 분석해서 교통안전공단에서 필요한 정보를 전달하고 관리한다. 이 사례는 데이터가 정형화 되어 있어 비정형 데이터에 대해서는 관리하지 않아 수집된 모든 데이터가 데이터베이스 서버에 저장된다.


<그림5> 교통안전공단의 빅데이터 아키텍처에 레이어 맵핑
출처: 교통안전공단


그림5를 살펴보면, 그림의 숫자는 그림2에서 나타낸 각 레이어의 번호와 맵핑 되어 있다. 자동차의 운행정보를 수집(①데이터 수집)하고 있고, 수집된 데이터를 정제(②데이터 정제)하여 분석 시스템으로 보내게 된다. 분석 시스템은 미리 정의된 기준에 따라 데이터를 분석(③데이터 분석)하게 되고, 분석된 데이터는 데이터베이스에 저장(④데이터 정보화)한다. 마지막으로, 정보를 시각화(⑤정보 시각화)하여 보여주게 된다. 나머지 부분은 데이터에 대한 정책, 연계 등을 위한 모니터링, 관리 시스템으로 구분된다.