[HADOOP] 노드 수를 늘리더라도 Spark CSV 읽기 속도가 매우 느립니다.

노드 수를 늘리더라도 Spark CSV 읽기 속도가 매우 느립니다.

Google Compute Engine에서 두 개의 클러스터를 만들었고이 클러스터는 100GB 데이터를 읽습니다.

클러스터 I : 마스터 1 개-15GB 메모리-250GB 디스크 10 개 노드-7.5GB 메모리-200GB 디스크

클러스터 II : 마스터 1 개-15GB 메모리-250GB 디스크 150 개 노드-1.7GB 메모리-200GB 디스크

파일을 읽는 데 사용하고 있습니다.

또한 이것은 55k 개의 행과 850k 개의 열을 포함하는 데이터 세트입니다.

Q1 : 머신 수를 늘 렸지만 읽기 속도가 크게 향상되지 않았습니다. 무엇이 잘못되었거나이 과정을 더 빨리해야합니까? 노드를 더 늘려야합니까?

Q2 : 머신 수의 증가가 빠를수록 중요합니까, 아니면 메모리 양의 증가가 Spark에 중요합니까? 노드, 메모리 및 속도간에 성능 그래프가 있습니까?

Q3 : 또한 hadoop에 대한 복사 또는 이동 명령이 매우 느리게 작동합니다. 데이터는 100GB에 불과합니다. 대기업은 테라 바이트 단위의 데이터를 어떻게 처리합니까? 데이터 읽기 속도의 증가를 포착 할 수 없습니다.

답변 주셔서 감사합니다

해결법

1. ==============================

   1.TL; DR Spark SQL (일반적으로 Spark 및 유사한 아키텍처 및 디자인을 공유하는 다른 프로젝트)은 주로 길고 상대적으로 좁은 데이터를 처리하도록 설계되었습니다. 이것은 입력이 넓고 (상대적으로) 짧은 데이터의 정반대입니다.

   TL; DR Spark SQL (일반적으로 Spark 및 유사한 아키텍처 및 디자인을 공유하는 다른 프로젝트)은 주로 길고 상대적으로 좁은 데이터를 처리하도록 설계되었습니다. 이것은 입력이 넓고 (상대적으로) 짧은 데이터의 정반대입니다.

   Spark는 핵심 처리 모델을 캐싱하기 위해 열 형식을 사용하지만 데이터의 행 (레코드)을 처리합니다. 데이터가 넓지 만 짧으면 데이터 배포 기능이 제한 될뿐만 아니라 더 중요한 것은 매우 큰 객체의 초기화로 이어집니다. 이는 전체 메모리 관리 및 가비지 수집 프로세스 (JVM GC의 큰 개체)에 해로운 영향을 미칩니다.

   Spark SQL에 매우 넓은 데이터를 사용하면 추가 문제가 발생합니다. 다른 옵티 마이저 구성 요소는 조회에 사용 된 표현식의 관점에서 비선형 복잡성을 갖습니다. 이것은 일반적으로 데이터가 좁아도 (1K 미만의 열) 문제는 아니지만 더 넓은 데이터 세트로 인해 병목 현상이 발생할 수 있습니다.

   또한 고성능 분석 및 고가의 리더 옵션 (스키마 추론)에 적합하지 않은 입력 형식을 사용하고 있습니다.

   데이터에 대해 알고있는 정보와 나중에 처리하는 방법에 따라 읽기시 긴 형식으로 변환하거나 일부 스파 스 표현 (해당되는 경우)을 사용하여 직접 데이터를 인코딩하여 이러한 문제 중 일부를 해결하려고 시도 할 수 있습니다.

   그 밖의 최선의 선택은 런타임 통계를 기반으로 신중한 메모리 및 GC 조정입니다.

2. ==============================

   2.수동으로 스키마를 제공하는 대신 inferSchema를 사용하지 마십시오. spark가 거대한 데이터에 대해 스키마를 유추하는 데 시간이 걸립니다.

   수동으로 스키마를 제공하는 대신 inferSchema를 사용하지 마십시오. spark가 거대한 데이터에 대해 스키마를 유추하는 데 시간이 걸립니다.

from https://stackoverflow.com/questions/51428195/spark-csv-reading-speed-is-very-slow-although-i-increased-the-number-of-nodes by cc-by-sa and MIT license