빅데이터의 파일 형식: 간략한 교육 프로그램

Remarin의 날씨 신

팀 Mail.ru 클라우드 솔루션 제공 기사 번역 Clairvoyant의 엔지니어 Rahul Bhatia는 빅 데이터에 어떤 파일 형식이 있는지, Hadoop 형식의 가장 일반적인 기능은 무엇인지, 어떤 형식을 사용하는 것이 더 좋은지에 대해 설명합니다.

왜 다른 파일 형식이 필요한가요?

MapReduce 및 Spark와 같은 HDFS 지원 애플리케이션의 주요 성능 병목 현상은 데이터를 검색하고 읽고 쓰는 데 걸리는 시간입니다. 이러한 문제는 고정된 스키마가 아닌 진화하는 스키마가 있거나 일부 저장 제약이 있는 경우 대규모 데이터 세트를 관리하는 데 어려움이 있기 때문에 더욱 복잡해집니다.

빅 데이터를 처리하면 스토리지 하위 시스템의 로드가 증가합니다. Hadoop은 내결함성을 달성하기 위해 데이터를 중복 저장합니다. 디스크 외에 프로세서, 네트워크, 입출력 시스템 등이 로드됩니다. 데이터의 양이 늘어나면 이를 처리하고 저장하는 데 드는 비용도 늘어납니다.

다양한 파일 형식 하둡 이러한 문제를 정확하게 해결하기 위해 발명되었습니다. 적절한 파일 형식을 선택하면 다음과 같은 몇 가지 중요한 이점을 얻을 수 있습니다.

1. 읽는 시간이 빨라집니다.
2. 녹화 시간이 더 빨라졌습니다.
3. 공유된 파일.
4. 스키마 발전을 지원합니다.
5. 확장된 압축 지원.

일부 파일 형식은 일반적인 용도로 만들어졌고, 다른 파일 형식은 보다 구체적인 용도로 사용되었으며, 일부는 특정 데이터 특성을 충족하도록 설계되었습니다. 따라서 선택의 폭이 정말 넓습니다.

아브로 파일 형식

에 데이터 직렬화 Avro는 널리 사용됩니다. 문자열 기반, 즉 Hadoop의 문자열 데이터 저장 형식입니다. 스키마를 JSON 형식으로 저장하므로 모든 프로그램에서 쉽게 읽고 해석할 수 있습니다. 데이터 자체는 바이너리 형식으로 되어 있어 컴팩트하고 효율적입니다.

Avro의 직렬화 시스템은 언어 중립적입니다. 파일은 현재 C, C++, C#, Java, Python 및 Ruby 등 다양한 언어로 처리될 수 있습니다.

Avro의 주요 기능은 시간이 지남에 따라 변화하는, 즉 진화하는 데이터 스키마에 대한 강력한 지원입니다. Avro는 필드 삭제, 추가, 변경과 같은 스키마 변경 사항을 이해합니다.

Avro는 다양한 데이터 구조를 지원합니다. 예를 들어 배열, 열거 유형 및 하위 레코드가 포함된 레코드를 생성할 수 있습니다.

