250x250
반응형
Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- XAI
- flask
- hadoop
- 공분산
- top_k
- GCP
- gather_nd
- BigQuery
- 상관관계
- tensorflow text
- UDF
- integrated gradient
- Airflow
- TensorFlow
- Counterfactual Explanations
- requests
- 유튜브 API
- correlation
- subdag
- Retry
- youtube data
- login crawling
- spark udf
- API Gateway
- session 유지
- airflow subdag
- chatGPT
- grad-cam
- GenericGBQException
- API
Archives
- Today
- Total
데이터과학 삼학년
[SQL : impala] Join 최적화 (Broadcast Vs Partitioned) 본문
Data Visualization & DataBase
[SQL : impala] Join 최적화 (Broadcast Vs Partitioned)
Dan-k 2024. 11. 7. 22:23반응형
1. JOIN 방식의 개요
- 임팔라의 JOIN 방식: 두 가지 방식 제공
- BROADCAST JOIN: 작은 테이블을 모든 노드에 전송하여 메모리상에서 JOIN 수행
- PARTITIONED JOIN: 큰 테이블 간 결합 시 파티셔닝을 통한 분산 처리 수행
BROADCAST JOIN
- 정의: JOIN 대상 중 작은 테이블을 쿼리 참여 노드에 모두 전송하여 JOIN 연산 수행
- 적합한 사용 시기: 작은 테이블과 큰 테이블의 JOIN 연산 시 유리
- 특징: 작은 테이블이 전체 노드에 복제되므로 빠른 처리 가능. 큰 테이블 broadcast 시 메모리 과부하 발생 가능
PARTITIONED JOIN
- 정의: JOIN 연산에 참여하는 두 테이블을 키(key) 기준으로 파티셔닝 후 각 파티션에서 JOIN 수행
- 적합한 사용 시기: 큰 테이블 간 결합에 주로 사용
- 특징: 데이터를 분산 처리하여 메모리 사용 최적화 및 대규모 데이터 JOIN에서 성능 향상 가능
2. BROADCAST JOIN과 PARTITIONED JOIN 비교
비교 항목 BROADCAST JOIN PARTITIONED JOIN
사용 상황 | 작은 테이블과 큰 테이블의 JOIN | 큰 테이블 간의 JOIN |
처리 방식 | 작은 테이블을 모든 노드로 전송 | 테이블을 키 기준으로 파티셔닝 |
장점 | 간단한 구성으로 빠른 JOIN 가능 | 메모리 사용 최적화, 대규모 데이터 효율적 처리 |
단점 | 큰 테이블 broadcast 시 메모리 과다 사용 위험 | 초기 파티셔닝 작업으로 오버헤드 발생 |
메모리 사용 | 테이블 크기에 따라 메모리 사용 급증 | 파티셔닝을 통한 메모리 사용 절감 |
3. JOIN 힌트를 통한 최적화 방법
- JOIN 힌트: 특정 JOIN 방식을 강제하여 쿼리 최적화 가능
- 힌트 종류
- BROADCAST: BROADCAST JOIN 강제
- SHUFFLE: PARTITIONED JOIN 강제
JOIN 힌트 사용 예시
- BROADCAST 힌트: 작은 테이블을 모든 노드로 전송
- small_table을 broadcast하여 JOIN 수행
- large_table이 큰 경우 적합
SELECT *
FROM large_table AS t1
JOIN /* +BROADCAST */ small_table AS t2 ON t1.id = t2.id;
- SELECT /*+ BROADCAST(t1) */ * FROM large_table AS t1 JOIN small_table AS t2 ON t1.id = t2.id;
- SHUFFLE 힌트: 테이블을 파티셔닝하여 PARTITIONED JOIN 수행
- large_table1과 large_table2 간 PARTITIONED JOIN 수행 강제
- 대규모 데이터 집합 간 JOIN 시 유리
SELECT *
FROM large_table1 AS t1
JOIN /* +SHUFFLE */ large_table2 AS t2 ON t1.id = t2.id;
4. 결론: 데이터 특성에 맞는 JOIN 방식 선택하기
- BROADCAST JOIN: 작은 테이블 JOIN에서 성능이 뛰어남, 큰 테이블 broadcast 시 메모리 부담
- PARTITIONED JOIN: 큰 테이블 간 JOIN에 적합, 파티셔닝을 통한 메모리 최적화 가능
- JOIN 힌트 활용: 데이터 특성 및 쿼리 목적에 맞는 JOIN 방식 강제 가능
SELECT
straight_join t1.name, t2.id, t3.price
FROM t1 join /* +shuffle */ t2 join /* +broadcast */ t3 on t1.id = t2.id and t2.id = t3.id;
https://impala.apache.org/docs/build/html/topics/impala_hints.html
728x90
반응형
LIST
'Data Visualization & DataBase' 카테고리의 다른 글
CopyOnWrite VS MergeOnRead (0) | 2023.08.22 |
---|---|
[DE] 데이터 파티셔닝 & 샤딩 (0) | 2023.08.07 |
ODS(Operational Data Store), 팩트 테이블, 디멘션 테이블 (0) | 2023.05.29 |
[Impala] with 문(clause) 결과셋을 임의 저장하지 않음 (0) | 2023.02.13 |
[DB] overwrite VS upsert (0) | 2022.12.06 |
Comments