ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Parquet 파일 잘 써보기
    개발하면서/타인글보면서 2018. 12. 2. 17:36
    반응형

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

     

    Dremio is the Data-as-a-Service Platform.

    Get more value from your data, faster. Dremio makes your data engineers more productive, and your data consumers more self-sufficient.

    www.dremio.com

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

     

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

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

     

    A: 커다란 Parquet file에 커다란 Row group 인 경우

    연산 속도나 압축 효율은 증가하겠지만, 하나의 Parquet file/Row group이

    두 개 Disk block에 걸쳐 있을 확률이 높기 때문에 추가적인 Disk I/O가 발생한다.

     

    B: 작은 Parquet file과 작은 Row group 인 경우

    A처럼 두 개의 Disk block에 걸치는 경우는 적겠지만 columnar storage의 장점이 줄어든다.

    (row-based 저장하는 것과 비슷해질 수도...)

     

    C: 1개의 Parquet file에 1개의 Row group가 1개의 disk block에 있으면 가장 좋다. (Ideal!!!!)

     

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

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

     


     

    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 값을 메타데이터에 저장한다.

    (아래에도 나오지만 4만 개가 한계라고 한다. Vcnc에서 관련 작업을 어떻게 해결했는지 나온다.)

     

    질문: 그럼 어떤 column을 정렬해서 저장해야 효율적인가요?

    답변: 각자 환경에 따라 다르므로 실행되는 쿼리들을 모두 기록하여 자주 사용되는 필터(where)가 어떤 건지

    파악 후 해당 Column을 정렬해서 저장하는 것을 추천한다.

     

    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.

    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.


     

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

     

    적절한 파티션 분리는 조회 시 꽤나 유용하게 사용된다.

    예로 일별 파티션 된 데이터가 2년 정도 쌓였는데 이때 최근 7일 데이터를 조회하고 싶다면

    730개 파티션 중에서 7개만 조회하면 된다. 100x 효율 개이득!!

     

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

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

     

    각 Parquet 파일에는 min/max 정보가 담긴 메타 데이터가 있다.

     

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

    Parquet Row Group Skipping via min/max Statistics 테이블 생성 시

    Sort BY를 했을 때와 안 했을 때의 차이를 보여줌

     

    Impala는 자동으로 Dictionary filtering을 적용한다.

    Parquet file 하나에  한 column distinct value 개수가 4만 개를 넘으면 적용하지 않는다.

     

    min/max 범위가 매우 커서 그다지 효과적이지 않은 경우 dictionary filtering을 이용하여

    해당 값이 존재하는 파일인지 체크가 바로 가능해서 읽어드릴 파일 개수를 줄일 수 있다.

     

    쌩짜로 만들어진 테이블과 파티션 테이블, 파티션과 클러스터링으로 만든 테이블의 비교한 표는 재미있게 보았다.

     

    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로 조회하는 부분이 있는데 테스트하면서 현재 상황에 맞게 수정해봐야겠다.

    (현재 내가 회사에서 사용하는 건 Impala 2.11)

    반응형

    댓글

Designed by Tistory.