빅데이터 컴퓨팅 기술 리뷰

_m_4114m “빅데이터 컴퓨팅 기술”  책은 일반적인 기술 개발서적은 아니다. 이 책은 빅데이터라는 큰 개념을 잘개 쪼개서 현재 기술들을 아주 상세하게 리뷰해 놓은 개론서이다.

한빛리더스 8기 5번째 미션도서 첫인상

책 자체가 한빛아카데미의 IT Cookbook 시리즈로 나와서 사실상 대학생 교재 및 참고도서라 봐도 무방하다.  그래서인지 총 6분의 공저자 모두 현직 대학교수들로 이루어져 있다. 또한 매 챕터마다 간단한 내용확인 수준의 연습문제가 제공되고 레퍼런스가 꼼꼼하게 달려있다. 레퍼런스가 잘 달려 있어서 관심있는 부분을 자세하게 찾아볼 수 있다는 점이 마음에 든다.

내용은 크게는 다음의 3개의 파트로 구분된다.

  1. 빅데이터 개요
  2. 빅데이터 컴퓨팅 기술
  3. 빅데이터 기술 개발현황과 실제 구현예

목차를 보고 책을 읽으면 각 파트별로 세부적으로 현재 나와 있는 거의 모든 기술 들에 대해서 조사해서 담았다는 것을 알 수 있다.  현재 석사생으로 이 책을 읽으며 가장 먼저 들었던 느낌은 과제 제안서에 넣을 키워드가 소스가 풍부한 책이라는 점이다. 빅데이터가 뭔지, 어디서부터 조사를 시작할지 잘 모르겠다면 이 책은 빅데이터에 대한 숲을 보여주는데 제 몫을 한다.

한빛리더스 8기 5번째 미션도서 첫인상

그런데, 이 점이 단점으로 작용하기도 한다. 이유는 단순한 기술과 정보의 나열이다 보니 책이 좀 지루하다. 계속 읽게끔 하는 매력이 별로 없다. 챕터마다 다음 챕터로 넘어가게끔하는 내용의 재미가 느껴지지 않는다. 조금 더아쉬운 점을 이야기하면, 단순히 현재 기술을 나열한 것 이상의 통찰을 주지는 못하는 것 같다.

정리하면, 빅데이터라는 주제를 백과사전식으로 잘 종합한 것은 좋은 점수를 줄 수 있으나 다소 내용이 평면적이고 딱딱하다는 점이 아쉽다.

풀컬러 내용

그러나  내용이 지루할 것을 편집자들이 이미 예견했다는 듯이 화려한 풀컬러로 독자들을 조금 더 책에 붙든다. 십중팔구 내용까지 단조로운 모노톤이었다면 읽기 쉽지 않았을 것이다. 지루하기 쉬울 내용을 풀컬러의 화려한 장표와 그림으로 채운 것에는 플러스 점수를 줄 수 있다.
풀컬러 내용

요약하면, 빅데이터와 연관이 있는 거의 모든 키워드들을 잘 짜여진 틀 안에 차곡 차곡 쌓아놓은 기술백서이다. 그래서 책에서 느껴지는 장단점도 보통의 white paper 같은 느낌이 드는 책이다.

책 첫머리에서 설명하는대로 빅데이터를 입문할 때 간단하게 살펴보기에 적절한 책이며 심화학습 및 내용을 위한 길라잡이라고 볼 수 있다.

이 리뷰는 한빛리더스 8기 활동의 일환으로 작성한 것입니다.

한빛리더스 8기

[번역] 인메모리 데이터 그리드에 대해서

원문: http://architects.dzone.com/articles/memory-data-grids

요즘 영어 공부할 요량으로 자주 영어 원문 아티클을 번역 중입니다. 이 글도 제가 연구하는 주제와 밀접한 관련이 있는 내용이라 급조(?) 번역한 것이라 오역이 있을 수 있으니 어색한 부분은 원문을 대조해서 보시길 바랍니다.

2012년의 IT분야의 유행어는 틀림없이(without a doubt) 빅데이터이다. 빅데이터는 전통적인 데이터베이스 시스템의 프로세싱 능력을 초과하는 데이터를 말한다.

