작성
·
705
0
안녕하세요
대용량 데이터 join 방법에 대해 질문드립니다.
source A,B,C가 있고 A와 B를 union 하고 C를 조인해야 하는 상황입니다. A, B, C 각각은 모두 대용량 데이터입니다.
하지만, 이 코드를 실행하면 spark 내부적으로 C를 2번 read해 A와 C를 조인하고, B와 C를 조인하는 DAG이 생성되는 것을 UI에서 확인했습니다.
이에, C를 1번만 read하게 만들기 위해서 cDF.persist(StorageLevel.DISK_ONLY)를 중간에 삽입해, 원래 의도대로 A와 B를 union하고 C를 조인하도록 DAG을 변경하였습니다.
이런 상황에서 persist를 사용하지 않고 해결할 방법이 있을까요?
답변 1
0
안녕하세요,
우선 질문 주신 것 감사합니다. 우선 Cache나 Persist는 그런 경우를 대비해서 만들어 놓았습니다.
Persist를 사용하기 힘드시다면, A와 B를 조인하고 아웃풋한 후에 다시 읽어들여 조인하시는 방법도 있습니다만,
혹시 join 명령어를 사용하셨나요? sql 커멘드를 사용하셔서 쿼리를 돌려보시겠어요?
그리고 현재 문제는 Disk Space 때문에 그러신가요? MEMORY_AND_DISK_SER를 사용하시면 안되는 이유가 있나요?
아니면 통합시 Shuffle 속도 때문에 그러신가요? 조인하시기 전에 필요한 데이터만 필터 후 조인하시는 건가요?
데이터를 보지 않은 상태에서 도움이 될지 모르겠지만, 생각나는 대로 적어봤습니다.
1) 네 가끔식 쿼리에 따라 차이가 나는 경우가 있습니다.
2) 거의 80~90는 Persist를 사용하신다고 보시면 됩니다. 그리고 최대한 디스크에 흘리지 않는게 최대 관건입니다.(Disk Spill한다고 하죠)
3) 네 여러가지가 있는데, 그 중 하나가 최대한 좋은(메모리 많은) 인스턴스를 단시간 사용하시고, 그 인스턴스 개수를 줄이는게 셔플을 줄이는 좋은 방법입니다.
4) 굿입니다! ㅎㅎ
상세한 답변 정말 감사합니다.
1) join 함수를 사용하였습니다. sql을 사용하는 것과 join 을 사용하는 것에 차이가 있을 수가 있나요?? 방금 physhical plan을 비교해보았는데, 동일했습니다.
2) Disk Space가 아니라, 데이터가 크면 cache나 persist를 할 수 밖에 없는지 궁금했습니다.ㅎㅎ! 이렇게 쓰는게 맞는가 해서요
3) shuffle 속도를 높이는 튜닝도 있을까요???
4) 조인시 필요한 데이터만 필터 후 조인하고 있습니다.