parquet format
1.0.0
Repositori ini berisi spesifikasi definisi Apache Parquet dan Apache Thrift untuk membaca dan menulis metadata Parket.
Apache Parket adalah format file data sumber terbuka dan berorientasi kolom yang dirancang untuk penyimpanan dan pengambilan data yang efisien. Ini menyediakan skema kompresi dan pengkodean kinerja tinggi untuk menangani data kompleks secara massal dan didukung dalam banyak bahasa pemrograman dan alat analisis.
Kami menciptakan Parket untuk memanfaatkan keunggulan representasi data kolom terkompresi dan efisien yang tersedia untuk proyek apa pun di ekosistem Hadoop.
Parket dibangun dari awal dengan mempertimbangkan struktur data bersarang yang kompleks, dan menggunakan algoritma penghancuran dan perakitan rekaman yang dijelaskan dalam makalah Dremel. Kami yakin pendekatan ini lebih unggul daripada perataan sederhana ruang nama bertingkat.
Parket dibuat untuk mendukung skema kompresi dan pengkodean yang sangat efisien. Berbagai proyek telah menunjukkan dampak kinerja dari penerapan skema kompresi dan pengkodean yang tepat pada data. Parket memungkinkan skema kompresi ditentukan pada tingkat per kolom, dan tahan di masa depan untuk memungkinkan penambahan lebih banyak pengkodean saat ditemukan dan diterapkan.
Parket dibangun untuk digunakan oleh siapa saja. Ekosistem Hadoop kaya dengan kerangka pemrosesan data, dan kami tidak tertarik untuk menjadi favorit. Kami percaya bahwa substrat penyimpanan berbentuk kolom yang efisien dan diterapkan dengan baik akan berguna untuk semua kerangka kerja tanpa biaya ketergantungan yang ekstensif dan sulit diatur.
Proyek parquet-format berisi spesifikasi format dan definisi hemat metadata yang diperlukan untuk membaca file Parket dengan benar.
Proyek parquet-java berisi beberapa sub-modul, yang mengimplementasikan komponen inti membaca dan menulis aliran data berorientasi kolom yang bersarang, memetakan inti ini ke dalam format parket, dan menyediakan Format Input/Output Hadoop, pemuat Pig, dan lainnya utilitas berbasis java untuk berinteraksi dengan Parket.
Proyek parquet-compatibility berisi tes kompatibilitas yang dapat digunakan untuk memverifikasi bahwa implementasi dalam bahasa berbeda dapat membaca dan menulis file satu sama lain.
Sumber daya Java dapat dibangun menggunakan mvn package . Versi stabil saat ini harus selalu tersedia dari Maven Central.
Sumber daya hemat C++ dapat dihasilkan melalui make.
Thrift juga dapat dibuat kode ke dalam bahasa lain yang mendukung thrift.
Blokir (blok HDFS): Ini berarti blok dalam HDFS dan artinya tidak berubah untuk menjelaskan format file ini. Format file dirancang untuk bekerja dengan baik di atas HDFS.
File: File HDFS yang harus menyertakan metadata untuk file tersebut. Itu tidak perlu berisi data.
Grup baris: Partisi horizontal logis dari data menjadi beberapa baris. Tidak ada struktur fisik yang dijamin untuk kelompok baris. Grup baris terdiri dari potongan kolom untuk setiap kolom dalam kumpulan data.
Potongan kolom: Potongan data untuk kolom tertentu. Mereka tinggal di grup baris tertentu dan dijamin berdekatan dalam file.
Halaman: Potongan kolom dibagi menjadi beberapa halaman. Sebuah halaman secara konseptual merupakan unit yang tidak dapat dibagi (dalam hal kompresi dan pengkodean). Mungkin ada beberapa tipe halaman yang disisipkan dalam satu potongan kolom.
Secara hierarki, sebuah file terdiri dari satu atau lebih grup baris. Grup baris berisi tepat satu potongan kolom per kolom. Potongan kolom berisi satu halaman atau lebih.
File ini dan definisi Thrift harus dibaca bersama untuk memahami formatnya.
4-byte magic number "PAR1"
<Column 1 Chunk 1>
<Column 2 Chunk 1>
...
<Column N Chunk 1>
<Column 1 Chunk 2>
<Column 2 Chunk 2>
...
<Column N Chunk 2>
...
<Column 1 Chunk M>
<Column 2 Chunk M>
...
<Column N Chunk M>
File Metadata
4-byte length in bytes of file metadata (little endian)
4-byte magic number "PAR1"
Pada contoh di atas, terdapat N kolom dalam tabel ini, dibagi menjadi M grup baris. Metadata file berisi lokasi semua lokasi awal potongan kolom. Detail lebih lanjut tentang apa yang terkandung dalam metadata dapat ditemukan di definisi Thrift.
File Metadata ditulis setelah data untuk memungkinkan penulisan single pass.
Pembaca diharapkan membaca metadata file terlebih dahulu untuk menemukan semua potongan kolom yang mereka minati. Potongan kolom kemudian harus dibaca secara berurutan.
Ada dua jenis metadata: metadata file dan metadata header halaman. Semua struktur penghematan diserialkan menggunakan TCompactProtocol.
Tipe yang didukung oleh format file dimaksudkan seminimal mungkin, dengan fokus pada pengaruh tipe pada penyimpanan disk. Misalnya, int 16-bit tidak secara eksplisit didukung dalam format penyimpanan karena dicakup oleh int 32-bit dengan pengkodean yang efisien. Hal ini mengurangi kerumitan penerapan pembaca dan penulis untuk format tersebut. Jenis-jenisnya adalah:
Tipe logis digunakan untuk memperluas tipe yang dapat digunakan untuk menyimpan parket, dengan menentukan bagaimana tipe primitif harus diinterpretasikan. Hal ini menjaga kumpulan tipe primitif seminimal mungkin dan menggunakan kembali pengkodean parket yang efisien. Misalnya, string disimpan dengan tipe primitif BYTE_ARRAY dengan anotasi STRING. Anotasi ini menentukan cara mendekode dan menafsirkan data lebih lanjut. Anotasi disimpan sebagai bidang LogicalType dalam metadata file dan didokumentasikan di LogicalTypes.md.
Parket menyimpan statistik min/maks di beberapa tingkatan (seperti Potongan Kolom, Indeks Kolom, dan Halaman Data). Perbandingan nilai suatu tipe mematuhi aturan berikut:
Setiap tipe logis memiliki urutan perbandingan tertentu. Jika kolom dianotasi dengan tipe logika yang tidak diketahui, statistik tidak boleh digunakan untuk memangkas data. Urutan untuk tipe logis didokumentasikan di halaman LogicalTypes.md.
Untuk tipe primitif, aturan berikut berlaku:
BOOLEAN - salah, benar
INT32, INT64 - Perbandingan bertanda tangan.
FLOAT, DOUBLE - Perbandingan yang ditandatangani dengan penanganan khusus NaN dan angka nol yang ditandatangani. Detailnya didokumentasikan dalam definisi Thrift di serikat ColumnOrder . Mereka dirangkum di sini tetapi definisi Hemat dianggap otoritatif:
+0.0 harus ditulis ke dalam bidang statistik maksimal.-0.0 harus ditulis ke dalam bidang statistik min.Untuk kompatibilitas mundur saat membaca file:
BYTE_ARRAY dan FIXED_LEN_BYTE_ARRAY - Perbandingan byte-bijaksana leksikografis yang tidak ditandatangani.
Untuk mengkodekan kolom bersarang, Parket menggunakan pengkodean Dremel dengan tingkat definisi dan pengulangan. Tingkat definisi menentukan berapa banyak bidang opsional di jalur untuk kolom yang ditentukan. Tingkat pengulangan menentukan pada bidang berulang mana di jalur yang nilainya diulang. Definisi maksimal dan tingkat pengulangan dapat dihitung dari skema (yaitu berapa banyak sarang yang ada). Ini menentukan jumlah bit maksimum yang diperlukan untuk menyimpan level (level ditentukan untuk semua nilai dalam kolom).
Dua pengkodean untuk level tersebut didukung BIT_PACKED dan RLE. Hanya RLE yang sekarang digunakan karena menggantikan BIT_PACKED.
Nullitas dikodekan dalam tingkat definisi (yang dikodekan run-length). Nilai NULL tidak dikodekan dalam data. Misalnya, dalam skema non-bersarang, kolom dengan 1000 NULL akan dikodekan dengan pengkodean run-length (0, 1000 kali) untuk tingkat definisi dan tidak ada yang lain.
Untuk halaman data, 3 informasi dikodekan secara berurutan, setelah header halaman. Tidak ada padding yang diperbolehkan di halaman data. Agar kita memiliki:
Nilai uncompressed_page_size yang ditentukan di header adalah untuk ketiga bagian yang digabungkan.
Nilai yang dikodekan untuk halaman data selalu diperlukan. Tingkat definisi dan pengulangan bersifat opsional, berdasarkan definisi skema. Jika kolom tidak bertumpuk (yaitu jalur ke kolom memiliki panjang 1), kami tidak mengkodekan tingkat pengulangan (akan selalu bernilai 1). Untuk data yang diperlukan, tingkat definisi dilewati (jika dikodekan, akan selalu memiliki nilai tingkat definisi maksimal).
Misalnya, jika kolom tidak bertumpuk dan wajib diisi, data di halaman hanyalah nilai yang dikodekan.
Pengkodean yang didukung dijelaskan di Encodings.md
Codec kompresi yang didukung dijelaskan di Compression.md
Potongan kolom terdiri dari halaman-halaman yang ditulis saling membelakangi. Halaman-halaman tersebut memiliki header yang sama dan pembaca dapat melewati halaman yang tidak mereka minati. Data untuk halaman tersebut mengikuti header dan dapat dikompresi dan/atau dikodekan. Kompresi dan pengkodean ditentukan dalam metadata halaman.
Potongan kolom mungkin sebagian atau seluruhnya dikodekan kamus. Artinya, indeks kamus disimpan di halaman data, bukan di nilai sebenarnya. Nilai sebenarnya disimpan di halaman kamus. Lihat detailnya di Encodings.md. Halaman kamus harus ditempatkan pada posisi pertama potongan kolom. Maksimal satu halaman kamus dapat ditempatkan dalam satu potongan kolom.
Selain itu, file dapat berisi indeks kolom opsional untuk memungkinkan pembaca melewati halaman dengan lebih efisien. Lihat PageIndex.md untuk detail dan alasan di balik penambahan ini ke format.
Semua jenis halaman dapat di-checksum satu per satu. Hal ini memungkinkan penonaktifan checksum pada tingkat file HDFS, untuk lebih mendukung pencarian baris tunggal. Checksum dihitung menggunakan algoritma CRC32 standar - seperti yang digunakan misalnya GZip - pada representasi biner serial dari suatu halaman (tidak termasuk header halaman itu sendiri).
Jika metadata file rusak, file tersebut akan hilang. Jika metadata kolom rusak, potongan kolom tersebut akan hilang (tetapi potongan kolom untuk kolom ini di grup baris lain tidak masalah). Jika header halaman rusak, halaman yang tersisa dalam potongan tersebut akan hilang. Jika data dalam suatu halaman rusak, halaman itu akan hilang. File akan lebih tahan terhadap korupsi dengan kelompok baris yang lebih kecil.
Potensi ekstensi: Dengan grup baris yang lebih kecil, masalah terbesar adalah menempatkan metadata file di bagian akhir. Jika terjadi kesalahan saat menulis metadata file, semua data yang ditulis tidak akan terbaca. Hal ini dapat diperbaiki dengan menulis metadata file setiap grup baris ke-N. Setiap metadata file akan bersifat kumulatif dan mencakup semua grup baris yang ditulis sejauh ini. Menggabungkan ini dengan strategi yang digunakan untuk file rc atau avro menggunakan penanda sinkronisasi, pembaca dapat memulihkan file yang ditulis sebagian.
Format ini secara eksplisit dirancang untuk memisahkan metadata dari data. Hal ini memungkinkan pemisahan kolom menjadi beberapa file, serta memiliki satu file metadata yang mereferensikan beberapa file parket.
Ada banyak tempat dalam format untuk ekstensi yang kompatibel:
Parket Thrift IDL mencadangkan field-id 32767 dari setiap struktur Thrift untuk ekstensi. Jenis (Thrift) bidang ini selalu binary .
Pengujian Apache/parket berisi sekumpulan file Parket untuk tujuan pengujian.
Komentari masalah ini dan/atau hubungi milis pengembang parket untuk menyampaikan pertanyaan dan ide Anda. Perubahan pada definisi format inti ini diusulkan dan dibahas secara mendalam di milis. Anda mungkin juga tertarik untuk berkontribusi pada subproyek Parquet-Java, yang berisi semua implementasi dan API sisi Java. Lihat bagian "Cara Berkontribusi" pada proyek Parket-Java
Kami dan komunitas pengembang Parket mematuhi kode etik seperti yang dijelaskan oleh Twitter OSS: https://github.com/twitter/code-of-conduct/blob/master/code-of-conduct.md.
Hak Cipta 2013 Twitter, Cloudera dan kontributor lainnya.
Berlisensi di bawah Lisensi Apache, Versi 2.0: http://www.apache.org/licenses/LICENSE-2.0