대표적인 예제로 연간 25페타바이트의 실험 데이터를 발생시키는 Large Hadron Collider의 CERN이나 매 시간당 백만건 이상의 고객 트랜잭션을 다루는 월마트가 있다.

문제점

이렇게 막대한 양의 데이터는 우리에게 두 가지 문제점을 남긴다.

문제점 1:  이러한 데이터로부터 가치있는 정보를 얻기 위해서 빅데이터를 처리할 수 있는 대안을 선택해야만 한다. 조직에게 있어서 빅데이터의 가치는 분석적 사용과 새로운 제품의 활성화라는 두 가지로 카테고리로 나뉜다. 빅데이터 분석은 이전에는 처리하는 비용이 많이 들어 감추어진 통찰을 들어낼 수 있다. 예를 들면 쇼핑 고객의 거래기록, 사회적, 지리적 데이터를 분석을 통해 들어나는 고객간의 상호 영향도와 같은 정보들이 있다. 적합한 시점마다 모든 아이템의 데이터를 처리하는 것은 사전에 정의된 보고서의 정적인 성질과는 다소 대조적으로 샘플링이라는 고질적인 필요를 줄여주고, 데이터에 대한 조사적인 접근을 증진시킨다.

문제점 2: 데이터가 너무 크고, 빠르게 흐르기 때문에 또는 데이터베이스 아키텍쳐의 제약(stricture)에 적합하지 않다. CERN의 LHC가 연간 25페타바이트의 데이터를 생성하는 것을 상기해 보면, 어떠한 전통적인 데이터베이스 아키텍쳐나 구성도 이만한 양의 데이터를 저장할 수 없다.

해결책

운 좋게도 두 가지 문제 모두 정확한 인프라스트럭쳐의 구현과 데이터 저장소에 대한 재고를 통해 해결가능하다. 빅데이터 환경에는 크기와 속도라는 두 개의 핵심적인 요소가 있다. 우리는 이미 데이터의 양과 빠르게 데이터에 접근과 연산하려는 요구가 있음을 논의했다. 후자의 경우가 전통적 데이터 웨어하우스와는 대비되는 주요한 차별점이다. 만약 모든 데이터에 실시간으로 접근할 수 있을때 우리가 할 수 있는 것들을 상상해 보라. 빅데이터에 접근하는 것이다.

일반적인 빅데이터 구현은 분산 클러스터에서 운영되는 인메모리 데이터 그리드를 사용하는 것이다. 이는 데이터를 메모리에 저장하므로 속도와 함께 클러스터를 통한 확장성을 갖추고 있기 때문에 수용력까지 보장하게 된다. 더불어 분산 클러스터 덕분에 가용성까지 보너스로 보장받는다. 데이터 저장소를 위해서는 인메모리 데이터베이스와 인메모리 데이터 그리드라는 전형적인 두 가지 방식이 존재한다.

그러나 우선 몇가지 배경이 있다. 메인메모리를 디스크 대신 저장소로 활용하는 것은 새로운 접근법은 아니다. 우리 일상에서 디스크 기반의 데이터베이스보다 더욱 빠른 메인메모리 데이터베이스(main memory databases, MMDB)의 여러 예들이 이미 있다. 우리 일상에서 볼 수 있는 예는 모바일 폰이다. SMS나 전화를 할때 대부분의 모바일 서비스는 MMDB를 사용하여 최대한 빠르게 연락처의 정보를 가져온다. 똑같은 방식으로 누군가가 내게 전화를 걸면, 송신자의 상세정보가 주소록에서 빠르게 조회되어 주로 이름과 사진정보를 제공하게 된다.

인메모리 데이터 그리드 (In memory data grids)

인메모리 데이터 그리드(In Memory Data Grid, IMDG)는 메인메모리에 데이터를 저장한다는 점에서 MMDB와 동일하지만 전혀 다른 아키첵쳐를 가지고 있다. IMDG의 특징을 다음과 같이 요약할 수 있다.

  • 데이터가 분산되어 여러 서버에 저장된다.
  • 각 서버는 활성화된 상태로 운영된다.
  • 데이터 모델은 주로  (직렬화된) 객체 지향이면서 비관계형이다.
  • 필요여부에 따라 종종 서버를 증감할 수 있다.
  • 테이블과 같은 전통적인 데이터베이스 특징이 아니다.

