SQL
- Aggregation 함수
- DataFrame이 아닌 SQL로 작성하는 것을 추천
- Group By (SUM, MIN, MAX, AVG, COUNT)
- Window(ROW_NUMBER, FIRST_VALUE, LAST_VALUE)
- Rank
- JOIN
- SQL 조인은 두 개 혹은 그 이상의 테이블들을 공통 필드를 가지고 머지
- 스타 스키마로 구성된 테이블들로 분산되어 있던 정보를 통합하는데 사용
- 왼쪽 테이블을 LEFT라고 하고 오른쪽 테이블을 RIGHT이라고 하면
- JOIN의 결과는 방식에 따라 양쪽의 필드를 모두 가진 새로운 테이블을 생성
- 조인의 방식에 따라 다음 두가지가 달라짐
- 어떤 레코드들이 선택되는지?
- 어떤 필드들이 채워지는지?
- 다양한 종류의 조인
(1) JOIN 실습 - 예제 데이터 준비
(2) JOIN 실습 - INNER JOIN
- 양쪽 테이블에서 매치가 되는 레코드들만 리턴
- 양쪽 테이블의 필드가 모두 채워진 상태로 리턴
SELECT * FROM Vital v
JOIN Alert a ON v.vitalID = a.vitalID;
(3) JOIN 실습 - LEFT JOIN
- 왼쪽 테이블(Base)의 모든 레코드들을 리턴
- 오른쪽 테이블의 필드는 왼쪽 레코드와 매칭되는 경우에만 채워진 상태로 리턴
SELECT * FROM raw_data.Vital v
LEFT JOIN raw_data.Alert a ON v.vitalID = a.vitalID;
(4) JOIN 실습 - FULL JOIN
- 왼쪽 테이블과 오른족 테이블의 모든 레코드들을 리턴
- 매칭되는 경우에만 양쪽 테이블들의 모든 필드들이 채워진 상태로 리턴됨
SELECT * FROM raw_data.Vital v
FULL JOIN raw_data.Alert a ON v.vitalID = a.vitalID
(5) JOIN 실습 - CROSS JOIN
- 왼쪽 테이블과 오른쪽 테이블의 모든 레코드들의 조합을 리턴
SELECT * FROM raw_data.Vital v CROSS JOIN raw_data.Alert a;
(6) JOIN 실습 - SELF JOIN
- 동일한 테이블을 alias를 달리해서 자기 자신과 조인
SELECT * FROM raw_data.Vital v1
JOIN raw_data.Vital v2 ON v1.vitalID = v2.vitalID;
(7) 최적화 관점에서 본 조인의 종류
- Shuffle JOIN
- 일반 조인 방식
- Bucket JOIN : 조인 키를 바탕으로 파티션을 새로 만들고 조인을 하는 방식
- Broadcast JOIN
- 큰 데이터와 작은 데이터 간의 조인
- 데이터 프레임 하나가 충분히 작으면 작은 데이터 프레임을 다른 데이터 프레임에 있는 서버들로 뿌리는 것(Broadcasting)
- spark.sql.autoBroadcastJoinThreshold 파라미터로 충분히 작은지 여부 결정
- 기본적으로 이 값을 Executor에 지정한 메모리보다 작게 해주는게 좋다.
Shuffle JOIN
- 왼쪽 데이터프레임, 오른쪽 데이터프레임 모두 각 레코드에서 조인키에 해싱을 적용한 후
- 그 해싱된 값을 조인 후 데이터프레임의 파티션 수로 나머지 계산을 해서
- 나머지에 해당하는 파티션으로 복사
- 여기서 엄청난 셔플링(데이터 이동)이 발생하고, 파티션의 크기가 달라질 수 있다.
Broadcast JOIN
- 원래는 Shuffle Join 처럼 모든 데이터가 새로운 파티션으로 복사 되어야하는데,
- BroadCast JOIN은 왼쪽 데이터프레임이 있는 파티션으로 작은 데이터프레임을 복사를 하는 것(해싱을 쓰지 않는다)
- 이렇게 셔플링의 양을 최소화 시키고, 별다른 오버헤드 없이 Join 연산을 수행할 수 있다.
