인프런 커뮤니티 질문&답변
작성한 질문수
broadcast 코드 예시 관련 질문
해결된 질문
작성
·
20
0
안녕하세요.
broadcast 예제코드에서는 이미 aggregation된 dataframe(코드에서 interviwer_count)에 대해서 udf 실행을 위해서 meta 딕셔너리를 broadcast한 다음에 udf를 실행하는 것으로 이해하였는데요.
실제 운영하는 상황에서는 이런 경우에는 이미 aggregation이 된 dataframe이 먼저 만들어질 것이기 때문에 meta 딕셔너리를 dataframe으로 만든 후 join하는 것과 큰 차이가 없지 않나요?
해당 코드에서 broadcast를 함으로써 다른 방법(join 등)에 비해 얻는 이점이 어떤 건지 궁금합니다.
답변 2
0
안녕하세요 워농님,
좋은 질문 감사합니다. 제가 연말이라 바쁘다보니 답변이 늦었는데, AI가 답변을 해줬네요 ㅎㅎ.
일단 워농님이 말씀하신 부분도 맞고 AI가 대답한 부분도 맞습니다. 여기 실습에서는 어떤 식으로 작동을하는지 보여드릴려고 이렇게 작성을 했고, 실질적인 프로젝트에서는 두개의 데이터를 조인할 때 하나의 데이타가 다른 데이터에 비해 상당히 작고, 메모리에 들어갈 경우에 이런 식으로 조인합니다. 기본적인 셔플 조인은 노드끼리 Shuffle이 많이 일어나기 때문에 훨씬 느리기 때문이죠.
혹시 더 질문 있으시면 남겨주세요!
0
안녕하세요, 인프런 AI 인턴입니다.
워농님께서 질문하신 broadcast 예제 코드에 관한 사항을 이해하기 위해 몇 가지 지적하신 부분을 요약하자면, 이미 aggregation된 데이터에 대해 UDF를 실행할 때, broadcast 변수를 사용하는 것과 dataframe을 만든 후 join하는 방식의 차이에 대한 것입니다.
Broadcast 변수를 사용하는 가장 큰 이유는 작은 데이터셋을 각 노드의 메모리에 저장하여 네트워크 병목을 줄이고, 노드 간 통신 비용을 최소화하려는 데 있습니다. 이런 접근은 주로 다음과 같은 상황에서 이점을 제공합니다:
Broadcast의 메모리 효율성: Broadcast는 작은 사이즈의 데이터셋을 클러스터의 모든 노드에 복제하여 빠르게 접근할 수 있습니다. 상대적으로 view 작업이 많지 않은 데이터라면 전체 네트워크 간의 통신 비용을 최소화할 수 있습니다.
작업 성능 향상: join 연산은 일반적으로 데이터를 섞어 처리하게 되므로 많은 양의 데이터 셔플링이 발생할 수 있습니다. 하지만, 작은 데이터셋을 broadcast하면, 이러한 셔플링 과정을 피하게 되어 성능이 개선될 수 있습니다.
코드의 유연성: Broadcast를 사용하면, 특정 key-value 쌍처럼 작은 크기의 데이터를 복잡한 UDF 내에서 쉽게 참조할 수 있게 되어, 코드 가독성과 유지보수 측면에서도 장점이 있습니다.
— 관련된 기존 게시글 —
- 대용량 데이터 Join: 이 게시물에서는 Spark에서 데이터 Join 방법과 발생할 수 있는 문제점들, 그리고 이를 다룰 수 있는 다양한 테크닉들에 대해 설명하고 있습니다. 워농님이 궁금해 하시는 join에 관련한 기술적인 부분도 다뤄지고 있으니 참고하시면 도움이 될 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.