Apache Flink

1. Apache Flink
   • streaming dataflow 엔진을 기반으로 한 스트리밍&배치 플랫폼
   • streaming mode: native 방식이 아니기 때문에 스트림 처리에 대해 spark 보다 low latency를 보인다
     * spark는 micro-batch 방식을 통해 스트림 데이터 처리
   • exactly-once 보장

 

• low-level building block
  stateful and timely stream processing을 제공
  process function을 통해 datastream API에 임베디드 되어 있음 ← 이쪽은 많은 유저에게는 필요가 없을 것이고, core API를 많이 쓸 듯하다.
• core API
  datastream API (bounded/unbounded stream) / dataset API (bounded data set)
  datastream은 스트림 데이터일 때 사용하고 dataset은 배치에서 사용되는 것 같다.
  둘 다 immutable 한 속성 (변경되지 않음)
  transformation, join, aggregation, window, state와 같은 데이터 프로세싱을 위한 기능들을 제공한다.
• table API
  stream을 표현하는 테이블을 동적으로 변경할 수 있는 확장된 관계형 모델.
  테이블에는 스키마가 연결되어 있으며 API는 select, project, join, group by, aggregate 등의 연산자 제공
• SQL
  가장 높은 단계의 추상화이며, Table API와 유사하지만 sql 쿼리로 표현한다.
  table API에 정의된 테이블에서 이 sql 쿼리가 실행될 수 있다.

 

Stream dataflow

  input stream → source

  operator → transformation

  output stream → sink                    로 표현

(카프카, 키네시스 등 메시지 큐나 분산로그에서 real-time data를 가져올 수 있음. 그 경우 flink가 consumer)

→ source로 스트림 데이터를 받아 여러 transformation으로 데이터를 가공하고 sink로 데이터를 처리(저장)하는 streaming dataflow

* lazy evaluation

spark와 마찬가지로 sink 메소드가 실행되기 전까지는 실제 연산이 수행되지 않고 sink가 실행되는 순간 지정된 transformation들이 실행됨

 

Parallel dataflows

하나 이상의 stream partition → stream

하나 이상의 operator subtasks → operation

operator substasks는 독립적이며, 다른 쓰레드에서 실행될 수 있기 때문에 여러 쓰레드에서 병렬적으로 분산 처리를 할 수 있다.

위 그림처럼 parallelism을 설정할 수 있음 → 병렬로 실행되는 tasks들은 각각의 쓰레드에서 실행되어 처리된다.

1:1 stream: source와 map()연산자 사이처럼 element의 파티션과 순서 유지

→ map()[1]은 source[1]에 의해 생성된 것과 동일한 순서 동일한 요소로 보게 됨

redistributing stream: 두번째 파티션처럼 전 단계의 모든 subtasks로부터 데이터를 받아와서 transformation. ex) keyBy(), broadcast(), rebalance() 처럼 다시 분할

 

Stateful stream processing

flink의 operation은 stateful 할 수 있다 (특정 operation이 stateful할 수 있음) → 상태 저장이 가능 → 한 이벤트가 처리될 때 이전에 발생한 모든 이벤트의 누적효과에 따라 다른 결과를 낼 수 있다.

stateful operator의 parallel instances는 sharded key-vallue로 저장되어 있음

위 그림에서 세 번째 operation이 stateful하다고 한다면, key-value 형태로 저장되기 때문에 전 단계의 subtasks들과 fully network shuffle이 발생한다.

 

Timely stream processing

스트림 데이터 처리를 위해서는 데이터가 전달되는 순서보다 이벤트가 발생한 순서에 집중해야 함

ex) 특정 이벤트 패턴을 검색할 때 (지금까지 발생한 이벤트 시퀀스의 저장이 필요) 등

→ flink에서는 데이터를 처리하는 시스템의 클락이 아니라, 데이터 스트림에 기록된 이벤트 timestamp를 이용

 

Distributed execution

flink에는 두 가지 프로세스가 있음

• master process (job manager)
  task의 스케쥴링, 체크포인트, 리커버리 담당
  worker들을 관리
• worker process (task manager)
  task를 실제로 실행

standalone, resource framework(yarn, mesos etc) 환경에서 실행 가능

TaskManager

JVM 프로세스 단위로 동작

한 worker에는 여러개의 Task Slot이 있으며, Task Slot에는 여러 개의 쓰레드가 있으며, 각 쓰레드로 subtasks가 수행된다.

Time slot끼리는 worker 내의 리소스를 나누어서 관리 → slot별로 개별적인 리소스를 사용하여 task를 실행

→ slot의 개수는 cpu core 개수로 지정하는 것이 좋다.

한 쓰레드에 한 Task가 실행되지만 source/map처럼 operator chain이 가능한 경우 한 쓰레드에서 실행

 

Window

스트림 데이터는 시작과 끝이 존재하지 않는 unbounded data → 집계와 같은 연산을 수행하기 위해 시작과 끝을 정해주어야 함

window: 시작과 끝을 일정한 룰에 따라서 정해진 연산을 수행하기 위해 사용

빨간 네모 한 칸이 한 window

Tumbling Window

고정된 시간 단위로 데이터의 중복 처리 없이 window를 설정하는 방식

window size를 5초로 설정했다면 5초 간격으로 window가 분리됨

Sliding Window

N시간 크기의 window를 M시간 씩 slide 해서 window를 정하는 방식.

데이터의 중복 처리 허용

M시간 단위의 데이터가 중복처리되고 있다.

Session Window

session gap을 설정

일정 기간동안 반응이 없는 경우 세선 시작부터 반응이 없는 시간가지의 데이터를 하나의 window size로 처리

→ 반응이 없는 시간 >= session gap이 되면 다른 window로 분할

session gap을 5초로 설정: 5초동안 데이터가 들어오지 않으면 서로 다른 window로 쪼갬

하나의 window에서 처리되는 element의 개수가 매우매우 달라질 수 있다.

 

Fault Tolerance

sparks는 lineage를 이용해 전체 과정을 다시 계산함으로써 내고장성 보장

flink는 checkpoint를 설정하고 checkpoint 이후로 datasource에서 replay하는 방식으로 내고장성 보장

처리되는 stream 중간에 checkpoint barrier를 끼워넣음 (job manager가 요청)

sink에 barrier가 도착하면 barrier 이전의 데이터에 대해 연산이 완료된 것응로 간주,  source로 해당 barrier에 대해 ack를 보냄 ( source는 ack 받은 barrier 이전의 데이터에 대해서 삭제 )

만약 스트림이 처리되는 중간에 fault가 발생하면 ack를 받은 barrier 이후의 데이터부터 다시 처리 

→ 모든 레코드마다 replay하지 않기 때문에 빠른 성능

→ exactly-once 보장