ray 객체 개념 정리
ray에서 작업과 액터는 객체를 생성하고 계산하는데 이 객체는 ray 클러스터 어디서나 저장될 수 있기 때문에 원격 객체라고 한다.
객체 참조를 통해 원격 객체를 참조하고, 원격 객체는 ray의 분산 공유메모리 객체 저장소에 캐시되며 클러스터의 노드당 하나의 객체 저장소가 존재한다. 클러스터 세팅에서 원격 객체는 하나 혹은 그 이상의 노드에 있을 수 있다.
객체 참조는 값을 보지 않고 원격 객체를 참조할 수 있는 포인터 혹은 고유한 id이다. ray 객체 참조는 futures와 유사하다.
객체 참조는 두가지 방법으로 만들 수 있는데
- 원격 함수 호출에 의해 반환(remote)
- put(docstring)에 의해 반환
- 원격 객체는 생성후에 변경이 불가하다. 원격 객체는 복사본을 동기화할 필요없이 여러개의 객체 저장소에 복제 가능하다.
- get메서드( docstring )를 사용 하여 개체 참조에서 원격 개체의 결과를 가져올 수 있고 현재 노드의 객체 저장소에 객체가 없으면 객체가 다운로드된다.
- ray는 플라즈마 객체저장소를 사용해서 객체를 다른 프로세스와 다른 노드로 전달한다.
- 객체 저장소 내에 있는 넘피배열은 같은 노드의 작업자끼리 공유된다(zero-copy deserialization).
- ray는 PyArrow serializer대신 Pickle protocol version 5를 사용해서 직렬화한다.
테스트 결과
| dask | dask-on-ray | 차이 | |
|---|---|---|---|
| k-model | 14분 20초 | 14분 3초 | 18초 |
| l-model | 13분 39초 | 13분 2초 | 37초 |
| t-model | 18분 14초 | 15분 46초 | 2분 28초 |
dask-on-ray를 사용한 t-모델 테스트 추가 진행
write/read parquet 지우고 테스트
-> 17분 48초
-> 더 오래걸림
t-모델 데이터프레임에 put, get 사용
-> 21분 51초
-> 더 오래걸림
persist()메소드 사용
-> 14분 13초
-> 더 빨라짐
테스트 결과 분석
-
모든 경우에서 레이 사용했을때 좀더 빨랐다.
-> 연산이 복잡해 질수록 레이의 효과가 더 좋은것으로 예상되는데. 좀더 큰 데이터에 대해서도 테스트가 필요하다.
-> 1b짜리 데이터도 테스트를 진행했으나, ray를 돌렸을때 spill되는 양이 너무 많아서 죽어버림. -
k모델이 l모델 보다 오래걸림...왜??
-
write/read parquet 안하면(파케파일로 변환안하면) 더 느려짐...왜.?
-> 레이는 파이썬 객체를 직렬화하기 위해 피클 프로토콜 버전5를 사용하는데, 얘는 다양한 범위의 데이터 타입을 다룰수 있기 때문에(판다스 데이터프레임, 넘피 배열 등) 굳이 파케파일로 변환할 필요가 없고 그냥 데이터를 레이 클러스터에 넘겨주면 레이가 데이터를 직렬화하고 저장한다.
하지만 경우에 따라 파케파일로 변환하는 것을 고려해 볼 수 있는데, 파케파일 자체가 압축된 파일이므로 메모리랑 디스크 공간을 절약하기 때문에 저장 오버헤드를 줄여줄 수 있다. 파케같은 columnar(열 형식)는 효율적인 압축이 가능하고 디스크에서 읽어야 하는 데이터의 양이 줄어들기 때문에 큰 데이터셋을 다룰때 유리하다.
=> parquet 파일로 쓰고 읽는 과정을 남겨두는게 낫다고 판단함. -
persist()를 사용했을때 성능이 개선됐다.
dask-on-ray 스케줄러로 dask.persist()를 호출하면, 작업을 ray 클러스터에 submit하고 dask 컬렉션에 포함된 future를 반환한다.
aggregations같은 다운스트림연산에서 다스크 어레이같은 베이스 컬렉션 연산에 효과적인데,
베이스 컬렉션 연산이 더 빨리시작되고 공유 메모리를 통해 모든 다운스트림연산에서 참조되므로, 연산이 더 빨라진다.
