Streaming System 1장: 스트리밍 101

실제로 처리시간에서 발생하는 지연과 이벤트 시간에서 발생하는 왜곡은 한 지점을 놓고 보면 동일한 크기이다.

이벤트 시간이 중요한 경우라면 파이프라인 관측 시점만으로는 데이터를 분석할 수 없다 안타깝게도 이 방식이 역사적으로 무한 데이터를 위해 설계된 많은 시스템이 동작해온 방식이기도하다.

정확성과 이벤트 시간을 중요한 경우라면, 처리 시간을 사용해 이 경계를 설정해서는 안되며 그렇지 않을 경우 처리시간과 이벤트 시간 사이의 어떤 일관된 관계없이는 이벤트 시간 데이터 중 일부가 잘못된 처리 시간 윈도우에 들어가 정확성에 문제가 생길 것이다.

실제 processing을 배치에 의존할 수 밖에 없으니까 윈도우로 나누는거고,

처리 시간을 기준으로 하는 경우가 이제 배치일거고 이벤트 시간을 기준으로 하는 경우도 윈도우의 완결 시점을 확정할 수 없기에(데이터 유실, 비행기에서 동작한 로그들,등등… ) 새로운 데이터가 도착하면 이전 데이터를 철회하거나 갱신할 수 있어야한다는데, 스트리밍 특성상 결국에 불확실한 상태에서 윈도우를 닫을 수 밖에 없고 그걸 갱신한다고 해도 이미 소비해버린 경우면 어쩌지?

사실상 그러면 풀 수 없는 문제긴 하겠네? 아무리 이벤트 시간 기준을 결과를 내보내고, 데이터를 고치고, 워터마크를 넣고, 트리거를 해도, 결국에 데이터가 고쳐진 시간과 데이터를 소비한 시간의 이격동안에은 틀린 값을 본거니까 말야. 이 경우는 사실 누구도 해결할 수 없는 문제인거지? silver bullet같은 문제겠지?

1. 지금까지의 정보로는 맞는 값이라는 것이 실제 세계의 진리라는 것을 의미하진 않는 거긴 하니까 사실 이건 신 만이 알만한 이데아인거니까
2. 당연히 배치도 해결할 수 는 경우에 대해 찬성해.
3. 데이터가 언제까지 도착할지 확실히 알 수 있는 환경이면 배치도 성공하는거 아닌가? ㅋㅋㅋ

복잡도 이슈가 진짜 크긴 하다. 대부분 데이터 시스템은 분석계나 ML처럼 데이터 소비자의 의지에 따라 발현되는건데, 대부분이 사실 실시간성을 요구하는 경우가 드물고, 추가적으로 원천 적재가 아니라면, 결국에는 파생데이터를 산출해서 쓰는 거고, 파생데이터라는 것이 소비자의 의지에 따라 매번 바뀌다보니까, 배치가 좀더 유리한 경우가 더 많은 것 같다. 그럼에도 불구하고 스트리밍이 이기는 뾰족한 케이스는 더 뭐가 있을까?

여기서 얻은 답은 스트리밍은 “늦으면 손해가 나는 곳” 이나 “데이터 소비자가 사람이 아닌곳”

1. 이상 거래 탐지
2. 시세와 트레이딩

무한데이터: 배치

1. 고정 윈도우
2. 세션

무한데이터: 스트리밍

1. 시간 무시
2. 필터링
3. 내부 조인
4. 근사 알고리즘
5. 윈도우
   1. 고정 윈도우
   2. 슬라이딩 윈도우
   3. 세션
   4. 처리 시간 윈도우
   5. 이벤트 시간 윈도우

결과가 데이터의 내용으로만 결정된다 -> 이거를 좀 더 쉽게 설명해볼래? 늦게와도 아무상관없다는 사실 파생데이터에서 어떻게 사용하냐에 따른 문제인것 같은데 말야…

claude의 답변

1. 하류에서 시간이 필요한 질문을 던지면, 파이프라인 전체가 시간에 민감해집니다
2. 결과의 정확성과 결과의 쓸모는 다른 문제입니다

내부조인의 경우에, 연산이 시간무시의 특성을 가지면서, 내부조인을 걸어야하는 경우

1. 조인키가 특정한 쌍 -> 이해했음
2. 양쪽 모두 변하지 않는 사실입니다. -> 이벤트라는 것이 원래 불변성을 지니긴 하잖아. 근데 한쪽 값이 계속 바뀌는 경우라고 하면 upsert를 치는 거고, 사실 그 조인 시기에 따라서 진실이 매번 바뀌는거고, 파생 이벤트도 processed_time 당시에는 진실이었던 거 아닐까? 조금 더 설명
3. 짝이 없는 데이터에는 관심이 없습니다 -> 이거는 당연한데, 이벤트 윈도우가 닫혔다는 것은 확신할 수는 없긴 하지만, 우리는 어쩔 수 없이 일단 그 순간을 믿는거겠지?
4. 대부분의 짝이 결국 도착합니다 -> ㅇㅋ

Schema Registry 호환성 규칙은 어떻게 정의하나?

추가적으로 너가 말한 백필을 할만하게 하는 장치 5개는 이거지?

1. append only
2. shcema versioning
3. ? 이건 멱등성 관련한건가?
4. 이건 schema에 주석 다는거겠지?
5. Write audit push 말하는거고, dbt랑 함께?

이벤트 시간 윈도우의 단점 2가지

1. 버퍼링 : 윈도우 수명이 길어져서 정보를 들고 있어야하는데, 사실 디스크로 가져오니까 ㄱㅊ, 아니면 증분 집계도 되니까
2. 완결성 : 윈도우가 언제 끝날지 확정할 수 없다. 휴리스틱(워터마크)

여기서 밀휠, 클라우드 데이터 플로우, 플링크에서 제공하는 워터마크로 윈도우 완료를 결정하는 비교적 정확한 휴리스틱을 제공할 수 있다는데 도대체 어떻게!?

일단 이해는 못했지만 간단하게는 워터마크는 n 이후의 이벤트 시간의 데이터는 오지 않는다! 그리고 이 워터마크로 윈도우를 끝날지 확정지음.

정리

스트리밍: 무한 데이터를 고려해 설계된 시스템 큰 규모의 데이터셋과 관련된 두 가지 차원

기수

1. 유한
2. 무한

구성

1. 테이블
2. 스트림

배치는 스트리밍의 부분집합이다. 람다 아키텍처는 틀렸다!, 스트리밍은 열등하지 않으며 오히려 상위의 개념이다. (이 책의 주장)

well- function하는 스트리밍 시스템의 두 가지 개념

1. 정확성 -> 장애가 나도 결과가 틀리지 않는다
2. 시간 판단 도구 -> 윈도우, 워터마크

이벤트 시간: 이벤트가 발생한 시간 PUB 처리 시간(processed_time, ingested_at?) SUB

무한, 유한 데이터 처리 패턴

1. 시간 무시
2. 근사
3. 처리 시간 윈도우
4. 이벤트 시간 윈도우