Plik RC

W systemach zarządzania bazami danych RCFile ( plik kolumnowy rekordu) to struktura rozmieszczenia danych, która określa sposób przechowywania tabel relacyjnych w klastrach komputerów . Jest przeznaczony dla systemów korzystających z MapReduce struktura. Struktura RCFile obejmuje format przechowywania danych, podejście do kompresji danych i techniki optymalizacji odczytu danych. Jest w stanie spełnić wszystkie cztery wymagania dotyczące umieszczania danych: (1) szybkie ładowanie danych, (2) szybkie przetwarzanie zapytań, (3) wysoce efektywne wykorzystanie przestrzeni dyskowej oraz (4) silna adaptacja do dynamicznych wzorców dostępu do danych.

RCFile jest wynikiem badań i wspólnych wysiłków Facebooka , Uniwersytetu Stanowego Ohio i Instytutu Technologii Obliczeniowych Chińskiej Akademii Nauk .

Streszczenie

Format przechowywania danych

Na przykład tabela w bazie danych składa się z 4 kolumn (od c1 do 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

Aby serializować tabelę, RCFile dzieli tę tabelę najpierw w poziomie, a następnie w pionie, zamiast tylko partycjonować tabelę w poziomie, jak w zorientowanym na wiersze systemie DBMS (magazyn wierszy). Partycjonowanie poziome najpierw podzieli tabelę na wiele grup wierszy na podstawie grupy wierszy , czyli wartości określonej przez użytkownika, określającej rozmiar każdej grupy wierszy. Na przykład powyższą tabelę można podzielić na dwie grupy wierszy, jeśli użytkownik określi trzy wiersze jako rozmiar każdej grupy wierszy.

Grupa wierszy 1
c1	c2	c3	c4
11	12	13	14
21	22	23	24
31	32	33	34

Grupa wierszy 2
c1	c2	c3	c4
41	42	43	44
51	52	53	54

Następnie w każdej grupie wierszy RCFile dzieli dane pionowo, podobnie jak magazyn kolumn. Zatem tabela zostanie serializowana jako:

Grupa wierszy 1 Grupa wierszy 2 11, 21, 31; 41, 51; 12, 22, 32; 42, 52; 13, 23, 33; 43, 53; 14, 24, 34; 44, 54;

Kompresja danych kolumnowych

W każdej grupie wierszy kolumny są kompresowane, aby zmniejszyć wykorzystanie miejsca w pamięci. Ponieważ dane kolumny są przechowywane obok siebie, można wykryć wzór kolumny i w ten sposób wybrać odpowiedni algorytm kompresji w celu uzyskania wysokiego współczynnika kompresji.

Korzyści w zakresie wydajności

Magazyn kolumn jest bardziej wydajny, gdy zapytanie wymaga tylko podzbioru kolumn, ponieważ magazyn kolumn odczytuje tylko niezbędne kolumny z dysków, ale magazyn wierszy odczyta cały wiersz.

RCFile łączy zalety magazynu wierszowego i magazynu kolumnowego poprzez partycjonowanie poziome i pionowe. Dzięki partycjonowaniu poziomemu RCFile umieszcza wszystkie kolumny wiersza na jednej maszynie, co pozwala wyeliminować dodatkowe koszty sieciowe podczas konstruowania wiersza. Dzięki partycjonowaniu pionowemu w przypadku zapytania RCFile odczyta tylko niezbędne kolumny z dysków, co może wyeliminować niepotrzebne lokalne koszty we/wy. Co więcej, w każdej grupie wierszy można dokonać kompresji danych za pomocą algorytmów kompresji używanych w kolumnie-store .

Na przykład baza danych może mieć następującą tabelę:

EmId	Nazwisko	Imię	Wynagrodzenie
10	Kowal	Joe	40000
12	Jonesa	Maryja	50000
11	Johnsona	Cathy	44000
22	Jonesa	Pion	55000

Ta prosta tabela zawiera identyfikator pracownika (EmpId), pola imienia (Nazwisko i Imię) oraz wynagrodzenie (Wynagrodzenie). Ten dwuwymiarowy format istnieje tylko w teorii, w praktyce sprzęt pamięci masowej wymaga serializacji danych w takiej czy innej formie.

W systemach opartych na MapReduce dane są zwykle przechowywane w systemie rozproszonym, takim jak rozproszony system plików Hadoop (HDFS) , a różne bloki danych mogą być przechowywane na różnych komputerach. Zatem w przypadku magazynu kolumn w MapReduce różne grupy kolumn mogą być przechowywane na różnych komputerach, co powoduje dodatkowe koszty sieciowe, gdy zapytanie projektuje kolumny umieszczone na różnych komputerach. W przypadku systemów opartych na MapReduce zaletą magazynu wierszy jest to, że nie ma dodatkowych kosztów sieciowych na utworzenie wiersza w przetwarzaniu zapytań, a zaletą magazynu kolumn jest to, że nie ma niepotrzebnych lokalnych kosztów we/wy podczas odczytywania danych z dyski.

Systemy zorientowane rzędowo

Typowym rozwiązaniem problemu z pamięcią masową jest serializacja każdego wiersza danych w następujący sposób:

001:10,Smith,Joe,40000;002:12,Jones,Mary,50000;003:11,Johnson,Cathy,44000;004:22,Jones,Bob,55000;

Systemy oparte na wierszach zaprojektowano tak, aby efektywnie zwracały dane dotyczące całego wiersza lub całego rekordu w jak najmniejszej liczbie operacji. Pasuje to do przypadków użycia, w których system próbuje uzyskać wszystkie informacje o konkretnym obiekcie, powiedzmy pełne informacje o jednym kontakcie w systemie rolodex lub pełne informacje o jednym produkcie w systemie zakupów online.

Systemy oparte na wierszach nie są wydajne w wykonywaniu operacji, które dotyczą całego zbioru danych, a nie konkretnego rekordu. Na przykład, aby znaleźć w przykładowej tabeli wszystkie rekordy, w których pensje mieszczą się w przedziale od 40 000 do 50 000, system wierszowy musiałby przeszukać cały zbiór danych w poszukiwaniu pasujących rekordów. Chociaż przykładowa tabela pokazana powyżej może zmieścić się w pojedynczym bloku dysku, tabela zawierająca nawet kilkaset wierszy nie zmieściłaby się, dlatego do pobrania danych konieczne byłoby wykonanie wielu operacji na dysku.

Systemy kolumnowe

System zorientowany kolumnowo serializuje razem wszystkie wartości kolumny, a następnie wartości następnej kolumny. W naszej przykładowej tabeli dane będą przechowywane w ten sposób;

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;

Różnicę widać wyraźniej w tej powszechnej modyfikacji:

...;Smith:001,Jones:002,004,Johnson:003;...

Dwa z rekordów przechowują tę samą wartość „Jones”, dlatego teraz można ją zapisać w systemie kolumnowym tylko raz, a nie dwa razy. W przypadku wielu typowych wyszukiwań, takich jak „znajdź wszystkie osoby o nazwisku Jones”, odpowiedź można teraz znaleźć w jednej operacji.

To, czy system zorientowany kolumnowo będzie bardziej wydajny w działaniu, zależy w dużej mierze od automatyzacji operacji. Operacje pobierania danych dla obiektów byłyby wolniejsze i wymagałyby wielu operacji dyskowych w celu złożenia danych z różnych kolumn w celu utworzenia rekordu obejmującego cały wiersz. Jednak takie operacje na całym rzędzie są na ogół rzadkie. W większości przypadków pobierany jest tylko ograniczony podzbiór danych. Przykładowo w aplikacji rolodex operacje polegające na zbieraniu imion i nazwisk z wielu wierszy w celu zbudowania listy kontaktów są znacznie częstsze niż operacje polegające na odczytywaniu danych o adresie domowym.

Przyjęcie

RCFile został zastosowany w rzeczywistych systemach do analizy dużych zbiorów danych.

RCFile stał się domyślną strukturą rozmieszczania danych w produkcyjnym klastrze Hadoop Facebooka. Do 2010 roku był to największy na świecie klaster Hadoop, do którego codziennie dodawane były zestawy skompresowanych danych o wielkości 40 terabajtów. Ponadto wszystkie zestawy danych przechowywane w HDFS przed RCFile również zostały przekształcone w celu użycia RCFile .
RCFile został zaadaptowany w Apache Hive (od wersji 0.4), który jest systemem przechowywania danych typu open source działającym na platformie Hadoop i jest szeroko stosowany w różnych firmach na całym świecie, w tym w kilku usługach internetowych, takich jak Facebook , Taobao , i Netflixa .
RCFile został zastosowany w Apache Pig (od wersji 0.7), który jest kolejnym systemem przetwarzania danych typu open source szeroko stosowanym w wielu organizacjach, w tym u kilku głównych dostawców usług internetowych, takich jak Twitter , Yahoo , LinkedIn , AOL i Salesforce.com .
RCFile stał się de facto standardową strukturą przechowywania danych w środowisku oprogramowania Hadoop wspieraną przez projekt Apache HCatalog (wcześniej znany jako Howl), czyli usługę zarządzania tabelami i pamięcią masową dla Hadoopa. RCFile jest obsługiwany przez bibliotekę Elephant Bird typu open source używaną na Twitterze do codziennej analizy danych.

W kolejnych latach popularne stały się także inne formaty danych Hadoop. W lutym 2013 r. firma Hortonworks ogłosiła format pliku Optimized Row Columnar (ORC) . Miesiąc później zapowiedziano format Apache Parquet , opracowany przez Cloudera i Twittera .

Zobacz też

Linki zewnętrzne