데이터브릭스에서 힌트란?

GarionNachal·2026년 3월 14일

databricks

목록 보기

39/45

Databricks SQL의 “힌트(Hint)”는 옵티마이저가 실행 계획(Execution Plan)을 만들 때 참고하도록 주는 ‘권고(guide)’입니다. 즉, 힌트를 줬다고 해서 항상 그대로 실행되는 것은 아니며, 조인 타입/전략 지원 여부 등에 따라 무시될 수 있습니다. Databricks Documentation

Databricks는 내부적으로 Apache Spark 기반이므로, 힌트의 개념/이름/우선순위는 Spark SQL 힌트와 매우 유사합니다. spark.apache.org

힌트 문법(기본)

Databricks SQL에서 힌트는 /*+ ... */ 형태의 코멘트로 작성합니다. 예:

SELECT /*+ COALESCE(3) */ * FROM t;

Databricks Documentation

Spark SQL 쪽 문법도 동일하게 /*+ hint [ , ... ] */ 형태로 설명합니다. spark.apache.org

Databricks SQL 힌트 종류 3가지

Databricks 문서 기준으로 힌트는 크게 아래 3종으로 분류됩니다.

Partition(파티셔닝) 힌트: COALESCE, REPARTITION, REPARTITION_BY_RANGE, REBALANCE
Join(조인) 힌트: BROADCAST, MERGE, SHUFFLE_HASH, SHUFFLE_REPLICATE_NL
Skew(스큐) 힌트: SKEW
Databricks Documentation

1) Partition(파티셔닝) 힌트: 파일 개수/셔플/병렬도 컨트롤

Partitioning 힌트는 결과 데이터의 파티션 수(= 실행 병렬도, 출력 파일 수)에 직접 영향을 주기 때문에, “쿼리는 빠르지만 파일이 너무 많이 생김(스몰 파일)” 같은 문제를 다룰 때 특히 유용합니다. 또한 Databricks 문서에서는 이 힌트들이 Dataset API의 coalesce, repartition, repartitionByRange와 “동등(equivalent)”하다고 명시합니다. Databricks Documentation

참고: Spark 문서에서는 여러 파티셔닝 힌트를 동시에 쓰면 논리 계획에 여러 노드가 들어가지만, 최종적으로 옵티마이저는 “가장 왼쪽(leftmost)” 힌트를 고른다고 설명합니다. spark.apache.org

1-1. COALESCE(N): 파티션 수 줄이기(셔플 최소화 성향)

SELECT /*+ COALESCE(8) */ *
FROM fact_table;

목적: 파티션을 N개로 줄여 출력 파일 수를 줄이거나, 지나친 태스크 분할을 완화
특성: 일반적으로 repartition보다 셔플 비용이 덜한 방향(케이스에 따라 다름)
Databricks Documentation

1-2. REPARTITION(...): 파티션 재분배(셔플 발생 가능)

-- 파티션 수만 지정
SELECT /*+ REPARTITION(200) */ * FROM t;

-- 컬럼 기준 재파티셔닝
SELECT /*+ REPARTITION(user_id) */ * FROM t;

-- 파티션 수 + 컬럼
SELECT /*+ REPARTITION(200, user_id) */ * FROM t;

Spark 문서에서 REPARTITION은 파티션 수, 컬럼, 또는 둘 다를 인자로 받을 수 있다고 예시로 보여줍니다. spark.apache.org

1-3. REPARTITION_BY_RANGE(...): 범위 기반 재파티셔닝

SELECT /*+ REPARTITION_BY_RANGE(50, event_date) */ *
FROM events;

목적: 특정 컬럼의 범위를 기준으로 분배해, 정렬/범위 조건 처리 등에 유리한 형태를 유도
spark.apache.org

1-4. REBALANCE(...): 결과 파티션 “크기 균등화” (AQE 필요)

Databricks 문서에서는 REBALANCE가 결과 파티션을 “reasonable size”로 맞추는 데 도움이 되며, AQE가 꺼져 있으면 무시(ignored)된다고 명시합니다. Databricks Documentation

SELECT /*+ REBALANCE */ *
FROM t;

2) Join(조인) 힌트: 조인 전략을 직접 “유도”

Join 힌트는 Spark/Databricks가 어떤 조인 전략을 선택할지에 영향력을 행사합니다.

Databricks 문서에 따르면, 서로 다른 조인 힌트를 양쪽 테이블에 주면 우선순위는 다음과 같습니다.

BROADCAST > MERGE > SHUFFLE_HASH > SHUFFLE_REPLICATE_NL
Databricks Documentation

