[HADOOP] Hadoop 입력에 가장 적합한 분할 가능 압축 = bz2?

Hadoop 입력에 가장 적합한 분할 가능 압축 = bz2?

Hadoop 처리를 위해 GZip 형식으로 파일을 보관하는 것은 그리 좋은 생각이 아닙니다. GZip은 splittable이 아니며, 참고로 여기에 반복하지 않을 문제가 있습니다.

제 질문은 BZip2가 단일 아카이브 파일을 Hadoop에 의해 동시에 처리 할 수 ​​있도록하는 최고의 아카이브 압축입니까? Gzip은 확실히 아닙니다, 그리고 내 독서 LZO에서 몇 가지 문제가 있습니다.

해결법

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

   1.BZIP2는 hadoop에서 분할 가능합니다. 매우 우수한 압축률을 제공하지만 CPU 시간과 성능은 압축이 매우 많은 CPU 소비로 인해 최적의 결과를 제공하지 못합니다.

   BZIP2는 hadoop에서 분할 가능합니다. 매우 우수한 압축률을 제공하지만 CPU 시간과 성능은 압축이 매우 많은 CPU 소비로 인해 최적의 결과를 제공하지 못합니다.

   LZO는 hadoop에서 분할 가능합니다. 분할 가능한 압축 LZO 파일이 있습니다. 병렬로 처리하려면 외부 .lzo.index 파일이 있어야합니다. 라이브러리는 로컬 또는 분산 방식으로 이러한 인덱스를 생성하는 모든 방법을 제공합니다.

   LZ4는 hadoop에서 분할 가능합니다. 분할 가능한 4mc 파일을 가지고 있습니다. 외부 색인 생성이 필요 없으며 제공되는 명령 줄 도구 또는 Java / C 코드 (내부 / 외부)에 아카이브를 생성 할 수 있습니다. 4mc는 속도 / 압축 비율의 모든 레벨에서 hadoop LZ4에서 사용할 수 있습니다. 고속 모드에서부터 500MB / s 압축 속도에 이르기까지 고 / 초 모드에 이르기까지 압축률이 증가하여 GZIP와 거의 유사합니다.

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

   2.나는이 다른 답변을 올바른, bzip2 고려하지 않습니다 :

   나는이 다른 답변을 올바른, bzip2 고려하지 않습니다 :

   http://comphadoop.weebly.com/

   분할 가능합니다. LZO도 색인이 생성됩니다.

   따라서 대답은 '예'입니다. 파일보다 더 많은 매퍼를 사용하려면 bzip2를 사용하는 것이 좋습니다.

   이렇게하려면 간단한 MR 작업을 작성하여 데이터를 읽은 다음 다시 작성하면됩니다. mapred.output.compression.codec을 org.apache.hadoop.io.compress.BZip2Codec로 설정해야합니다.

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

   3.gzip에는 5 가지 방법이 있으며, 3 가지 방법은 인덱스가 필요하고, 2 가지 방법은 인덱스가 필요합니다.

   gzip에는 5 가지 방법이 있으며, 3 가지 방법은 인덱스가 필요하고, 2 가지 방법은 인덱스가 필요합니다.

   zran.c에 의해 수행 된 것처럼 gzip 파일, 즉 특별히 구성되지 않은 gzip 파일에 대한 색인을 작성할 수 있습니다. 그런 다음 블록 경계에서 압축 해제를 시작할 수 있습니다. 색인에는 각 진입 점에서 32K의 비 압축 데이터 기록이 포함됩니다.

   gzip 파일을 생성하는 경우 주기적 엔트리 포인트를 사용하여 색인을 생성 할 수 있습니다.이 엔트리 포인트는 인덱스가 압축되지 않은 기록을 필요로하지 않으므로 작은 인덱스가됩니다. 이것은 zlib의 deflate ()에 Z_FULL_FLUSH 옵션을 사용하여 수행됩니다.

   Z_SYNC_FLUSH 다음에 Z_FULL_FLUSH를 추가하여 두 개의 마커를 삽입 할 수 있습니다. 그런 다음 9 바이트 패턴 00 00 ff ff 00 00 00 ff ff를 검색하여 찾을 수 있습니다. 이는 잘못된 긍정이 9 바이트로 발생할 확률이 훨씬 낮은 것을 제외하고는 bzip2 파일에서 6 바이트 마커를 검색하는 것과 다릅니다. 그렇다면 별도의 색인 파일이 필요 없습니다.

   gzip과 xz 모두 간단한 연결을 지원합니다. 이렇게하면 다른 방법으로 병렬 압축 해제 용 아카이브를 쉽게 준비 할 수 있습니다. 간단히 말해서 :

   gzip < a > a.gz
   gzip < b > b.gz
   cat a.gz b.gz > c.gz
   gunzip < c.gz > c
   cat a b | cmp - c
   

   성공할 것입니다.

   그런 다음 원하는 크기의 청크를 압축하고 결과를 연결합니다. 인덱스를 각 gzip 스트림의 시작 오프셋에 저장하십시오. 해당 오프셋에서 압축 해제하십시오. 응용 프로그램에 따라 청크의 크기를 원하는대로 선택할 수 있습니다. 그러나 너무 작게 만들면 압축이 영향을받습니다.

   gzip 파일을 간단히 연결하면 각 청크를 압축되지 않은 고정 크기로 만들면 색인을 잃을 수도 있습니다. 그런 다음 각 청크는 동일한 4 바이트로 끝나며 압축되지 않은 길이는 리틀 엔디안 순서로 끝납니다. 00 00 10 00, 1 MiB 청크, gzip 헤더의 시작 부분 인 다음 청크에서 1f 8b 08. 그런 다음 7 바이트 마커는 bzip2 마커처럼 검색 될 수 있지만 잘못된 검색 가능성은 낮습니다.

   머리말이 7 바이트 인 연결 xz 파일도 마찬가지입니다 : fd 37 7a 58 5a 00 00.

4. ==============================

   4.내 2 센트, bzip은 쓰기가 매우 느립니다. Apache Spark 1.6.2, Hadoop 2.7에서 테스트 한 결과, 50Go의 간단한 JSON 파일이 압축되었습니다. gzip보다 bzip으로 2 배의 시간이 걸렸습니다.

   내 2 센트, bzip은 쓰기가 매우 느립니다. Apache Spark 1.6.2, Hadoop 2.7에서 테스트 한 결과, 50Go의 간단한 JSON 파일이 압축되었습니다. gzip보다 bzip으로 2 배의 시간이 걸렸습니다.

   하지만 bzip으로, 50Go ==> 4Go!

from https://stackoverflow.com/questions/14820450/best-splittable-compression-for-hadoop-input-bz2 by cc-by-sa and MIT license