Quelle est la différence entre le partitionnement et la création de compartiments d'une table dans la Ruche ?

Je sais que les deux est effectuée sur une colonne dans la table, mais comment est-ce que chaque opération différents.

InformationsquelleAutor NishM | 2013-10-02
  1. 229

    Partitionnement de données est souvent utilisé pour la distribution de la charge à l'horizontale, ce qui a d'avantage de performances, et les aide dans l'organisation des données dans une logique de mode. Exemple: si nous avons affaire à un grand employee table et souvent exécuter des requêtes avec des WHERE clauses de restreindre les résultats à un pays particulier ou d'un département . Pour accélérer la réponse à la requête de table de la Ruche peut être PARTITIONED BY (country STRING, DEPT STRING). Le partitionnement des tables de change le fonctionnement de la Ruche de structures de stockage des données et de la Ruche va maintenant créer des sous-répertoires reflétant la structure de partitionnement comme

    .../employés/pays=ABC/DEPT=XYZ.

    Si les limites de la requête pour l'employé de country=ABC, il suffira de scanner le contenu d'un répertoire country=ABC. Cela peut améliorer considérablement les performances de la requête, mais seulement si le schéma de partitionnement reflète commune de filtrage. Partitionnement fonctionnalité est très utile dans la Ruche, cependant, une conception qui crée trop de partitions peuvent optimiser certaines requêtes, mais préjudiciables pour d'autres requêtes. L'autre inconvénient est d'avoir trop de partitions est le grand nombre de Hadoop fichiers et répertoires créés inutilement et les frais généraux de NameNode, car il doit garder toutes les métadonnées du système de fichiers dans la mémoire.

    Écopage est une autre technique de décomposition des ensembles de données dans des pièces plus faciles à gérer. Par exemple, supposons qu'une table à l'aide de date que le niveau supérieur de la partition et employee_id que le deuxième niveau de la partition conduit à de trop nombreuses petites partitions. Au lieu de cela, si nous seau à la table des employés et l'utilisation employee_id que l'écopage colonne, la valeur de cette colonne sera haché par un définis par l'utilisateur nombre dans des seaux. Les enregistrements avec le même employee_id seront toujours stockées dans le même seau. En supposant que le nombre de employee_id est beaucoup plus grande que le nombre de compartiments, chaque compartiment aura beaucoup de employee_id. Lors de la création de la table, vous pouvez spécifier comme CLUSTERED BY (employee_id) INTO XX BUCKETS; où XX est le nombre de compartiments . Écopage a plusieurs avantages. Le nombre de compartiments est fixé de sorte qu'il ne varient pas en fonction de données. Si les deux tables sont placées dans un compartiment par employee_id, la Ruche peut créer une logique d'échantillonnage. Écopage aussi le sida en faisant efficace la carte-côté se joint etc.

    • Grâce Navneet. Cependant, pouvez-vous préciser de quelle manière la création de compartiments qui se passe avec le partitionnement ? Supposons que si l'on précise 32 seaux dans le CLUSED PAR clause et l'instruction CREATE TABLE contient également le Partitionnement de la clause, comment les partitions et les seaux seront gérés ensemble ? N'nombre de partitions sera limité à 32 ? OU pour chaque partition, 32 seaux seront créés ? Est chaque seau un fichier HDFS ?
    • Un tableau de la ruche peut avoir à la fois le partitionnement et la création de compartiments. Basé sur votre partition de la clause , pour chaque partition de 32 seaux créé. Oui HDFS fichier.
    • La Partition est un dossier, un seau est un fichier.
    • Pour mémoire, cette réponse découle du texte de la Programmation de la Ruche (O'Reilly, 2012).
    • J'ai trouvé ce lien très utile. Il a de l'information qui va ajouter plus de valeur à cette réponse. linkedin.com/pulse/...
    • Peut-on la colonne de partitionnement ainsi placées dans un compartiment? créer la table emp (nom de la chaîne)divisée par(id int) regroupés par(id) en 4 seaux; Ce qui donne: ÉCHEC: SemanticException [Erreur 10002]: Invalid colonne de référence. Est-ce possible de le faire? Si oui, alors quelle est la bonne syntaxe?
    • Selon votre scénario, si employee_id sont plus de 1000, et je mentionne 256 seaux. Comment cela sera traité dans Bucketting? Il va jeter une erreur?

    InformationsquelleAutor Navneet Kumar
  2. 118

    Il y a quelques détails manquants dans les explications précédentes.
    Pour mieux comprendre comment le partitionnement et la création de compartiments fonctionne, vous devriez regarder la façon dont les données sont stockées dans la ruche.
    Disons que vous avez une table

    CREATE TABLE mytable ( 
         name string,
         city string,
         employee_id int ) 
PARTITIONED BY (year STRING, month STRING, day STRING) 
CLUSTERED BY (employee_id) INTO 256 BUCKETS

    puis ruche va stocker les données dans une hiérarchie de répertoire comme

    /user/hive/warehouse/mytable/y=2015/m=12/d=02

    Donc, vous devez être prudent lors du partitionnement, parce que si vous avez par exemple la partition par employee_id et que vous avez des millions de salariés, vous finirez par avoir des millions de répertoires dans votre système de fichiers.
    Le terme "cardinalité " désigne le nombre de valeur possible d'un champ peut avoir. Par exemple, si vous avez un champ pays, les pays dans le monde sont environ 300, de sorte que la cardinalité serait ~300. Pour un domaine comme 'timestamp_ms', qui change à chaque milliseconde, la cardinalité peut être des milliards. En général, lors du choix d'un terrain pour le partitionnement, il ne devrait pas avoir une grande cardinalité, parce que vous vous retrouverez avec beaucoup trop de répertoires dans votre système de fichiers.

    De Clustering aka écopage sur l'autre main, sera le résultat avec un nombre fixe de fichiers, puisque vous ne spécifiez le nombre de compartiments. Ce hive faire est de prendre le champ, de calculer une valeur de hachage et attribuer un enregistrement de ce seau.
    Mais qu'advient-il si vous utilisez disons 256 seaux et le terrain, vous êtes écopage sur a un faible cardinalité (par exemple, c'est un état AMÉRICAIN, donc peut être que de 50 valeurs différentes) ? Vous aurez 50 seaux de données, et 206 seaux avec pas de données.

    Quelqu'un a déjà parlé de la façon dont les partitions peuvent réduire considérablement la quantité de données que vous interrogez. Donc, dans mon exemple de tableau, si vous voulez interroger uniquement à partir d'une certaine date, le partitionnement par année/mois/jour va considérablement réduire la quantité de IO.
    Je pense que quelqu'un a également parlé de la façon dont la création de compartiments peuvent accélérer les jointures avec les autres tables qui ont exactement la même écopage, donc, dans mon exemple, si vous êtes à joindre deux tables de la même employee_id, la ruche peut faire la jointure seau par seau (encore mieux si ils sont déjà triés par employee_id car il va mergesort les pièces qui sont déjà triés, qui fonctionne en temps linéaire aka O(n) ).

    Ainsi, la création de compartiments fonctionne bien lorsque le terrain a une cardinalité élevée et que les données sont réparties de façon égale entre les seaux. Partitionnement fonctionne mieux lorsque la cardinalité de la segmentation du champ n'est pas trop élevé.

    Aussi, vous pouvez partition sur plusieurs champs, avec un ordre (année/mois/jour est un bon exemple), tandis que vous pouvez seau sur un seul champ.

    • Pouvez-vous nous expliquer le CLUSTER PAR le comportement avec TRIÉS PAR dans un exemple? Comme pour mon exemple, j'ai constaté TRIÉS PAR ne rien faire. Ai-je raté quelque chose.
    • REGROUPÉS PAR x,y, c'est comme l'écriture de DISTRIBUER PAR x,y TRIER PAR x,y (voir cwiki.apache.org/confluence/display/Hive/...) donc, l'ajout de TRIER PAR REGROUPÉS EN a aucun effet.
    • Intéressant, je suis d'accord w.r.t l'utilisation dans une requête select. Mais il se demande pourquoi les gens sont à l'aide de cluster par et triés par ensemble dans la création de la table de déclaration. Si il n'y a pas d'importance pour TRIÉS PAR en DDL, alors pourquoi ce mot-clé est présent? N'a pas l'obtenir.
    • TRIÉS PAR est destiné à être utilisé avec DISTRIBUÉES PAR. Par exemple, vous souhaitez peut-être distribuées par id d'utilisateur et de les trier par moment dans le seau. CLUSTER est juste un raccourci pour quand la clause sur l'TRIÉ et DISTRIBUÉ PAR sont les mêmes. Seule chose que je peux penser est que si vous êtes à la distribution par x,y et le tri par x,y et z
    • Je ne suis pas sûr de ce que tu veux dire par "vous pouvez seau sur un seul champ." Je pense qu'il est possible de seau par de multiples champs de la fonction de hachage suffit de prendre tous les champs et de les combiner.
    • Vous avez raison, ce n'est pas tout à fait correct, ce que je voulais dire, c'est que vous pouvez partition à travers plusieurs dimensions, tandis que la création de compartiments, vous pouvez le faire qu'à travers une dimension, qu'il peut être un champ unique ou une combinaison d'entre eux. Comme vous l'avez dit, vous avez une fonction de hachage qui réduit les multiples domaines d'un domaine (la valeur de hachage).
    • "mergesort qui fonctionne en temps linéaire..." Tu veux dire juste une fusion pas un mergesort ici, je crois, mergesort est toujours en O(n*log(n))
    • Pas toujours.....si les pièces étant fusionnées sont déjà triées comme dans l'exemple que j'ai mentionné, il fonctionne en temps linéaire. Mais bon point, je vous annonce une clarification.

    InformationsquelleAutor Roberto Congiu
  3. 18

    Je pense que je suis en retard pour répondre à cette question, mais de garder à venir dans mon alimentation.

    Navneet a fourni une excellente réponse. En ajoutant à cela visuellement.

    Partitionnement aide à l'élimination des données, si elle est utilisée dans la clause where, où, comme la création de compartiments aide dans l'organisation des données dans chaque partition en plusieurs fichiers, de sorte que même jeu de données est toujours écrite dans le même seau. Aide beaucoup à se joindre à des colonnes.

    Imaginons que vous ayez une table avec cinq colonnes, nom, server_date, some_col3, some_col4 et some_col5. Supposons que, vous avez partitionné le tableau de la server_date et placées dans un compartiment sur nom colonne de 10 seaux, la structure de votre fichier devrait ressembler à quelque chose comme ci-dessous.

    1. server_date=xyz
      • 00000_0
      • 00001_0
      • 00002_0
      • ........
      • 00010_0

    Ici server_date=xyz est la partition et 000 fichiers sont les compartiments dans chaque partition. Les seaux sont calculées en fonction de certaines fonctions de hachage, de sorte que les lignes avec nom=Sable la volonté de toujours aller dans le même seau.

    • Selon Roberto dans la réponse ci-dessus server_date serait un mauvais exemple pour faire le partitionnement que c'est cardinalité la valeur est très élevée. Et donc, vous finirez par avoir un trop grand nombre de dossiers dans hdfs.
    • server_date est mentionné comme un exemple ici. Dans le monde réel, la partition est généralement le cas, comme illustré par Roberto, par la transgression de la date année/mois/jour. C'est la façon dont il devrait être.
    InformationsquelleAutor Priyesh
  4. 14

    Ruche De Partitionnement:

    Partition divise grande quantité de données en plusieurs tranches en fonction de la valeur d'une colonne de table(s).

    Supposons que vous êtes à stocker des informations de personnes dans le monde entier répartis dans 196 pays couvrant environ 500 crores d'entrées. Si vous voulez interroger les gens à partir d'un pays en particulier (cité du Vatican), en l'absence de partitionnement, vous devez analyser tous les 500 crores de participations, même pour aller chercher de mille entrées d'un pays. Si vous avez une partition de la table selon les pays, vous pouvez affiner processus de requête par la simple vérification des données pour un seul pays de la partition. La ruche partition crée un répertoire séparé pour une colonne(s) de valeur.

    Pour:

    1. Distribuer de l'exécution de la charge à l'horizontale
    2. Exécution plus rapide des requêtes dans le cas de la partition avec le faible volume de données. par exemple, Obtenir la population de "de la cité du Vatican" revient très vite au lieu de chercher ensemble de la population du monde.

    Contre:

    1. Possibilité de trop petite partition de créations de trop nombreux répertoires.
    2. Efficace pour un faible volume de données d'une partition donnée. Mais certaines requêtes comme groupe par le volume élevé de données de toujours prendre du temps pour s'exécuter. par exemple, le Regroupement de la population de la Chine va prendre beaucoup de temps par rapport à de regroupement de la population dans la cité du Vatican. La Partition n'est pas résoudre la réactivité problème dans le cas de données de l'inclinaison vers une partition de la valeur.

    De La Ruche De La Création De Compartiments:

    Écopage se décompose de données plus faciles à gérer ou des parties égales.

    Avec le partitionnement, il ya une possibilité que vous pouvez créer de multiples petites partitions en fonction des valeurs de la colonne. Si vous optez pour la création de compartiments, vous limitez le nombre de compartiments pour stocker les données. Ce nombre est défini lors de la création de la table des scripts.

    Pros

    1. En raison de l'égalité des volumes de données dans chaque partition, se joint à la Carte, côté sera plus rapide.
    2. Plus rapidement la réponse à la requête, comme le partitionnement

    Contre

    1. Vous pouvez définir le nombre de compartiments lors de la création de la table, mais le chargement de l'égalité de volume de données doit être fait manuellement par les programmeurs.
    InformationsquelleAutor Ravindra babu
  5. 6

    La différence est écopage divise les fichiers par Nom de Colonne, et partitionnement divise les fichiers sous Par une valeur particulière à l'intérieur de la table de

    J'espère que je définis correctement

    InformationsquelleAutor uriya harel
  6. 2

    Avant d'aller dans Bucketing, nous avons besoin de comprendre ce que Partitioning est. Prenons le tableau ci-dessous à titre d'exemple. Note que j'ai donnée à seulement 12 enregistrements dans l'exemple ci-dessous pour les débutants niveau de compréhension. En temps réel scénarios, vous pouvez avoir des millions d'enregistrements.

    Quelle est la différence entre le partitionnement et la création de compartiments d'une table dans la Ruche ?

    PARTITIONNEMENT

    ---------------------

    Partitioning est utilisé pour obtenir les performances tout en interrogeant les données. Par exemple, dans le tableau ci-dessus, si nous écrire ci-dessous sql, il faut analyser tous les enregistrements dans la table, ce qui réduit les performances et augmente la surcharge.

    select * from sales_table where product_id='P1'

    Pour éviter full table scan et de lire uniquement les enregistrements associés à product_id='P1' nous pouvons partition (split de la ruche de la table de fichiers) dans plusieurs fichiers basé sur le product_id colonne. En cela, la table de la ruche du fichier sera divisé en deux fichiers un avec product_id='P1' et d'autres avec product_id='P2'. Maintenant, lorsque nous exécutons la requête ci-dessus, il va scanner uniquement le product_id='P1' fichier.

    ../hive/warehouse/sales_table/product_id=P1
