Recommended
More Related Content
What's hot
What's hot (12)
R 속도 향상을 위한 소소한 팁
- 1. R 속도 향상을 위한 소소한 팁 Enterprise분석1팀 채규병
- 2. 목차 1. 들어가며 2. R vs Python 3. TIP 1 : 컴퓨터를 바꾸자 4. TIP 2 : 필요한 연산만 하자 5. TIP 3 : 병렬 처리시 주의 할점 6. TIP 4 : R한테 잘하는것만 시키고 나머지는 다른 툴한테 시키자 7. 결론
- 3. 들어가며: 12시간 → 2시간의 비밀? 2020년 10월 U+ CRM 2.0에서 거리를 계산 전국 1900 개 U+매장 X 80만 개 RN장비 X 400만개 영업 대상(소상공인) = 6,080,000,000,000,000????
- 4. 우리 팀 선호도는? R vs Python 설문조사 결과 총 32명 17 대 15로 R 승리!! 그러나???
- 5. R vs Python 어떤 언어가 더 빠를까요? 10000 이상 R은 lapply 함수를 사용할 때 Python을 능가!! R에서 for 루프는 느리다 그러나 R이 Python보다 언제나 느 린 것은 아니다! R을 이해하고 조금만 신경 써주면 훌륭한 퍼포먼스를 낼 수 있다!! 반복 횟수가 1000 회 미만인 경우 Python > R 100 단계 미만 Python이 R보다 최대 8 배 빠름 물론 Python이 대부분의 경우 빠름 출처: https://datascienceplus.com/loops-in-r-and-python-who-is-faster/
- 6. R은 왜 느릴까? Call by Value VS Call by Reference 깊은 복사 VS 얕은 복사 객체 생성을 많이 하면 R이 느려지는 주된 이유!! R은 분석가에게 친절하다! 컴퓨터에겐 차갑다… 주소값만 복사하는 것과 값 자체를 복사해오는 것은 컴퓨터에겐 천지차이!!
- 7. R은 왜 느릴까?
- 8. R은 왜 느릴까? list vs environment 둘 다 key와 value를 갖는 Map 구조 객체만 바꿨을 뿐인데??
- 9. R 속도 향상 방법 1 : 컴퓨터를 바꾸자 요새 딥러닝 덕분에 GPU, RAM, CPU코어 수 등에 관심 높아졌으나, 보통 분석가들은 하드웨어에 관심이 없는 경우가 많음. QUIZ!!! 현재 클라우드 PC의 RAM의 크기는? 코어 수는? 오창 분석 서버(117)의 RAM 크기는? 코어 수는?
- 10. R 속도 향상 방법 1 : 컴퓨터를 바꾸자
- 11. TIP 2 : 필요한 연산만 하자 사실 대부분의 연산이 낭비되고 있다!
- 12. TIP 2 : 필요한 연산만 하자 U+ 매장별로 가까운 거리를 기준으 로 ‘영업 대상’을 지정하려면? 1,900 개의 매장 X 4,000,000 개의 SOHO = 7,600,000,000 (76억번 연산) 1,900 개의 매장 X 1,250,000 개의 건물 = 2,375,000,000 (23.75억번 연산) 약 68% 연산량 감소
- 13. TIP 3 : 병렬 처리시 주의 할 점 병렬처리는 쪼개고 합치는 작업, 즉 오버헤드를 고려해야 합니다.
- 14. TIP 3 : 병렬 처리시 주의 할 점 코어1 코어2 코어3 작업 코어가 3개라면 작업을 몇 개로 나누어야 할까?
- 15. TIP 3 : 병렬 처리시 주의 할 점 코어1 코어2 코어3 작업 결과
- 16. TIP 3 : 병렬 처리시 주의 할 점 코어1 코어2 코어3 작업 결과 오 버 헤 드
- 17. TIP 3 : 병렬 처리시 주의 할 점 코어1 코어2 코어3 작업 결과 오 버 헤 드
- 18. TIP 4 : 다른 도구와 함께 조인 연산은 DBMS가 잘한다. 잘하는 애에게 잘하는 것만 시키자 열1 열2 열3 열4 R에서 880만 건 열1 열2 열3 열4 ... ... …. ... 다른 테이블 과 조인 후 2700만 건
- 19. 결론 : 약간만 신경 쓰자 “조기 최적화는 모든 악의 근원입니다. 97%의 시간 동안 작은 효율성은 잊어야합니다. 그러나 우리는 그 중요한 3 %의 기회를 포기해서는 안됩니다. 훌륭한 프로그래머라면 중요한 코드를 주의 깊게 살펴 보아야 합니다. 하지만 그 코드가 제대로 돌아간 후에 말이죠” — Donald Knuth.
- 20. 참고 1. Getting Started with doMC and foreach (https://cran.r-project.org/web/packages/doMC/vignettes/gettingstartedMC.pdf) 2. R에서 병렬처리 하기([https://cinema4dr12.tistory.com/entry/Data-Science-Data-Mining-with-R-R%EC%97%90%EC%84%9C- %EB%B3%91%EB%A0%AC%EC%B2%98%EB%A6%AC-%ED%95%98%EA%B8%B0#6) 3. R에서 코드를 병렬처리 하는 방법 [https://devlab.neonkid.xyz/2019/02/10/R/R%EC%97%90%EC%84%9C- %EC%BD%94%EB%93%9C%EB%A5%BC-%EB%B3%91%EB%A0%AC%EC%B2%98%EB%A6%AC-%ED%95%98%EB%8A%94- %EB%B0%A9%EB%B2%95/] 4. High performance computing in R using doSNOW package http://biostat.mc.vanderbilt.edu/wiki/pub/Main/MinchunZhou/HPC_SNOW.rwn.pdf 5. 사용자 관점에서의 R 병렬 컴퓨팅 https://cinema4dr12.tistory.com/1024 6. https://sodocumentation.net/ko/r/topic/1677/%EB%B3%91%EB%A0%AC-%EC%B2%98%EB%A6%AC 7. cores 개수의 결정 https://thebook.io/006723/ch05/07/01-01/ 8. https://arxiv.org/pdf/1503.00855.pdf 9. http://adv-r.had.co.nz/Environments.html 10. https://cran.r-project.org/doc/manuals/R-lang.html#Environment-objects 11. https://www.r-bloggers.com/2013/04/faster-higher-stonger-a-guide-to-speeding-up-r-code-for-busy-people/ 12. https://stackoverflow.com/questions/2908822/speed-up-the-loop-operation-in-r 13. http://www.burns-stat.com/pages/Tutor/R_inferno.pdf
Editor's Notes
- 농담이 아닙니다. 하드웨어 성능이 떨어지면 아무리 코드를 바꾸어도 속도는 개선되지 않을 수 있습니다. 코드가 느리다면 자신의 하드웨어가 어떤 스펙을 가지고 있는지 살펴봅시다. 요즘 딥러닝 등으로 GPU, RAM과 CPU의 코어 수 등에 관심도 높아지고 있어 쉽게 설명한 자료도 많습니다. 간단한 CPU 코어와 RAM에 대한 설명은 참고자료(8)을 보면 좋습니다. 자신이 사용하고 있는 하드웨어를 확인하는 것이 왜 중요할까요? 저는 이번 프로젝트에서 샌드박스라고 VM을 할당받아서 사용하고 있었습니다. 그런데 기존의 프로그램이 개발되었던 프로젝트는 A 샌드박스를 사용하고 있었지만, 저는 B 샌드박스를 할당받았습니다. 그런데 똑같은 코드를 돌려도 너무나 느린 겁니다. 알고보니 A 샌드박스는 RAM이 144GB에 8 코어였고, B는 96GB에 4 코어였습니다. 이것도 모르고 기존 코드대로 8코어로 병렬처리를 돌리니 속도도 느리고, 메모리 문제도 발생했습니다. 꼭 자신의 하드웨어 성능을 확인해보는 걸 잊지 맙시다. R에서는 운영체제에 따라 명령어를 실행해볼 수 있는 system()이라는 함수가 구현되어 있습니다. 운영체제에 맞게 자신의 하드웨어 스펙을 확인해보면 되겠습니다. 아래 코드는 리눅스에서 현재 R 프로세스에 할당된 VM 크기와 여유 메모리를 확인하는 예시입니다.
- R에서는 운영체제에 따라 명령어를 실행해볼 수 있는 system()이라는 함수가 구현되어 있습니다. 운영체제에 맞게 자신의 하드웨어 스펙을 확인해보면 되겠습니다. 아래 코드는 리눅스에서 현재 R 프로세스에 할당된 VM 크기와 여유 메모리를 확인하는 예시입니다. parallel 패키지는 뒤에 더 자세히 말씀드리겠니다만 코어를 확인해주는 함수를 가지고 있습니다. 코어를 확인해봅시다. 두 코드가 다른 결과를 보여줄텐데 이에 대해서는 logical core를 구글에 검색해서 공부해봅시다.
- 정말로 이 계산이 필요한가? 사실 대부분의 계산은 필요가 없습니다. 필요 없는 계산을 하는 사람이 있을까 싶지만 생각보다 많은 사람들이 비슷한 실수를 하고 있습니다. 위 코드는 어떤 결과를 보고 싶었던 걸까요? distRN이라는 거리를 계산한 벡터에서 제일 근접한 거리, 즉 제일 작은 거리를 도출하기 위한 코드입니다. 이를 위해 order() 함수를 통해서 distRN을 순서대로 정렬하고 제일 앞에 있는 인덱스를 찾습니다. 여기서 정렬은 굉장히 리소스를 많이 잡아먹는 행위입니다. 모든 벡터의 값을 하나씩 비교해봐야 하고 매번 정렬하면서 새로운 벡터도 생성해야 합니다. 그러나 which.min()함수를 사용하면 정렬한 벡터를 생성하지 않고도 원하는 결과를 얻을 수 있습니다.
- 이처럼 컴퓨팅 방식 변경 말고도 본질적으로 정말 필요한지 생각해볼 수 있습니다. 저는 매장과 SOHO(소상공인) 사이의 거리를 계산하고 있었는데요. 400만 개의 SOHO가 있었습니다. 그런데 과연 주어진대로 400만 번 거리 계산을 수행하야만 할까요? 한 건물에 있는 SOHO는 그 거리가 몇 미터 이내입니다. 거의 차이가 없죠. 게다가 비즈니스적으로도 이러한 몇 미터 차이는 아무 의미가 없습니다. 왜냐하면 영업점 별로 영업 타겟을 선정할 때에 구역별로 선정하기 때문입니다. 그래서 건물별 좌표를 확인해보니 125만 개가 되었습니다. 즉 한 건물에 있는 SOHO는 한 좌표로 보겠다는 겁니다. 이렇게 해서 275만 번의 계산을 줄일 수 있었습니다. 왜 이 계산이 필요하지라고 질문했을 뿐인데 70%의 계산을 줄일 수 있었습니다.
- 기본적으로 R은 단일 프로세스로서 단일 코어에서 계산이 됩니다. 하지만 병렬처리도 가능합니다. 어렵지도 않습니다. 이미 구현된 패키지를 가져다가 쓰면 됩니다. 여러 가지가 있지만 doSNOW, doParallel, parallel 이 3가지 패키지를 추천합니다. 사용법도 직관적이고 쉽고, 옵션도 꽤 다양하게 줄 수 있습니다. 하지만 병렬 처리를 한다고 해서 무조건 빨라지지 않습니다. 동시에 계산을 하기 위해서 한 가지 작업을 쪼개야 합니다. 그리고 이 쪼갠 작업의 결과를 다시 합치는 추가적인 리소스가 필요하기 때문입니다. 기존 코드는 8 코어에서 210만개의 프로세스를 생성했습니다. 그냥 거리 계산 한 건을 하나의 프로세스로 잡은 것이지요. 그래서 하나의 계산보다 병렬 처리를 위한 사전 작업이 더 오래 걸리는 문제가 생겼습니다. 저는 이러한 병렬처리의 사전 작업을 줄이기 위해서, 건 바이 건이 아닌 Chunk로 묶어서 처리하고자 했습니다. 210만 개를 8개의 Chunk로 쪼갭니다. 그리고 이를 각각 코어에 맡겼습니다. 그래서 합치는 작업은 8번만 수행이 되는 것이지요. 어차피 8개의 코어라면 8배 속도 개선을 생각하는 것이 최선일 것입니다. 이렇게 미리 쪼개고 병렬처리하는 것이 의도대로 잘 동작하는 편입니다.
- 예를 들어 연산이 100만 번 필요하다고 해봅시다. 이 작업을 100만 개로 쪼개서 병렬 처리한다고 빨라질까요? 무조건 병렬 처리를 하는 것이 능사가 아닙니다. 왜냐하면 병렬 처리는 오버헤드가 발생하기 때문입니다. 오버헤드(overhead)는 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간 · 메모리 등을 말한다. 예를 들어 A라는 처리를 단순하게 실행한다면 10초 걸리는데, 안전성을 고려하고 부가적인 B라는 처리를 추가한 결과 처리시간이 15초 걸렸다면, 오버헤드는 5초가 된다. 또한 이 처리 B를 개선해 B'라는 처리를 한 결과, 처리시간이 12초가 되었다면, 이 경우 오버헤드가 3초 단축되었다고 말한다
- 예를 들어 연산이 100만 번 필요하다고 해봅시다. 이 작업을 100만 개로 쪼개서 병렬 처리한다고 빨라질까요? 무조건 병렬 처리를 하는 것이 능사가 아닙니다. 왜냐하면 병렬 처리는 오버헤드가 발생하기 때문입니다. 오버헤드(overhead)는 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간 · 메모리 등을 말한다. 예를 들어 A라는 처리를 단순하게 실행한다면 10초 걸리는데, 안전성을 고려하고 부가적인 B라는 처리를 추가한 결과 처리시간이 15초 걸렸다면, 오버헤드는 5초가 된다. 또한 이 처리 B를 개선해 B'라는 처리를 한 결과, 처리시간이 12초가 되었다면, 이 경우 오버헤드가 3초 단축되었다고 말한다
- 예를 들어 연산이 100만 번 필요하다고 해봅시다. 이 작업을 100만 개로 쪼개서 병렬 처리한다고 빨라질까요? 무조건 병렬 처리를 하는 것이 능사가 아닙니다. 왜냐하면 병렬 처리는 오버헤드가 발생하기 때문입니다. 오버헤드(overhead)는 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간 · 메모리 등을 말한다. 예를 들어 A라는 처리를 단순하게 실행한다면 10초 걸리는데, 안전성을 고려하고 부가적인 B라는 처리를 추가한 결과 처리시간이 15초 걸렸다면, 오버헤드는 5초가 된다. 또한 이 처리 B를 개선해 B'라는 처리를 한 결과, 처리시간이 12초가 되었다면, 이 경우 오버헤드가 3초 단축되었다고 말한다
- 예를 들어 연산이 100만 번 필요하다고 해봅시다. 이 작업을 100만 개로 쪼개서 병렬 처리한다고 빨라질까요? 무조건 병렬 처리를 하는 것이 능사가 아닙니다. 왜냐하면 병렬 처리는 오버헤드가 발생하기 때문입니다. 오버헤드(overhead)는 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간 · 메모리 등을 말한다. 예를 들어 A라는 처리를 단순하게 실행한다면 10초 걸리는데, 안전성을 고려하고 부가적인 B라는 처리를 추가한 결과 처리시간이 15초 걸렸다면, 오버헤드는 5초가 된다. 또한 이 처리 B를 개선해 B'라는 처리를 한 결과, 처리시간이 12초가 되었다면, 이 경우 오버헤드가 3초 단축되었다고 말한다
- 다른 Tool도 활용해보자 대량의 데이터 구조 변경(join)은 R의 전문 영역이 아닙니다. 오히려 Hadoop 기반의 Impala가 전문이죠. R에서만 모든 것을 하려고 하기보다는 각 언어나 프로그램의 장점을 살려서 작업하는 것이 좋습니다. R에서 생성하는 데이터는 최대한 열을 줄이고 압축했습니다. 그리고 Impala에서 조인을 통해 원하는 형태로 데이터를 만들었습니다. R에서 4개의 열로 880만건인 결과를, 고객이 원하는 형태로 만들면 2700만 건이 되었습니다. dplyr 의 left_join()함수도 빠르긴 하지만, 여전히 R에서 리소스를 사용하는 것은 굉장히 비싼 일입니다. 또한 이러한 방식은 네트워크 속도나 안정성에서도 이점을 얻을 수 있습니다. 2700만 건을 DB에 밀어넣기보다는 880만 건을 밀어넣는 것이 더 빠르겠죠?