taille de bloc de données dans HDFS, pourquoi 64MO?

• merci pour votre réponse. Assumer la taille des blocs de 4 ko et d'un fichier est de stocker en continu les blocs du disque. Pourquoi ne peut-on pas récupérer 1000 MO fichier en utilisant 1 demande? Je sais peut-être actuellement HDFS ne prend pas en charge une telle méthode d'accès. Mais quel est le problème de cette méthode d'accès?
• In the case of small files, lets say that you have a bunch of 1k files, and your block size is 4k. That means that each file is wasting 3k, which is not cool. - ce n'est pas vrai dans le cas de HDFS. Disons que le fichier est de 100 mo, puis les blocs sont 64MM et 36BM. Généralement la taille du dernier bloc est de moins en moins, sauf si le fichier est un multiple de 64 MO.
• HDFS pourrait récupérer un 1000 MO fichier dans l'un demande si la taille des blocs ont été au moins 1000 MO.
• Est-ce à dire que, si je stocker un fichier de 1 mo dans HDFS avec une taille de bloc de 64 mo, il faudra jusqu'à 64 mo de HDFS la capacité de stockage?
• Non, un fichier de 1 mo ne prendra pas de 64 mo sur le disque.
• Cette réponse est tout simplement faux. Ce "bloc" ou "taille de bloc" signifie dépend du système de fichiers et, dans le cas de HDFS il n' pas signifie la plus petite unité, il peut stocker, c'est la plus petite unité de la namenode références. Et un bloc est généralement stockées de manière séquentielle sur un disque physique, ce qui rend la lecture et l'écriture d'un bloc rapide. Pour les petits fichiers, la taille de bloc n'a pas d'importance, parce qu'ils seront plus petites que la taille des blocs de toute façon et stocké dans un bloc plus petit. Alors le plus gros bloc de tailles sont généralement mieux, mais on doit peser contre la quantité désirée de données et mappeur de distribution.
• Dire que la taille de bloc est la plus petite unité d'un namenode références est correcte...mon explication est une légère simplification excessive. Je ne sais pas pourquoi cela fait la réponse " tout simplement faux, cependant.
• Au moins 3 choses sont fausses: 1. La plupart des fichiers ne sont pas un multiple de la taille de bloc de sorte que le dernier bloc est effectivement plus petite que la taille de bloc par défaut (et oui sa référencé par le namenode). 2. Il n'y a pas une chose telle que la "taille de bloc", puisque la taille de bloc est un attribut de fichier et peuvent donc être différentes d'un fichier à l' (il y a un "taille de bloc par défaut" si, et c'est ce que la question était de savoir). 3. Vous donner de mauvais conseils, si vous avez déjà essentiellement de petits fichiers de prise de la taille de bloc, même les plus petites ferait qu'aggraver les choses
• Je suis d'accord avec votre troisième point et mise à jour de ma réponse quand je ne suis pas sur mobile. Votre premier point est une supposition de votre part..je n'ai jamais dit qu'un bloc partiel prend l'espace d'un bloc complet. Le deuxième point est juste nit la cueillette, la grande majorité des gens ne changent pas cet attribut de fichier pour le fichier, donc je ne pense pas que c'était la peine de mentionner.
• Le second point n'est pas en coupant les cheveux en quatre, si vous modifiez la taille de bloc par défaut il laisse vos anciens fichiers à l'ancienne taille de bloc, à moins de migrer de façon explicite avec distcp et il est important de comprendre que. Donc, même si vous n'avez jamais mis sur un fichier niveau individuel, vous pouvez vous retrouver avec des fichiers de différentes tailles de bloc. Aussi il s'avère le premier point: si il n'y a pas qu'une seule taille de bloc, le namenode ne pouvez pas utiliser le "taille de bloc par défaut" en tant que plus petite unité adressable. Pas besoin de faire des hypothèses ici.
• mais ce n'est pas la question qui a été posée. La question était de savoir la taille de bloc par défaut. Si vous prenez beaucoup de problème avec ma réponse, alors je vous suggère de soumettre une modification à nos soumettre votre propre réponse.
• Vous avez mentionné que l'utilisation de blocs de 64 mo, le nombre de demande devrait être abaissé à 16 ans. Mais le système d'exploitation serait de traiter les données en blocs de 4 ko. Il ne sera pas le traitement des données à 64 mo. Comment cela fonctionne dans le fond? Comment peut-on réduire le temps de recherche avec 64mo de bloc lorsque le système d'exploitation serait seulement de processus de bloc de 4 ko à la fois?
• J'ai essayé aujourd'hui pour répondre à votre question en aspect 3 de stackoverflow.com/a/43382368/2727750. Fondamentalement recherche sur disque, le temps n'a pas beaucoup d'importance si vous disposez déjà d'un réseau de transfert de passe, mais le débit TCP questions. Je ne voudrais pas prétendre que l'avantage est la diminution du nombre de "demandes", mais la baisse du nombre de connexions TCP persistantes.
• D'abord celle concernant le débit du Disque. Vous avez mentionné des données peuvent être écrites de manière séquentielle sur le disque. Donc, si j'ai 64 mo de données dans le nœud esclave,8 ko blocs de 64 mo de données serait formé de manière séquentielle dans le disque de nœud esclave de couper vers le bas le temps de recherche. Lorsque les données sont écrites ou lues, il serait procédé en blocs de 8 ko? Est-ce exact?
• Le but de l'utilisation d'une plus grande taille de bloc est de réduire le nombre de demandes pour le nom de nœud. Donc, quelqu'un disait: "où puis-je trouver ce fichier?" pour le nom du noeud, qui aurait dit, "Vous pouvez trouver ce 64mo morceau ici, et celle-ci, etc." Le demandeur serait aller à chaque lieu une partie est stockée et dire, "hey, donnez-moi une copie de ce morceau." Ce HDFS reconnaît comme un bloc n'est pas le même que le sous-jacent FS. Si le sous-jacent FS utilise des blocs de 4k, alors que 64 go morceau prendrait environ 67 millions de blocs. C'est bien parce que le temps de latence est faible, à la différence de la latence pour le nom de nœud.
• Pour apaiser les choses différemment: Le but n'est pas de réduire le système d'exploitation du fardeau dans le stockage des blocs; c'est pour réduire combien la pensée le nom de nœud de a à faire quand il s'agit de se souvenir où chaque pièce du dossier est. Le nom de nœud est beaucoup plus lent qu'un local d'exploitation du système de fichiers.
• Alors, comment ces morceaux sont gérées par l'OS? Avons-nous chercher (pas de saut) option dans HDFS pour accéder à une position d'octet à un point aléatoire?
• Est-il un outil à la disposition des déficients regardez comment ces blocs sont stockés à l'OS du système de fichiers sur les données des nœuds?

