TIL(20241111) [Creator_hub 프로젝트 성능최적화]
일단 spark을 다루는 나의 미숙함에 정말 좌절의 쓴 맛을 많이 맛보았다.
내가 과연 할 수 있을까? 이런 생각도 많이 했었고, 정말 데이터 처리를 잘 해보고싶은 마음이 컸다.
잘 알지 못하지만.. 그래도 spark로 기능 구현을 해보며 알아가고 싶었다. 그래서 삽질도 많이 하고.. 그랬나보다.
먼저 내가 구현하려고 계획 중인 기능은 추천동영상이다.
정말 단순하게 user는 회원가입시 관심사 3개를 선택하게 되고 해당 사항이 db에 저장된다. 그리고 youtube data api를 사용했는데, 동영상 list 를 get요청 해보면 videoId에 tags라는 리스트가 있다. users의 관심사와 video의 tags의 키워드와 유사도를 계산하는 방식으로 구현해서 추천동영상을 구현해보았다.
처음에는 TF-IDF, 코사인 유사도 (Cosine Similarity)로 구현을 어찌저찌 했는데.. 문제는 user의 관심사에 대한 벡터화가 잘 이루어지지 않았다. 지식 부족이다. (나는 문과생이라 어떻게든 벡터화를 이해해보려고 노력했다..😂)
어쨌든 추천 동영상 Id들은 DB에 들어오는데 문제는 유사도에서 0으로 측정되는 것이다. 그래서 로그를 찍어보며 확인했는데. TF-IDF의 과정에서 문제가 있는 것 같았다.
1
2
3
4
TF-IDF란?
TF-IDF는 문서 내에서 특정 단어가 얼마나 중요한지를 평가하는 데 사용되는 방식입니다.
텍스트 분석에서 자주 등장하는 개념으로, 각 단어의 **출현 빈도(Term Frequency, TF)**와 그 단어가 다른 문서에서는
얼마나 드물게 등장하는지(Inverse Document Frequency, IDF)를 결합하여 단어의 중요도를 계산합니다.
user의 데이터는 TF-IDF 계산이 당연히 안된다.. 왜냐하면.. 출현빈도가 당연히 한 번 뿐이니.. 한 번 뿐이라는건 user의 관심사는 문서에 자주 등장하지 않는다. 한 번 딱 정의된 값인데, 어떻게 자주 등장할 수 있는가… 뒤늦게 알아챈 나에게 꿀밤을 한 대 먹이고 단순한 방법인 문자열 비교로 넘어갔다.
참고로 이게 좋은 성능 최적화인지는 모르겠지만 나의 최선이다. 앞으로도 조금씩 더 공부를 해보며 나아가야지!
💡 BroadCast vs Repartition(Suffle join)
본론부터 하면 postman으로 API 요청을 했을 때 거의 8-9초 대가 나왔다. 그래서 성능최적화가 필요했고, 어디서 문제가 있는지 살펴볼 필요가 있었다.
성능 테스트 도구로 Spark UI를 사용했다. 직관적이라 spark -shell보다 편리하다..ㅎㅎ
BroadCast
1
2
3
브로드캐스트는 작은 데이터셋을 모든 노드에 공유하여 네트워크 트래픽을 줄이고,
중복 데이터 전송을 방지하며, 샤플(shuffle) 연산을 피하는 등, 성능을 최적화하는 중요한 기술입니다.
조인 연산이나 빈번하게 참조되는 작은 데이터셋을 처리할 때 매우 유효하게 활용될 수 있습니다.
왜 브로드캐스트를 사용하나?
- 네트워크 효율성: 큰 데이터를 여러 컴퓨터에 나눠서 처리할 때, 작은 데이터를 매번 모든 컴퓨터에 보내면 시간이 많이 걸려요. 브로드캐스트를 사용하면 작은 데이터를 한 번만 보내고, 각 컴퓨터에서 그 데이터를 재사용할 수 있어요. 네트워크 비용이 줄어듭니다.
- 중복된 데이터 전송 방지: 예를 들어, 작은 데이터를 각 컴퓨터로 여러 번 보내면, 그만큼 네트워크 트래픽이 증가하고, 시간을 낭비하게 돼요. 브로드캐스트는 이 데이터를 한 번만 보내기 때문에 더 효율적입니다.
- 빠른 계산: 작은 데이터를 각 컴퓨터에 로컬로 저장한 후, 다른 큰 데이터를 처리하는 작업을 할 때, 그 데이터를 매번 찾을 필요 없이 빠르게 참조할 수 있어요. 계산이 빨라집니다. 예시 예를 들어, 사용자 정보(작은 데이터)와 영화 데이터(큰 데이터)를 조인해야 한다고 해볼게요.
- 브로드캐스트 없이 작은 사용자 정보를 매번 큰 영화 데이터와 조인할 때마다 모든 컴퓨터로 사용자 정보를 보내야 해요. 그만큼 시간이 오래 걸리고, 네트워크에 부담이 됩니다.
- 브로드캐스트 사용 작은 사용자 정보를 모든 컴퓨터에 한 번만 보내고, 그 컴퓨터들이 로컬에서 데이터를 빠르게 참조하도록 만들면, 조인 작업이 훨씬 더 빠르고 효율적으로 처리됩니다.
즉, 브로드캐스트는 작은 데이터를 모든 컴퓨터에 한 번만 보내서 중복되는 전송을 줄이고, 계산을 더 빨리 할 수 있게 도와주는 기술이에요.
user의 관심사는 video에 비해 엄청나게 작은 데이터이기 때문에 브로드 캐스트를 사용하면 좋겠다고 생각했다.
총 소요 시간=0.050+0.2+0.3+0.043+3+0.2+0.060+0.033+3+0.2+0.3+0.026+0.023 즉, 7.406seconds
큰 변화가 없었다.
Repartition(Suffle join)
1
2
3
**리파티셔닝(Repartitioning)**은 데이터를 여러 파티션으로 나누는 작업을 말합니다.
Spark에서는 데이터를 분산 처리하기 위해 데이터를 파티션이라는 작은 단위로 나누어 처리하는데, 리파티셔닝은 기존의 파티션 구조를 변경하거나 새롭게 재구성하는 과정입니다.
쉽게 말하면, 리파티셔닝은 데이터를 여러 조각으로 나누어 두어서, 각각의 파티션에서 병렬로 처리할 수 있도록 돕는 작업이에요.
언제 리파티셔닝을 사용해야 할까?
리파티셔닝을 사용할 때는 성능 개선을 위한 목적이 필요합니다. 하지만 리파티셔닝도 비용이 발생할 수 있기 때문에 불필요하게 많이 사용하면 오히려 성능이 나빠질 수 있습니다. 리파티셔닝을 사용할 때 주의해야 할 점은 다음과 같습니다
- 조인이 필요한 경우: 조인 전에 데이터를 리파티셔닝하면 셔플을 줄이고 성능을 향상시킬 수 있습니다.
- 불균형한 데이터 처리: 데이터가 특정 파티션에 몰려 있는 경우, 리파티셔닝을 통해 균등하게 분배할 수 있습니다.
- 적절한 파티션 수 설정: 너무 적거나 너무 많은 파티션을 만들지 않도록 적절한 파티션 수를 설정해야 합니다.
총 소요 시간=0.029+0.9+0.2+0.8+0.3+3+0.3+0.3+0.037+0.026 즉, 5.886seconds
기존대비 20.5%로가 향상된 것을 알 수 있다.
RDD 쪽에서 뭔가 오버헤드가 많이 발생하는 것 같은데.. 이 부분도 파헤쳐 봐야한다.. 화이띵…