수없이 다양한 원인과 에러가 발생합니다. 주요 이슈와 해결 방법을 확인합니다.
● 모니터링 대상
- 어플리케이션의 프로세스 (CPU, 메모리 사용률 등)
- 프로세스 내부의 쿼리 실행 과정 (Job과 Task)
● 디버깅 및 응급처치
-
느리거나 뒤처진 태스크 : 머신 간에 작업이 균등하게 분배되지 않은 경우 자주 발생합니다.
- 스파크 UI를 통해 태스크 간에 데이터가 불균현한지 가장 먼저 확인합니다.
- 파티션별 데이터양을 줄이기 위해 파티션 수를 증가시켜봅니다.
- 다른 컬럼을 조합해 파티션을 재분배합니다. 예를 들어 데이터 치우침이 심한 ID 컬럼을 파티셔닝하거나, 컬럼에서 많은 값이 null이라면 느린 태스크(낙오자)가 발생할 수 있습니다. 후자의 경우 null을 먼저 필터링하는게 좋을 수 있습니다.
- 익스큐터의 메모리를 증가시킵니다.
-
느린 집계 속도
- groupby 호출 시 느린 태스크가 발생하고 집계 처리 이후 잡도 느린 현상이 있습니다.
- 집계 연산 전에 파티션 수를 증가시켜 태스크별로 처리할 키 수를 줄입니다.
- 익스큐터의 메모리를 증가시킨 경우 데이터가 많은 키를 처리하는 익스큐터는 다른 키를 처리하는 익스큐터에 비해 여전히 느릴 수 있습니다. 하지만 데이터를 디스크에 저장하는 빈도를 줄일 수 있어 이전보다 더 빠르게 처리할 수 있습니다.
- 집계 처리가 끝나고 이어서 실행되는 태스크가 느리다면 집계 처리된 데이터셋에 불균형 현상이 남아있음을 의미합니다. 이 경우 파티션을 임의로 재분배할 수 있도록 repartition을 해야합니다.
-
느린 조인 속도
- 여러 조인 타입 중 상황에 가장 맞는 타입으로 최적화합니다.
- 조인 순서를 변경하면서 잡의 처리속도가 올라가는지 테스트합니다.
- 조인 전에 데이터셋을 분할하면 클러스터 노드 간 데이터 이동을 줄일 수 있습니다. 동일한 데이터셋이 여러 조인 연산에서 사용된다면 더욱 유용합니다.
- 모든 필터와 select 구분이 조인연산보다 우선 처리된다면 필요한 데이터만 이용해서 조인 연산을 수행할 수 있습니다.
- 하느이 테이블이 작은 경우 브로드캐스트 조인을 하거나 스파크의 통계 수집 명령을 통해 테이블을 분석한 후에 조인을 수행합니다.
-
드라이버 OutOfMemory 또는 응답없음
- 원인이 너무 많아 복잡한 문제입니다.
- 사용자가 collect와 같은 명령어를 통해 드라이버를 너무 많은 데이터를 전송하려고 시도했을 수 있습니다.
- 너무 큰 데이터를 브로드캐스트 조인에 사용했을 수 있습니다.
- 익스큐터 OutOfMemory 또는 응답없음
- 익스큐터의 가용 메모리와 인스큐터 수를 증가시킵니다.
- 워커 스펙을 올립니다.
- 로그에 가비지 컬렉션 오류가 발생했는지 확인합니다. 실행중인 태스크의 일부가 너무 많은 객체를 생성하고 있어서 가비지 컬렉션이 발생했을 수 있습니다. 특히 UDF를 사용하는 경우에 발생활 확률이 높습니다. 파티션을 재분배하여 병렬성을 높이고, 태스크 별로 처리해야하는 양을 줄입니다.
- 모든 익스큐터에 동일한 양의 작업이 할당되었는지 확인합니다.
yozzum