Hadoop termasuk produk yang dapat bekerja dengan file berbagai format. Saya telah berulang kali mencari, membaca, dan memikirkan format mana yang lebih baik. Ketika saya berlari ke dalam format ORC yang relatif acak, saya menjadi tertarik, membaca (dan bahkan sedikit dimanja), dan itulah yang saya pahami - tidak benar membandingkan format seperti itu. Lebih tepatnya, mereka biasanya dibandingkan, menurut pendapat saya, dengan cara yang salah. Sebenarnya, artikel tentang ini, serta tentang format ORC Apache (dalam istilah teknis) dan peluang yang diberikannya.

Saya akan mulai dengan pertanyaan: apa yang bisa menjadi ukuran tabel relasional (dalam byte dan sangat kira-kira), terdiri dari 10 ribu baris (dua bidang bilangan per baris)? Biasanya mereka meletakkan kat di sini, dan jawabannya ditempatkan di bawah kat - saya akan menjawab di sini: 628 byte. Dan detail dan sejarah akan ditransfer ke bawah kucing.

Bagaimana semuanya dimulai: Saya membangun perpustakaan untuk bekerja dengan Apache ORC (lihat halaman utama proyek - https://orc.apache.org ) dan mengumpulkan contoh mereka sendiri tentang menulis ke ORC (untuk mematahkan kepala - kita mulai dengan pekerjaan apa) , ia memiliki 2 bidang dan 10 ribu baris di dalamnya. Saya memulainya - saya menerima file orc, karena saya melakukannya di suatu tempat di luar kantor - untuk berjaga-jaga, saya menulis ulang perpustakaan dan file pada flash drive (terburu-buru - saya tidak melihat ukurannya, saya pikir flash drive akan bertahan hidup).

Tapi entah bagaimana saya cepat berkorespondensi ... Saya melihat ukuran - 628 byte. Saya pikir itu adalah kesalahan, saya duduk dan mulai mengerti. Saya meluncurkan utilitas untuk melihat ORC dari perpustakaan terkompilasi yang sama - isi file menunjukkan semuanya jujur ​​- 10 ribu baris. Setelah itu, saya bertanya-tanya bagaimana 10 ribu baris dapat masuk ke dalam 628 byte (pada saat itu saya sudah tahu sedikit tentang ORC dan menyadari bahwa ada juga metadata - formatnya swasembada). Dipahami, bagikan.

Tentang format ORC

Saya tidak akan mengulangi di sini kata-kata umum tentang format - lihat tautan di atas, itu ditulis dengan baik di sana. Saya akan fokus pada dua kata sifat dalam bentuk luar biasa dari gambar di atas (gambar diambil dari beranda proyek): mari kita coba mencari tahu mengapa ORC adalah "yang tercepat" dan "yang paling kompak".

Kecepatan

Kecepatannya bisa berbeda, berkenaan dengan data - setidaknya kecepatan membaca atau menulis (Anda bisa melangkah lebih jauh, tetapi mari kita berhenti untuk sekarang). Karena Hadoop secara eksplisit disebutkan dalam slogan di atas, kami terutama akan mempertimbangkan kecepatan membaca.

Mengutip lebih banyak dari dokumentasi ORC:

Ini dioptimalkan untuk membaca streaming yang besar, tetapi dengan dukungan terintegrasi untuk menemukan baris yang diperlukan dengan cepat. Menyimpan data dalam format kolom memungkinkan pembaca membaca, mendekompresi, dan memproses hanya nilai-nilai yang diperlukan untuk permintaan saat ini.

Saya akan menerjemahkan sedikit:

• format dioptimalkan untuk streaming membaca volume besar
• pada saat yang sama berisi dukungan untuk pencarian cepat dari baris yang diperlukan
• memungkinkan Anda untuk hanya membaca data yang Anda butuhkan

Ukuran

Tidak ada kutipan, saya akan katakan dengan kata-kata saya sendiri

• format secara optimal menyimpan meta-informasi
• mencapai keseimbangan antara kecepatan baca streaming dan penyimpanan yang ringkas
• dukungan bawaan untuk penyimpanan nilai kolom paling ringkas

Memberikan peluang

Saya ingin menarik perhatian Anda pada kata-kata dari kutipan di atas: "dioptimalkan untuk ...", "berisi dukungan ...", "memungkinkan Anda membaca ..." - format file, sebagai bahasa pemrograman, adalah sarana (dalam hal ini, memastikan penyimpanan yang efisien dan akses ke data). Apakah penyimpanan dan akses ke data akan benar-benar efektif tergantung tidak hanya pada alat, tetapi juga pada siapa yang menggunakannya dan bagaimana.

Mari kita lihat format apa yang disediakan format untuk kecepatan dan kekompakan.

Penyimpanan kolom dan garis

Data dalam ORC disimpan dalam bentuk kolom, pertama-tama itu mempengaruhi ukuran. Untuk memastikan kecepatan pembacaan streaming, file dibagi menjadi apa yang disebut "garis", masing-masing strip mencukupi, mis. dapat dibaca secara terpisah (dan, karena itu, secara paralel). Karena strip, ukuran file akan meningkat (nilai kolom yang tidak unik akan disimpan beberapa kali - dalam strip di mana nilai tersebut terjadi) - keseimbangan yang sama "ukuran - kecepatan" (ini adalah kompromi).

Indeks

Format ORC menyiratkan indeks yang memungkinkan Anda untuk menentukan apakah garis (atau lebih tepatnya, bagian garis masing-masing 10 ribu baris, yang disebut "grup baris") berisi data yang Anda cari atau tidak. Indeks dibuat di masing-masing kolom. Ini mempengaruhi kecepatan membaca, meningkatkan ukuran. Saat streaming membaca indeks, omong-omong, Anda tidak bisa membaca.

Kompresi

Semua metadata disimpan dalam bentuk terkompresi, dan ini

• informasi statistik dan deskriptif (format ini memungkinkan Anda untuk membuat ulang tabel yang disimpan di dalamnya, termasuk nama dan jenis bidang)
• indeks
• informasi partisi (menjadi garis-garis dan aliran)

(di bawah ini kita akan melihat bahwa metadata adalah bagian penting dari file)

Nilai kolom juga disimpan dalam bentuk terkompresi. Pada saat yang sama, dimungkinkan untuk membaca dan membongkar hanya blok data yang diperlukan (mis., Bukan file yang dikompresi dan bukan keseluruhan strip). Kompresi mempengaruhi ukuran dan kecepatan baca.

Coding

Nilai kolom - dan file menyimpan nilai-nilai ini - disimpan dalam bentuk yang disandikan. Dalam versi format saat ini (ORC v1) untuk bilangan bulat, misalnya, 4 opsi pengkodean tersedia. Pada saat yang sama, bukan seluruh kolom dikodekan, bagian-bagian kolom dikodekan, setiap bagian dapat dikodekan secara optimal untuk bagian ini (bagian-bagian seperti itu disebut "run" dalam spesifikasi). Dengan demikian, minimalisasi total panjang data yang disimpan tercapai. Sekali lagi, efeknya pada ukuran dan kecepatan.

Mari kita lihat file ORC

Mari kita lihat secara singkat apa yang ada di dalam file ORC (yang itu sendiri adalah 628 byte). Bagi mereka yang tidak terlalu tertarik dengan detail teknis, gulir ke bawah ke bagian berikutnya (tentang perbandingan format).

Ini adalah bagaimana tabel kami didefinisikan dalam contoh rekaman dalam ORC:

Metadata

Informasi tentang panjang (saya memberikan screenshot jupyter notebook, saya pikir cukup jelas)

Apa yang kita lihat di sini:

• dalam "shank" (dan ini Postscript + Footer + Metadata) hanya 1 + 23 + 115 + 50 = 189 byte
• dalam satu strip, hanya 3 + 436 = 439 byte, total 628 byte
• strip berisi indeks (73 byte), data (276 byte), footer (87 byte)

Mari kita perhatikan perbandingan volume data dan metadata (276 hingga 352 byte). Tapi 276 byte data ini juga bukan hanya data, data ini mengandung sedikit "berlebihan" (di sini demi singkatnya saya tidak memberikan tangkapan layar - butuh waktu lama dengan mereka, saya hanya akan mengelola komentar saya), yang termasuk dalam data:

• PRESENT stream untuk setiap kolom, ada tiga di antaranya (termasuk struct pseudo-kolom umum) - 20 byte per masing-masing, total 60 byte
• aliran data (di sini pseudo-kolom tidak diwakili) - 103 dan 113 byte (masing-masing kolom "x" dan "y")

Aliran PRESENT adalah string bit yang memberi tahu Anda di mana kolomnya NULL. Sebagai contoh kami, kehadiran mereka terlihat aneh (dalam statistik file kami ditulis dengan jelas bahwa tidak ada NULL dalam data - mengapa kemudian menyertakan PRESENT? Tampaknya seperti cacat ...)

Secara total, data itu sendiri menempati 216 byte, metadata - 352.

Dapat juga dilihat dari metadata bahwa kedua kolom dikodekan menggunakan metode DIRECT_V2 (untuk bilangan bulat, memungkinkan 4 jenis representasi, untuk detail saya merujuk pada spesifikasi - ada di situs web proyek).

Data

Mari kita lihat (lagi tanpa screenshot untuk singkatnya) bagaimana 10 ribu angka masuk dalam 103 byte (untuk kolom "x"):

• delta encoding digunakan, di mana parameter adalah nilai awal dan langkah (sedikit disederhanakan untuk singkatnya)
• kami selalu memiliki 1 langkah, nilai awal untuk proses pertama adalah 0, kemudian 511, 1022, dll.
• run (satu set data yang dikodekan dalam satu cara) dalam kasus kami berisi 511 nilai (nilai maksimum yang mungkin untuk pengkodean delta)
• panjang setiap run dalam file adalah dari 4 hingga 6 byte (panjang run tumbuh karena fakta bahwa nilai awal diwakili menggunakan zigzag)
• total untuk kolom "x" kita dapatkan di file 20 run-s dengan total panjang 103 byte (saya memeriksa - semuanya cocok bersama-sama)

Sebagai penutup ulasan dari penyajian tabel sederhana kami dalam sebuah file, saya akan mengatakan bahwa indeks dalam contoh ini merosot - mereka menunjukkan awal dari aliran data. Saya akan berurusan dengan indeks menggunakan contoh-contoh kehidupan nyata; Saya mungkin akan menggambarkannya dalam artikel terpisah.

Bagi yang berminat: di bawah tautan Anda dapat menemukan notebook jupyter, di mana saya "memahami" format internal. Anda dapat menggunakannya dan ulangi (file ORC juga dilampirkan di sana).

Saya yakin bahwa banyak pembaca "hilang" - ya, format ORC tidak sederhana (baik dalam hal memahami detail dan dalam hal menggunakan fitur yang disediakan).

Tentang perbandingan format

Sekarang mari kita beralih ke poin utama - perbandingan format yang salah.

Seberapa sering format dibandingkan: mari kita bandingkan ukuran file dalam format A dan B, kecepatan membaca (berbagai jenis bacaan - acak, streaming, dll.) Dalam format A dan B. Bandingkan, kami menyimpulkan bahwa format A lebih baik daripada format B.

Menggunakan contoh alat compactness (encoding) terakhir yang tercantum di atas: dapatkah data dikodekan dalam ORC secara optimal? Ya, ada peluang - lihat di atas. Tapi sama baiknya, Anda tidak bisa melakukan ini! Itu tergantung pada "penulis" (penulis dalam terminologi ORC): dalam contoh di atas, penulis bisa melakukan ini. Tapi dia hanya bisa menuliskan 2 kali dalam 10 ribu angka dan ini juga benar dalam hal format. Membandingkan format "berdasarkan ukuran" kami membandingkan tidak hanya dan tidak begitu banyak format dengan kualitas algoritmik sistem aplikasi menggunakan format ini .

Siapa "penulis" di Hadoop? Ada banyak dari mereka - misalnya, Hive, yang membuat tabel yang menyimpan datanya dalam file dalam format ORC. Membandingkan, misalnya, ORC dengan Parket di Hadoop, kami benar-benar mengevaluasi kualitas implementasi algoritma konversi data yang diterapkan di Hive. Kami tidak membandingkan format (dengan demikian).

Fitur penting dari Hadoop

Dalam dunia relasional klasik, kami tidak memiliki cara untuk mempengaruhi ukuran tabel di Oracle - itu entah bagaimana disimpan dan hanya Oracle yang tahu caranya. Dalam Hadoop, situasinya sedikit berbeda: kita dapat melihat bagaimana tabel ini atau itu disimpan (seberapa baik Hive, misalnya, berhasil "menyandikan" itu). Dan, jika kita melihat bahwa ini dapat diperbaiki, kita memiliki peluang nyata untuk ini: untuk membuat file ORC kita sendiri yang lebih optimal dan memberikannya kepada Hive sebagai tabel eksternal.

Bandingkan ORC dan QVD

Baru-baru ini saya menggambarkan format QVD yang digunakan QlikVew / QlikSense secara aktif. Mari kita ilustrasikan secara singkat kedua format ini dalam hal kemampuan yang mereka berikan untuk mencapai kecepatan membaca maksimum dan meminimalkan ukuran. Kemampuan ORC dijelaskan di atas, seperti pada QVD:

Penyimpanan kolom

QVD dapat dianggap sebagai format "berbentuk kolom", tidak ada duplikasi nilai kolom di dalamnya - nilai unik disimpan satu kali. TETAPI itu tidak memungkinkan pemrosesan paralel - pertama Anda harus sepenuhnya membaca nilai-nilai semua kolom, maka Anda dapat membaca baris secara paralel.

Dan ada duplikasi di tingkat baris - baris menyimpan nilai indeks duplikat dalam tabel karakter.

Kompresi

Saya tidak menemukan file QVD terkompresi - saya tidak berhasil - ada tag seperti itu di metadata, mungkin masing-masing bagian tentang yang ada offset dan panjang dalam metadata (dan ini adalah masing-masing tabel karakter dan seluruh tabel string) dapat dikompresi. Dalam hal ini, pembacaan paralel dari baris adalah "selamat tinggal" ...

Indeks

Tidak ada cara untuk memahami dalam file QVD bagian mana yang perlu dibaca. Dalam praktiknya, Anda harus menguraikan tabel karakter byte-by-byte (masing-masing!), Bukan cara yang sangat efisien ...

Coding

Pengkodean dalam QVD tidak digunakan, dimungkinkan untuk menggambar analogi dari indeks bit dalam tabel string dengan pengkodean, tetapi analogi ini "dikompensasi" dengan menduplikasi angka dengan string dalam tabel karakter (untuk detail, lihat artikel, secara singkat - nilai kolom sering diwakili oleh angka DAN string).

Kesimpulan pada perbandingan singkat ini yang saya pribadi buat adalah ini - format QVD praktis tidak mengandung kemampuan yang memungkinkan penyimpanan yang ringkas dan pembacaan cepat data yang terkandung dalam file format ini.

(Entah bagaimana itu terdengar ofensif untuk QVD, saya akan menambahkan sedikit - format telah dibuat sejak lama, hanya QlikView / QlikSense digunakan, dan mereka "menyimpan" semua data dalam memori. Saya pikir file QVD hanya membaca semua "sebagaimana adanya" dalam memori, dan kemudian ini yang luar biasa dalam semua hal produk BI bekerja sangat cepat dengan presentasi ini - di sini mereka adalah master ...)

Alih-alih sebuah kesimpulan

Dia mengkritik dan belum menawarkan apa pun ... - Saya sarankan.

Sepertinya saya bahwa format perlu dibandingkan bukan dengan contoh implementasi spesifiknya, format perlu dibandingkan dalam hal alat yang disertakan di dalamnya dan kemampuan untuk menggunakan alat ini untuk menyelesaikan masalah khusus kami. Kecepatan prosesor terus meningkat, sekarang kami dapat membeli hampir semua algoritma konversi data setelah dibaca - bagaimanapun, membaca dari disk akan lebih lambat. Itu sebabnya "sarana ekspresif" dari format itu penting.

Di atas, saya mendaftar secara singkat kemungkinan-kemungkinan menarik dari format ORC. Saya masih belum memiliki statistik tentang bagaimana hal-hal dalam prakteknya (yang mana dari fitur-fitur ini dan sejauh mana digunakan oleh Hive, misalnya). Ketika muncul - saya akan menulis. Rencana segera adalah untuk membuat tinjauan serupa terhadap format penyimpanan populer lainnya - Parket.

Yah - dan sebagai kesimpulan - di dunia modern ada banyak informasi, sayangnya, bagian dari informasi ini terlalu dangkal. Kami tidak akan menyerah, kami akan melihat esensi.