빅데이터 처리

# 배치 처리(batch_processing)

일괄 처리(batch_processing)란 컴퓨터 프로그램 흐름에 따라 순차적으로 자료를 처리하는 방식을 의미한다. 일괄처리 방식은 사용자와 상호작용하는 것이 초기에는 불가능했지만, 운영체제가 발전하면서 프로그램 입출력을 통해 상호작용화는 것이 가능해졌다.
배치 처리 방식은 간단히 말하면 일정기간 또는 한정된 데이터를 모아두었다가 한 시점에 순차적으로 처리하는 방식이다. 맵리듀스(Mapreduce) 기법인 하둡 또한 배치 처리 방식 중 하나이다. 배치 처리 방식은 일정 기간의 데이터를 일괄 처리하기 때문에 실시간 데이터는 조회하기 힘들다는 단점이 있다. 이런 단점을 극복하기 위해 최근에는 실시간 분산 쿼리나 스트리밍 기법이 많이 연구되고 있다.

출처 :https://ko.wikipedia.org/wiki/%EC%9D%BC%EA%B4%84_%EC%B2%98%EB%A6%AC

실시간 분산 쿼리는 클러스터를 구성하는 노드가 각자 쿼리를 처리하게 해 한 번에 처리할 데이터의 크기는 작게 하면서 이를 병렬 처리해 응답 시간을 실시간 수준으로 높이는 방식이다.

스트리밍 처리는 끊임없이 들어오는 데이터를 유입 시점에 분석해 원하는 데이터 뷰로 미리 만드는 방식이다. 이 방식은 CEP(complex event processing)이라고 부른다.

분산 쿼리의 기본 동작 방식

분산 환경에서 데이터를 단일 부로 제공하는 것은 어렵다. 파티셔닝과 셔플은 기본적인 분산 처리 방식을 이다.

• @파티셔닝
  • 파티셔닝은 특정 키를 기준으로 이 테이블을 여러 노드로 분할해 저장하는 방식이다. 키를 범위로 나눠 저장하거나(range partitioning), 키 값을 해시 키로 사용해 수평적으로 데이터를 나눠 저장할 수 있다(hash partitioning). 파티셔닝은 노드 간의 키 중첩을 없애기 때문에 각 노드 에서 파티션 키를 조인 키로 쓰는 경우 독립적인 조인 처리가 가능하다.
• @셔플
  • 만약 파티션키로 조인하는 것이 아닌 다른 키로 조인해야 한다면, 데이터를 조인 키 단위로 모으는 재분할(re-partitioning) 과정이 필요하다. 이 과정을 셔플이라 하고, 셔플은 노드 간 데이터 전송을 많이 발생시키므로 부담이 된다. 만약 조인 할 테이블이 작은 크기의 테이블이라면 , 굳이 셔플하지 않고도 그 테이블만 다른 모든 노드로 복제한 다음 각 노드에서 조인할 수 있다. 이러한 방식을 broadcast Join이라고 한다.

데이터 집계(aggregation)는 두 단계로 나눌 수 있다. 개별 노드에서 각자 결과를 집계하고 그 결과를 모아 전체 결과로 집계한다. 그루핑(Group BY) 또는 정렬(Order By)도 집계 처리와 같이 두 단계로 수행한다. 각 노드의 수행 결과를 모아 처리하는 방식은 map reduce와 유사하다.

스트리밍 방식

스트리밍 데이터는 시간에 따라 지나가 버리지만 쿼리는 시점에 관계없이 동일한 조건으로 요청할 수 있다. 혹은 클러스터 내 노드 중 하나에 장애가 발생하더라도 쿼리를 다시 수행을 마쳐야 할 수도 있다. 계속 들어오는 데이터를 지속적으로 쌓아 두려면 많은 리소스가 필요한데, 리소스의 제약이 있다면 처리를 다음과 같은 방식으로 처리를 할 수 있다.

lineage tracking

