RCFile (Record Columnar File) er en datastruktur som bestemmer hvordan relasjonstabeller skal lagres på dataklynger . Den er designet for systemer som bruker MapReduce- rammeverket . RCFile-strukturen inkluderer et datalagringsformat, en datakomprimeringsmetode og optimaliseringsteknikker for lesing av data. Den er i stand til å oppfylle de fire kravene til dataplassering: (1) rask datainnlasting, (2) rask spørringsbehandling, (3) svært effektiv bruk av lagringsplass, og (4) sterk tilpasningsevne til modeller for datatilgangsdynamikk.
RCFile er resultatet av forskning og samarbeid fra Facebook , Ohio State University og Institute of Computing Technology ved Chinese Academy of Sciences . En forskningsartikkel om RCFile ble utgitt i 2011. Dataplasseringsstrukturen og implementeringen av den presentert i artikkelen er blitt adoptert av åpen kildekode, store datapublisister og applikasjonsbrukere.
For eksempel består en tabell i en database av fire kolonner (c1 til c4):
| c1 | c2 | c3 | c4 |
|---|---|---|---|
| 11 | 12 | 1. 3 | 14 |
| 21 | 22 | 23 | 24 |
| 31 | 32 | 33 | 34 |
| 41 | 42 | 43 | 44 |
| 51 | 52 | 53 | 54 |
For å serieisere tabellen partisjonerer RCFile denne tabellen først horisontalt, deretter vertikalt, i stedet for å dele den horisontalt som radorientert DBMS. Horisontal partisjonering vil først partisjonere tabellen i flere radgrupper basert på størrelsen på radgruppen, som er en brukerdefinert verdi. For eksempel, hvis brukeren spesifiserer 3, kan tabellen ovenfor deles i to grupper av rader
| c1 | c2 | c3 | c4 |
|---|---|---|---|
| 11 | 12 | 1. 3 | 14 |
| 21 | 22 | 23 | 24 |
| 31 | 32 | 33 | 34 |
| c1 | c2 | c3 | c4 |
|---|---|---|---|
| 41 | 42 | 43 | 44 |
| 51 | 52 | 53 | 54 |
I hver radgruppe partisjonerer RCFile dataene vertikalt som en kolonnelager. Så tabellen blir seriell som:
Groupe de colonne 1 Groupe de clo 2 11, 21, 31; 41, 51; 12, 22, 32; 42, 52; 13, 23, 33; 43, 53; 14, 24, 34; 44, 54;I hver radgruppe komprimeres kolonnene for å redusere bruken av lagringsplass. Ettersom dataene til en kolonne er lagret side om side, kan mønsteret til en kolonne oppdages, og dermed kan den passende kompresjonsalgoritmen velges for et høyt kompresjonsforhold.
Kolonnelageret er mest effektivt når et spørsmål bare krever et delsett av kolonner, fordi kolonnelageret bare leser de nødvendige kolonnene fra disker, men radlageret leser en hel rad.
RCFile kombinerer fordelene med radlager og kolonnelager gjennom horisontal-vertikal partisjonering. Med horisontal partisjonering plasserer RCFile alle kolonnene i en rad på en enkelt maskin og kan dermed eliminere de ekstra nettverkskostnadene knyttet til å bygge en rad. Med vertikal partisjonering, for et spørsmål, vil RCFile bare lese de nødvendige kolonnene fra diskene og dermed være i stand til å eliminere unødvendige lokale I / O-kostnader. I tillegg, i hver radgruppe, kan datakomprimering utføres ved hjelp av komprimeringsalgoritmer som brukes i kolonnelageret .
For eksempel kan en database ha denne tabellen:
| EmpId | Etternavn | Fornavn | lønn |
|---|---|---|---|
| 10 | Smith | Joe | 40.000 |
| 12 | Jones | Gift | 50.000 |
| 11 | Johnson | Cathy | 44000 |
| 22 | Jones | Bob | 55000 |
Denne enkle tabellen inkluderer en ansattidentifikator (EmpId), navnefelt (Etternavn og fornavn) og en lønn (Lønn). Dette todimensjonale formatet eksisterer bare i teorien. I praksis krever lagringsmaskinvare at dataene serialiseres i en eller annen form.
I MapReduce-baserte systemer lagres data normalt på et distribuert system, for eksempel HDFS , og forskjellige datablokker kan lagres på forskjellige maskiner. Så for kolonnelageret på MapReduce kan forskjellige kolonnegrupper lagres på forskjellige maskiner, noe som resulterer i ekstra nettverkskostnader når et spørsmål projiserer kolonner plassert på forskjellige maskiner. For systemer basert på MapReduce er fordelen med online lagring at det er ingen ekstra nettverkskostnader for å bygge en rad i behandlingen av forespørsler, og fordelen med kolonneorientert lagring er at det ikke er noen I / O-kostnader unødvendig plass for å lese data fra plater. .
Den vanlige løsningen på lagringsproblemet er å serieisere hver rad med data, slik som denne;
001: 10, Smith, Joe, 40000; 002: 12, Jones, Mary, 50000; 003: 11, Johnson, Cathy, 44000; 004: 22, Jones, Bob, 55000;Radorienterte lagre er designet for effektivt å returnere data for en hel rad eller registrere med minimale operasjoner. Dette tilsvarer brukstilfeller der systemet prøver å hente all informasjon om et bestemt objekt, for eksempel fullstendig kontaktinformasjon i et rolodex- system eller fullstendig produktinformasjon i et online shoppingsystem.
Radorienterte lagre er ikke effektive for å utføre operasjoner som gjelder datasettet, i motsetning til en bestemt post. For eksempel, for å finne alle poster i eksempeltabellen med lønn mellom 40 000 og 50 000, må det radbaserte systemet søke i hele datasettet for samsvarende poster. Selv om prøvetabellen vist ovenfor kan passe inn i en enkelt diskblokk, ville en tabell med noen hundre rader ikke. Derfor vil det være nødvendig med flere diskoperasjoner for å gjenopprette dataene.
Et kolonneorientert system serialiserer alle verdiene i en kolonne og deretter verdiene i neste kolonne. For eksempelet vårt, vil dataene bli lagret på denne måten;
10: 001,12: 002,11: 003,22: 004; Smith: 001, Jones: 002, Johnson: 003, Jones: 004; Joe: 001, Mary: 002, Cathy: 003, Bob: 004 et 40000: 001,50000: 002,44000: 003,55000: 004;Forskjellen kan sees tydeligere i denne vanlige modifikasjonen:
…; Smith: 001, Jones: 002 004, Johnson: 003;…To av platene lagrer samme verdi, "Jones". Det er derfor nå mulig å lagre det i det kolonneorienterte systemet bare en gang i stedet for to ganger. For mange vanlige søk, for eksempel "finn alle med etternavnet Jones", kan svaret nå hentes på en gang.
Den mer effektive driften av et kolonnesystem avhenger i stor grad av automatiserte operasjoner. Operasjoner som henter data for objekter, vil være tregere, og krever mange diskoperasjoner for å samle data fra forskjellige kolonner for å opprette en hel radoppføring. Imidlertid er slike operasjoner langs linjen generelt sjeldne. I de fleste tilfeller gjenopprettes bare en begrenset delmengde av data. I et rolodex-program er for eksempel operasjoner som samler for- og etternavn fra mange linjer for å opprette en kontaktliste mye mer vanlig enn operasjoner som leser data for hjemmeadressen.
RCFile er adoptert i virkelige systemer for stor dataanalyse.
I løpet av de følgende årene ble også andre Hadoop-dataformater populære. IFebruar 2013, ble et format fra Optimized Row Columnar (ORC) annonsert av Hortonworks . En måned senere ble Apache Parquet- formatet kunngjort, utviklet av Cloudera og Twitter .