RCFile - RCFile
RCFile (Record Kolumn File) är en data placering struktur som avgör hur man lagrar relationstabeller på datorkluster . Den är utformad för system som använder MapReduce- ramverket. RCFile-strukturen inkluderar ett datalagringsformat, datakomprimeringsmetod och optimeringstekniker för dataläsning. Den kan uppfylla alla de fyra kraven för dataplacering: (1) snabb datainladdning, (2) snabb frågebehandling, (3) mycket effektivt lagringsutnyttjande och (4) en stark anpassning till dynamiska datatillgångsmönster.
RCFile är resultatet av forskning och samarbete från Facebook , Ohio State University och Institute of Computing Technology vid Chinese Academy of Sciences .
Sammanfattning
Datalagringsformat
Till exempel består en tabell i en databas av fyra kolumner (c1 till c4):
| c1 | c2 | c3 | c4 |
|---|---|---|---|
| 11 | 12 | 13 | 14 |
| 21 | 22 | 23 | 24 |
| 31 | 32 | 33 | 34 |
| 41 | 42 | 43 | 44 |
| 51 | 52 | 53 | 54 |
För att serieera tabellen partitionerar RCFile denna tabell först horisontellt och sedan vertikalt, istället för att bara partitionera tabellen horisontellt som den radorienterade DBMS (rad-butik). Den horisontella partitioneringen delar först upp tabellen i flera radgrupper baserat på radgruppens storlek, vilket är ett användardefinierat värde som bestämmer storleken på varje radgrupp. Tabellen ovan kan till exempel delas upp i två radgrupper om användaren anger tre rader som storleken på varje radgrupp.
| c1 | c2 | c3 | c4 |
|---|---|---|---|
| 11 | 12 | 13 | 14 |
| 21 | 22 | 23 | 24 |
| 31 | 32 | 33 | 34 |
| c1 | c2 | c3 | c4 |
|---|---|---|---|
| 41 | 42 | 43 | 44 |
| 51 | 52 | 53 | 54 |
I varje radgrupp partitionerar RCFile sedan data vertikalt som kolumnlager. Således kommer tabellen att serienummeras som:
Row Group 1 Row Group 2
11, 21, 31; 41, 51;
12, 22, 32; 42, 52;
13, 23, 33; 43, 53;
14, 24, 34; 44, 54;
Kolumndatakomprimering
Inom varje radgrupp komprimeras kolumner för att minska lagringsutrymmet. Eftersom data från en kolumn lagras intill varandra kan mönstret för en kolumn detekteras och sålunda kan den lämpliga kompressionsalgoritmen väljas för ett högt kompressionsförhållande.
Prestationsfördelar
Column-store är effektivare när en fråga bara kräver en delmängd av kolumner, eftersom column-store bara läser nödvändiga kolumner från diskar men rad-store läser en hel rad.
RCFile kombinerar fördelar med rad-butik och kolumn-butik via horisontell-vertikal partitionering. Med horisontell partitionering placerar RCFile alla kolumner i en rad i en enda maskin och kan därmed eliminera de extra nätverkskostnaderna när du konstruerar en rad. Med vertikal partitionering, för en fråga, läser RCFile bara nödvändiga kolumner från diskar och kan därmed eliminera onödiga lokala I / O-kostnader. Dessutom, i varje radgrupp, kan datakomprimering göras med komprimeringsalgoritmer som används i kolumnlager .
Till exempel kan en databas ha den här tabellen:
| EmpId | Efternamn | Förnamn | Lön |
|---|---|---|---|
| 10 | Smed | Joe | 40000 |
| 12 | Jones | Mary | 50000 |
| 11 | Johnson | Cathy | 44000 |
| 22 | Jones | Guppa | 55000 |
Denna enkla tabell innehåller en anställd-identifierare (EmpId), namnfält (Efternamn och Förnamn) och en lön (Lön). Detta tvådimensionella format existerar endast i teorin, i praktiken kräver lagringsmaskinvara att data serieras till en eller annan form.
I MapReduce-baserade system lagras data normalt på ett distribuerat system, såsom Hadoop Distributed File System (HDFS) , och olika datablock kan lagras på olika datorer. Således, för kolumnlagring på MapReduce, kan olika grupper av kolumner lagras på olika maskiner, vilket medför extra nätverkskostnader när en fråga projicerar kolumner placerade på olika maskiner. För MapReduce-baserade system är fördelen med rad-butik att det inte finns några extra nätverkskostnader för att konstruera en rad i fråga-bearbetning, och fördelen med kolumn-butik är att det inte finns några onödiga lokala I / O-kostnader när man läser data från skivor.
Radorienterade system
Den vanliga lösningen på lagringsproblemet är att serieera varje rad data, så här;
001:10,Smith,Joe,40000;002:12,Jones,Mary,50000;003:11,Johnson,Cathy,44000;004:22,Jones,Bob,55000;
Radbaserade system är utformade för att effektivt returnera data för en hel rad, eller en hel post, i så få operationer som möjligt. Detta matchar användningsfall där systemet försöker hämta all information om ett visst objekt, säg den fullständiga informationen om en kontakt i ett rolodexsystem eller den fullständiga informationen om en produkt i ett online-shoppingsystem.
Radbaserade system är inte effektiva för att utföra operationer som gäller för hela datamängden, i motsats till en specifik post. För att till exempel hitta alla poster i exempeltabellen som har löner mellan 40 000 och 50 000, måste det radbaserade systemet söka igenom hela datamängden och leta efter matchande poster. Även om exempeltabellen som visas ovan kan passa i ett enda diskblock, skulle en tabell med till och med några hundra rader inte göra det, därför skulle flera diskoperationer behövas för att hämta data.
Kolumnorienterade system
Ett kolumnorienterat system serierar alla värdena i en kolumn tillsammans och sedan värdena i nästa kolumn. För vårt exempel tabell skulle data lagras på detta sätt;
10:001,12:002,11:003,22:004;Smith:001,Jones:002,Johnson:003,Jones:004;Joe:001,Mary:002,Cathy:003,Bob:004;40000:001,50000:002,44000:003,55000:004;
Skillnaden kan tydligare ses i den här vanliga modifieringen:
...;Smith:001,Jones:002,004,Johnson:003;...
Två av posterna lagrar samma värde, "Jones", därför är det nu möjligt att lagra detta i det kolumnorienterade systemet bara en gång istället för två gånger. För många vanliga sökningar, som "hitta alla personer med efternamnet Jones", kan svaret nu hämtas i en enda operation.
Huruvida ett kolumnorienterat system kommer att vara effektivare i drift beror i hög grad på att de automatiseras. Åtgärder som hämtar data för objekt skulle vara långsammare, vilket kräver många diskoperationer för att samla data från olika kolumner för att bygga upp en helradspost. Sådana helradoperationer är dock i allmänhet sällsynta. I de flesta fall hämtas endast en begränsad delmängd av data. I en rolodex-applikation är till exempel operationer som samlar förnamn och efternamn från många rader för att skapa en kontaktlista mycket vanligare än operationer som läser data för hemadress.
Adoption
RCFile har antagits i verkliga system för stora dataanalyser.
- RCFile blev standarddataplaceringsstrukturen i Facebook: s produktion Hadoop-kluster. År 2010 var det världens största Hadoop-kluster, där 40 terabytes komprimerade datamängder läggs till varje dag. Dessutom har alla datauppsättningar som lagrats i HDFS innan RCFile också omvandlats till att använda RCFile.
- RCFile har antagits i Apache Hive (sedan v0.4), som är ett datakällsystem med öppen källkod som körs ovanpå Hadoop och används i stor utsträckning i olika företag runt om i världen, inklusive flera internettjänster, som Facebook , Taobao , och Netflix .
- RCFile har antagits i Apache Pig (sedan v0.7), som är ett annat databehandlingssystem med öppen källkod som används i stor utsträckning i många organisationer, inklusive flera stora webbtjänstleverantörer, som Twitter , Yahoo , LinkedIn , AOL och Salesforce.com .
- RCFile blev de facto standard datalagringsstruktur i Hadoop-mjukvarumiljön som stöds av Apache HCatalog- projektet (tidigare känt som Howl) som är tabellen och lagringstjänsten för Hadoop. RCFile stöds av det öppna källkodsbiblioteket Elephant Bird som används i Twitter för daglig dataanalys.
Under de följande åren blev också andra Hadoop-dataformat populära. I februari 2013 tillkännagavs ett format för Optimized Row Columnar (ORC) av Hortonworks . En månad senare tillkännagavs Apache Parquet- formatet, utvecklat av Cloudera och Twitter .
