A
약 80초
분산 환경 데이터 처리 경험 구체적 수치 중심
졸업 논문 연구에서 약 3GB 규모의 로그 데이터를 단일 머신으로 처리하다가 메모리 부족 문제가 발생했습니다. Spark를 처음 써보면서 데이터를 파티션으로 나눠 병렬 처리하는 구조로 전환했고, 처리 시간이 로컬 pandas 대비 약 8배 빨라졌습니다. 가장 어려웠던 건 파티션 수 튜닝이었는데, 너무 많으면 스케줄링 오버헤드가 생기고 너무 적으면 병렬화 효과가 없어서 데이터 크기 대비 2~4배 파티션이 적합하다는 걸 실험으로 확인했습니다. 또한 조인이 많은 경우 broadcast join으로 셔플 비용을 줄이는 방식도 적용했습니다. 앞으로도 분산 처리에서 파티셔닝 전략과 셔플 최소화를 먼저 고려하는 방식을 유지하겠습니다. 앞으로도 분산 처리 설계에서 파티셔닝 전략과 셔플 비용 최소화를 먼저 고려하는 방식을 유지하겠습니다.
데이터 규모가 커질수록 설계 초기의 파티션 전략이 성능에 미치는 영향이 커집니다. 실험으로 최적값을 직접 확인하는 습관이 이론만으로는 알기 어려운 현장 감각을 키우는 방법입니다.
이 결의 특징
3GB 로그 데이터를 단일 머신으로 처리하다 메모리 부족을 겪고 Spark로 파티션 병렬 처리로 전환해 처리 시간을 8배 단축한 흔적이 있습니다. 파티션 수를 실험으로 튜닝하고 broadcast join까지 적용한 지점이 이어집니다.
이 결이 통하는 자리
문제 상황과 전환 이유, 구체적 수치 개선이 순서대로 이어질 때 통합니다. 실험으로 최적값을 직접 확인했다는 태도가 붙어 있을 때 면접관이 현장 감각을 읽는 결이 보입니다.