Serverless dataflow
- Beam의 가장 큰 특징은 이식성임.
- 이식성 API(Portability API)라고 불림.
- SDK와 러너가 서로 균일하게 작동할 수 있음
[Separating compute and storage with Dataflow]
-
Dataflow
-
Dataflow Shuffle Service GroupByKey: GroupByKey는 전체 데이터를 셔플하기 때문에 비용이 크고, 성능 저하가 있을 수 있어요. 가능하면 CombinePerKey 같은 변형으로 대체하는 것이 좋습니다. CoGroupByKey: 두 개 이상의 데이터셋을 key 기준으로 join할 때. 예: 사용자 정보와 구매 이력, 학생과 성적 등. 각 PCollection은 key-value 쌍이어야 하며, key는 동일한 타입이어야 함 Combine: 데이터에 대해 집계 연산을 수행하는 트랜스폼입니다. 예를 들어 합계, 평균, 최대값 등을 구할 수 있어요. 두 가지 주요 변형이 있습니다: CombineGlobally: 전체 데이터에 대해 집계 CombinePerKey: key별로 집계
셔플(Shuffle)이란? Shuffle은 데이터가 여러 작업자(worker) 사이에서 재분배(re-distribution) 되는 과정입니다.
[("fruit", "apple"), ("fruit", "banana"), ("color", "red")]
→ GroupByKey
"fruit"이라는 key를 가진 값들을 같은 곳으로 모으기 위해
"apple"과 "banana"가 서로 다른 worker에 있으면, 그 중 하나가 네트워크를 통해 다른 쪽으로 이동해야 함
이게 바로 셔플입니다
일반 파이썬에서는 데이터가 한 머신에 있음
일반 파이썬 코드는 하나의 메모리 공간(즉, 한 컴퓨터)에서 작동해요.
리스트나 딕셔너리를 groupby, sort, filter 해도 모든 데이터가 한 곳에 있으므로 데이터 재분배가 필요 없음.
-
Dataflow Streaming Engine 작업자의 VM에 연결된 영구 디스크에서 백엔드 서비스로 Window 상태 저장소를 오프로드함.
Dataflow의 스트리밍(Streaming) 환경에서 Window, State, Timer는 핵심적인 개념입니다. 특히 스트리밍은 끝없는 데이터 흐름을 처리하기 때문에, 데이터를 “언제”, “어떻게” 묶고, “상태"를 유지할지 정하는 것이 매우 중요하죠.
Window: 스트리밍 데이터를 시간 단위로 “묶는” 방식 State: 각 key나 element 별로 “상태(메모리 값)“를 유지하는 기능 Timer: 특정 시간에 상태를 확인하거나 처리하도록 예약하는 기능
[Window – 데이터 시간별 묶음] Fixed Windows: 고정 시간 간격 (예: 5분 단위) Sliding Windows: 중첩 가능 (예: 5분 간격, 1분마다 시작) Session Windows: 유저 활동 기반 비정기적 묶음 (예: 활동 30분 이상 없으면 세션 종료) Global Window: 전체 데이터 (무한 스트림, 보통 상태/타이머와 함께 사용)
[State – 키 기반으로 상태 저장] State는 Dataflow 스트리밍에서 key별로 어떤 상태를 기억할 수 있게 해줍니다. 이게 없으면 데이터는 흘러가기만 하고 아무것도 기억 못 하겠죠? (예)각 user_id별로 클릭 수를 기억함. 상태는 자동으로 관리되고 체크포인팅됨
[Timer – 시간 기준으로 트리거 설정] Timer는 특정 시간(이벤트 시간 또는 처리 시간)에 맞춰 상태를 정리하거나 알림을 트리거할 수 있어요. 예: 5분 동안 클릭이 없으면 “세션 종료”
-
Flexble Resource Scheduling(FlexRS) Dataflow Shuffle Service에서 고급 스케쥴링 기술을 사용하고, 선점형 가상머신과 일반 가상머신을 함께 활용할 수 있음으로, 일괄처리 파이프라인의 비용을 줄이는데 도움이 됨. FlexRS작업을 제출하면 Dataflow는 작업을 대기열에 넣고 작업 생성 후 6시간 이내에 실행을 위해 제출함. 이런 특징으로 인해 FlexRS는 특정 기간 내에 완료할 수 있는 일일 또는 주간 작업처럼 시간에 민감하지 않은 작업 부하에 적합.
Your project’s current SSD usage is 100 TB. You want to launch a streaming pipeline with shuffle done on the VM. You set the initial number of workers to 5 and the maximum number of workers to 100. What will be your project’s SSD usage when the job launches? 140 TB
Recall that the number of disks allocated equals the maximum number of workers in streaming pipelines. When shuffle is done on the VM, the default PD size is 400 GB. Doing 100 + (0.4 TB * 100 workers) gives you 140 TB.
[security]
- Data Locality
- Shared VPC
- Private IPs 외부 IP지정을 비활성화 하는 방법.
- CMEK 고객관리 암호화키.(stands for customer managed encryption key.)