Alluxio의 Spark java로 여러 파일 읽기가 느림

Alluxio를 로컬에 설치하고 Alluxio의 메모리에 1000 개의 파일을 삽입했습니다.
그러나 읽기 파일이 매우 느리므로 Alluxio 메모리의 파일 읽기 시간은 디스크의 파일 읽기 시간과 같습니다.Alluxio의 Spark java로 여러 파일 읽기가 느림

FileSystem fs = FileSystem.Factory.get(); 
AlluxioURI path = new AlluxioURI(/partition0); 
List<URIStatus> status = fs.listStatus(path); 
for (int i=0; i<status.size(); i++) 
        { 
         path = new AlluxioURI(status.get(i).getPath()); 
         if(fs.exists(path)==true) 
         { 
          FileInStream in = fs.openFile(path); 
          String file = ""; 

          InputStreamReader ipsr = new InputStreamReader(in); 

          BufferedReader br=new BufferedReader(ipsr); 
          String line; 
          line=br.readLine(); 
          while (line != null){ 
           //System.out.println(line); 

           file = file + line; 
           line=br.readLine(); 
          } 

          byte[] cfv = file.getBytes(); 
          br.close(); 
          // Close file relinquishing the lock 
          in.close(); 
         } 
        }

테스트가 1000 개 파일 파티션을 읽을 수 있기 때문에 정말 사용 지금은 스파크하지 않습니다 나는

File Name Size Block Size In-Memory Persistence State Pin Creation Time Modification Time 
file1 54.73KB 512.00MB  100% NOT_PERSISTED NO 08-16-2016 12:52:31:278 08-16-2016 12:52:31:372 
file2 54.73KB 512.00MB  100% NOT_PERSISTED NO 08-16-2016 12:52:31:377 08-16-2016 12:52:31:384 
file3 54.72KB 512.00MB  100% NOT_PERSISTED NO 08-16-2016 12:52:31:386 08-16-2016 12:52:31:393 
file4 54.71KB 512.00MB  100% NOT_PERSISTED NO 08-16-2016 12:52:31:394 08-16-2016 12:52:31:400 
file5 54.72KB 512.00MB  100% NOT_PERSISTED NO 08-16-2016 12:52:31:401 08-16-2016 12:52:31:407 
...

내가 파일 API와 데이터를 읽을 ... 왜 understant하지 않습니다 매우 느립니다 ... (나는 futur에서 Spark로 파티션별로 파일을 읽길 원합니다).

누군가에게 왜 읽는 것이 너무 느린지 생각해보십시오.

출처

2016-08-16 TiGi

예제에서 약간 벗어나는 몇 가지가 있습니다.

먼저 파일에 표시되는 정보는 파일이 각각 약 50kB로 매우 작지만 512MB 블록을 사용하도록 Alluxio가 구성되어 있음을 나타냅니다. 이는 잠재적으로 실제로 필요한 것보다 훨씬 많은 데이터를 전송하고 있음을 의미합니다. 따라서 고려해야 할 한 가지 사항은 주로 작은 파일을 사용하려는 경우 매우 작은 블록 크기로 구성하는 것이 더 좋습니다.

두 번째로 테스트 케이스에서 파일을 실제로 읽는 방법은 대단히 비효율적입니다. 줄 단위로 문자열을 읽고, 문자열 연결을 사용하여 파일을 작성한 다음 다시 바이트로 변환합니다. 따라서 메모리의 바이트에서 문자열로 이동 한 다음 다시 바이트로 이동합니다. 게다가 문자열 연결을 사용하면 지금까지 읽은 파일 전체를 강제로 메모리 기술에 복사 할 수 있습니다. 일반적으로

당신은 어느 다른 Writer 쓰기가/StringBuilder에 라인으로 파일 라인을 읽거나 다른 OutputStream 예를 들어, 쓰기가/byte[]에 바이트로 당신은 파일을 읽을 것 ByteArrayOutputStream은 궁극적으로 byte[]이되고 미리 크기를 모르는 경우

세 번째 고려 사항은 클러스터 내에서 코드가 실행되는 곳입니다. 파일이 메모리에 있더라도 클러스터의 모든 노드에서 메모리에 없을 수 있습니다. 파일이 아직 메모리에없는 노드에서 파일을 읽으면 네트워크를 통해 파일을 읽어야 만 성능이 저하됩니다.

마지막으로 고려해야 할 사항은 OS 파일 캐싱입니다. 테스트 파일을 생성 한 다음 테스트를 즉시 실행 한 경우 해당 파일은 OS에서 메모리에 캐시 될 가능성이 큽니다. 캐싱이 OS 레벨이기 때문에 Alluxio보다 성능이 좋지는 않지만 좋은 점을 얻을 수 있습니다. 의미있는 비교를 실제로하고 싶다면 파일 기반 테스트를 실행하기 전에 OS 파일 캐시를 플러시해야합니다.

출처

2016-08-17 09:18:33 RobV

감사합니다. 실수를 더 잘 이해합니다. 블록 크기에 따라 최적의 블록 크기를 선택하는 규칙이 있습니까? – TiGi

몇 가지 테스트를 한 후에는 파일 크기가 읽기 시간의 주된 문제입니다. 작은 파일은 읽기 시간이 20 배 이상 증가 할 수 있습니다. 블록 크기도 읽기 시간에 영향을 미치며 읽기 시간이 약 1 % 증가 할 수 있습니다.

출처

2016-08-23 07:37:07 TiGi

Alluxio의 Spark java로 여러 파일 읽기가 느림

답변

관련 문제