../hive/warehouse/sales_table/product_id=P2

    La syntaxe pour la création de la partition est donnée ci-dessous. Notez que nous ne devrions pas utiliser la product_id définition de la colonne ainsi que le non-partitionné colonnes dans le dessous de la syntaxe. Ce devrait être uniquement dans le partitioned by clause.

    create table sales_table(sales_id int,trans_date date, amount int) 
partitioned by (product_id varchar(10))

    Contre : Nous devons être très prudents lors du partitionnement. C'est, il ne doit pas être utilisé pour les colonnes où nombre de le répéter, les valeurs sont très moins (en particulier les colonnes de clé primaire), car il augmente le nombre de fichiers partitionnés et augmente la charge pour les Name node.

    ÉCOPAGE

    ------------------

    Bucketing est utilisé pour surmonter la cons que je l'ai mentionné dans la section de partionnement. Cela devrait être utilisé lorsqu'il y a très peu de doublons dans une colonne (par exemple colonne de la clé primaire). Ceci est similaire à la notion d'index sur la colonne de clé primaire dans les SGBDR. Dans notre tableau, nous pouvons prendre Sales_Id colonne pour la création de compartiments. Il sera utile lorsque nous avons besoin d'interroger le sales_id colonne.

    Ci-dessous est la syntaxe pour la création de compartiments.

    create table sales_table(sales_id int,trans_date date, amount int) 
