Einführung
Die Dateien des Einzelhändlers haben Namen und Verzeichnisse, doch Rechner müssen auch ihre Inhalte irgendwo speichern. Wie lässt sich eine große Datei auf Speicherknoten verteilen? Was kopiert HDFS, wenn es ein Replikat vorhält, und reserviert ein fast leerer Block den Speicherplatz eines ganzen Blocks?
Sie wissen bereits, wie Sie Dateien ordnen und aufbewahren. In diesem Lab schauen Sie unter die Ebene ihrer Pfade. Ein HDFS-Block ist ein Teil einer Datei, den HDFS erfasst und speichert. Der NameNode hält Metadaten zu Dateien und Blockspeicherorten; DataNodes enthalten die Blockdaten. Ein Replikat ist eine weitere gespeicherte Kopie eines Blocks, kein neuer Handelsdatensatz und keine weitere für Benutzer sichtbare Datei.
Sie laden zwei vorbereitete Dateien mit einer bewusst kleinen, gültigen Blockgröße hoch, sagen ihre Blockanzahlen voraus und prüfen die tatsächlichen Speicherorte. Diese Umgebung mit einem DataNode verwendet den Replikationsfaktor 1. Sie liefert echte Beobachtungen, ohne eine Wiederherstellung über mehrere Rechner vorzutäuschen. Alle Daten und Dienste werden unabhängig vorbereitet. Verwenden Sie das Terminal; Programmierung ist nicht erforderlich.
Verknüpfen Sie Dateigröße und Blöcke
In diesem Schritt laden Sie eine Datei mit bekannter Blockgröße hoch und prüfen ihre Metadaten.
Ein Dateisystempfad benennt eine logische Datei. HDFS zerlegt deren Inhalt in Blöcke, damit verschiedene Teile in einem größeren Cluster auf unterschiedlichen DataNodes gespeichert werden können. Die konfigurierte Blockgröße ist eine maximale Datengröße für diesen Block, keine Zusage, dass jeder Block voll ist.
Beginnen Sie im Projektverzeichnis:
cd /home/labex/project
Der lokale Befehl wc -c zählt Bytes. Wenden Sie ihn auf die erste vorbereitete Datei an:
wc -c /home/labex/project/data/products-a.txt
Das Ergebnis beginnt mit 1572864: genau 1,5 MiB. Ein MiB entspricht 1.048.576 Byte. Diese Datei wiederholt eine einfache Produktbezeichnung, damit der Speicherversuch keine komplizierten Geschäftsregeln benötigt.
Erstellen Sie ein persönliches HDFS-Verzeichnis:
hdfs dfs -mkdir -p /user/labex/block-study
Für diese Demonstration überschreibt -Ddfs.blocksize=1048576 die Blockgrößeneinstellung des Clients für den folgenden Upload. -D übergibt eine Konfigurationseigenschaft für diesen Befehl; die gemeinsamen Konfigurationsdateien werden nicht bearbeitet. Ein MiB erfüllt die Mindestblockgröße dieses Images und hält die Demonstration klein:
hdfs dfs -Ddfs.blocksize=1048576 -put /home/labex/project/data/products-a.txt /user/labex/block-study/products-a.txt
Sagen Sie die Aufteilung voraus: 1,5 MiB bei einer Blockgröße von 1 MiB benötigen einen vollen und einen halb gefüllten Block, also zwei Blöcke.
Die HDFS-Operation -stat gibt ausgewählte Metadaten aus. Im Format in Anführungszeichen steht %b für die Dateilänge in Byte, %o für die Blockgröße und %r für den Replikationsfaktor:
hdfs dfs -stat 'bytes=%b blocksize=%o replication=%r' /user/labex/block-study/products-a.txt
Erwartete Werte:
bytes=1572864 blocksize=1048576 replication=1
Die Dateilänge beträgt weiterhin 1,5 MiB. Replikationsfaktor 1 bedeutet eine gespeicherte Kopie pro Block, nicht einen Block für die gesamte Datei. Speichern Sie die tatsächlichen Metadaten:
hdfs dfs -stat 'bytes=%b blocksize=%o replication=%r' /user/labex/block-study/products-a.txt > /home/labex/project/output/file-a-metadata.txt
Falls die Datei von einem abgeschlossenen Upload bereits existiert, prüfen Sie sie, bevor Sie den Upload wiederholen. Löschen Sie eine Datei nicht bloß, weil -put ein vorhandenes Ziel meldet.
Prüfen Sie Speicherorte und sagen Sie eine Änderung voraus
In diesem Schritt ermitteln Sie die tatsächlichen Blöcke der ersten Datei und testen Ihre Vorhersage mit einer größeren Datei.
Der Befehl hdfs fsck kann den Speicherzustand einer Datei untersuchen. Bei der folgenden ausschließlich lesenden Prüfung nimmt -files Dateidetails auf, -blocks Blockinformationen und -locations die DataNodes, die jeden Block enthalten. Keine dieser Optionen repariert oder löscht Dateien:
hdfs fsck /user/labex/block-study/products-a.txt -files -blocks -locations
Suchen Sie die Zeile mit der Dateilänge, die Blockeinträge und das Feld Total blocks (validated) in der Zusammenfassung. Es sollten zwei Blöcke vorhanden sein. Einer enthält 1.048.576 Byte, der andere 524.288 Byte. Blockkennungen, Adressen und Zeitstempel variieren. Die abschließende Zusammenfassung des Dateisystemzustands sollte HEALTHY lauten.
Speichern Sie die Untersuchung:
hdfs fsck /user/labex/block-study/products-a.txt -files -blocks -locations > /home/labex/project/output/file-a-blocks.txt
Ein gesunder Zustand bedeutet, dass diese Prüfung die erforderlichen Blöcke und Replikate gefunden hat. Bei einem Replikat pro Block auf einem Rechner bedeutet das nicht, dass die Datei den Verlust dieses Rechners überstehen kann.
Prüfen Sie nun die Größe der zweiten lokalen Datei:
wc -c /home/labex/project/data/products-b.txt
Ihre Länge beträgt 2621440 Byte, also 2,5 MiB. Sagen Sie vor dem Upload Anzahl und Größen ihrer Blöcke bei derselben Blockgröße von 1 MiB voraus. Nur die Dateilänge ändert sich:
hdfs dfs -Ddfs.blocksize=1048576 -put /home/labex/project/data/products-b.txt /user/labex/block-study/products-b.txt
Prüfen Sie das Ergebnis:
hdfs fsck /user/labex/block-study/products-b.txt -files -blocks -locations
Sie sollten drei Blöcke finden: zwei volle Blöcke und einen Block mit 524.288 Byte. Alle Speicherorte verweisen in diesem Lab auf denselben DataNode. Speichern Sie die Beobachtung:
hdfs fsck /user/labex/block-study/products-b.txt -files -blocks -locations > /home/labex/project/output/file-b-blocks.txt
In einem größeren Cluster können die Blockspeicherorte auf unterschiedlichen Rechnern liegen. Der NameNode liefert den Clients Ortsmetadaten; er ist keine zentrale Leitung, durch die jedes Byte des Dateiinhalts fließen muss.
Deuten Sie Speicherplatz, Replikate und den Datenweg
In diesem Schritt setzen Sie die Blockbeobachtungen mit der Dateigröße und dem tatsächlichen Speicherknotenbericht in Beziehung.
Ein halb gefüllter letzter Block reserviert nicht ein ganzes MiB Datenplatz, nur weil die Blockgröße auf 1 MiB eingestellt ist. Verwenden Sie -du ohne -h, damit genaue Bytezahlen sichtbar bleiben:
hdfs dfs -du /user/labex/block-study
Die ersten beiden Spalten für jede Datei sollten so aussehen:
1572864 1572864 .../products-a.txt
2621440 2621440 .../products-b.txt
Die erste Spalte ist die logische Dateilänge; die zweite berücksichtigt die Replikation. Hier stimmen sie überein, weil die Replikation 1 beträgt. Diese Werte beschreiben HDFS-Dateidaten, nicht jedes Metadatenbyte des Dateisystems oder die gesamte Festplattenbelegung der VM. Speichern Sie die Zeilen:
hdfs dfs -du /user/labex/block-study > /home/labex/project/output/block-report.txt
Prüfen Sie den tatsächlichen Speicherknotenbericht mit dem ausschließlich lesenden administrativen Befehl aus dem Umgebungs-Lab:
sudo -u hdfs /usr/local/bin/hdfs dfsadmin -report
Suchen Sie nach Live datanodes (1). Ein Replikationsfaktor von 3 würde keine drei Rechner erzeugen. Dieses Lab belässt ihn bei 1, statt Blöcke auf nicht verfügbare Replikate warten zu lassen.
Verknüpfen Sie die Beobachtungen mit dem Datenweg:
Schreiben: Client bittet NameNode, eine Datei anzulegen, und sendet dann Blockdaten an DataNode(s).
Lesen: Client fragt NameNode nach Speicherorten und liest dann Blockdaten von DataNode(s).
Bei mehreren Replikaten in einem größeren Cluster kann ein Client eine verfügbare Kopie verwenden, und ein Verarbeitungsframework kann versuchen, Arbeit in der Nähe der Daten auszuführen. Dieses Konzept heißt Datenlokalität. Eine mit -cp erstellte benannte Kopie ist eine zweite logische Datei; Replikate sind Speicherkopien von Blöcken innerhalb einer logischen Datei. Sie lösen unterschiedliche Probleme.
Bei Ihrer Vorhersageübung wurde die Dateigröße geändert, nicht der Replikationsfaktor. Datei A hat weiterhin zwei Blöcke, Datei B drei, und beide haben ein Replikat pro Block. Als Nächstes lernen Sie, warum eine vorhandene und gesunde Datei für einen bestimmten Benutzer dennoch unlesbar sein kann: Zugriffsberechtigungen.
Zusammenfassung
Sie haben vorhergesagt und beobachtet, wie Dateien mit 1,5 MiB und 2,5 MiB in zwei beziehungsweise drei Blöcke mit einer Blockgröße von 1 MiB aufgeteilt werden. Sie haben tatsächliche Blockspeicherorte untersucht und logische Dateilänge, Replikatspeicher und zusätzliche benannte Dateien unterschieden.
Außerdem haben Sie diese Ergebnisse mit NameNode-Metadaten und DataNode-Übertragungen verknüpft. Die Einzelknotenumgebung veranschaulicht diese Zuständigkeiten; Kapazität und Fehlertoleranz über mehrere Rechner erkunden Sie später.
