Parquet vs ORC vs ORC với Snappy

Tôi đang chạy một vài thử nghiệm trên các định dạng lưu trữ có sẵn với Hive và sử dụng Parquet và ORC làm các tùy chọn chính. Tôi đã bao gồm ORC một lần với nén mặc định và một lần với Snappy.

Tôi đã đọc nhiều tài liệu nói rằng Parquet có độ phức tạp về thời gian / không gian tốt hơn so với ORC nhưng các thử nghiệm của tôi lại trái ngược với các tài liệu tôi đã xem qua.

Làm theo một số chi tiết về dữ liệu của tôi.

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

Sàn gỗ là tồi tệ nhất cho đến khi nén cho bàn của tôi có liên quan.

Các thử nghiệm của tôi với các bảng trên cho kết quả như sau.

Hoạt động đếm hàng

Text Format Cumulative CPU - 123.33 sec

Parquet Format Cumulative CPU - 204.92 sec

ORC Format Cumulative CPU - 119.99 sec 

ORC with SNAPPY Cumulative CPU - 107.05 sec

Tổng của một hoạt động cột

Text Format Cumulative CPU - 127.85 sec   

Parquet Format Cumulative CPU - 255.2 sec   

ORC Format Cumulative CPU - 120.48 sec   

ORC with SNAPPY Cumulative CPU - 98.27 sec

Trung bình của một hoạt động cột

Text Format Cumulative CPU - 128.79 sec

Parquet Format Cumulative CPU - 211.73 sec    

ORC Format Cumulative CPU - 165.5 sec   

ORC with SNAPPY Cumulative CPU - 135.45 sec 

Chọn 4 cột từ một dải ô đã cho bằng mệnh đề where

Text Format Cumulative CPU -  72.48 sec 

Parquet Format Cumulative CPU - 136.4 sec       

ORC Format Cumulative CPU - 96.63 sec 

ORC with SNAPPY Cumulative CPU - 82.05 sec 

Điều đó có nghĩa là ORC nhanh hơn sau đó Parquet? Hoặc có điều gì đó mà tôi có thể làm để làm cho nó hoạt động tốt hơn với thời gian phản hồi truy vấn và tỷ lệ nén?

Cảm ơn!

Tôi muốn nói rằng cả hai định dạng này đều có lợi thế riêng.

Parquet có thể tốt hơn nếu bạn có dữ liệu được lồng ghép cao, vì nó lưu trữ các phần tử của nó dưới dạng cây giống như Google Dremel ( Xem tại đây ).
Apache ORC có thể tốt hơn nếu cấu trúc tệp của bạn được làm phẳng.

Và theo như tôi biết thì sàn gỗ chưa hỗ trợ Indexes. ORC đi kèm với Chỉ số trọng lượng nhẹ và kể từ Hive 0.14, một Bộ lọc Bloom bổ sung có thể hữu ích cho thời gian phản hồi truy vấn tốt hơn, đặc biệt là khi nói đến các phép tính tổng.

Nén mặc định của Parquet là SNAPPY. Bảng A - B - C và D có cùng Tập dữ liệu không? Nếu có, có vẻ như có điều gì đó mờ ám về nó, khi nó chỉ nén xuống 1,9 GB

Bạn đang thấy điều này bởi vì:

• Hive có một đầu đọc ORC được vector hóa nhưng không có đầu đọc parquet được vector hóa.

• Spark có đầu đọc ván gỗ được vector hóa và không có đầu đọc ORC được vector hóa.

• Spark hoạt động tốt nhất với sàn gỗ, tổ ong hoạt động tốt nhất với ORC.

Tôi đã thấy sự khác biệt tương tự khi chạy ORC và Parquet với Spark.

Vectơ hóa có nghĩa là các hàng được giải mã theo lô, cải thiện đáng kể khả năng sử dụng bộ nhớ và bộ nhớ đệm.

(đúng như Hive 2.0 và Spark 2.1)

Cả Parquet và ORC đều có những ưu và nhược điểm riêng. Nhưng tôi chỉ cố gắng làm theo một quy tắc ngón tay cái đơn giản - "Dữ liệu của bạn được lồng vào nhau như thế nào và có bao nhiêu cột ở đó" . Nếu bạn theo dõi Google Dremel, bạn có thể tìm thấy sàn gỗ được thiết kế như thế nào. Họ sử dụng cấu trúc dạng cây phân cấp để lưu trữ dữ liệu. Càng làm tổ sâu hơn cây.

Nhưng ORC được thiết kế cho một kho lưu trữ tập tin phẳng. Vì vậy, nếu Dữ liệu của bạn được làm phẳng với ít cột hơn, bạn có thể sử dụng ORC, nếu không, bạn sẽ sử dụng parquet. Tính năng nén trên Dữ liệu phẳng hoạt động đáng kinh ngạc trong ORC.

Chúng tôi đã thực hiện một số phép đo điểm chuẩn với một tệp được làm phẳng lớn hơn, chuyển đổi nó thành khung dữ liệu spark và lưu trữ nó ở cả định dạng parquet và ORC trong S3 và thực hiện truy vấn với ** Redshift-Spectrum **.

Size of the file in parquet: ~7.5 GB and took 7 minutes to write
Size of the file in ORC: ~7.1. GB and took 6 minutes to write
Query seems faster in ORC files.

Ngay sau đó chúng tôi sẽ thực hiện một số đo điểm chuẩn cho Dữ liệu lồng nhau và cập nhật kết quả tại đây.

Chúng tôi đã thực hiện một số điểm chuẩn so sánh các định dạng tệp khác nhau (Avro, JSON, ORC và Parquet) trong các trường hợp sử dụng khác nhau.

https://www.slideshare.net/oom65/file-format-benchmarks-avro-json-orc-parquet

Tất cả dữ liệu đều có sẵn công khai và mã điểm chuẩn đều là mã nguồn mở tại:

https://github.com/apache/orc/tree/branch-1.4/java/bench

Cả hai đều có lợi thế của họ. Chúng tôi sử dụng Parquet cùng với Hive và Impala, nhưng chỉ muốn chỉ ra một vài ưu điểm của ORC so với Parquet: trong các truy vấn thực thi lâu, khi Hive truy vấn, bảng ORC GC được gọi ít thường xuyên hơn khoảng 10 lần . Có thể không là gì đối với nhiều dự án, nhưng có thể rất quan trọng đối với những dự án khác.

ORC cũng mất ít thời gian hơn nhiều, khi bạn chỉ cần chọn một vài cột từ bảng. Một số truy vấn khác, đặc biệt với các phép nối, cũng mất ít thời gian hơn do thực thi truy vấn được vector hóa, không có sẵn cho Parquet

Ngoài ra, nén ORC đôi khi hơi ngẫu nhiên, trong khi nén Parquet nhất quán hơn nhiều. Có vẻ như khi bảng ORC có nhiều cột số - nó cũng không nén. Nó ảnh hưởng đến cả nén zlib và snappy