partitioned by (product_id varchar(10)) Clustered by(Sales_Id) into 3 buckets

    Ici, nous allons découper les données en quelques fichiers supplémentaires sur le dessus de partitions.

    Quelle est la différence entre le partitionnement et la création de compartiments d'une table dans la Ruche ?

    Depuis, nous avons spécifié 3 seaux, elle est divisée en 3 fichiers pour chaque product_id. Il utilise en interne modulo operator de déterminer dans quelle seau chaque sales_id doit être stocké. Par exemple, pour la product_id='P1', le sales_id=1 seront stockées dans 000001_0 fichier (c'est à dire, 1%3=1), sales_id=2 seront stockées dans 000002_0 fichier (c'est à dire, 2%3=2),sales_id=3 seront stockées dans 000000_0 fichier (c'est à dire, 3%3=0), etc.

    InformationsquelleAutor Sarath Avanavu
  7. 2

    À l'aide de Partitions dans le tableau de la Ruche est fortement recommandée pour les raisons suivantes -

    • Insérer dans la table de la Ruche devrait être plus rapide ( car il utilise plusieurs threads
      pour écrire des données sur des partitions )
    • Requête à partir de la table de la Ruche doit être efficace avec une faible latence.

    Exemple :-

    Supposons que le Fichier d'Entrée (100 GO) est chargé en temp-ruche-table et il contient les données de la banque de dans des zones géographiques différentes.

    Tableau de la ruche sans Partition

    Insert into Hive table Select * from temp-hive-table

/hive-table-path/part-00000-1  (part size ~ hdfs block size)
/hive-table-path/part-00000-2
....
/hive-table-path/part-00000-n

    Problème avec cette approche est - Il analyse l'ensemble des données pour chaque requête que vous exécutez sur ce tableau. Le temps de réponse sera élevé en comparaison à d'autres approches où le partitionnement et la création de compartiments sont utilisés.

    Tableau de la ruche avec de la Partition

    Insert into Hive table partition(country) Select * from temp-hive-table

/hive-table-path/country=US/part-00000-1       (file size ~ 10 GB)
/hive-table-path/country=Canada/part-00000-2   (file size ~ 20 GB)
....
/hive-table-path/country=UK/part-00000-n       (file size ~ 5 GB)

    Pros - Là, on peut accéder à des données plus rapide quand il s'agit de l'interrogation des données spécifiques à la géographie des transactions.
    Les inconvénients de l'Insertion et d'interrogation de données peut encore être améliorée par le fractionnement des données au sein de chaque partition. Voir Écopage des options ci-dessous.

    Tableau de la ruche avec de la Partition et la création de compartiments

    Remarque: Créer un tableau de la ruche ..... avec "CLUSTER PAR(Partiton_Column) dans les 5 seaux

    Insert into Hive table partition(country) Select * from temp-hive-table

/hive-table-path/country=US/part-00000-1       (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-2       (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-3       (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-4       (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-5       (file size ~ 2 GB)

/hive-table-path/country=Canada/part-00000-1   (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-2   (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-3   (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-4   (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-5   (file size ~ 4 GB)

....
/hive-table-path/country=UK/part-00000-1       (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-2       (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-3       (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-4       (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-5       (file size ~ 1 GB)

    Pros - Plus Rapide De L'Insertion. Plus Rapide Requête.

    Contre - Écopage permettra de créer plusieurs fichiers. Il pourrait y avoir de problème avec de nombreux petits fichiers, dans certains cas spécifiques

    Espère que cela va aider !!

    InformationsquelleAutor Ajay Ahuja
  8. 0

    Il y a de grandes réponses ici. Je voudrais le garder court et à mémoriser la différence entre la partition & seaux.

    Vous, en général, de la partition sur un moins de colonne unique. Et écopage sur la plupart colonne unique.

    Exemple, si vous envisagez de la population Mondiale avec des pays, le nom de la personne et leur bio-métrique id comme un exemple. Comme vous pouvez le deviner, le champ pays serait le moins unique de la colonne et de la bio-métrique id seraient les plus uniques de la colonne. Idéalement, vous devez partitionner le tableau par pays et d'un seau en bio-métrique id.

    InformationsquelleAutor SVK