Format fail dalam data besar: program pendidikan ringkas

Dewa Cuaca oleh Remarin

Pasukan Penyelesaian Awan Mail.ru menawarkan terjemahan artikel jurutera Rahul Bhatia daripada Clairvoyant tentang format fail yang terdapat dalam data besar, apakah ciri paling biasa bagi format Hadoop dan format mana yang lebih baik untuk digunakan.

Mengapakah format fail yang berbeza diperlukan?

Kesesakan prestasi utama untuk aplikasi berdaya HDFS seperti MapReduce dan Spark ialah masa yang diperlukan untuk mencari, membaca dan menulis data. Masalah ini ditambah lagi dengan kesukaran mengurus set data yang besar jika kita mempunyai skema yang berkembang dan bukannya skema tetap, atau jika terdapat beberapa kekangan storan.

Memproses data besar meningkatkan beban pada subsistem storan - Hadoop menyimpan data secara berlebihan untuk mencapai toleransi kesalahan. Selain cakera, pemproses, rangkaian, sistem input/output, dan sebagainya dimuatkan. Apabila jumlah data bertambah, begitu juga kos pemprosesan dan penyimpanannya.

Pelbagai format fail dalam Hadoop dicipta untuk menyelesaikan masalah ini dengan tepat. Memilih format fail yang sesuai boleh memberikan beberapa faedah penting:

1. Masa membaca lebih cepat.
2. Masa rakaman yang lebih cepat.
3. Fail kongsi.
4. Sokongan untuk evolusi skema.
5. Sokongan mampatan yang diperluaskan.

Sesetengah format fail bertujuan untuk kegunaan umum, yang lain untuk kegunaan yang lebih khusus, dan sesetengahnya direka untuk memenuhi ciri data tertentu. Jadi pilihannya agak besar.

Format fail Avro

Untuk siri data Avro digunakan secara meluas - ia berasaskan rentetan, iaitu format penyimpanan data rentetan dalam Hadoop. Ia menyimpan skema dalam format JSON, menjadikannya mudah dibaca dan ditafsir oleh mana-mana program. Data itu sendiri adalah dalam format binari, padat dan cekap.

Sistem bersiri Avro adalah neutral bahasa. Fail boleh diproses dalam pelbagai bahasa, pada masa ini C, C++, C#, Java, Python dan Ruby.

Ciri utama Avro ialah sokongan teguhnya untuk skema data yang berubah dari semasa ke semasa, iaitu berkembang. Avro memahami perubahan skema—memadam, menambah atau menukar medan.

Avro menyokong pelbagai struktur data. Sebagai contoh, anda boleh mencipta rekod yang mengandungi tatasusunan, jenis terhitung dan subrekod.

Format ini sesuai untuk menulis ke zon pendaratan (peralihan) tasik data (tasik data, atau tasik data - koleksi kejadian untuk menyimpan pelbagai jenis data sebagai tambahan kepada sumber data secara langsung).

Jadi, format ini paling sesuai untuk menulis ke zon pendaratan tasik data atas sebab berikut:

1. Data daripada zon ini biasanya dibaca secara keseluruhannya untuk diproses selanjutnya oleh sistem hiliran - dan format berasaskan baris adalah lebih cekap dalam kes ini.
2. Sistem hiliran boleh mendapatkan semula jadual skema daripada fail dengan mudah—tidak perlu menyimpan skema secara berasingan dalam storan meta luaran.
3. Sebarang perubahan kepada skema asal mudah diproses (evolusi skema).

Format Fail Parket

Parket ialah format fail sumber terbuka untuk Hadoop yang disimpan struktur data bersarang dalam format kolumnar rata.

Berbanding dengan pendekatan baris tradisional, Parket lebih cekap dari segi penyimpanan dan prestasi.

Ini amat berguna untuk pertanyaan yang membaca lajur tertentu daripada jadual yang luas (banyak lajur). Terima kasih kepada format fail, hanya lajur yang diperlukan dibaca, jadi I/O dikekalkan pada tahap minimum.

Penyimpangan dan penjelasan kecil: Untuk lebih memahami format fail Parket dalam Hadoop, mari lihat apakah format berasaskan lajur - iaitu kolumnar -. Format ini menyimpan nilai yang serupa untuk setiap lajur bersama-sama.

Sebagai contoh, rekod termasuk medan ID, Nama dan Jabatan. Dalam kes ini, semua nilai lajur ID akan disimpan bersama, begitu juga nilai lajur Name, dan seterusnya. Jadual akan kelihatan seperti ini:

ID
Nama
Jabatan

1
emp1
d1

2
emp2
d2

3
emp3
d3

Dalam format rentetan, data akan disimpan seperti berikut:

1
emp1
d1
2
emp2
d2
3
emp3
d3

Dalam format fail lajur, data yang sama akan disimpan seperti ini:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Format lajur adalah lebih cekap apabila anda perlu menanyakan berbilang lajur daripada jadual. Ia hanya akan membaca lajur yang diperlukan kerana ia bersebelahan. Dengan cara ini, operasi I/O dikekalkan pada tahap minimum.

Sebagai contoh, anda hanya memerlukan lajur NAME. DALAM format rentetan Setiap rekod dalam set data perlu dimuatkan, dihuraikan mengikut medan, dan kemudian mengekstrak data NAME. Format lajur membolehkan anda menelusuri terus ke lajur Nama kerana semua nilai untuk lajur itu disimpan bersama. Anda tidak perlu mengimbas keseluruhan rakaman.

