Mga format ng file sa malaking data: isang maikling programang pang-edukasyon

Weather Deity ni Remarin

Koponan Mail.ru Cloud Solutions Nag-aalok ang pagsasalin ng artikulo engineer na si Rahul Bhatia mula sa Clairvoyant tungkol sa kung anong mga format ng file ang mayroon sa malaking data, ano ang mga pinakakaraniwang feature ng mga format ng Hadoop at kung aling format ang mas mahusay na gamitin.

Bakit kailangan ang iba't ibang mga format ng file?

Ang isang pangunahing bottleneck sa pagganap para sa mga application na pinagana ng HDFS tulad ng MapReduce at Spark ay ang oras na kinakailangan upang maghanap, magbasa, at magsulat ng data. Ang mga problemang ito ay pinagsasama ng kahirapan sa pamamahala ng malalaking set ng data kung mayroon kaming isang umuusbong na schema sa halip na isang nakapirming isa, o kung mayroong ilang mga hadlang sa storage.

Ang pagpoproseso ng malaking data ay nagpapataas ng load sa storage subsystem - Ang Hadoop ay nag-iimbak ng data nang labis upang makamit ang fault tolerance. Bilang karagdagan sa mga disk, ang processor, network, input/output system, at iba pa ay na-load. Habang lumalaki ang dami ng data, tumataas din ang gastos sa pagproseso at pag-iimbak nito.

Iba't ibang mga format ng file sa Hadoop imbento upang malutas ang tiyak na mga problemang ito. Ang pagpili ng naaangkop na format ng file ay maaaring magbigay ng ilang makabuluhang benepisyo:

1. Mas mabilis na oras ng pagbabasa.
2. Mas mabilis na oras ng pagre-record.
3. Nakabahaging mga file.
4. Suporta para sa ebolusyon ng schema.
5. Pinalawak na suporta sa compression.

Ang ilang mga format ng file ay inilaan para sa pangkalahatang paggamit, ang iba ay para sa mas partikular na paggamit, at ang ilan ay idinisenyo upang matugunan ang mga partikular na katangian ng data. Kaya ang pagpipilian ay talagang medyo malaki.

Avro file format

Para sa serialization ng data Ang Avro ay malawakang ginagamit - ito batay sa string, iyon ay, isang format ng imbakan ng data ng string sa Hadoop. Iniimbak nito ang schema sa JSON na format, na ginagawang madaling basahin at bigyang-kahulugan ng anumang programa. Ang data mismo ay nasa binary format, compact at mahusay.

Ang sistema ng serialization ng Avro ay neutral sa wika. Maaaring iproseso ang mga file sa iba't ibang wika, kasalukuyang C, C++, C#, Java, Python at Ruby.

Ang isang pangunahing tampok ng Avro ay ang matatag na suporta nito para sa mga schema ng data na nagbabago sa paglipas ng panahon, iyon ay, nagbabago. Naiintindihan ng Avro ang mga pagbabago sa schema—pagtanggal, pagdaragdag, o pagpapalit ng mga field.

Sinusuportahan ng Avro ang iba't ibang istruktura ng data. Halimbawa, maaari kang lumikha ng isang tala na naglalaman ng isang array, isang enumerated na uri, at isang subrecord.

