복붙노트

[HADOOP] 작은 파일을위한 HDFS 성능

HADOOP

작은 파일을위한 HDFS 성능

나는 Haddoop에 처음 온 사람입니다. 최근 hdfs / hadoop에서 많은 작은 파일을 처리하려고합니다. 평균 파일 크기는 약 1KB이고 파일 수는 10M 이상입니다. 프로그램은 C ++로 작성해야합니다.

이것은 성능 평가 일 뿐이므로 데이터 노드에 5 대의 기계 만 사용합니다. 각 데이터 노드에는 5 개의 데이터 디스크가 있습니다.

나는 하드 디스크 (HDFS가 아닌)에서 직접 파일을 읽는 작은 C ++ 프로젝트를 작성하여 성능 기준선을 작성했습니다. 프로그램은 각 디스크에 대해 4 개의 읽기 스레드를 만듭니다. 성능 결과는 디스크 당 약 14MB / s입니다. 총 처리량은 약 14MB / s * 5 * 5 = 350MB / s (14MB / s * 5 디스크 * 5 대)입니다.

그러나이 프로그램 (여전히 libhdfs.so에 동적으로 링크 된 C ++을 사용하여 4 * 5 * 5 = 100 스레드 생성)이 hdfs 클러스터에서 파일을 읽으면 처리량은 약 55MB / s에 불과합니다.

이 프로그래밍이 mapreduce에서 실행되면 (hadoop 스트리밍, 5 개의 작업이 각각 20 개의 스레드를 가지며 총 스레드 수는 여전히 100입니다) 처리량이 약 45MB / s로 떨어집니다. (나는 그것이 부기 과정에 의해 천천히 추측된다).

나는 HDFS가 할 수있는 합리적인 성능이 무엇인지 궁금합니다. 보시다시피, 원시 코드와 비교할 때 데이터 처리량은 약 1/7에 불과합니다. 내 설정의 문제입니까? 아니면 HDFS 제한? 또는 Java 제한? 내 시나리오에서 가장 좋은 방법은 무엇입니까? 시퀀스 파일 도움이됩니까 (많이)? 우리가 기대할 수있는 네이티브 IO 읽기와 비교할 때 합리적인 처리량은 무엇입니까?

다음은 내 설정 중 일부입니다.

NameNode 힙 크기 32G.

작업 / 태스크 노드 힙 크기 8G.

NameNode 처리기 개수 : 128

DataNode 처리기 개수 : 8

DataNode 전송 스레드의 최대 수 : 4096

1GBps 이더넷.

감사.

