Flink SQL/Table API — DataStream API의 '상위 호환'이 아니라 '다른 도구'
직관적으로
엑셀 함수(SQL/Table API에 해당)와 매크로 코드(DataStream API에 해당)의 관계와 비슷하다. 엑셀 함수는 빠르고 선언적이라 반복 업무에 좋지만, 아주 세밀한 커스텀 로직은 매크로 코드로 짜야 한다. 둘 다 없어지지 않고 상황에 맞게 골라 쓴다.
실제 사례
"카테고리별 5분 단위 매출 합계"처럼 관계형 연산으로 충분히 표현되는 로직은 Flink SQL 한 줄로 끝난다(`SELECT category, TUMBLE_START(...), SUM(amount) FROM sales GROUP BY category, TUMBLE(...)`). 반면 Day 3에서 배운 Keyed State를 직접 다루며 복잡한 커스텀 판단 로직(예: 사용자별 이상행동 패턴을 여러 단계에 걸쳐 추적)을 짜야 한다면 DataStream API(또는 더 저수준의 ProcessFunction)가 필요하다.
정확한 원리
Flink 공식 문서는 Table API/SQL을 DataStream API와 '나란히 있는 핵심 추상화'로 설명하며, DataStream API가 조만간 없어지지 않을 것이라고 명시한다 — 즉 Table API/SQL이 DataStream API를 대체하는 관계가 아니라 **더 높은 추상화 수준의 선언적 인터페이스**라는 관계다. 둘은 상호운용 가능해서(Table ↔ DataStream 변환), 대부분은 Table API/SQL로 선언적으로 짜다가 세밀한 제어가 필요한 부분만 DataStream API로 내려가는 하이브리드 파이프라인도 흔하다.
흔한 오해
"최근엔 다들 SQL만 쓰고 DataStream API는 레거시다"라는 주장을 실무 블로그에서 종종 볼 수 있는데, 공식 문서 기준으로는 근거가 부족한 과장이다. 관계형으로 표현 가능한 로직 비중이 높은 조직에서 SQL/Table API 비중이 커지는 **경향**은 있지만, DataStream API가 폐기 예정이라는 근거는 없다 — 복잡한 상태 로직에는 여전히 DataStream API(또는 ProcessFunction)가 필요하다.
확인 문제
"우리 팀은 대부분의 스트리밍 파이프라인이 단순 필터+집계라 SQL로 충분한데, 딱 하나만 사용자별로 최근 5번의 행동 시퀀스를 추적해 이상 패턴을 판단하는 복잡한 로직이 필요합니다"라면, 파이프라인 전체를 SQL로 짤지 DataStream API로 짤지 어떻게 결정하겠는가?
Answer Guide
전체를 하나의 방식으로 통일할 필요 없이, 단순 필터+집계 부분은 Table API/SQL로, 복잡한 시퀀스 추적 로직만 DataStream API(또는 ProcessFunction)로 짜서 Table↔DataStream 변환으로 연결하는 하이브리드 접근이 합리적이라는 요지.