read 메소드를 통해서 csv파일을 읽는데,
헤더는 True
where을 걸어 필터링을 걸어줌. 젠더가 F가 아님
select로 필드 2개를 걸어줌
groupby로 gender로 걸어줌
count()로 수를 잡음.
.show()는 일부 드라이버쪽으로 넘어와 디스플레이됨.
데이터 프레임이 로딩 된 다음, where로 필터링, 그다음 select, 그다음 그룹바이, count, 마지막 show
파티션 관점에서 보면
로딩이 된순간, 하나 이상의 파티션으로 구성
필터링과 select를 하는 작업은 그 파티션에서 가능한 작업, 엑시큐터의 태스크들이 독립적으로 작동.
groupby 키에 맞게 같은 파티션으로 재정렬되어야 하기에 셔플링 발생.
count 하는 작업은 해당 파티션에서 가능한 작업
show는 일부 레코드를 드라이버로 가져오는 작업.
show - action 이라고 부름.
데이터프레임 관련 작업들을 수행시키는 역할.
spark이 레이지 엑시큐션을 함
작업이 그때마다 바로 시작되는게 아니라, 액션이라는 작업이 수행될 때 그때서야 앞서의 연산들이 수행됨.
show 실행 전 앞단의 작업들이 실행
write - action
데이터프레임 read도 작업에 따라 action
collect도 마찬가지. 스파크데이터프레임을 드라이버 쪽으로 다운로드 받는 것.
transformation이 있고,
narrow 트랜스포메이션
wide
있음
네로우 - 독립적으로 파티션 레벨에서 작업 가능
와이드 - 셔플링이 필요함.
액션
대기중인 트랜스포메이션을 실행시킴 (잡)
read, write, show, collect가 있음
액션을 통해 실행되는 연산들을 job이라고 함.
코드는 하나 혹은 그 이상의 잡
하나의 잡은 다수의 트랜스포메이션으로 구성
하나의 잡-> 하나 이상의 스테이지
스테이지 -> 하나 이상의 트랜스포메이션
스테이지-> 셔플링 없이 독립적 연산 가능함.
셔플링이 생긴다? 2개의 스테이지로 잡이 구성
하나의 스테이지는 다수의 태스크로 구성
태스크는 내로우 디펜던시 트랜스포매이션을 실행
데이터프레임에 연산별로 수행시키면 최적화를 할 수 없음.
어느정도 쌓여서 그림을 이해하고 최적화를 해야함.
실행을 최대한 뒤로 미루게 되는 이유임.
결과가 실제로 수행되는 시점까지 미루다가, 대기하고 있다가 연산들을 보고 최적화를 시도함.
sql로 수행하는게 스파크에게 좋음. select에게 뭘쓸건지, where 등 조건들을 한번에 주기 때문
액션이 show 에 의해 앞에 대기중이던 트랜스포메이션들이 실행됨.
그룹바이라는 와이드 디펜던시가 있음
show가 만들어낸 잡은 두개의 스테이지로 구성이 될 것임.
첫번째 스테이지는 where, select
두번재 스테이지는 그룹바이, 카운트임
하나의 액션은 하나의 잡이 되고 하나의 잡은 그 이상의 스테이지. 스테이지는 하나 이상의 태스크
액션은
잡을 하나 만들어내고 코드 실행
잡
하나 혹은 그 이상의 스테이지
내로우 디펜던시 태스크들의 집합. 셔플링이 발생하는 경우 스테이지
스테이지
태스크들의 집합. 태스크는 파티션 수만큼 병렬로 실행
태스크
가장작은 실행 유닛. 하나의 내로우 디펜던시 트랜스포매이션
웹 UI 시각화
2개이 잡이 있음
처음 데이터를 읽을 때 바로 실행. csv읽을 때 헤더가 true, 읽어서 어떤 스키마인지 알아내야하기 때문.
레코드 한줄을 읽게됨
두번째 잡은 .show에 의해 트리거가 됨 20개의 레코드를 collect해서 드라이버로 보냄.
그룹바이가 있어 두개의 스테이지로 구성
익스체인지는 셔플링임
같은 젠더를 같은 레코드들은 같은 파티션으로 가게끔.
실제 스파크 웹 UI에서 시각화가되는지. 어떻게 스테이지로 나뉘는지 확인.
각 스테이지 안에는 하나의 태스크로 내로우들이 실행
csv로 읽을 때 타입을 더 알고싶으면 inferSchema를 넣으면 잡이 하나 더 추가됨.
실제로 인풋을 읽으면서 컬럼 타입이 무엇인지 파악하려고 함.
이런것들이 엑시큐션 플랜임.
스파크가 어떻게 실제 코드로 바꿔서 실행해주는지.
이 엑시큐션 플랜을 보면서 최적화 포인트를 알 수 있음.
이어서 세개의 다른 예를 깊게 보도록 한다.
1. 워드카운트
2. 셔플 조인
3. 브로드캐스트 조인