다시 말하면 IMDG는 메인 메모리에 데이터를 저장하기 위해 고안되었으며 확장성을 보장하며 객체를 바로 저장한다. 최근에 많은 IMDG 제품이 상용이나 오픈소스로 존재한다. 다음은 주로 사용되는 제품의 일부이다.

왜 메모리인가?

데이터 저장소로 메인메모리를 사용하는 주요한 이유는 다시 말하지만 빅데이터의 두 가지 특성인 속도와 수용력 때문이다. 메인메모리의 연산 퍼포먼스는 HDD보다 800배나 빠르며, () 보다는 40배까지 빠르다. 더욱이 최신 x86서버는 서버당 수백GB의 메인 메모리를 지원한다.

전통적인 데이터베이스의 (OLTP) 데이터 수용 제약은 대략 1TB 정도이며 OLTP 데이터 연산 수용력은 잘 증대되지 않는다. 만약 서버가 메인메모리를 1TB나 그 이상을 쓰는 일이 흔해진다면, 적어도 OLTP분야에서는 전체 데이터를 메인메모리에 넣고 운영을 수행할 수도 있다.

IMDG 아키텍쳐

메인 메모리를 저장장치로 사용하기 위해서는 두가진 약점을 극복해야 한다.

  • 제한된 수용력: 서버의 메인메모리의 수용력을 초과하는 데이터가 포함된 경우
  • 신뢰성(Reliability): 시스템 오류에 따른 데이터 손실의 경우

IMDG는 분산아키텍쳐를 통해서 수평적 확장성을 보장하여 제한된 수용능력을 극복하고 그리드(또는 분산 클러스터)의 부분으로 복제시스템으로 인해 신뢰성의 이슈를 해결한다.

그럼 이제 IMDG가 실제로 어떻게 작동하는지 논의해 보자. 무엇보다도 IMDG가 인메모리 데이터베이스(메인 메모리 데이터베이스라 불리는, MMDB)와 동일하지 않다는 점을 인지하는 것이 중요하다. MMDB의 대표적인 제품은 오라클의TimesTen과 SAP의 HANA가 있다. MMDB는 메모리 상에서 운영되는 완벽한 데이터베이스 제품이다. 완전한 기능을 갖춘(full-blown) 데이터베이스로서, MMDB 역시 데이터베이스 운영 특성상 무겁고 오버헤드를 동반한다. IMDG는 다르다. 테이블, 인덱스, 트리거, 저장된 프로시져나 프로세스 관리 등이 없다. 그저 단순한 저장소이다.

IMDG에서 사용되는 데이터 모델은 키-밸류 쌍이다. 키-밸류 상은 키와 밸류의 오직 두 요소만을 갖는 리스트이다. 키는 리스트 안에서 밸류를 저장하고 찾는데 사용된다. 키는 데이터베이스에서 인덱스나 기본키(Primary Key)와 비교할 수 있다. IMDG는 프로그래밍 환경에서 키-밸류 쌍이 데이터 구조로 표현될 수 있기 때문에 Java와 같은 개발환경과 밀접하게 연관되어 있다는 점을 주목해야 한다. 대부분의 IMDG 제품은 Java로 개발되었기 때문에 다른 Java 애플리케이션 안에서만 사용이 가능하다. 그러므로 키-밸류 쌍의 값들은 문자열, 숫자와 같은 단순한 데이터 타입에서부터 복잡한 객체에 이르기까지 Java안에서 어떤 형태로든 지원된다는 점이다. 이러한 점은 두개의 주요한 문제를 극복할 수 있게 한다. 복잡합 Java 객체를 값으로 저장하기 때문에 이러한 객체를 관계형 데이터 모델(저장소를 위해서 데이터베이스를 사용하는 다소 전통적인 애플리케이션과 같은 예)로 변환할 필요가 없게 된다. 더욱이, 유일하게 키 당 하나의 밸류를 저장할 수 있다는 외형적 제약은 실제로 전혀 제약이 아니다.

