Quiz: Dynamic tables and changelogs

사용자별 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 이 됐을 때