또한 Spark 문서에서는:

BROADCAST 힌트가 있으면 autoBroadcastJoinThreshold와 무관하게 브로드캐스트 조인을 “제안”
양쪽 다 BROADCAST(또는 SHUFFLE_HASH)면 통계 기반으로 작은 쪽을 build side로 선택
조인 타입에 따라 해당 전략이 불가능하면 힌트가 보장되지 않음
을 명확히 적어두고 있습니다. spark.apache.org

2-1. BROADCAST(table): Broadcast Hash Join 유도

SELECT /*+ BROADCAST(dim) */ f.*, dim.*
FROM fact f
JOIN dim
  ON f.dim_id = dim.id;

추천 상황: 한쪽 테이블이 충분히 작아 전체 워커로 보내도 부담이 없을 때(“작은 차원 테이블” 등)
주의: 브로드캐스트 대상이 커지면 메모리 압박/성능 악화 가능
spark.apache.org

2-2. MERGE(table): Sort-Merge Join 유도

SELECT /*+ MERGE(t1) */ *
FROM t1
JOIN t2 ON t1.key = t2.key;

Spark 문서에서 MERGE는 shuffle sort-merge join을 제안한다고 설명합니다(별칭: SHUFFLE_MERGE, MERGEJOIN). spark.apache.org

2-3. SHUFFLE_HASH(table): Shuffle Hash Join 유도

SELECT /*+ SHUFFLE_HASH(t1) */ *
FROM t1
JOIN t2 ON t1.key = t2.key;

양쪽에 SHUFFLE_HASH를 주면 Spark가 통계 기반으로 작은 쪽을 build side로 선택 가능
spark.apache.org

2-4. SHUFFLE_REPLICATE_NL(table): Nested Loop Join 유도(고위험)

SELECT /*+ SHUFFLE_REPLICATE_NL(t1) */ *
FROM t1
JOIN t2 ON t1.non_equi_condition = t2.x;

보통은 equi-join이 아닌 경우 등에서 고려될 수 있으나, 비용이 매우 커질 수 있어 신중히 사용
spark.apache.org

3) Skew 힌트: SKEW(스큐 조인)

Databricks SQL 힌트 문서에는 Skew hint로 SKEW가 존재한다고 분류되어 있고, 추가로 “legacy skew join” 문서를 링크로 제공합니다. Databricks Documentation

Databricks 쪽 링크(추가 참고): https://docs.databricks.com/aws/en/archive/legacy/skew-join

또한 “힌트”와 별개로, Spark 성능 튜닝 문서에서는 AQE가 스큐 조인을 런타임에 완화(skewed partition을 쪼개고 복제해 태스크 균등화)할 수 있다고 설명합니다. 즉, 실무에선 힌트만 보지 말고 AQE 기반 스큐 최적화도 함께 고려하는 편이 안전합니다. Apache Spark

힌트가 먹었는지 확인하는 2가지 방법

1) EXPLAIN으로 플랜 확인 (Databricks SQL)

Databricks SQL은 아래 형태로 실행 계획을 확인할 수 있습니다.

EXPLAIN [ EXTENDED | CODEGEN | COST | FORMATTED ] statement

기본은 physical plan을 보여주고, EXTENDED 등 옵션으로 더 많은 정보를 확인할 수 있습니다. docs.databricks.com

2) Query Profile로 병목 시각화 (Databricks SQL)

Databricks SQL의 Query Profile은 실행 중 각 오퍼레이터(operator)별 시간/처리 row 수/메모리 사용량 등을 시각화해 병목을 빠르게 찾는 데 도움을 줍니다. 또한 exploding join, full table scan 같은 흔한 실수도 발견하는 데 유용하다고 문서가 설명합니다. Databricks Documentation

실전 팁(경험적으로 자주 터지는 포인트)

힌트는 “강제”가 아니라 “제안”이라서, 통계/조인 타입/지원 전략에 의해 무시될 수 있습니다. 특히 Databricks 문서에서도 조인 힌트가 보장되지 않는다고 못 박습니다. Databricks Documentation
조인 힌트가 서로 충돌하면 우선순위(BROADCAST > MERGE > SHUFFLE_HASH > SHUFFLE_REPLICATE_NL)에 의해 한쪽이 덮어씌워질 수 있습니다. spark.apache.org
AQE는 런타임 통계로 조인 전략을 바꾸거나(예: sort-merge → broadcast), 스큐를 완화할 수 있습니다. 힌트만 믿기보다 AQE 동작까지 포함해서 튜닝하세요. Apache Spark