달력

012019  이전 다음

  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  

https://www.dremio.com/tuning-parquet/


Parquet 파일 하나는 1 이상의 Row group이 있고 Row group column 별로 저장 되어있다.


Row Group 크기를 크게하면 column 데이터가 연속적으로 저장이 되는 부분이 커져 연산 속도나 압축 효율이 좋아진다.


하지만 disk block 크기까지 고려한다면….


A: 커다란 Parquet file 커다란 row group
앞에서도 얘기한것 처럼 연산 속도나 압축 효율은 증가하겠지만,
하나의 Parquet 파일/Row group이 두개 disk block에 걸쳐 있을 확률이 높기 때문에 추가적인 disk I/O가 발생한다.

B: 그렇다고 작은 Parquet file 작은 Row group 한다면...
두개의 disk block 걸칠 경우는 적겠지만 Parquet columnar storage 장점이 줄어든다. (row-based 저장하는것과 비슷해질듯)

C: 가장 이상적인 방식은 1개의 Parquet file 1개의 Row group 1개의 disk block 있으면 가장 좋다. (이상적!!)



But how does the block size of the disk come into play?

"come into play"

This mitigates the number of block crossings, but reduces the efficacy of Parquet’s columnar storage format.

mitigates, efficacy




https://blog.usejournal.com/sorting-and-parquet-3a382893cde5


SELECT * FROM Customers WHERE Country=’Mexico’;

쿼리를 실행하기 위해서는 모든 데이터를 읽으면서 Country Mexico 데이터를 추출하는 작업을 해야한다.
만약 Country가 Mexico 고객이 전체 고객 1 %밖에 되지 않는다고 하더라도 전체 데이터를 읽어야 한다. OMG!!


Predicate pushdown이란 query engine에서 storage layer 조건을 적용하여 읽어들일 양을 줄이는것을 의미한다.


Parquet Row group 메타데이터를 이용하여 predicate pushdown 동작한다.

Eg: integer column 경우 min/max 값을 메타데이터에 저장한다.
string column 경우 Row group 내 distinct 값을 메타데이터에 저장한다.
(아래에도 나오지만 40,000개가 한계라고 한다. vcnc에서 관련 작업을 어떻게 해결했는지 나온다.)


근데 어떤 column 정렬해야하나요?
각자 환경에 따라 다르므로 실행되는 쿼리들을 모두 기록하여 자주 사용되는 필터(where) 어떤건지 파악
해당 column sort해서 저장하는것을 권고한다.



Predicate pushdown means that the query engine is able to push the condition right into the storage layer and thus reduce the amount of data that is read.

and thus. and then 하고 비슷하면서도 뭔가 다른것 같다.

Another idea is to keep a record of all the queries that are run into a log and then analyze the queries to understand which column is filtered on the most.
"column is filtered on the most"



https://blog.cloudera.com/blog/2017/12/faster-performance-for-selective-queries/


적절한 파티션 분리는 조회시 꽤나 유용하게 사용된다.
예로 일별로 파티션 데이터가 2년정도 쌓였는데 이때 최근 7 데이터를 조회하고 싶다면 730 파티션 중에서 7개만 조회하면 된다. 100x 효율 개이득!!

하지만 파티션이 너무 많으면 메타 데이터 관리가 부담이 될수 있으므로 적절하게 지정해야한다.

그리고 모든 것을 파티션으로 해결하는것은 불가능하므로 몇가지 유용한 분할 스키마 방식이 있다.


Parquet 파일에는 최대/최소 같은 정보가 담긴 메타 데이터가 있다.
Impala 2.9 부터는 필드의 min_value, max_value 필드를 읽어 조회시 파일 읽을 건너뛴.
Hive / Spark 파일을 경우에 Impala deprecated min, max 필드만 읽는. (현재 회사에서 사용하는건 Impala 2.11)


※ Parquet row group dictionary filter 대해 이해를 돕기 위한 친절한 그림.. 보세요!!


Parquet Row Group Skipping via Min/Max Statistics 테이블 생성시 Sort BY 했을때와 했을때의 차이를 보여줌


Parquet Row Group Skipping via Dictionary Filtering 
Impala 자동으로 dictionary filtering 적용한다.
하나의 parquet 파일  column distinct value 갯수 40,000개를 넘으면 예외

Min/Max 범위가 매우 커서 그다지 효과적이지 않을때 dictionary filtering 이용하여 해당값이 존재하는 파일인지 체크하여
읽어드릴 파일 갯수를 줄일수 있다.


앞에 설명이 되어있어서

쌩짜로 만들어진 테이블과 partition 으로 만든 테이블, partition clustering으로 만든 테이블의 비교한 표는 재미지게 볼 수 있다.



This approach significantly speeds up selective queries by further eliminating data beyond what static partitioning alone can do

This means that when the min/max skipping may not be effective due to the min/max range being too large, dictionary filtering can check for the existence of values without reading any of the rows in the file.



VCNC 기술 블로그 글을 보고 호기심이 생겨 찾아보았습니다.

http://engineering.vcnc.co.kr/2018/05/parquet-and-spark/


현재 Spark로 parquet 파일 쓰고 Hive, Impala로 조회하는 부분이 있는데 테스트 하면서 현재 상황에 맞게 수정 해봐야겠다.

Posted by 오산돌구