Format file dina data gedé: program atikan ringkes

Cuaca Déwa ku Remarin

regu Mail.ru Cloud Solutions nawaran tarjamahan artikel insinyur Rahul Bhatia ti Clairvoyant ngeunaan format file naon anu aya dina data gedé, naon fitur anu paling umum tina format Hadoop sareng format mana anu langkung saé dianggo.

Naha format file anu béda diperyogikeun?

Hambatan kinerja utama pikeun aplikasi anu diaktipkeun HDFS sapertos MapReduce sareng Spark nyaéta waktos anu diperyogikeun pikeun milarian, maca, sareng nyerat data. Masalah ieu diperparah ku kasusah dina ngatur susunan data badag lamun urang boga hiji schema ngembang tinimbang hiji tetep, atawa lamun aya sababaraha konstrain gudang.

Ngolah data badag ningkatkeun beban dina subsistem gudang - Hadoop nyimpen data redundantly pikeun ngahontal kasabaran kasalahan. Salian disk, prosesor, jaringan, sistem input/output, jeung saterusna dimuat. Nalika volume data naék, ogé biaya ngolah sareng nyimpen éta.

Rupa-rupa format file dina Hadoop invented pikeun ngajawab persis masalah ieu. Milih format file anu luyu tiasa masihan sababaraha kauntungan anu penting:

1. Waktos bacaan langkung gancang.
2. Waktos ngarékam langkung gancang.
3. file dibagikeun.
4. Rojongan pikeun évolusi skéma.
5. rojongan komprési dimekarkeun.

Sababaraha format file dimaksudkeun pikeun pamakéan umum, lianna pikeun pamakéan leuwih husus, sarta sababaraha dirancang pikeun minuhan ciri data husus. Jadi pilihan bener rada badag.

Format file Avro

keur serialization data Avro loba dipaké - éta string dumasar, nyaeta, format gudang data string dina Hadoop. Éta nyimpen skéma dina format JSON, sahingga gampang dibaca sareng diinterpretasi ku program naon waé. Datana sorangan dina format binér, kompak sareng éfisién.

Sistem serialisasi Avro nyaéta basa nétral. Payil bisa diolah dina rupa-rupa basa, ayeuna C, C ++, C #, Java, Python jeung Ruby.

Fitur konci Avro nyaéta dukungan anu kuat pikeun skéma data anu robih kana waktosna, nyaéta, mekar. Avro ngartos parobahan skéma-ngahapus, nambahkeun, atawa ngarobah widang.

Avro ngarojong rupa-rupa struktur data. Contona, Anjeun bisa nyieun rékaman nu ngandung hiji Asép Sunandar Sunarya, hiji tipe enumerated, sarta subrecord a.

Format ieu idéal pikeun nulis ka zona badarat (transisi) hiji danau data (danau data, atawa data lake - kumpulan instansi pikeun nyimpen rupa-rupa tipe data salian sumber data langsung).

Janten, format ieu paling cocog pikeun nyerat ka zona badarat danau data kusabab alesan ieu:

1. Data ti zona ieu biasana dibaca sacara lengkep pikeun diolah satuluyna ku sistem hilir - sareng format dumasar baris langkung éfisién dina hal ieu.
2. Sistem hilir tiasa kalayan gampang nyandak tabel skéma tina file-teu kedah nyimpen skéma nyalira dina panyimpenan meta éksternal.
3. Sagala parobahan kana skéma aslina gampang diolah (évolusi skéma).

Format File Parquet

Parquet mangrupikeun format file open source pikeun Hadoop anu disimpen struktur data nested dina format columnar datar.

Dibandingkeun sareng pendekatan baris tradisional, Parquet langkung éfisién dina hal neundeun sareng kinerja.

Ieu hususna kapaké pikeun queries nu maca kolom husus tina lega (loba kolom) tabel. Hatur nuhun kana format file, ngan ukur kolom anu diperyogikeun dibaca, janten I / O dijaga minimal.

A digression leutik jeung katerangan: Pikeun leuwih hadé ngartos format file Parquet di Hadoop, hayu urang tingali naon basis kolom - i.e. columnar - format. Format ieu nyimpen nilai anu sami pikeun unggal kolom babarengan.

contona, catetan ngawengku widang ID, Ngaran, jeung Departemen. Dina hal ieu, sadaya nilai kolom ID bakal disimpen babarengan, kitu ogé nilai kolom Ngaran, jeung saterusna. tabél bakal kasampak kawas kieu:

ID
nami
departemen

1
emp1
d1

2
emp2
d2

3
emp3
d3

Dina format string, data bakal disimpen saperti kieu:

1
emp1
d1
2
emp2
d2
3
emp3
d3

Dina format file columnar, data anu sarua bakal disimpen kawas kieu:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Format kolom langkung éfisién nalika anjeun kedah naroskeun sababaraha kolom tina méja. Ieu ngan bakal maca kolom diperlukeun sabab padeukeut. Ku cara kieu, operasi I/O dijaga minimal.

Contona, anjeun ngan butuh kolom NAME. DI format string Unggal catetan dina set data perlu dimuat, parsed ku widang, lajeng sasari data NAME. Format kolom ngamungkinkeun anjeun ngebor langsung kana kolom Ngaran sabab sadaya nilai pikeun kolom éta disimpen babarengan. Anjeun teu kudu nyeken sakabéh rekaman.

