Apache Flink — 스트림을 엔진으로 돌린다 · 동적 테이블과 변경 로그 · 测验
퀴즈: 동적 테이블과 변경 로그
6道题. 完成作答后会显示正确答案和解析。
사용자별 COUNT(*) 를 스트리밍으로 돌렸다. 이미 2번 클릭한 사용자의 세 번째 클릭이 들어오면 결과 로그에 무엇이 나오나?
- +I 한 줄 — 새 값 3 을 추가한다
- -U 로 옛 값 2 를 철회하고 +U 로 새 값 3 을 낸다
- -D 로 옛 행을 지우고 +I 로 새 행을 넣는다
- 아무것도 없다 — 창이 닫힐 때 한 번에 낸다
클릭 100건이 사용자 10명에게서 왔다. 사용자별 COUNT 를 기본 설정·병렬도 1 의 스트리밍으로 돌리면 변경 로그는 몇 줄인가?
- 100줄 — 입력 한 행마다 결과 한 줄
- 10줄 — 사용자마다 최종 값 한 줄
- 190줄 — 새 사용자 10줄에, 나머지 90건마다 -U·+U 두 줄
- 200줄 — 입력 한 행마다 -U·+U 두 줄
`EXPLAIN CHANGELOG_MODE` 로 본 필터 질의(`WHERE dwell > 60`)의 Calc 노드가 changelogMode=[I] 다. 이 뜻은?
- 이 노드는 추가만 내보내므로 추가 전용 싱크에도 그대로 쓸 수 있다
- 이 노드는 상태를 들고 있어 입력이 바뀌면 결과를 고친다
- 이 노드는 배치 모드에서만 동작한다
- 이 노드는 결과를 업서트로 보내므로 키가 필요하다
사용자별 COUNT 를 filesystem 싱크에 INSERT 했더니 'doesn't support consuming update changes' 로 거절됐다. 결과를 파일에 남기는 올바른 방법은?
- table.dml-sync 를 켜서 잡이 끝날 때까지 기다린다
- 싱크 표에 PRIMARY KEY 를 선언하면 파일 싱크가 덮어쓰기를 한다
- TO_CHANGELOG 로 변경 종류를 열로 꺼내 모든 행을 추가로 바꾼 뒤 쓴다
- 병렬도를 1 로 낮추면 갱신이 사라져 파일에 쓸 수 있다
같은 GroupAggregate 가 print 싱크 앞에서는 [I,UB,UA], PRIMARY KEY 를 둔 싱크 앞에서는 [I,UA] 로 계획됐다. 왜 다른가?
- 키가 있는 싱크는 상태를 대신 들어 주므로 집계가 상태를 버린다
- 옵티마이저가 싱크가 받을 수 있는 변경 종류를 거슬러 올라가며 정하는데, 키로 덮어쓰는 싱크는 갱신 전 값이 필요 없다
- print 싱크는 배치 모드로 돌기 때문에 UB 가 붙는다
- PRIMARY KEY 를 선언하면 Flink 가 중복 행을 검사해 걸러 준다
클릭 수별 사용자 수(집계 위의 집계) 로그에 -D 가 나왔다. 어떤 순간인가?
- 원천 파일에서 행이 지워졌을 때
- 상태 TTL 이 지나 오래된 키가 지워졌을 때
- 창이 닫혀 중간 결과를 비울 때
- 사용자가 다른 칸으로 옮겨 어떤 칸의 사용자 수가 0 이 됐을 때