퀴즈: 동적 테이블과 변경 로그

6문항. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. 사용자별 COUNT(*) 를 스트리밍으로 돌렸다. 이미 2번 클릭한 사용자의 세 번째 클릭이 들어오면 결과 로그에 무엇이 나오나?

   1. +I 한 줄 — 새 값 3 을 추가한다
   2. -U 로 옛 값 2 를 철회하고 +U 로 새 값 3 을 낸다
   3. -D 로 옛 행을 지우고 +I 로 새 행을 넣는다
   4. 아무것도 없다 — 창이 닫힐 때 한 번에 낸다

2. 클릭 100건이 사용자 10명에게서 왔다. 사용자별 COUNT 를 기본 설정·병렬도 1 의 스트리밍으로 돌리면 변경 로그는 몇 줄인가?

   1. 100줄 — 입력 한 행마다 결과 한 줄
   2. 10줄 — 사용자마다 최종 값 한 줄
   3. 190줄 — 새 사용자 10줄에, 나머지 90건마다 -U·+U 두 줄
   4. 200줄 — 입력 한 행마다 -U·+U 두 줄

3. `EXPLAIN CHANGELOG_MODE` 로 본 필터 질의(`WHERE dwell > 60`)의 Calc 노드가 changelogMode=[I] 다. 이 뜻은?

   1. 이 노드는 추가만 내보내므로 추가 전용 싱크에도 그대로 쓸 수 있다
   2. 이 노드는 상태를 들고 있어 입력이 바뀌면 결과를 고친다
   3. 이 노드는 배치 모드에서만 동작한다
   4. 이 노드는 결과를 업서트로 보내므로 키가 필요하다

4. 사용자별 COUNT 를 filesystem 싱크에 INSERT 했더니 'doesn't support consuming update changes' 로 거절됐다. 결과를 파일에 남기는 올바른 방법은?

   1. table.dml-sync 를 켜서 잡이 끝날 때까지 기다린다
   2. 싱크 표에 PRIMARY KEY 를 선언하면 파일 싱크가 덮어쓰기를 한다
   3. TO_CHANGELOG 로 변경 종류를 열로 꺼내 모든 행을 추가로 바꾼 뒤 쓴다
   4. 병렬도를 1 로 낮추면 갱신이 사라져 파일에 쓸 수 있다

5. 같은 GroupAggregate 가 print 싱크 앞에서는 [I,UB,UA], PRIMARY KEY 를 둔 싱크 앞에서는 [I,UA] 로 계획됐다. 왜 다른가?

   1. 키가 있는 싱크는 상태를 대신 들어 주므로 집계가 상태를 버린다
   2. 옵티마이저가 싱크가 받을 수 있는 변경 종류를 거슬러 올라가며 정하는데, 키로 덮어쓰는 싱크는 갱신 전 값이 필요 없다
   3. print 싱크는 배치 모드로 돌기 때문에 UB 가 붙는다
   4. PRIMARY KEY 를 선언하면 Flink 가 중복 행을 검사해 걸러 준다

6. 클릭 수별 사용자 수(집계 위의 집계) 로그에 -D 가 나왔다. 어떤 순간인가?

   1. 원천 파일에서 행이 지워졌을 때
   2. 상태 TTL 이 지나 오래된 키가 지워졌을 때
   3. 창이 닫혀 중간 결과를 비울 때
   4. 사용자가 다른 칸으로 옮겨 어떤 칸의 사용자 수가 0 이 됐을 때