대형의 메모리 크기

위에서 소개된 대부분의 제품은 Java를 구현 언어로 사용하고 있다. Java는 메모리의 동적 할당을 위해서 RAM의 일부를 예약해 두고 사용한다. 이 예약된 메모리 공간을 Java에서 Heap이라고 한다. Java 애플리케이션을 통해 생성된 모든 실행 객체들은 Heap에 저장된다.

많은 양의 데이터를 사용하는 것은 두 가지 문제를 일으킨다.

  • 크기의 제약: 기본적으로 Heap의 크기는 128MB이지만 최근의 비즈니스 애플리케이션은 이러한 한계에 쉽게 다다른다. 일단 Heap이 가득차면, 새로운 객체는 생성될 수 없고 Java 애플리케이션은 곧 형편없는(nasty) 에러를 보여줄 것이다.
  • 성능:  Heap의 크기를 증가시키는 것은 가능하지만 이는 새로운 문제를 일으킨다. Heap이 4 기가바이트는 넘는 크기에 이르게 되면 Java는 애플리케이션이 느려지거나 심지어 일시적으로 멈추게 되는 메모리 관리와 관련된 심각한 문제를 내포한다. Java에는 가비지 컬렉터(Garbage Collector)라는 기능이 있어 주기적으로 Heap을 조회하여 각 객체가 여전히 유효하고 사용되고 있는지를 체크한다. 만약 그렇지 않으면 가비지 컬렉터는 객체를 제거하고 새롭게 가용한 공간을 모아 재배열한다. 즉 문제는 Heap의 크기가 커지면 가비지 컬렉터가 할 일이 많아지게 되고 결과적으로 성능 저하가 발생한다.

큰 은행에서 고객과 계좌 및 트랜잭션을 관리하는 Java 애플리케이션을 가지고 있다고 가정해보자. 우리는 IMDG가 애플리케이션이 모든 데이터를 메모리에 넣어둠으로서 상대적으로 느린 데이터베이스에 데이터를 저장하는 것과 달리 빠르게 저장과 접근을 가능하게 해준다는 것을 확인했다. 결합된 데이터의 양이 40기가바이트에 해당한다고 가정해 보자. 이 데이터를 Heap에 저장하는 것은 Java가 지니고 있는 메모리 관리 능력 성능 페널티를 고려할 때 단순하게 적용할 수 있는 것이 아니다.

아래 그래프는 데이터를 Heap에 저장할 때의 가비지 컬렉터의 정지 시간을 보여준다.

Terracotta의 BigMemory 제품은 이러한 제약을 극복하는 방법을 가지고 있다. 그것은 off-Heap 메모리(direct buffer)를 사용하는 것이다. 데이터는 Java의 Heap에 저장되는 것이 아니라 직접 가용한 내부 메모리(RAM)에 저장된다. 내부 메모리는 Java의 가비지 컬렉터의 관리하에 있지 않기 때문에 성능 페널티 문제가 발생하지 않는다. 성능의 차이가 다르다는 것을 아래 그래프에서 보는바와 같이 알 수 있다.

off-Heap의 사용은 몇가지 혜택을 갖는다.

  • Heap에 할당된 메모리 크기 만이 아니라 머신의 가용한 메모리를 다 사용할 수 있다. 이는 좀 더 많은 데이터를 메인 메모리에 저장하여 애플리케이션의 속도를 더할 수 있다.
  • 메인 메모리에 데이터를 저장하면서 Heap은 부담을 덜게 되고 결과적으로 가비지 컬렉터가 관리해야 하는 Heap의 크기가 줄어 Java 애플리케이션의 속도를 높일 수 있다.

클러스터링, 장애 극복 과 고가용성

지금까지 우리는 IMDG의 특징을 단일한 서버에 적용한 것으로 살펴보았다. 그러나 IMDG의 진정한 힘은 네트워킹과 클러스터링을 통해 데이터 복제, 클라이언트 간 데이터 동기화, 장애극복, 고가용성을 갖는다는 점이다. 이러한 혜택을 얻기 위해서는 서버들(서버군)의 클러스터를 인프라스트럭쳐의 백본으로 운영해야 한다. (아직도 홀로 IMDG 또는 off-Heap 캐쉬를 가지고 있는) 애플리케이션은 클러스터에 연결되어 그들의 데이터를 서로 다른 애플리케이션이나 클러스터와 공유, 복제, 백업할 수 있다.