Oleh itu, format kolumnar meningkatkan prestasi pertanyaan kerana ia memerlukan masa carian yang lebih sedikit untuk sampai ke lajur yang diperlukan dan mengurangkan bilangan operasi I/O kerana hanya lajur yang dikehendaki dibaca.

Salah satu ciri unik Parket adakah dalam format ini boleh menyimpan data dengan struktur bersarang. Ini bermakna dalam fail Parket, medan bersarang pun boleh dibaca secara individu tanpa perlu membaca semua medan dalam struktur bersarang. Parket menggunakan algoritma carik dan pemasangan untuk menyimpan struktur bersarang.

Untuk memahami format fail Parket dalam Hadoop, anda perlu mengetahui istilah berikut:

1. Kumpulan baris (kumpulan baris): pembahagian data mendatar logik ke dalam baris. Kumpulan baris terdiri daripada serpihan setiap lajur dalam set data.
2. Serpihan lajur (ketulan lajur): Serpihan lajur tertentu. Serpihan lajur ini hidup dalam kumpulan baris tertentu dan dijamin bersebelahan dalam fail.
3. Page (halaman): Serpihan lajur dibahagikan kepada halaman yang ditulis satu demi satu. Halaman tersebut mempunyai tajuk yang sama, jadi anda boleh melangkau halaman yang tidak perlu semasa membaca.

Di sini tajuk hanya mengandungi nombor ajaib PAR1 (4 bait) yang mengenal pasti fail sebagai fail Parket.

Pengaki menyatakan perkara berikut:

1. Metadata fail yang mengandungi koordinat permulaan setiap metadata lajur. Semasa membaca, anda mesti membaca metadata fail terlebih dahulu untuk mencari semua serpihan lajur yang diminati. Bahagian lajur kemudiannya hendaklah dibaca secara berurutan. Metadata lain termasuk versi format, skema dan sebarang pasangan nilai kunci tambahan.
2. Panjang metadata (4 bait).
3. nombor ajaib PAR1 (4 bait).

Format Fail ORC

Format fail baris-lajur dioptimumkan (Lajur Baris Dioptimumkan, ORC) menawarkan cara yang sangat cekap untuk menyimpan data dan direka bentuk untuk mengatasi batasan format lain. Menyimpan data dalam bentuk yang padat sempurna, membolehkan anda melangkau butiran yang tidak perlu - tanpa memerlukan pembinaan indeks yang besar, kompleks atau diselenggara secara manual.

Kelebihan format ORC:

1. Satu fail ialah output bagi setiap tugasan, yang mengurangkan beban pada NameNode (nod nama).
2. Sokongan untuk jenis data Hive, termasuk DateTime, jenis data perpuluhan dan kompleks (struktur, senarai, peta dan kesatuan).
3. Pembacaan serentak fail yang sama oleh proses RecordReader yang berbeza.
4. Keupayaan untuk memisahkan fail tanpa mengimbas penanda.
5. Anggaran peruntukan memori timbunan maksimum yang mungkin untuk proses baca/tulis berdasarkan maklumat dalam pengaki fail.
6. Metadata disimpan dalam format siri binari Penampan Protokol, yang membolehkan medan ditambah dan dialih keluar.

ORC menyimpan koleksi rentetan dalam satu fail dan dalam koleksi, data rentetan disimpan dalam format lajur.

Fail ORC menyimpan kumpulan baris yang dipanggil jalur dan maklumat sokongan dalam pengaki fail. Postscript di penghujung fail mengandungi parameter mampatan dan saiz pengaki termampat.

Saiz jalur lalai ialah 250 MB. Disebabkan oleh jalur yang begitu besar, bacaan daripada HDFS dilakukan dengan lebih cekap: dalam blok bersebelahan yang besar.

Pengaki fail merekodkan senarai lorong dalam fail, bilangan baris setiap lorong dan jenis data setiap lajur. Nilai kiraan, min, maks dan jumlah yang terhasil untuk setiap lajur juga ditulis di sana.

Pengaki jalur mengandungi direktori lokasi aliran.

Data baris digunakan semasa mengimbas jadual.

Data indeks termasuk nilai minimum dan maksimum untuk setiap lajur dan kedudukan baris dalam setiap lajur. Indeks ORC digunakan hanya untuk memilih jalur dan kumpulan baris, bukan untuk menjawab pertanyaan.

Perbandingan format fail yang berbeza

Avro berbanding Parket

1. Avro ialah format storan baris, manakala Parket menyimpan data dalam lajur.
2. Parket lebih sesuai untuk pertanyaan analitikal, bermakna operasi baca dan data pertanyaan jauh lebih cekap daripada penulisan.
3. Operasi tulis dalam Avro dilakukan dengan lebih cekap daripada dalam Parket.
4. Avro berurusan dengan evolusi litar dengan lebih matang. Parket hanya menyokong penambahan skema, manakala Avro menyokong evolusi pelbagai fungsi, iaitu menambah atau menukar lajur.
5. Parket sesuai untuk menanyakan subset lajur dalam jadual berbilang lajur. Avro sesuai untuk operasi ETL di mana kami menanyakan semua lajur.

ORC lwn Parket

1. Parket menyimpan data bersarang dengan lebih baik.
2. ORC lebih sesuai untuk menolak predikat.
3. ORC menyokong sifat ACID.
4. ORC memampatkan data dengan lebih baik.

Apa lagi yang perlu dibaca mengenai topik tersebut:

1. Analisis data besar dalam awan: bagaimana syarikat boleh menjadi berorientasikan data.
2. Panduan Rendah untuk Skema Pangkalan Data.
3. Saluran telegram kami tentang transformasi digital.

Sumber: www.habr.com