A
약 108초
로그 1억 건 처리 졸업 프로젝트에서 Spark 파티셔닝 실수를 고쳐 8배 성능을 낸 경험
Spark를 처음 써본 건 졸업 프로젝트에서 로그 데이터 1억 건 처리를 단일 머신으로 하다가 시간이 너무 걸려서였습니다. 분산 처리가 뭔지 개념만 알고 있었는데, 실제로 클러스터를 로컬에서 띄워보고 스테이지 분리와 셔플 비용이 병목이라는 걸 직접 확인했습니다. 처음 짠 코드가 오히려 단일 처리보다 느렸는데, 그 이유가 파티셔닝 전략이 잘못됐기 때문이었습니다.
키를 제대로 고르지 않아서 특정 익스큐터에 데이터가 쏠렸습니다. 이후 파티션 수를 조정하고 브로드캐스트 조인을 적용하면서 처리 시간이 8배 줄었습니다. Flink는 실시간 처리를 따로 공부하면서 개념만 잡고 있고, 아직 제품 수준으로 써본 적은 없습니다. 그 프로젝트 이후로 분산 처리 코드를 짜기 전에 데이터 흐름을 먼저 그리는 습관이 생겼습니다.
이 결의 특징
학습 과정에서 만난 구체적인 실패를 정확히 진단한 서술입니다. 파티셔닝 실수가 무엇인지, 어떻게 측정했는지, 무엇으로 8배 개선했는지 단계별로 이어집니다.
이 결이 통하는 자리
성능 개선의 근본 원인을 찾아내고 수정하는 과정을 중요하게 보는 데이터 엔지니어링 조직에서 신뢰를 얻습니다. 숫자로 측정하고 개선했다는 증거가 명확할 때 실무 역량이 인정되는 환경과 맞닿아 있습니다.