분산 처리를 위한 노드 토폴로지에서 데이터는 일련의 이벤트처럼 흘러 다닌다. 최초에 입력된 데이터는 여러 노드에 걸쳐 처리된 후 최종 결과를 데이터베이스에 저장한다. 노드는 입력된 데이터를 특정 조건으로 필터링하거나, 이전 노드에서 온 데이터를 합치거나(merging), 그루핑(grouping)하거나, 정렬(ordering)하거나 집계(aggregation)할 수 있다. 이런 처리 과정 중 특정 노드에서 수행에 실패하면 이를 검출하고 다시 수행해야 한다.
lineage tracking은 각 이벤트마다 이진 값 형태의 시그니처(signature)를 부여한다. 어떤 노드로 이벤트를 보내면 다운스트림 노드는 이벤트를 처리한 후 그 이벤트의 시그니처를 XOR 연산하고, 결국 이벤트가 최종 목적지에 도달하면 그 시그니처 값은 0이 된다. 이 시그니처는 이벤트 ID별로 테이블에 유지하며 주기적으로 확인한다. 만약 유입된 지 일정 시간(timeout)이 지난 이벤트의 시그니처가 0이 아니라면, 수행 실패로 간주하고 데이터 유입 지점부터 재수행 한다. 이 장애 검출 방법은 중앙에서 관리할 필요가 없는(decentralized) 방식으로 이벤트 처리가 최소 한 번은 수행됨을 보장한다. 하지만 두 번 이상도 수행될 수 있기 때문에 트랜잭션 처리는 어렵다.

state checkpointing

checkpoint란 보통 특정 시점의 상태(state)를 영구 저장하는 것을 의미한다. 데이터를 변경할 때마다 영구 저장하지 않는다면, 시점을 복구하기 위해서는 변경 시작부터 복구할 시점까지 수행한 내용을 모두 재수행(redo)해야 한다. 이때, 재수행 하는 양을 줄이기 위해 중간중간 상태를 영구 저장해 두고, 저장 시점 이후부터 재수 행해도 된다. 배치 단위의 트랜잭션 처리에서도 이런 처리가 필요하다. 배치 처리가 상태를 가진다면(stateful), 즉 이전의 배치 결과를 보고 현재 배치를 처리한다면, 시점 복구를 위해서는 상태 정보가 필요하다. 예를 들면 카운트 계산 방법으로 기존 카운트에 현재 데이터 윈도에 대한 카운트만 증가시키는 경우가 있다. 복구를 하려면 시작부터 재수행을 해야 하는데, 이때 계산할 것이 많아 리소스가 많이 필요할 수 있다. 따라서, 배치 처리를 커밋할 때 계산 상태(computational state)도 같이 저장한다. 즉, 그 시점에 각 노드별로 메모리에 적재된 데이터 상태를 HDFS 같은 곳에 영구 저장한다. 하지만 상태 정보가 많다면 효율적으로 동작하지 않을 수 있다. 이런 경우 상태 변경을 모두 로그(transaction log)로 저장했다가 수행해서 특정 상태로 되돌릴 수 있다.


출처 : https://d2.naver.com/helloworld/694050

 

# 실시간 처리(Real_time Processing)

실시간 처리 시스템은 처리할 데이터의 입력과 동시에 실시간으로 처리하여 즉시 응답해주는 데이터 처리 방식이다. 즉, 사용자가 처리하여야 할 문제를 해경할 수 있도록 해 주는 데이터 처리 방식이다. 실시간 처리 시스템의 장점으로 데이터가 발생하면 신속하게 즉시 처리가 된다. 항상 최신의 데이터를 유지할 수 있다. 그리고 데이터 처리의 전체적인 시간이 단축되어 시스템 이용자가 즉시 응답을 주고받을 수 있다. 그러나 단점으로 부수적인 통신 장비들이 요구되어 유지보수가 어렵고 시스템에 이상이 생겼을 경우 복구하기 힘들다.

• Near_Real_Time : 초단위 수준의 지연시간 보장
• Real_Time : 밀리세컨드 (1000분의 1초) 수준의 데이터 처리 보장
• Real Real _Time : 마이크로 세컨드(100만분의 1초) 수준의 데이터 처리 보장