Big Data 스파크 배치를 성능개선하다 (리팩토링)

 

최근에 Big Data 처리 배치 성능개선에 대한 고민을 할 기회가 있었다.
전체 소요시간을 3시간 이상 줄여야하는 도전적인 과제였는데, 결국 성공했다...! (뿌듯)

 
 
 
 
 

---

데이터 입수 상황

---

 

 
1) 원본 소스 데이터세트는 10개 가량이다.
 
2) 1차 마트 데이터를 만드는 dag은 원본 소스 데이터 10개의 완료시점을 계속 감지하고 있다. (sensor 존재)
센서가 10개 다 성공하면, 10개 데이터에 여러가지 필터를 적용하여 1차 마트 데이터를 만든다.
 
3) 2차 마트 데이터는 1차 마트 데이터를 기반으로 만드는데, 이벤트 시간을 주요 검색 key로 사용한다.
 
 
 

---

리팩토링 방법

---

 

 

A. 센서 병렬화

이것은 아주 단순한 아이디어였는데, 크게 효과가 있었다.
센서 10개가 다 성공한 후 전체 데이터를 만들지 말고, 센서 1개가 성공할 때마다 데이터를 조금씩 조금씩 만들면 어떨까?라는 아이디어.
그러니까 빨리 할 수 있는 숙제들은 미리 해놓고, 늦을 수 밖에 없는 것들만 나중에 처리하는 것이다.
 
 
 
 

---

 
 
 
 

 

B. skew 제거

배치가 오래 걸리는 이유는, 데이터가 큰 것도 있지만, skew task가 원인인 케이스가 대부분이다.
하나의 task에 row가 몰빵되어서... 다른 task들은 호다닥 끝났음에도, 언제나 늦게 끝나는 한 두개의 task를 기다리는 상황.
이번에도 그럴 것이라 생각했고, 역시나 그랬다.
 
skew를 완화하면 실행 시간이 크게 줄어든다. (하지만 말이 쉽지...)
 
salting 기법 등등 사용했음에도 문제가 풀리지 않아서, skew가 발생하는 원인을 도메인적으로 파악하려고 했다.
 
 
내 경우에는, 파악해보니 어뷰징 케이스들이 있었다. 어뷰징 조건을 정의하여, 해당하는 row들은 정제대상에서 아예 제외를 시켜버렸다
즉, 그 무거운 문제 row들은 task에서 빠지게 되었고, skew가 완화될 수 있었다.
 
 
 
 
 

---

 

 

 

C. 테이블 포맷 변경

와우...!! A,B까지 하고 나니 아주 획기적으로 소요 시간이 줄어든 상황.
그렇지만 조금 더 줄여보고 싶었다.
 
마지막 아이디어는, 1차 마트 데이터를 잘 정렬해서 준비해놓는 것이었다.
쉽게 말해, 챕터마다 책갈피를 만드는 것!
그러면 데이터 검색 범위가 획기적으로 줄어들 것이다. 해당 책갈피 부분만 열어서 검색해보면 되니까...!
 

포스트잇 플래그와 같은 원리

 
 
테이블 포맷을 iceberg로 변경하고, 이벤트 시간으로 정렬하면 이런 '플래그'효과를 누릴 수 있다.
iceberg는 메타데이터에 파일별 컬럼 최소/최대값 범위를 저장하고 있기 때문이다.
 
과거에는 스파크 엔진이, 해당 시간대 이벤트를 찾기 위해 전체데이터셋을 다 뒤져야했지만,
변경 이후에는 해당 이벤트가 들어있는 '파일'을 특정할 수 있어졌다.
 
데이터 볼륨이 클수록 시간 감소 효과는 더욱 커진다.
 
 
 

---

 
✔️ 관련포스팅
 
2025.01.15 - [개발지식 아카이브/Data - Iceberg] - [Apache Iceberg] 아이스버그 테이블 최적화 - 메트릭 수집

[Apache Iceberg] 아이스버그 테이블 최적화 - 메트릭 수집