이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 Trino로 여러 데이터 소스를 조인하는 쿼리가 10분이 넘게 걸렸습니다. 처음엔 데이터 양 문제라고 생각했는데, Trino의 EXPLAIN ANALYZE로 실행 계획을 보니 조인 순서가 비효율적으로 선택돼 있었습니다.
큰 테이블과 작은 테이블 조인 시 브로드캐스트 조인을 명시적으로 힌트로 지정했습니다. 작은 테이블을 각 워커에 뿌려서 처리하는 방식으로 바꾸니 8분에서 45초로 줄었습니다.
처음엔 힌트를 잘못 써서 오히려 메모리 부족 에러가 났습니다. 브로드캐스트할 테이블이 워커 메모리보다 크면 역효과가 난다는 걸 그때 배웠습니다. 분산 쿼리 최적화는 실행 계획을 먼저 읽고 병목을 파악하는 것에서 시작한다는 기준이 그때 생겼습니다.
팀 프로젝트에서 Trino로 Hive 기반 로그 테이블을 조회할 때, 날짜 조건이 있는데도 전체 파티션을 스캔하는 현상이 있었습니다.
원인을 찾아보니 쿼리의 날짜 조건에 함수가 사용돼 파티션 프루닝이 비활성화된 것이었습니다. WHERE DATE(event_time) = '2024-01-01' 대신 WHERE event_date = '2024-01-01'로 바꾸니 파티션 프루닝이 적용됐고 스캔 범위가 당일 파티션으로 줄었습니다.
같은 결과를 내는 쿼리인데 작성 방식에 따라 성능이 100배 이상 차이났습니다. 이후로 파티션 컬럼에 함수를 씌우면 안 된다는 것을 팀 내 코드 리뷰 체크리스트에 추가했습니다. 분산 쿼리에서 쿼리 작성 방식이 실행 계획을 결정한다는 걸 그때 배웠습니다.
사이드 프로젝트에서 대용량 조인 쿼리가 중간에 뚝 느려지는 현상이 있었습니다. 로그를 보니 디스크 스필이 발생하며 처리 속도가 급격히 낮아졌습니다.
조인 중간 결과가 워커 메모리를 초과해 디스크에 기록되는 것이 원인이었습니다. 불필요한 컬럼을 조인 전에 미리 제거하는 방식으로 중간 결과 크기를 줄였습니다. SELECT * 대신 필요한 컬럼만 선택하고 조인 이전에 필터링 조건을 적용했습니다.
중간 결과가 30% 줄면서 스필이 사라지고 처리 속도가 3배 빨라졌습니다. 분산 쿼리에서 메모리 사용은 쿼리 작성 단계에서 이미 절반이 결정된다는 걸 그때 배웠습니다. 이후엔 대용량 조인 전에 항상 선택 컬럼과 필터를 먼저 정리하는 습관이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.