RCFile

Format de stockage de données

Par exemple, une table dans une base de données est composée de 4 colonnes (c1 à c4):

Pour sérialiser la table, RCFile partitionne cette table d’abord horizontalement, puis verticalement, au lieu de la partitionner horizontalement comme le SGBD orienté ligne. Le partitionnement horizontal partitionnera d'abord la table en plusieurs groupes de lignes en fonction de la taille du groupe de lignes, qui est une valeur spécifiée par l'utilisateur. Par exemple,si l'utilisateur spécifie 3 ,  la table ci-dessus peut être partitionnée en deux groupes de lignes 

Ensuite, dans chaque groupe de lignes, RCFile partitionne les données verticalement comme un magasin de colonnes. Ainsi, la table sera sérialisée comme:

 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; 

Compression de données de colonne

Dans chaque groupe de lignes, les colonnes sont compressées afin de réduire l'utilisation de l'espace de stockage. Comme les données d'une colonne sont stockées côte à côte, le modèle d'une colonne peut être détecté et ainsi l'algorithme de compression approprié peut être sélectionné pour un taux de compression élevé.

Avantages de performance

Le magasin de colonnes est plus efficace lorsqu'une requête nécessite uniquement un sous-ensemble de colonnes, car le magasin de colonnes ne lit que les colonnes nécessaires des disques, mais le magasin de lignes lit une ligne entière.

RCFile combine les avantages du magasin de lignes et du magasin de colonnes via un partitionnement horizontal-vertical. Avec le partitionnement horizontal, RCFile place toutes les colonnes d'une ligne sur une seule machine et peut ainsi éliminer les coûts réseau supplémentaires liés à la construction d'une ligne. Avec le partitionnement vertical, pour une requête, RCFile ne lira que les colonnes nécessaires des disques et pourra ainsi éliminer les coûts d'E / S locaux inutiles. De plus, dans chaque groupe de lignes, la compression des données peut être effectuée à l'aide d'algorithmes de compression utilisés dans le magasin de colonnes .

Par exemple, une base de données pourrait avoir cette table:

Cette table simple comprend un identifiant d'employé (EmpId), des champs de nom (Nom et Prénom) et un salaire (Salaire). Ce format bidimensionnel n'existe qu'en théorie. En pratique, le matériel de stockage exige que les données soient sérialisées sous une forme ou une autre.

Dans les systèmes basés sur MapReduce, les données sont normalement stockées sur un système distribué, tel que HDFS, et différents blocs de données peuvent être stockés sur différentes machines. Ainsi, pour le magasin de colonnes sur MapReduce, différents groupes de colonnes peuvent être stockés sur différentes machines, ce qui entraîne des coûts de réseau supplémentaires lorsqu'une requête projette des colonnes placées sur différentes machines. Pour les systèmes basés sur MapReduce, l'avantage du stockage en ligne est qu'il n'y a pas de coûts réseau supplémentaires pour construire une ligne dans le traitement des requêtes, et l'avantage du stockage orienté colonnes est qu'il n'y a pas de coûts E/S locaux inutiles pour la lecture des données sur disques. .

Systèmes orientés ligne

La solution courante au problème de stockage consiste à sérialiser chaque ligne de données, comme ceci;

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

Les stockages orienté lignes sont conçus pour renvoyer efficacement les données de toute une ligne ou de tout un enregistrement en un minimum d'opérations. Cela correspond aux cas d'utilisation où le système tente de récupérer toutes les informations sur un objet particulier, par exemple les informations complètes sur un contact dans un système rolodex ou les informations complètes sur un produit dans un système d'achat en ligne.

Les stockages orienté lignes ne sont pas efficaces pour effectuer des opérations qui s'appliquent à l'ensemble de données, par opposition à un enregistrement spécifique. Par exemple, pour rechercher tous les enregistrements de la table exemple dont les salaires sont compris entre 40 000 et 50 000, le système basé sur les lignes doit rechercher dans l'ensemble du jeu de données la recherche d'enregistrements correspondants. Bien que l'exemple de table présenté ci-dessus puisse s'intégrer dans un seul bloc de disque, une table comportant quelques centaines de lignes ne le serait pas. Par conséquent, plusieurs opérations sur disque seraient nécessaires pour récupérer les données.

Systèmes orienté colonnes

Un système orienté colonne sérialise toutes les valeurs d'une colonne, puis les valeurs de la colonne suivante. Pour notre exemple de table, les données seraient stockées de cette manière;

 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; 

La différence se voit plus clairement dans cette modification commune:

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

Deux des enregistrements stockent la même valeur, "Jones". Il est donc désormais possible de la stocker dans le système orienté colonne une seule fois au lieu de deux fois. Pour de nombreuses recherches courantes, comme "trouver toutes les personnes portant le nom de famille Jones", la réponse peut désormais être extraite en une seule opération.

Le fonctionnement plus efficace d’un système à colonnes dépend largement des opérations automatisées. Les opérations qui récupèrent des données pour des objets seraient plus lentes, nécessitant de nombreuses opérations sur disque pour assembler des données de différentes colonnes afin de créer un enregistrement de ligne entière. Cependant, de telles opérations sur toute la ligne sont généralement rares. Dans la majorité des cas, seul un sous-ensemble limité de données est récupéré. Dans une application rolodex, par exemple, les opérations collectant les prénoms et les noms de famille de nombreuses lignes afin de créer une liste de contacts sont beaucoup plus courantes que les opérations lisant les données pour l'adresse de domicile.

RCFile a été adopté dans des systèmes du monde réel pour l'analyse de données volumineuses.

1. RCFile est devenu la structure de placement de données par défaut dans le cluster Hadoop de production de Facebook^[2]. En 2010, il s'agissait du plus grand cluster Hadoop au monde ^[3] lequel des ensembles de données compressées de 40 téraoctets étaient ajoutés chaque jour^[4]. En outre, tous les ensembles de données stockés dans HDFS avant RCFile ont également été transformés pour utiliser RCFile.
2. RCFile a été adopté dans Apache Hive (depuis la version 0.4) ^[5] un système de stockage de données open source fonctionnant sous Hadoop et largement utilisé dans diverses entreprises du monde entier ^[6] y compris plusieurs services Internet. tels que Facebook , Taobao et Netflix^[7].
3. RCFile a été adopté dans Apache Pig (depuis la v0.7) ^[8] un autre système de traitement de données en source ouvert largement utilisé dans de nombreuses organisations ^[9] y compris plusieurs grands fournisseurs de services Web, tels que Twitter , Yahoo , Linkedin , AOL et Salesforce.com .
4. RCFile est devenu la structure de stockage de données standard de facto dans l’environnement logiciel Hadoop pris en charge par le projet HCatalog (anciennement appelé Howl ), qui est le service de gestion de tables et de stockage de Hadoop^[10]. RCFile est pris en charge par la bibliothèque open source Elephant Bird utilisée dans Twitter pour l’analyse quotidienne des données^[11].

Au cours des années suivantes, d'autres formats de données Hadoop sont également devenus populaires. En février 2013, un format de fichier ORC (Optimized Row Columnar) a été annoncé par Hortonworks^[12]. Un mois plus tard, le format Apache Parquet était annoncé, développé par Cloudera et Twitter^[13].

• Colonne (magasin de données)
• SGBD orienté colonne
• MapReduce
• Apache Hadoop
• Apache Hive
• Big Data
• Apache ORC