배치 처리와 실시간 처리

배치 처리

배치 처리 프로그램 특징

- 사용자와 상호작용하지 않음

- 대량의 data를 처리하며

- 일련의 작업 묶음으로 이뤄져있다.

배치 프로그램의 주기

- 정기적으로 작업을 수행하거나

- 조건을 만족하는 이벤트가 발생 할 때 실행

- 사용자의 요구 조건에 따라 배치를 수행하는 경우는 on-demand 배치라고한다.

on-demand 배치는 일반 배치프로그램처럼

테이블 전체에 대해 수행하거나 하지는 않고

제한적인 범위에 대해 수행한다.

예를 들어, 일반 사용자의 on-demand 배치가 

전체 거래량에 대해 정산을 하지는 않는다. 

배치 프로그램의 튜닝

대용량 배치 프로그램 튜닝에서 중요한 것은

전체 처리 속도를 낮추는 것이다.

기업에서는 배치 프로그램을 관리하는 

"배치 윈도우"라는 설계도, 문서가 있는데

이는 배치 프로그램들의 튜닝과 플랜을 짜는데 도움이 된다.

일반적으로 배치 프로그램은

dbms 상에서 수행되는 일련의 sql 작업들로 구성되며

이 sql문의 튜닝이 전체 처리 속도에 큰 영향을 미친다.

배치 프로그램 구조

이 sql 작업들은

- one sql  = 하나의 sql문으로 전체 프로세스를 짜는 것

- 각 언어 구현체의 데이터베이스 커서를 사용하여 루프를 돌면서 실행한다.

- one sql보다 성능적으로 권장되는 방법은

one sql을 여러 sql 집합으로 쪼개서 단계적으로 실행하는 것이다.

commit시점이나 횟수가 완전 동일한 로직이라는 가정하에 

one sql이 curosr loop보다 더 간편하고 관리하기가 용이하다고 생각한다.

배치 관리 프로그램 - .sh - .py - sql (1단계)

                             - .sh - .py - sql (2단계)

                             - .sh - .py - sql (3단계)...

배치 관리 프로그램에 shell 스크립트를 등록하여

cronjob을 연동하여 사용한다.

Hadoop

구글의 하둡 도구를 보면 배치 시스템에 알맞는 기능을 제공하고 있다.

배치 처리는 즉시 결과가 필요한 작업이 아니기 때문에

분산되어 저장된 데이터 볼륨에 대해 병렬적으로 장기적인 작업을 실행할 수있다.

파일 시스템으로 HDFS를 사용하는데 Hadoop에 데이터가 입력되면

HDFS가 데이터와 파일 처리를 하고

맵리듀스 모델로 데이터를 처리하고 변환하는 작업을 한다.

실패한 작업에 대한 내결함성과 탄력성을 제공한다.

이 부분에 대해 어떤 소프트웨어적인 방식의 메커니즘을 쓰는지는

더 알아보지 못했다.

아래 실시간처리에서도 나오겠지만

쓰임에 따라 zookeeper와 같은

Hadoop 아키텍쳐에서의 도구와 Kafka에서의 도구가 서로 겹칠수도 있다.

실시간처리

실시간 처리 아키텍쳐는 

크게 (수집)-(데이터흐름 관리)-(처리)-(저장소)의 형태로 구성되며

각각의 파트마다 다른 제품이 쓰인다.

배치 프로세스의 긴 turn-around를 기다릴 수 없는 애플리케이션,

실시간에 근접한 결과가 나와야하는 애플리케이션에 쓰인다.

Linkedin 또한 hadoop기반의 빅데이터 처리에서 apache kafka로 넘어오게 되었다.

서비스 구성 및 조정 : zookeeper

분산 시스템에는 수직적 확장 방식에서는 나타나지 않는 문제들이 발생한다.

1. 상태 동기화 문제

2.시간 동기화 문제

zookeeper, etcd, raft는 위 두 문제를 해결하는 제품이다.

1. 상태 동기화

분산 시스템 관리를 위해서는

전체 시스템에 대한 상태와

개별 시스템에 대한 상태들이 공유돼야한다.

상태에는 여러 정보가 있는데

- master로 작동하고있는 서버의 정보

- 구성의 정확성

- 조정 결과의 유효성

등을 포함한다,

상태를 공유하기 위해서는 동시성이 요구되며

group a에 system a, b, c

group b에 system d, e

두 group간 연결이 유실되면 split brain 문제가 발생하는데

강등 전략과 정족수 알고리즘을 사용하여 해결한다.

2. 시간 동기화

하드웨어 시간은 세월이 지날수록 밀린다.

후행 이벤트 timestamp - 선행 이벤트 timestamp > 0, 양수의 값이 나와야 정상이지만

최악의 경우 

a 시스템에서 발생한 선행 이벤트가,

b 시스템에서 발생한 후행 이벤트보다 늦게 도달하여

b 이벤트 timestamp - a 이벤트 timestamp < 0, 음수의 값이 나올 수도 있다.

NTP, 네트워크 타임 프로토콜을 이용해 동기화를 하지만

복잡한 인증 Gateway를 통과하는 경우 딜레이가 발생한다.

여러 장비들에 걸친 분산 상태를 일관되게 관리하는 알고리즘

Paxos, Multi-Paxos 알고리즘을 사용하여 해결한다.

분산 데이터 흐름 : kafka, flume

- 최소 한 번 전달을 보장하고

- n+1 문제를 해결하는 제품

kafka, flume이 있다.

만약 처리 단계에서 이전 단계보다 2배 이상의 시간이 소요되는 경우

2배 이상의 작업 유닛을 할당한다.

데이터 처리 : storm, samza

Twitter에서 개발된 storm

linkedin에서 개발된 비교적 최신 samza가 있다.

Storm을 기준으로 설명한다.

dag topology로 구성하거나

트라이던트로 구성할 수 있다.

spout = 데이터소스

bolt = 계산 유닛

topology = 계산을 위한 spout와 bolt의 연결로 이루어진 그래프 형태의 구성

기본적으로 비순환 방식으로 구성하나

순환 구성의 경우 topology를 따라 무한히 흐른다.

worker node에 supervisor가 위치하고

supervisor에는 local task ( = spout or bolt)가 다수 있다.

님버스는 cluste 내worker의 spit, bolt로 task를 분산하며

슈퍼바이저를 통해 처리한다.

config파일에 주키퍼 서버, 님버스 서버, 전송 메커니즘의 정보를 기입한다.

저장소 : 애플리케이션에 따라 선택

실시간 처리 아키텍쳐가 차지하는 메모리를 데이터 저장소로 쓸 수도 있지만

- 데이터는 일정시간 유지돼야하며 이는 메모리에서 전부 감당할 수 없다.

- 운영 정지시 조치가 어렵고

- 장기적인 추세를 분석하려면 어쨌든 장기 저장소가 필요하다.

   rdbms, nosql, cloud warehousing 등