Apache Parquet의 특성은 다음과 같습니다.
- 자기 설명
- 기둥 형식
- 언어 독립적
Avro, Sequence Files, RC File 등과 비교하여 형식의 개요를 원합니다. 나는 이미 읽었습니다 : Impala가 Hadoop 파일 형식과 어떻게 작동하는지 , 형식 에 대한 통찰력을 제공하지만 데이터에 대한 액세스 및 데이터 저장이 각 형식에서 어떻게 수행되는지 알고 싶습니다. 마루는 다른쪽에 비해 어떻게 유리합니까?
답변
필자가 설명 할 수있는 주요 차이점은 레코드 지향 형식과 열 지향 형식과 관련이 있다고 생각합니다. 레코드 지향 형식은 텍스트 파일, CSV, TSV와 같이 구분 된 형식입니다. AVRO는 레코드에서 열 추가 또는 제거와 같이 시간이 지남에 따라 스키마를 변경할 수 있기 때문에 그보다 약간 더 시원합니다. 다양한 형식 (특히 압축 포함)의 다른 트릭은 형식을 분할 할 수 있는지 여부와 관련이 있습니다. 즉, 데이터 집합의 어느 곳에서나 레코드 블록을 읽고 여전히 스키마를 알 수 있습니까? 그러나 Parquet와 같은 컬럼 형식에 대한 자세한 내용은 다음과 같습니다.
쪽모이 세공 및 기타 기둥 형식은 일반적인 하둡 상황을 매우 효율적으로 처리합니다. 잘 설계된 관계형 데이터베이스에서 예상보다 많은 열을 가진 테이블 (데이터 집합)을 갖는 것이 일반적입니다. 백 열 또는 이백 열은 드문 일이 아닙니다. 관계형 형식의 데이터 를 비정규 화 하는 장소로 Hadoop을 자주 사용하기 때문입니다. 예, 반복되는 값이 많고 많은 테이블이 모두 단일 값으로 병합됩니다. 그러나 모든 조인이 해결되었으므로 쿼리하기가 훨씬 쉬워졌습니다. 상태 데이터 유지와 같은 다른 장점이 있습니다. 어쨌든 테이블에 열의 보트로드가있는 것이 일반적입니다.
132 개의 열이 있고 그 중 일부는 실제로는 긴 텍스트 필드이며, 각기 다른 열이 하나씩 이어지고 레코드 당 10K를 소모한다고 가정 해 봅시다.
SQL 관점에서는 이러한 테이블을 쿼리하는 것이 쉽지만 이러한 백 개 이상의 열 중 일부만 기반으로 몇 가지 레코드 범위를 얻는 것이 일반적입니다. 예를 들어, 판매가 $ 500를 초과하는 고객에 대해 2 월과 3 월의 모든 레코드를 원할 수 있습니다.
행 형식으로이 작업을 수행하려면 쿼리에서 데이터 집합의 모든 레코드를 검색해야합니다. 첫 번째 행을 읽고 레코드를 필드 (열)로 구문 분석하고 날짜 및 판매 열을 가져 와서 조건을 만족하는 경우 결과에 포함하십시오. 반복. 당신이 10 년 (120 개월)의 역사를 가지고 있다면, 당신은 그 두 달 중 하나를 찾기 위해 모든 기록을 읽고 있습니다. 물론 이것은 년과 월에 파티션을 사용할 수있는 좋은 기회이지만, 그럼에도 불구하고 고객의 판매가 $ 500 이상인지 확인하기 위해 두 달 동안 각 레코드 / 행의 10K를 읽고 파싱하고 있습니다.
열 형식으로 레코드의 각 열 (필드)은 다른 종류의 다른 열과 함께 저장되며, 연도 열, 월 열, 고객 직원 핸드북 열 (또는 기타 긴 텍스트), 그리고 그 레코드를 디스크에있는 별도의 장소와 함께 판매하기위한 열에서 모두 너무 크게 만드는 다른 모든 것. 글쎄, 날짜와 월은 숫자이며 판매도 마찬가지입니다. 몇 바이트에 불과합니다. 쿼리와 일치하는 레코드를 결정하기 위해 각 레코드에 대해 몇 바이트 만 읽어야한다면 좋지 않을까요? 구조를위한 기둥 형 스토리지!
파티션이 없어도 쿼리를 만족시키는 데 필요한 작은 필드를 검색하는 것이 매우 빠릅니다. 레코드 순서와 크기가 모두 같기 때문에 디스크는 포함 된 레코드에 대해 훨씬 적은 데이터 검사를 찾습니다. 직원 핸드북과 기타 긴 텍스트 필드를 읽을 필요가 없습니다. 무시하십시오. 따라서 행 대신 열을 서로 그룹화하면 거의 항상 적은 양의 데이터를 스캔 할 수 있습니다. 승리!
그러나 기다려라. 더 좋아진다. 쿼리에서 해당 값과 몇 개만 더 알고 (132 개 열 중 10 개를 말하자) 해당 직원 핸드북 열에 신경 쓰지 않았다면 반환 할 올바른 레코드를 선택하면 이제는 가야합니다. 10 개의 열로 돌아가서 결과를 렌더링하는 데 필요한 데이터 세트의 132 중 다른 122 개는 무시합니다. 다시, 우리는 많은 독서를 건너 뜁니다.
(참고 :이 때문에 열 변환 형식은 직선 변환을 수행 할 때 선택의 폭이 넓습니다. 예를 들어 두 테이블을 모두 하나의 큰 결과 집합에 결합하여 소스로 새 테이블로 저장하는 경우 어쨌든 완전히 스캔 될 것이므로 읽기 성능에는 큰 이점이 없으며 열 형식은 위치에 대해 더 많이 기억해야하기 때문에 비슷한 행 형식보다 더 많은 메모리를 사용합니다).
컬럼의 또 다른 이점 : 데이터가 분산되어 있습니다. 단일 레코드를 얻기 위해 132 명의 작업자가 132 개의 데이터 블록에서 132 개의 서로 다른 위치에서 데이터를 읽고 쓸 수 있습니다. 병렬화를위한 예!
이제 클린 처 : 압축 알고리즘이 반복되는 패턴을 찾을 때 훨씬 잘 작동합니다. 압축 할 수 AABBBBBBCCCCCCCCCCCCCCCC는 2A6B16C있지만 ABCABCBCBCBCCCCCCCCCCCCCC작아지지는 않습니다 (실제로이 경우에는 :-)). 다시 한 번, 더 적은 독서. 그리고 쓰기도.
따라서 일반적인 쿼리에 응답하기 위해 훨씬 적은 데이터를 읽고 병렬로 읽고 쓰는 것이 더 빠르며 압축이 훨씬 잘 작동하는 경향이 있습니다.
입력 측이 클 때 열이 크고 출력이 필터링 된 하위 집합입니다. 입력과 출력이 거의 같은 경우에는 유용하지 않습니다.
그러나 우리의 경우 Impala는 5, 10, 20 또는 30 분 동안 실행 된 이전 Hive 쿼리를 가져 와서 몇 초 또는 1 분 안에 대부분 완료했습니다.
이것이 귀하의 질문 중 적어도 일부에 답변하는 데 도움이되기를 바랍니다!
답변
Avro는 Hadoop의 행 기반 스토리지 형식입니다.
Parquet는 Hadoop의 열 기반 저장소 형식입니다.
유스 케이스가 일반적으로 각 쿼리에서 행의 모든 필드를 스캔하거나 검색하는 경우 일반적으로 Avro가 최선의 선택입니다.
데이터 집합에 많은 열이 있고 사용 사례에 일반적으로 전체 레코드가 아닌 해당 열의 하위 집합을 사용하는 경우 Parquet는 이러한 종류의 작업에 최적화되어 있습니다.
답변
Tom의 대답은 매우 상세하고 철저하지만 Allstate Insurance에서 수행 한 Parquet vs Avro에 대한 이 간단한 연구 에 관심 이 있을 수 있습니다.
“전체적으로 Parquet는 [Avro보다] 모든 테스트에서 유사하거나 더 나은 결과를 보여주었습니다. Parquet가 선호하는 큰 데이터 세트의 쿼리 성능 차이는 부분적으로 압축 결과 때문입니다. 넓은 데이터 세트를 쿼리 할 때 Spark는 3.5x를 읽어야했습니다. Avro보다 Parquet에 대한 데이터가 적습니다. Avro는 전체 데이터 세트를 처리 할 때 성능이 좋지 않은 것으로 나타났습니다. “