다음의 그래프는 Terracotta의 BigMemory 를 사용한 일반적인 셋팅이다.

애플리케이션 서버의 캐쉬는 주로 Level 1 캐쉬로 분류 되면, 서버군(Server Array)의 데이터 케쉬는 Level 2 캐쉬로 분류된다. 데이터를 저장, 클러스터링, 동기화, 및 복제하는 시나리오는 다양하다. 모든 토픽을 다루는 것은 이 아티클의 범위를 벗어난다. 더 많은 정보를 원하는 사람은 선택에 따라 각 제품의 기술 문서의 도움을 받기를 바란다.

결론

빅데이터는 우리에게 새로운 도전을 던져준다. 무엇보다도 막대한 양의 데이터의 저장 및 접근은 우리에게 전통적 방법과 기술에 대해 다시 생각하게 해준다. 다음으로, 가용한 모든 데이터를 가지고 무엇을 할 것인가에 대한 질문이 있다. 마케팅, 금융과 기타 비즈니스에서의 잠재적 가치는 거대하다.

빅데이터를 잘 활용하기 위해서는 인메모리 데이터 그리드를 최상의 선택으로 고려해 볼 만하다. off-Heap을 사용하는 IMDG는 더욱 강력하며, 메모리와 성능 제약을 갖고 있는 Java 플랫폼의 특정한 한계를 극복할 수 있는 데이터 중심의 엔터프라이즈 애플리케이션을 가능케 한다.

대형 회사들이 만들어내며 저장하는 데이터의 양이 급격하게 증가하면서 데이터베이스는 종언을 맞이하게 될 것이다. 성능 페널티 없이 데이터의 접근하는 방법은 단순히 이루어지지 않는다. 이에 대한 답은 인메모리 데이터 그리드(IMDG)를 사용하는 것이다.

 

The Power of Events 내용 요약

power_of_events_book_cover_only

The Power of Events는 CEP(Complex Event Processing)이라는 개념의 기본서와 같은 책이다. 저자 David Luckham은 스탠포드에서 CEP를 연구하였고 CEP 아버지쯤으로 불리는 사람이다. 따라서 CEP를 연구하는데 있어서 이 책은 반드시 봐야할 책이다. 책의 구성은 크게 다음과 같이 2개의 파트로 나누어진다.

Part 1 A Simple Introduction to Complex Event Processing
Part 2 Building Solutions with CEP

전반부 파트1에서 챕터 1~4까지는 실제 엔터프라이즈에서의 프로세스를 IT 관점에서 조망하며 CEP가 어떤 의미를 지니는 지를 살펴보고 챕터5~7장까지는 좀 더 기술적으로 CEP의 기본 개념을 차근히 설명한다.

후반부 파트2에서는 복합이벤트 검출을 위한 EPL에 대한 이론적 설명부터 네트워크 구성, 구현 및 사례까지 빼곡히 담아냈다.

앞으로 이 책의 내용의 핵심을 요약할 예정이다.

Part 1 A Simple Introduction to Complex Event Processing

  1. The Global Information Society and the Need for New Technology
  2. Managing the Electronic Enterprise in the Global Event Cloud
  3. Viewing the Electronic Enterprise-Keeping the Human in Control
  4. Designing the Electronic Enterprise: 생략
  5. Events, Timing, and Causality
  6. Event Pattern Rules
  7. Building Personalized Concept Abstraction Hierarhcies

 

Complex Event Processing Wiki 요약 부분 번역

2013년 12월 26일 기준 위키피디아에 있는 Complex Event Processing에 대한 내용 번역입니다.

원문 PDF 다운받기