Tous les commentaires

• De "MapReduce pourrait également profiter de la également distribué données par le lancement de plus de la carte de tâches de plus NodeManager et plus de cœurs de PROCESSEUR" - signifie la carte de réduire la tâche est appliquée sur une immense quantité de données?
• Je ne pouvais pas clairement à vous rendre ici ", mais dans la pratique, les avantages théoriques seront perdus sur de ne pas être en mesure d'effectuer séquentielle, tamponnée lit et à cause de la latence de chaque carte de tâche". Pouvez-vous donner des précisions sur ce point?

• donc tu veux dire que le sous-jacent de la mise en œuvre d'un bloc de 64 mo lire n'est pas décomposé en plusieurs bloc de 4 ko lit à partir du disque? Le disque de support de la lecture de 64 mo en 1 lire? N'hésitez pas à me demander des précisions si la question n'est pas claire. Merci.
• 64 mo de HDFS bloc sera divisé en plusieurs blocs de 4 ko fichier du système d'exploitation du système de blocs.
• si 64MO HDFS bloc sera divisé en plusieurs blocs de 4 ko, ce qui est le point de l'utilisation de 64 mo de HDFS bloc?
• Pour réduire la charge sur le Serveur de Nœud. Moins de blocs de piste = peu de demandes et moins de mémoire le suivi des blocs.
• Le actuel de la taille par défaut d'Apache Hadoop est de 128 MO.
• Donc, il n'y a vraiment aucun avantage de taille de bloc de 64 ans ou 128 en ce qui concerne l'accès séquentiel? Depuis, chaque bloc peut être divisé en plusieurs système de fichiers natif de blocs?
• Il est parti comme ces blocs de 4k sont stockés sur le disque de manière contiguë ce qui signifie qu'il est, sans chercher entre un bloc 4k à la prochaine
• la taille de bloc par défaut pour hadoop 1 était de 64 MO pour hadoop 2 de ses 128 MO
• U veux dire que si j'ai 64 mo de données dans le disque de nœud esclave,8 ko blocs de 64 mo de données serait formé de manière séquentielle pour les couper vers le bas supplémentaire de temps de recherche. Est-ce exact?
• Si c'est le cas, comment le système de fichiers enregistrer les données dans un ordre séquentiel. Parce que ce n'est pas la manière dont les données sont enregistrées dans le disque. Les données seraient dispersés dans le disque.Comment le séquentiel de la formation de données se produisent dans le disque. U pourrait me donner la clarté sur cette partie. Peu confus?
• Paul, C'est une très bonne question. Le but est d'obtenir des blocs contigus de la sous-jacentes du système de fichiers. En production mise en place HDFS obtient son propre volumes, pour l'obtention de blocs contigus n'est pas un problème. Si vous mélanger avec d'autres de stockage comme mapreduce temp de données, etc, alors la question se pose. Comment c'est exactement géré je ne suis pas sûr. Vous pouvez avoir à ouvrir le code et de voir comment il est géré.
• donc, pour résumer, de minimiser les chances qu'un fichier ne peut pas être stockés sur un seul bloc? Et même si les enregistrements sont stockés non pas de manière linéaire, l'ensemble du bloc est chargé dans la mémoire après le transfert, le temps de recherche disparaît? Mais est-ce vraiment de l'aide si le sous-jacent fs utilise des blocs de 4k? Je suppose que moins de demandes de blocs, par exemple en demandant de 64 ko une fois de plus un réseau est moins cher que de demander pour 4k 16 fois par 15 allers-retours.

Tous les commentaires

• Cela a déjà été mentionné dans ma réponse. Il aurait été préférable d'ajouter des commentaires à ma réponse que de poster un aswer qui ajoute que très peu avant de réponses.