Dataflow 논문 저자들: 스트리밍 분석의 종착점은 트리거가 아니라 SQL 물질화 뷰와 신선도 계약

스트리밍 연구개발을 10년 했고, 대형 데이터 웨어하우스 문제로 옮긴 뒤에는 분석은 그냥 SQL을 기본값으로 삼아야 한다고 결론 냈음. 스트림 프로그래밍 모델은 흥미롭지만, 고처리량·저지연 병렬 시스템의 주류가 되리라는 생각은 접었음.

처리가 map()에 들어맞을 때만 기존 모델로 충분한 것 같음. 대규모 동시 스트림에서 reduce()나 all_gather()를 쓰면 경기장 스마트폰 음향 삼각측량이나 10만 명 단일 인스턴스 MMORPG 같은 프로그램도 가능해질 거라 봄.

나도 스트리밍 업계에서 10년 일하고 스타트업을 세웠으며 대기업에서 플랫폼을 세 개 만들었는데 대체로 동의함. 낮은 지연이 정말 필요한 회사가 적고, 지속 실행되는 상태 보유 시스템은 배치보다 운영과 변경이 훨씬 복잡함.

웨어하우스와 데이터레이크에 비교적 낮은 지연으로 적재하는 일이 쉬워지니 복잡한 스트리밍 시스템에 투자할 이유가 약해졌음. 그래도 데이터가 특정 시각까지 거의 다 왔는지 알리는 일과 주기 쿼리의 비싼 재계산을 피하는 일은 데이터플로우 스트림 프로세서가 배치보다 잘 풀었음.

사람들은 자신이 아는 명령형 구조적 프로그래밍을 벗어나기 어려워서, 함수 개념을 아는데도 함수형 프로그래밍을 시도하게 만들기 힘들었음. 다만 LLM은 낯선 언어도 거리낌 없이 쓰니 데이터플로우 같은 패러다임의 주류 여부가 예전만큼 중요하지는 않다고 봄.

Dataflow와 Apache Beam에 깊이 빠져 있었는데, 이벤트 시간과 처리 시간의 구분, 완전성을 기다리지 말라는 주장은 맞았다고 생각함. 무한 스트림 트리거는 여전히 머리가 아프고, 테이블 중심 모델로 간 게 반가움.

Spanner의 아이디어를 가져와 데이터베이스를 메시지 버스로 쓰거나 행마다 일관성 정보를 두는 식의 인데이터베이스 CQRS도 보고 싶었음.

2002년 VLDB 논문은 스트림 처리를 쿼리와 데이터의 조인으로 보고, 내부에서는 모두가 서로를 조회하는 물질화 뷰라고 설명했음. 이번 저자들이 결국 비슷한 개념적 결론에 닿은 점이 흥미로움.

Beam API에서 Splitting을 원했는데 문서에 들어가서 반가움. 아주 큰 CSV 파일처럼 함수 하나가 원소 하나를 통째로 처리할 수 없는 경우가 있으며, 나중에 Splittable DoFn으로 지원됐지만 구현체별 지원 수준은 달랐음.

15년 전에는 SQL을 피하고 스트리밍 언어를 만들었지만, 지금 업계는 freshness나 시간 지연 약속이 붙은 SQL 물질화 뷰가 맞는 사고방식이라고 결론 낸 셈임.