Event Processing
이벤트 처리(Event Processing)란 발생하는 일련의 이벤트에 관한 정보(혹은 데이터)의 흐름을 추적하고 분석(및 처리)하고, 이로부터 결과를 도출하는 방법이다. 복합 이벤트 처리(Complex Event Processing, 줄여서 CEP)는 좀 더 복잡한 상황을 제안하는 이벤트나 패턴을 추론하기 위하여 복수의 정보원으로부터 데이터를 결합하는 이벤트 처리 방법이다. CEP의 목표는 의미있는 이벤트(기회나 위협)를 도출하고 이러한 결과에 대해 가능한 빠르게 대응하는 것이다.

이러한 이벤트들은 세일즈리드(Sales leads), 주문서 및 소비자 서비스 전화 같은 조직의 여러 계층들 상에서 발생할 수 있다. 아니면 새로운 품목, 문자 메시지, 소셜미디어상의 포스트, 주식시장의 피드, 교통정보, 기상 정보 등 여러 종류의  데이터도 이벤트가 될 수 있다. 또한 측정값이 사전의 정의된 시간, 온도 등의 기타 값의 임계치를 넘었을 때 “상태의 변화”를 이벤트로 정의할 수 있다. 분석가들은 CEP가 실시간으로 패턴을 분석하고 비즈니스 관련 부서에서 IT 및 서비스 부서와 더욱 원활하게 의사소통할 수 있는 새로운 길을 조직에 제공할 수 있다고 주장한다. 이벤트에 관련하여 이용가능한 막대한 양의 정보들을 때로 이벤트 구름(event cloud)으로 표현된다.

개념적 설명
유입되는 수천의 이벤트 가운데, 예를 들면 모니터링 시스템은 다음의 3가지 정보를 동일한 정보원으로부터 받을 수 있다.

  1. 교회의 종이 울린다.
  2. 턱시도를 차려입은 남성과 넘실거리는 하얀 가운을 걸친 여성의 외모
  3. 공기 중으로 음식냄새가 흐른다.

이러한 이벤트들로부터 모니터링 시스템은 아마도 복합이벤트로 “결혼식”을 도출할 것이다. CEP는 기술로서 다른 이벤트들(1번부터 3번)을 분석하고 연관시키면서 복합이벤트를 발견하는 것을 돕는다.