해결법

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

    1.우리의 한계를 이해하고 언제 우리가 그들을 때려 볼 수 있습니다 a) 파일이있는 곳에 정보를 제공하려면 namenode가 필요합니다. 이 숫자는 초당 수천 개라고 추측 할 수 있습니다. 자세한 내용은 https://issues.apache.org/jira/browse/HADOOP-2149를 참조하십시오. 이 숫자를 10000K라고 가정하면 1K 파일에 대해 10MB 초에 대한 정보를 얻을 수 있어야합니다. (어떻게 든 당신은 더 많이 얻는다. ..). 할 수있다 b) HDFS의 오버 헤드. 이 오버 헤드는 대부분 처리량이 아닌 대기 시간에 있습니다. HDFS는 여러 파일을 병렬로 제공하도록 조정할 수 있습니다. HBase는 그것을하고 있으며 HBase 튜닝 가이드에서 설정을 할 수 있습니다. 여기서 질문은 실제로 얼마나 많은 Datanodes가 필요한지입니다. c) 귀하의 LAN. 네트워크에서 데이터를 이동하므로 1GB 이더넷 처리량 한도에 도달 할 수 있습니다. (나는 당신이 가진 것이라고 생각합니다.

    우리의 한계를 이해하고 언제 우리가 그들을 때려 볼 수 있습니다 a) 파일이있는 곳에 정보를 제공하려면 namenode가 필요합니다. 이 숫자는 초당 수천 개라고 추측 할 수 있습니다. 자세한 내용은 https://issues.apache.org/jira/browse/HADOOP-2149를 참조하십시오. 이 숫자를 10000K라고 가정하면 1K 파일에 대해 10MB 초에 대한 정보를 얻을 수 있어야합니다. (어떻게 든 당신은 더 많이 얻는다. ..). 할 수있다 b) HDFS의 오버 헤드. 이 오버 헤드는 대부분 처리량이 아닌 대기 시간에 있습니다. HDFS는 여러 파일을 병렬로 제공하도록 조정할 수 있습니다. HBase는 그것을하고 있으며 HBase 튜닝 가이드에서 설정을 할 수 있습니다. 여기서 질문은 실제로 얼마나 많은 Datanodes가 필요한지입니다. c) 귀하의 LAN. 네트워크에서 데이터를 이동하므로 1GB 이더넷 처리량 한도에 도달 할 수 있습니다. (나는 당신이 가진 것이라고 생각합니다.

    Joe와 동의해야합니다. HDFS는 시나리오 용으로 제작되지 않았으며 Hadoop 스택을 원한다면 HBase와 같은 다른 기술을 사용해야합니다. 예를 들어 시퀀스 파일과 같이 파일을 함께 압축해야합니다.

    HDFS에서 더 큰 파일을 읽는 것에 관해서는 - DFSIO 벤치 마크를 실행하면 귀하의 번호가됩니다. 동시에 단일 호스트상의 SSD가 완벽하게 솔루션이 될 수 있습니다.

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

    2.HDFS는 실제로 많은 작은 파일을 위해 설계되지 않았습니다.

    HDFS는 실제로 많은 작은 파일을 위해 설계되지 않았습니다.

    읽은 새로운 파일마다 클라이언트는 namenode와 대화하여 파일의 블록 위치를 제공 한 다음 클라이언트가 데이터 노드에서 데이터를 스트리밍합니다.

    이제는 클라이언트가이 작업을 한 번 수행 한 다음 데이터가있는 머신임을 확인하고 디스크에서 직접 읽을 수 있습니다. 빠른 속도 : 직접 디스크 읽기와 비슷합니다.

    데이터가있는 시스템이 아닌 경우 네트워크를 통해 데이터를 스트리밍해야합니다. 그런 다음 네트워크 I / O 속도에 얽매여 있습니다.이 속도는 끔찍하지 않아야하지만 직접 디스크 읽기보다 조금 느립니다.

    그러나, 당신은 namenode와 대화하는 오버 헤드가 중대하게되는 상황을 더욱 악화시키고 있습니다. 1KB의 파일 만 있으면 실제 데이터만큼의 메타 데이터를 교환 할 수 있습니다. 클라이언트는 각 파일에서 데이터를 가져 오기 위해 두 개의 별도 네트워크 교환을 수행해야합니다. 이것에 namenode가 아마도이 모든 다른 쓰레드에 의해 망가질 것이기 때문에 병목 현상이 될 수도 있습니다.

    귀하의 질문에 대답하기 위해, 그렇습니다. HDFS를 사용하기 위해 고안된 것이 아니라면, 느려질 것입니다. 작은 파일을 병합하고 MapReduce를 사용하여 데이터 지역을 확보하면 성능이 훨씬 향상됩니다. 사실, 순차적 인 디스크 읽기를 더 잘 활용할 수 있기 때문에 하나의 큰 HDFS 파일을 읽는 것이 많은 작은 로컬 파일을 읽는 것보다 훨씬 빠르면 놀라지 않을 것입니다.

  3. ==============================

    3.HDFS와 다른 파일 시스템의 또 다른 차이점은 Joe가 말한 것을 추가하는 것입니다. FS 블록 크기가 기존의 FS와 비교하여 더 큰 블록 (일반적으로 64M 또는 128M)에 데이터를 저장하여 디스크 입출력을 가능한 한 적게 유지한다는 것입니다. KB 단위로 이러한 이유로 그들은 항상 HDFS가 작은 파일이 아닌 대용량 파일을 처리하는 데 능숙하다고 말합니다. 그 이유는 최근에 CPU, RAM 등의 구성 요소에 상당한 발전이 있었지만 디스크 I / O는 아직 많이 발전하지 못했던 부분입니다. 이것은 거대한 블록 (전통적인 FS와 달리)을 가지고 디스크의 사용을 가능한 한 적게 유지하려는 의도였습니다.

    HDFS와 다른 파일 시스템의 또 다른 차이점은 Joe가 말한 것을 추가하는 것입니다. FS 블록 크기가 기존의 FS와 비교하여 더 큰 블록 (일반적으로 64M 또는 128M)에 데이터를 저장하여 디스크 입출력을 가능한 한 적게 유지한다는 것입니다. KB 단위로 이러한 이유로 그들은 항상 HDFS가 작은 파일이 아닌 대용량 파일을 처리하는 데 능숙하다고 말합니다. 그 이유는 최근에 CPU, RAM 등의 구성 요소에 상당한 발전이 있었지만 디스크 I / O는 아직 많이 발전하지 못했던 부분입니다. 이것은 거대한 블록 (전통적인 FS와 달리)을 가지고 디스크의 사용을 가능한 한 적게 유지하려는 의도였습니다.

    또한 블록 크기가 너무 작 으면 더 큰 블록을 갖게됩니다. 더 많은 메타 데이터를 의미합니다. 이것은 많은 양의 정보가 메모리에로드 될 필요가 있기 때문에 성능을 다시 떨어 뜨릴 수 있습니다. HDFS에서 객체로 간주되는 각 블록에 대해 약 200B의 메타 데이터가 연관되어 있습니다. 작은 블록이 많으면 메타 데이터가 증가하고 RAM 문제가 발생할 수 있습니다.

    같은 문제에 대해 이야기하는 Cloudera의 블로그 섹션에는 아주 좋은 글이 있습니다. 여기를 방문 할 수 있습니다.

  4. from https://stackoverflow.com/questions/13993143/hdfs-performance-for-small-files by cc-by-sa and MIT license