Ang format na ito ay mainam para sa pagsulat sa landing (transition) zone ng isang data lake (lawa ng data, o data lake - isang koleksyon ng mga pagkakataon para sa pag-imbak ng iba't ibang uri ng data bilang karagdagan sa mga pinagmumulan ng data nang direkta).

Kaya, ang format na ito ay pinakaangkop para sa pagsulat sa landing zone ng isang data lake para sa mga sumusunod na dahilan:

1. Ang data mula sa zone na ito ay karaniwang binabasa sa kabuuan nito para sa karagdagang pagproseso ng mga downstream system - at ang isang row-based na format ay mas mahusay sa kasong ito.
2. Madaling makuha ng mga downstream system ang mga talahanayan ng schema mula sa mga file—hindi na kailangang mag-imbak ng mga schema nang hiwalay sa external na meta storage.
3. Ang anumang pagbabago sa orihinal na schema ay madaling naproseso (schema evolution).

Format ng Parquet File

Ang parquet ay isang open source na format ng file para sa Hadoop na nag-iimbak mga nested na istruktura ng data sa flat columnar na format.

Kung ikukumpara sa tradisyonal na row approach, ang Parquet ay mas mahusay sa mga tuntunin ng storage at performance.

Ito ay lalong kapaki-pakinabang para sa mga query na nagbabasa ng mga partikular na column mula sa isang malawak na (maraming column) na talahanayan. Salamat sa format ng file, ang mga kinakailangang column lang ang binabasa, kaya pinananatiling minimum ang I/O.

Isang maliit na digression at paliwanag: Para mas maintindihan ang Parquet file format sa Hadoop, tingnan natin kung ano ang column-based - i.e. columnar - format. Ang format na ito ay nag-iimbak ng magkatulad na mga halaga para sa bawat column nang magkasama.

Halimbawa, kasama sa record ang mga field ng ID, Pangalan, at Departamento. Sa kasong ito, ang lahat ng mga halaga ng column ng ID ay maiimbak nang magkasama, pati na rin ang mga halaga ng column ng Pangalan, at iba pa. Ang talahanayan ay magiging ganito ang hitsura:

ID
Pangalan
kagawaran

1
emp1
d1

2
emp2
d2

3
emp3
d3

Sa string na format, ang data ay ise-save tulad ng sumusunod:

1
emp1
d1
2
emp2
d2
3
emp3
d3

Sa isang columnar file format, ang parehong data ay ise-save tulad nito:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Ang columnar na format ay mas mahusay kapag kailangan mong mag-query ng maraming column mula sa isang table. Babasahin lamang nito ang mga kinakailangang column dahil magkatabi ang mga ito. Sa ganitong paraan, ang mga operasyon ng I/O ay pinananatiling pinakamababa.

Halimbawa, kailangan mo lang ang column na NAME. SA format ng string Ang bawat tala sa dataset ay kailangang i-load, i-parse ayon sa field, at pagkatapos ay i-extract ang NAME data. Binibigyang-daan ka ng format ng column na direktang mag-drill down sa column na Pangalan dahil ang lahat ng value para sa column na iyon ay naka-store nang magkasama. Hindi mo kailangang i-scan ang buong pag-record.

Kaya, pinapabuti ng columnar format ang pagganap ng query dahil nangangailangan ito ng mas kaunting oras ng paghahanap upang makarating sa mga kinakailangang column at binabawasan ang bilang ng mga operasyon ng I/O dahil ang mga gustong column lang ang nababasa.

Isa sa mga natatanging katangian kahoy na sahig ay na sa format na ito maaari mag-imbak ng data na may mga nested na istruktura. Nangangahulugan ito na sa isang Parquet file, kahit na ang mga nested field ay maaaring basahin nang isa-isa nang hindi kinakailangang basahin ang lahat ng mga field sa nested na istraktura. Gumagamit ang parquet ng shredding at assembly algorithm para mag-imbak ng mga nested structure.

Upang maunawaan ang format ng Parquet file sa Hadoop, kailangan mong malaman ang mga sumusunod na termino:

1. Grupo ng mga string (pangkat ng hilera): lohikal na pahalang na paghahati ng data sa mga hilera. Ang isang row group ay binubuo ng isang fragment ng bawat column sa set ng data.
2. fragment ng column (column chunk): Isang fragment ng isang partikular na column. Ang mga fragment ng column na ito ay nakatira sa isang partikular na pangkat ng mga row at ginagarantiyahan na magkadikit sa file.
3. Pahina (pahina): Ang mga fragment ng column ay nahahati sa mga pahinang nakasulat nang sunud-sunod. Ang mga pahina ay may karaniwang pamagat, kaya maaari mong laktawan ang mga hindi kailangan kapag nagbabasa.

Dito ang pamagat ay naglalaman lamang ng magic number PAR1 (4 bytes) na nagpapakilala sa file bilang Parquet file.

Sinasabi ng footer ang sumusunod:

1. Metadata ng file na naglalaman ng mga panimulang coordinate ng metadata ng bawat column. Kapag nagbabasa, kailangan mo munang basahin ang metadata ng file upang mahanap ang lahat ng mga fragment ng column ng interes. Ang mga bahagi ng column ay dapat basahin nang sunud-sunod. Kasama sa iba pang metadata ang bersyon ng format, schema, at anumang karagdagang mga pares ng key-value.
2. Haba ng metadata (4 bytes).
3. magic number PAR1 (4 bytes).

Format ng ORC File

Na-optimize na format ng file ng row-column (Na-optimize na Hanay ng Hilera, ORC) ay nag-aalok ng napakahusay na paraan upang mag-imbak ng data at idinisenyo upang malampasan ang mga limitasyon ng iba pang mga format. Nag-iimbak ng data sa isang perpektong siksik na anyo, na nagbibigay-daan sa iyong laktawan ang mga hindi kinakailangang detalye - nang hindi nangangailangan ng pagbuo ng malaki, kumplikado o manu-manong pinapanatili na mga index.

Mga kalamangan ng ORC format:

1. Ang isang file ay ang output ng bawat gawain, na binabawasan ang pagkarga sa NameNode (name node).
2. Suporta para sa mga uri ng data ng Hive, kabilang ang DateTime, decimal at kumplikadong mga uri ng data (struct, list, mapa at unyon).
3. Sabay-sabay na pagbabasa ng parehong file ng iba't ibang proseso ng RecordReader.
4. Kakayahang hatiin ang mga file nang walang pag-scan para sa mga marker.
5. Pagtatantya ng maximum na posibleng heap memory allocation para sa read/write na mga proseso batay sa impormasyon sa file footer.
6. Ang metadata ay naka-imbak sa Protocol Buffers binary serialization format, na nagbibigay-daan sa mga field na idagdag at alisin.

Ang ORC ay nag-iimbak ng mga koleksyon ng mga string sa isang file, at sa loob ng koleksyon, ang data ng string ay iniimbak sa isang columnar na format.

Ang isang ORC file ay nag-iimbak ng mga grupo ng mga linya na tinatawag na mga guhit at sumusuportang impormasyon sa footer ng file. Ang Postscript sa dulo ng file ay naglalaman ng mga parameter ng compression at ang laki ng naka-compress na footer.

Ang default na laki ng stripe ay 250 MB. Dahil sa gayong malalaking guhit, ang pagbabasa mula sa HDFS ay ginagawa nang mas mahusay: sa malalaking magkadikit na mga bloke.

Itinatala ng footer ng file ang listahan ng mga lane sa file, ang bilang ng mga row sa bawat lane, at ang uri ng data ng bawat column. Ang resultang halaga ng count, min, max at sum para sa bawat column ay nakasulat din doon.

Ang footer ng strip ay naglalaman ng isang direktoryo ng mga lokasyon ng stream.

Ginagamit ang row data kapag nag-scan ng mga talahanayan.

Kasama sa data ng index ang minimum at maximum na mga halaga para sa bawat column at ang posisyon ng mga row sa bawat column. Ang mga ORC index ay ginagamit lamang para sa pagpili ng mga stripes at row group, hindi para sa pagsagot sa mga query.

Paghahambing ng iba't ibang mga format ng file

Avro kumpara sa Parquet

1. Ang Avro ay isang row storage format, habang ang Parquet ay nag-iimbak ng data sa mga column.
2. Ang parquet ay mas angkop para sa mga analytical na query, ibig sabihin, ang mga read operation at querying data ay mas mahusay kaysa sa pagsusulat.
3. Ang mga operasyon sa pagsulat sa Avro ay ginagawa nang mas mahusay kaysa sa Parquet.
4. Ang Avro ay tumatalakay sa circuit evolution nang mas mature. Sinusuportahan lamang ng parquet ang pagdaragdag ng schema, habang sinusuportahan ng Avro ang multifunctional evolution, iyon ay, pagdaragdag o pagpapalit ng mga column.
5. Perpekto ang parquet para sa pag-query ng subset ng mga column sa isang multi-column table. Angkop ang Avro para sa mga pagpapatakbo ng ETL kung saan tinatanong namin ang lahat ng column.

ORC vs Parquet

1. Ang parquet ay nag-iimbak ng nested data nang mas mahusay.
2. Ang ORC ay mas angkop sa predicate pushdown.
3. Sinusuportahan ng ORC ang mga katangian ng ACID.
4. Ang ORC ay nag-compress ng data nang mas mahusay.

Ano pa ang mababasa sa paksa:

1. Big data analysis sa cloud: kung paano magiging data-oriented ang isang kumpanya.
2. Isang Mapagpakumbaba na Gabay sa Mga Schema ng Database.
3. Ang aming telegram channel tungkol sa digital transformation.

Pinagmulan: www.habr.com