CEP는 다음의 다양한 기술들을 기반으로 한다.

  • 이벤트 패턴 감지(Event-pattern detection)
  • 이벤트 추상화(Event abstraction)
  • 이벤트 필터링(Event filtering)
  • 이벤트 조합 및 변형(Event aggregation and transformation)
  • 이벤트 계층 모델링(Modeling event hierarchies)
  • 이벤트 관계 감지(Detecting relationships such as causality, membership or timing between events
  • 이벤트 기반 처리 추상화(Abstracting event-driven  process)

상용 CEP 어플리케이션이 다양한 산업군에서 존재하며 알고리즘을 활용한 주식거래, 신용카드 사기, 비즈니스 활동 모니터링 및 보안 모니터링 등을 포함한다.

역사
CEP 영역은 이산 이벤트 시뮬레이션, 활성 데이터베이스 영역과 일부 프로그래밍 언어에 그 뿌리를 드고 있다. 산업군에서의 활동은 1990년대의 연구프로젝트의 흐름을 따라 시작되었다. 범용적인 CEP 언어에 대한 길을 포장한 첫 프로젝트와 David Luckham이 주도한 스탠포드 대학의 Rapide 프로젝트에 따라서 3개의 다른 연구프로젝트가 병행되어왔다. K. Mani Chandy가 지도하는 Caltech의 Infospheres, John Bates가 이끄는 캠브리지대학의 Apama와 Opher Etzion의 IBM Haifa 연구소의 Amit이 있다. 상업용 제품들은 상기의 프로젝트 및 후속 연구 프로젝트에서 개발된 개념에 종속된다. 커뮤니티에서도 Event Processing 기술 그룹 및 후에는 ACM DEBS 컨퍼런스를 통해서 조직한 이벤트 처리 심포지움들을 통해 시작되었다. 커뮤니티의 기여 중 하나는 이벤트 처리 기준의 생산이었다.

관련 개념
CEP는 운영 인텔리전스(Operational Intelligence, OI) 솔루션에서 라이브 피드와 이벤트 데이터에 대해서 쿼리 분석을 실행함으로 비즈니스 운영에 대한 통찰력을 제공하기 위하여 사용된다. OI 솔루션은 실시간 데이터를 사용하여 현재 상황에 대한 분석과 통찰력을 제공하기 위해서 과거 데이터를 수집하여 연관시킨다. 데이터의 다양한 소스는 다양한 조직의 데이터 사일로로부터 결합된어 현재 정보를 활용하는 공통된 운영그림을 제공한다. 실시간의 통찰력이 큰 가치를 가지고 있든 없든, OI 솔루션은 정보와 필요를 제공하는데 응용될 수 있다.

네트워크, 시스템, 어플리케이션, 서비스 관리에서 사람들은 대신 주로 이벤트 연관을 참조한다. CEP 엔진으로서 이벤트 연관 엔진은(event correlator) 다량의 이벤트를 분석, 가장 중요한 이벤트를 정확히 집어서 조치를 취힌다. 그러나 대부분의 시스템은 새롭게 추론된 이벤트를 생성하지는 않는다. 대신에 그들은 고수준의 이벤트를 저수준의 이벤트와 연관시킨다.

추론 엔진(예를 들면 룰 기반의 추론 엔진)은 전형적으로 인공지능 분야에서 추론된 정보를 생산한다. 그러나 추론엔진은 복잡한 (추론된) 이벤트의 형태로 새로운 정보를 생산하지는 않는다.


생략…

타입
대부분 CEP 솔루션과 개념은 두 개의 메인 카테고리로 분류할 수 있다

  1. 집합 지향 CEP(Aggregation-oriented CEP)
  2. 감지 지향 CEP(Detection-oriented CEP)

집합 지향 CEP 솔루션은 시스템에 유입되는 이벤트 데이터에 대해서 그 반응으로 온라인 알고리즘을 실행하는데 집중된다. 간단한 예로 인바운드 이벤트에 대해서 지속적으로 평규기반의 데이터를 계산하는 것이 있다.

감지 지향 CEP 는 이벤트 패턴 혹은 상황이라고 불리는 이벤트의 조합을 감지하는 것에 집중되어 있다. 감지 상황의 간단한 예로 구체적인 이벤트의 순서를 찾는 것이다.

현재 많은 어플리케이션이 두 방식을 혼용해서 사용한다.

금용 서비스 관련
생략…

시계열 데이터베이스와의 통합
시계열 데이터베이스는 시간을 기준으로 구성된 데이터를 다루는데 최적화된 소프트웨어 시스템이다. 시계열은 유한하거나 무한한 데이터 아이템의 나열이며 각각의 아이템은 타임스탬프와 연관되어 그 순서가 내림차순이 아닌 방식으로 나열된다. 시계열 데이터는 조종 틱(tick)으로 불리기도 한다. 타임스탬프는 반드시 오름차순이지도 않은데 그 이유는 실제로 금용 데이터를 다루는 일부 시스템의 시간 측정 정밀도가 매우 낮아(밀리, 마이크로 혹은 심지어 나노 세컨드 급), 연속된 이벤트들이 동일한 타임스탬프를 가지게 될 수도 있기 때문이다.

시계열 데이터는 전형적으로 복합 이벤트 처리와 관련된 분석에 과거 문맥을 제공한다. 이는 금융권과 같은 모든 수직적 산업에 적용 가능하고 협력적으로 BPM과 같은 다른 기술들과 함께 적용될 수 있다.

미래 가격의 움직임의 통계적 임계치를 결정하기 위해서 과거 가격 변동성을 이해할 필요가 있는 금융권의 시나리오를 고려해보자. 이는 거래 모델과 매매 비용 분석 모두에 매우 유용하다.

CEP 분석의 이상적인 사례는 과거 시계열과 실시간 스트리밍 데이터를 단일한 시간연속체로 보는 것이다. 어제, 지난주 혹은 지난 달에 발생한 것은 단순이 오늘 그리고 미래에 일어날 것의 확장이다. 예로들면, 현재 시장의 크기와 과거의 크기를 비교할 수 있고, 매매실행 로직을 위한 가격와 변동성도 포함시킬 수 있다. (마지막 문장 생략)