Data Eng Wiki

Using LLMs to Analyze Spark SQL Plans

5 min read

Using LLMs to Analyze Spark SQL Plans: A Practical Approach to Debugging Long-Running Jobs

Author: Sagi Bhuvana (Expedia Group) | Source: Medium (Expedia Group Tech) | Published: 2026-06-30

한 줄 요약

자유 형식 프롬프트 대신 엄격한 판정 기준을 가진 anti-pattern 목록을 주고 모든 발견에 stage/task/node ID 근거를 강제하니, LLM이 300+ 노드짜리 Spark 물리 플랜에서 실제 병목을 일관되게 짚어냈다.

핵심 주장/내용

  • 문제: Spark SQL은 맞아 보이지만 규모에서 조용히 성능·비용 문제가 되는 코드를 쓰기 쉬움. 디버깅은 깊게 중첩된 물리 플랜, 파편화된 UI 지표, 근본 원인을 가리키지 않는 stage 통계를 헤집는 일 → 조인 전략인지, skew인지, 과도한 셔플인지, 메모리 압박인지 추측 게임
  • 1) 실제 컨텍스트 확보: 오픈소스 Spark MCP 서버(kubeflow/mcp-apache-spark-history-server)로 SQL 실행 메타데이터, final·physical plan, stage/task 지표, 셔플·spill·I/O 통계를 구조화해서 노출
  • 2) 자유 대화를 pattern-guided prompting으로 교체: “플랜을 분석하고 최적화를 제안해줘”는 너무 일반적이라 결과가 들쭉날쭉하고 환각과 누락을 만듦. 엄격한 기준을 가진 anti-pattern을 명시하고 그것만 탐지하게 만들자 분석이 일관되고 실제 지표에 grounded됨
  • 3) traceability 강제: 모든 발견은 stage ID, task ID, node ID, operator 이름, 테이블 참조라는 실제 증거를 가리켜야 하고, 출력은 downstream 시스템이 추측 없이 소비할 수 있도록 엄격한 JSON
  • 탐지 패턴과 실제 사례(공통 흐름: LLM이 리스크 표면화 → 물리 플랜에서 검증 → 타겟 변경 → 영향 측정):
    • Missed broadcast join — 조인 한쪽이 96.6 MiB로 broadcast 가능한데 SortMergeJoin 선택. “broadcast 임계값이 너무 낮고 AQE skew 처리가 SMJ를 선호했을 것”
    • Skewed partitions — “skew 있다”가 아니라 어디에 얼마나: median 0 B, 최대 279.7 GiB, 파티션 16개. null-heavy 키의 left join이 거의 전부를 한 파티션에 밀어넣고 있었음
    • Missing partition/date filters — 파티션 술어 없이 23.5 TiB Iceberg 테이블 풀 스캔
    • Oversized broadcasts — 2.7 GiB, 2.2 GiB 멀티 GB broadcast 다중 발생. 즉시 실패하지는 않지만 드라이버 메모리 압박과 불안정한 성능 유발
    • Aggressive coalesce — 셔플 파티션이 2GB 초과 또는 advisory 크기의 10배 초과로 커지고 전체 병렬도가 executor core 수 아래로 떨어질 때
    • High spill — 총 spill 1GB 초과, 입력 대비 20%+, 또는 stage 내 다수 task에서 발생. 5GB 초과면 심각도 상향
    • Join으로 인한 데이터 폭발 — 출력 row가 최대 입력 대비 2배 이상 증가(중복 키, 술어 누락, 잘못된 조인 grain)
  • 프롬프트 전략: 애플리케이션에서 가장 느린 SQL만 분석, 보고 전 증거 교차 확인, 모든 관찰을 stage/task/node ID로 grounding, 검증된 detection만 구조화 JSON으로 출력 → false positive 제거
  • Spark 전문가를 대체하는 게 아니라 레버리지를 주는 것. LLM이 반복적 triage를 처리하고 엔지니어는 중요한 수정에 집중

주요 수치 / 사실

  • Missed broadcast 수정(임계값 상향, 쿼리 재작성 0): ~1시간 → ~30분
  • Skew 수정(null 키 처리): 3시간+ → 정상 런타임
  • 파티션 술어 추가: ~20분 → ~1분
  • Broadcast 전략 재작업: ~20분 → ~1분 + 안정성 개선
  • 전체 워크로드 기준 런타임 40–95% 감소, 컴퓨트 비용 50–90% 감소
  • 확장 방향: 새 룰 추가, Delta/Iceberg 특화 체크, 느린 stage를 개별 플랜 노드에 매핑, 임계값 조정, detection을 대시보드·알림으로 연결한 사전 튜닝

관련 위키

Source: 원문 보기

그래프 뷰

백링크