이 형식은 데이터 레이크(데이터 레이크또는 데이터 레이크 - 데이터 소스 외에 다양한 유형의 데이터를 직접 저장하기 위한 인스턴스 모음입니다.

따라서 이 형식은 다음과 같은 이유로 데이터 레이크의 랜딩 존에 쓰는 데 가장 적합합니다.

1. 이 영역의 데이터는 일반적으로 다운스트림 시스템의 추가 처리를 위해 전체적으로 읽혀지며, 이 경우 행 기반 형식이 더 효율적입니다.
2. 다운스트림 시스템은 파일에서 스키마 테이블을 쉽게 검색할 수 있으므로 외부 메타 스토리지에 별도로 스키마를 저장할 필요가 없습니다.
3. 원래 스키마에 대한 모든 변경 사항은 쉽게 처리됩니다(스키마 진화).

마루 파일 형식

Parquet은 다음과 같은 정보를 저장하는 Hadoop용 오픈 소스 파일 형식입니다. 플랫 컬럼 형식의 중첩 데이터 구조.

전통적인 행 접근 방식에 비해 Parquet는 저장 및 성능 측면에서 더 효율적입니다.

이는 넓은(많은 열) 테이블에서 특정 열을 읽는 쿼리에 특히 유용합니다. 파일 형식 덕분에 꼭 필요한 컬럼만 읽어오기 때문에 I/O가 최소한으로 유지됩니다.

작은 여담과 설명: Hadoop의 Parquet 파일 형식을 더 잘 이해하기 위해 열 기반(즉, 열 형식) 형식이 무엇인지 살펴보겠습니다. 이 형식은 각 열에 대해 유사한 값을 함께 저장합니다.

예를 들면, 레코드에는 ID, 이름 및 부서 필드가 포함됩니다. 이 경우 모든 ID 열 값은 이름 열 값 등과 마찬가지로 함께 저장됩니다. 테이블은 다음과 같습니다.

ID
성함
학과

1
emp1
d1

2
emp2
d2

3
emp3
d3

문자열 형식으로 데이터는 다음과 같이 저장됩니다.

1
emp1
d1
2
emp2
d2
3
emp3
d3

열 형식 파일 형식에서는 동일한 데이터가 다음과 같이 저장됩니다.

1
2
3
emp1
emp2
emp3
d1
d2
d3

테이블에서 여러 열을 쿼리해야 하는 경우 열 형식이 더 효율적입니다. 인접한 열이므로 필요한 열만 읽습니다. 이러한 방식으로 I/O 작업이 최소한으로 유지됩니다.

예를 들어 NAME 열만 필요합니다. 안에 문자열 형식 데이터 세트의 각 레코드를 로드하고 필드별로 구문 분석한 다음 NAME 데이터를 추출해야 합니다. 열 형식을 사용하면 해당 열의 모든 값이 함께 저장되므로 이름 열로 직접 드릴다운할 수 있습니다. 전체 녹음을 스캔할 필요는 없습니다.

따라서 열 형식을 사용하면 필요한 열에 도달하는 데 필요한 조회 시간이 줄어들고 원하는 열만 읽기 때문에 I/O 작업 수가 줄어들기 때문에 쿼리 성능이 향상됩니다.

독특한 특징 중 하나 나무 마루로 이 형식으로 할 수 있다는 것입니다 중첩된 구조로 데이터 저장. 즉, Parquet 파일에서는 중첩 구조의 모든 필드를 읽지 않고도 중첩 필드도 개별적으로 읽을 수 있습니다. Parquet는 파쇄 및 조립 알고리즘을 사용하여 중첩된 구조를 저장합니다.

Hadoop의 Parquet 파일 형식을 이해하려면 다음 용어를 알아야 합니다.

1. 행 그룹 (행 그룹): 데이터를 행으로 논리적으로 수평 분할합니다. 행 그룹은 데이터 세트에 있는 각 열의 조각으로 구성됩니다.
2. 기둥 조각 (열 청크): 특정 열의 조각입니다. 이러한 열 조각은 특정 행 그룹에 있으며 파일에서 연속적으로 유지됩니다.
3. 페이지 (페이지): 열 조각이 차례로 작성된 페이지로 구분됩니다. 페이지에는 공통 제목이 있으므로 읽을 때 불필요한 페이지는 건너뛸 수 있습니다.

여기 제목에는 매직 넘버만 포함되어 있습니다. PAR1 파일을 Parquet 파일로 식별하는 (4바이트)입니다.

바닥글에는 다음과 같은 내용이 나와 있습니다.

1. 각 열의 메타데이터 시작 좌표를 포함하는 파일 메타데이터입니다. 읽을 때 먼저 파일의 메타데이터를 읽어 관심 있는 모든 열 조각을 찾아야 합니다. 그런 다음 열 부분을 순차적으로 읽어야 합니다. 기타 메타데이터에는 형식 버전, 스키마 및 추가 키-값 쌍이 포함됩니다.
2. 메타데이터 길이(4바이트)입니다.
3. 매직넘버 PAR1 (4 바이트).

ORC 파일 형식

최적화된 행-열 파일 형식 (최적화된 행 열, ORC)은 데이터를 저장하는 매우 효율적인 방법을 제공하며 다른 형식의 한계를 극복하도록 설계되었습니다. 크고 복잡하거나 수동으로 유지 관리되는 인덱스를 구성할 필요 없이 데이터를 완벽하게 컴팩트한 형식으로 저장하므로 불필요한 세부 정보를 건너뛸 수 있습니다.

ORC 형식의 장점:

1. 하나의 파일은 각 작업의 출력으로, NameNode(네임 노드)의 부하를 줄여줍니다.
2. DateTime, XNUMX진수 및 복합 데이터 유형(구조체, 목록, 맵 및 공용체)을 포함한 Hive 데이터 유형을 지원합니다.
3. 서로 다른 RecordReader 프로세스에서 동일한 파일을 동시에 읽습니다.
4. 마커를 스캔하지 않고 파일을 분할하는 기능.
5. 파일 바닥글의 정보를 기반으로 읽기/쓰기 프로세스에 대해 가능한 최대 힙 메모리 할당을 추정합니다.
6. 메타데이터는 필드를 추가하고 제거할 수 있는 프로토콜 버퍼 바이너리 직렬화 형식으로 저장됩니다.

ORC는 문자열 컬렉션을 단일 파일에 저장하고 컬렉션 내에서 문자열 데이터는 열 형식으로 저장됩니다.

ORC 파일은 스트라이프라고 불리는 줄 그룹과 파일 바닥글에 지원 정보를 저장합니다. 파일 끝에 있는 Postscript에는 압축 매개변수와 압축된 바닥글의 크기가 포함되어 있습니다.

기본 스트라이프 크기는 250MB입니다. 이러한 큰 스트라이프로 인해 HDFS에서 읽는 작업은 큰 연속 블록에서 더 효율적으로 수행됩니다.

파일 바닥글에는 파일의 레인 목록, 레인당 행 수, 각 열의 데이터 유형이 기록됩니다. 각 열의 개수, 최소값, 최대값 및 합계의 결과 값도 여기에 기록됩니다.

스트립의 바닥글에는 스트림 위치 디렉토리가 포함되어 있습니다.

행 데이터는 테이블을 스캔할 때 사용됩니다.

인덱스 데이터에는 각 열의 최소값과 최대값, 각 열의 행 위치가 포함됩니다. ORC 인덱스는 스트라이프 및 행 그룹 선택에만 사용되며 쿼리 응답에는 사용되지 않습니다.

다양한 파일 형식 비교

Avro와 쪽모이 세공 마루

1. Avro는 행 저장 형식인 반면 Parquet는 데이터를 열에 저장합니다.
2. Parquet는 분석 쿼리에 더 적합합니다. 즉, 읽기 작업과 데이터 쿼리가 쓰기보다 훨씬 더 효율적이라는 의미입니다.
3. Avro의 쓰기 작업은 Parquet보다 더 효율적으로 수행됩니다.
4. Avro는 회로 진화를 보다 성숙하게 처리합니다. Parquet는 스키마 추가만 지원하는 반면 Avro는 다기능 진화, 즉 열 추가 또는 변경을 지원합니다.
5. Parquet는 다중 열 테이블에서 열 하위 집합을 쿼리하는 데 적합합니다. Avro는 모든 열을 쿼리하는 ETL 작업에 적합합니다.

ORC 대 마루

1. Parquet는 중첩된 데이터를 더 잘 저장합니다.
2. ORC는 조건자 푸시다운에 더 적합합니다.
3. ORC는 ACID 속성을 지원합니다.
4. ORC는 데이터를 더 잘 압축합니다.

주제에 대해 더 읽을 내용:

1. 클라우드에서의 빅데이터 분석: 기업이 데이터 지향적이 되는 방법.
2. 데이터베이스 스키마에 대한 겸손한 가이드.
3. 디지털 혁신에 관한 전보 채널.

출처 : habr.com