Ku kituna, format columnar ngaronjatkeun kinerja query sabab merlukeun kirang waktos lookup pikeun meunangkeun ka kolom diperlukeun tur ngurangan jumlah I / O operasi sabab ngan kolom dipikahoyong dibaca.

Salah sahiji fitur unik Parket nyaeta dina format ieu bisa nyimpen data kalawan struktur nested. Ieu ngandung harti yén dina file Parquet, malah widang nested bisa dibaca individual tanpa kudu maca sagala widang dina struktur nested. Parquet ngagunakeun algoritma shredding jeung assembly pikeun nyimpen struktur nested.

Pikeun ngartos format file Parquet di Hadoop, anjeun kedah terang istilah-istilah ieu:

1. Grup senar (grup baris): division logis horizontal data kana barisan. Grup baris diwangun ku sempalan unggal kolom dina set data.
2. sempalan kolom (kolom chunk): A sempalan tina kolom husus. fragmen kolom ieu hirup dina grup baris husus sarta dijamin bakal contiguous dina file.
3. Halaman (kaca): fragmen kolom dibagi kana kaca ditulis hiji sanggeus lianna. Kacana gaduh judul anu umum, janten anjeun tiasa ngalangkungan anu teu perlu nalika maca.

Di dieu judulna ngan ngandung angka magic PAR1 (4 bait) anu ngaidentipikasi file salaku file Parquet.

footer nyebutkeun kieu:

1. Metadata file anu ngandung koordinat awal metadata unggal kolom. Nalika maca, anjeun kedah maca heula metadata file pikeun milarian sadaya fragmen kolom anu dipikaresep. Bagian-bagian kolom kedah dibaca sacara berurutan. Metadata sanésna kalebet versi format, skéma, sareng pasangan konci-nilai tambahan.
2. Panjang métadata (4 bait).
3. angka magic PAR1 (4 bait).

Format File ORC

Dioptimalkeun format file baris-kolom (Kolom Baris Dioptimalkeun, CRO) nawiskeun cara anu éfisién pikeun nyimpen data sareng dirarancang pikeun ngatasi watesan format anu sanés. Nyimpen data dina bentuk kompak anu sampurna, ngamungkinkeun anjeun ngalangkungan detil anu teu dipikabutuh - tanpa meryogikeun pangwangunan indéks ageung, kompleks atanapi dijaga sacara manual.

Keunggulan format ORC:

1. Hiji file mangrupa kaluaran unggal tugas, nu ngurangan beban dina NameNode (ngaran titik).
2. Rojongan pikeun tipe data Hive, kaasup DateTime, decimal jeung tipe data kompléks (struct, daptar, peta jeung union).
3. Bacaan sakaligus tina file anu sami ku prosés RecordReader anu béda.
4. Kamampuhan pikeun ngabagi file tanpa nyeken spidol.
5. Estimasi alokasi memori numpuk maksimum mungkin pikeun prosés maca / nulis dumasar kana informasi dina footer file.
6. Metadata disimpen dina format serialisasi binér Protocol Buffers, anu ngamungkinkeun widang pikeun ditambahkeun jeung dihapus.

ORC nyimpen kumpulan string dina file tunggal, sarta dina kumpulan, data string disimpen dina format columnar.

File ORC nyimpen grup garis anu disebut stripes sareng inpormasi anu ngadukung dina footer file. The Postscript di ahir file ngandung parameter komprési jeung ukuran footer dikomprés.

Ukuran strip standar nyaéta 250 MB. Kusabab belang ageung sapertos kitu, maca tina HDFS dilakukeun langkung éfisién: dina blok contiguous ageung.

Footer file ngarékam daptar jalur dina file, jumlah baris per jalur, sareng jinis data unggal kolom. Nilai anu dihasilkeun tina count, mnt, max jeung jumlah pikeun tiap kolom ogé ditulis di dinya.

Footer strip ngandung diréktori lokasi aliran.

Data baris dipaké nalika nyeken tabel.

Data indéks kalebet nilai minimum sareng maksimal pikeun tiap kolom sareng posisi baris dina unggal kolom. Indéks ORC ngan ukur dianggo pikeun milih garis sareng grup baris, sanés pikeun ngawalon patarosan.

Ngabandingkeun format file béda

Avro dibandingkeun Parquet

1. Avro mangrupakeun format gudang baris, bari Parquet nyimpen data dina kolom.
2. Parquet langkung cocog pikeun patarosan analitis, hartosna operasi maca sareng data query langkung éfisién tibatan nyerat.
3. Operasi nulis dina Avro dipigawé leuwih éfisién ti di Parquet.
4. Avro ngurus évolusi sirkuit langkung dewasa. Parquet ngan ukur ngadukung skéma tambahan, sedengkeun Avro ngadukung évolusi multifungsi, nyaéta, nambihan atanapi ngarobih kolom.
5. Parquet mangrupa idéal pikeun querying sawaréh ti kolom dina tabel multi-kolom. Avro cocog pikeun operasi ETL dimana urang naroskeun sadaya kolom.

ORC vs Parquet

1. Parquet nyimpen data nested hadé.
2. ORC leuwih cocog pikeun predikat pushdown.
3. ORC ngarojong sipat ACID.
4. ORC compresses data hadé.

Naon deui maca dina topik:

1. Analisis data ageung dina awan: kumaha perusahaan tiasa janten berorientasi data.
2. Pituduh Humble pikeun Skéma Database.
3. Saluran telegram kami ngeunaan transformasi digital.

sumber: www.habr.com