[Flink] 플링크의 스냅샷 생성

오늘 기억에 남는 것!!  -> 플링크 스냅샷에 아직 반영되지 않은 상태 수정은 임시적인 것으로 간주해야 한다

 

ABS 배경

1. 분산 스트리밍 프로세스에서 잠재적인 장애를 처리하려고 찍는 snapshot의 성능상 문제로 Asynchronous Barier Snapshotting (ABS) 이 나옴

-> 데이터플로우에 minimal record log를 적용

-> ABS 를 Flink 에 적용

 

2. 기존에 exactly one 에는 동기(synchronous) 스냅샷을 이용해서 실행을 멈춰야 되는 단점이 있으며, 처리되기 전의 메세지도 스냅샷에 포함된다는 것도 단점이었음

 

3. 그 후에 나온 방법들 (checkpointing, 비동기로  스냅샷 찍기)에 대한 아이디어를 확장함

 

Apache Flink

1. Flink는 배치랑 스트리밍으로 구성된 스트리밍 작업을 균일하게 처리하는 런타임 엔진임

2. Flink는 복잡한 스트리밍 분석 job을 DataStreams 를 통해 가능하게 한다.

-> DataStreams은 메세지 큐 같은 외부 소스에서 생성되고, map, filter, reduece 같은 연산을 사용하여 새로운 DataStreams를 만든다 . 모든 연산은 병렬로 구성되어 각각 다른 파티션에서 처리되어 분산 작업을 가능하게 한다.

3. Snapshot 을 통해서 특정 실행 시점에서 재시작할수 있는 컴퓨팅 환경에 필요한 모든 정보를 저장함

4. Snapshot 의 속성에는 Termination과 Feasibility가 있음

-> Termination 은 시작된 스냅샷 알고리즘이 언젠까는 끝나게 해줌

-> Feasibility는 스냅샷이 찍어지는 동안 정보가 유실되지 않게 보장해주고,스냅샷 리코드의 순서를 보장해준다(저장되는 순서와 보내지는 순서)

5. stage 는  barrier maker를 통해 연속적인 dataflow 실행을 따라간다. barrier maker는 data stream 에 주입되어 있다

6. stage의 task 들이 실행중인 stage를 가리키는 barrierr를 받으면 스냅샷은 계속 쌓인다.

7. 부분적인 복구 방침(partual graph recovery scheme, 나의 해석) 은 TimeStream 과 비슷하게 upstream task 의존성만 리스케쥴링을 함으로써 가능하다

-> exactly one  를 제동하게 위해서 downstream 의 record들은 무시되어야 한다

-> 이를 달성하기 위해 sequence number로 record를 마킹한다

8. operator의 상태를 구분짓기 위해서 OperatorState 인터페이스를 사용하여 상태를 업데이트하고 checkpoint를 찍는다 

-> Flink는 offset 이나 aggregation같은 stateful runtime operator 를 위한 OperatorState 를 제공한다

9. 스냅샷 Coordiation은 stage barrier를 주입해서 global state를 지속시킨다

-> 인메모리 DB에 저장된 최근 global snapshot 이 operator에 저장된다

 

 

 

Reference:

- 스트리밍 시스템 (타일러 아키다우 외)

- Lightweight Asyncronous Snapshots for Distributed DataFlows (논문 )