Keyed State — ValueState/ListState/MapState
직관적으로
개인 사물함을 떠올려보자. keyBy로 나뉜 각 키(예: user_id)마다 자기만의 사물함이 하나씩 배정된다. 이 사물함에 값 하나를 넣어두거나(ValueState), 목록을 쌓아두거나(ListState), 여러 항목을 키-값 쌍으로 저장해두는(MapState) 게 Flink의 Keyed State다.
실제 사례
"사용자별 누적 구매 금액을 계속 추적한다"는 ValueState(사용자 하나당 숫자 하나)의 전형적 사례다. "사용자가 최근 본 상품 10개 목록을 유지한다"는 ListState의 사례다. "사용자별로 카테고리마다 몇 번 클릭했는지 집계한다"(카테고리→클릭수 맵)는 MapState의 사례다. 이 상태들은 Day 2에서 배운 keyBy로 나뉜 키 단위마다 완전히 독립적으로 유지된다.
정확한 원리
Keyed State는 반드시 `keyBy()`가 적용된 스트림에서만 쓸 수 있고, 특정 키에 대한 상태 접근은 항상 그 키를 처리 중인 함수 인스턴스 안에서만 가능하다(다른 키의 상태를 임의로 조회할 수 없음) — 이 제약이 있기 때문에 상태를 파티션 경계를 넘어 옮길 필요 없이 로컬에서 빠르게 읽고 쓸 수 있다. ValueState는 단일 값, ListState는 append 가능한 리스트, MapState는 키-값 쌍 컬렉션이라는 API 형태 차이가 있을 뿐, 셋 다 keyBy로 나뉜 파티션 단위로 독립적으로 유지된다는 공통 원리는 동일하다.
흔한 오해
"State는 그냥 메모리에 있는 일반 변수 아닌가?"라고 생각하면 다음 스텝(체크포인트)을 이해하기 어렵다. Flink의 State는 단순 변수가 아니라 **Flink 런타임이 관리하며 장애 시 자동으로 복구 대상이 되는 특수한 저장소**다 — 이 관리 여부가 일반 지역 변수와의 결정적 차이다.
확인 문제
만약 사용자별 상태(ValueState)를 쓰고 있는데 keyBy 없이 그냥 map 함수 안에서 이 상태에 접근하려 하면 어떻게 될까? 왜 그런 제약이 있다고 생각하는가?
Answer Guide
Keyed State는 keyBy가 적용된 컨텍스트에서만 접근 가능하다(컴파일/런타임 에러). 이유: 어떤 키의 상태인지 알아야 올바른 사물함을 찾아 접근할 수 있는데, keyBy 없이는 '지금 처리 중인 레코드가 어느 키에 속하는지'라는 컨텍스트 자체가 없기 때문.