When Tables Became the Language of Time

Author: Giannis Polyzos | Source: ipolyzos.substack.com | Published: 2025-12-17

한 줄 요약

batch vs streaming은 거짓 이분법이며, “테이블 = 스트림의 materialization, 스트림 = 테이블의 history”라는 stream-table duality로 추상화를 통일하면 batch/streaming이 같은 진실의 시간적 뷰로 수렴한다.

데이터는 본질적으로 batch도 streaming도 아닌 “특정 시점에 일어난 변화”일 뿐. 스트림은 변화의 순서화된 history, 테이블은 그것을 적용한 누적 결과
통일은 batch/streaming 사이에 더 나은 glue를 추가하는 게 아니라, **구분을 무의미하게 만드는 추상화(테이블)**를 선택하는 데서 나옴. 배치 잡 = 유한한 history 적용, 스트리밍 잡 = 같은 행위를 연속 수행
Compute는 streaming-first여야: Flink는 모든 계산을 streaming으로 표현(bounded = 끝나는 스트림). batch/streaming은 conceptual이 아닌 operational 선택(완결성 vs 즉시성). 단 상태가 compute 엔진에 묶임
Lakehouse는 memory: 원자적·버전드 테이블 커밋의 시퀀스. backfill = late history, correction = 추가 커밋, time travel은 자연스럽게 따라옴
Kafka의 한계: 로그는 “데이터가 어떻게 이동하는가”를, 테이블은 “시스템이 무엇을 믿는가”를 답함. compacted topic/Kafka Streams도 full 테이블 추상화(스키마 진화, update/delete, point-in-time snapshot)엔 못 미침 → truth가 항상 다운스트림에 존재
Apache Fluss: “로그가 아닌 테이블에서 출발한 스트리밍 스토리지” — 스트림을 mutable table-like 엔티티로, 컬럼나 1급, lakehouse의 real-time tier로 동작. Flink와 긴밀 통합

예시(늦은 환불): topic-centric은 여러 시스템이 “refund logic”을 제각각 인코딩 → 단편화. table-centric은 order 테이블 update 한 번 → 실시간·과거 뷰 모두 일관
핵심 명제: “A log records what happened. A table represents what is believed to be true.”