Einführung
Ein Veranstaltungsort speichert seine bestätigten Besuche in einem Hive-Archiv. Eine freigegebene Korrektur ersetzt die vollständige Menge bestätigter Besuche eines Tages. Sie ist kein Nachtrag, der an die gestrigen Zeilen angehängt wird. Für einen freigegebenen Tag gibt es jetzt zwei bestätigte Besuche, für einen anderen keinen. Alle anderen Tage, einschließlich eines später hinzugekommenen Besuchs, müssen unverändert bleiben.
Du vergleichst Anhängen und Ersetzen an separaten Übungstabellen. Anschließend speicherst du eine SQL-Datei mit eng begrenztem Zielbereich und führst sie am echten ORC-Archiv aus. Du führst dieselbe Datei außerdem erneut aus und liest das Ergebnis noch einmal. Hive und HDFS laufen bereits; unabhängige Rohdaten, Korrekturkandidaten und ein Archiv sind vorbereitet.
Du solltest externe Hive-Tabellen, SELECT mit WHERE, Partitionsspalten, ORC und grundlegende HDFS-Pfade kennen. Dieses Lab führt statische Zielpartitionen und den vollständigen Ersatz eines Tages ein. Alle Arbeiten erfolgen im Tab Terminal. Die 65 Minuten sind eine Schätzung des Autors einschließlich Lesen und gewöhnlicher Fehler.
Vergleiche Anhängen und Ersetzen sicher
In diesem Schritt liest du einen normalen Archivtag und vergleichst anschließend drei Schreibbereiche an separaten Übungstabellen. Lasse das echte Archiv während dieses Vergleichs unverändert.
Öffne Terminal. Verwende während des gesamten Labs das vorbereitete Arbeitsverzeichnis:
cd /home/labex/project
Das lokale Verzeichnis venue enthält CSV-Referenzdateien und eine Freigabeliste. cat zeigt eine Datei an, ohne sie zu bearbeiten:
cat venue/approved-days.txt
2026-10-02
2026-10-03
Nur diese Tage im echten Archiv darfst du ersetzen. Lies zuerst einen normalen Tag. Beeline sendet SQL an HiveServer2. Im folgenden Befehl gibt -u die JDBC-Verbindungsadresse an, -n labex den Client-Benutzernamen und -e den SQL-Text. Doppelte Anführungszeichen halten den Text als ein Shell-Argument zusammen; die einfachen Anführungszeichen darin begrenzen SQL-Werte. DATE '...' macht den Datumstyp ausdrücklich kenntlich.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT * FROM venue_archive.archive WHERE visit_date=DATE '2026-10-04' ORDER BY visit_id;"
Lies die Datenzeilen unter den Startmeldungen. Der Tag enthält v4 / Music / 4 und v5 / LateWalk / 2. Der spätere Besuch v5 ist gültig und muss erhalten bleiben. Das Image kann SLF4J-Hinweise zu mehreren Logging-Bindungen ausgeben; diese sind von SQL-Fehlern zu unterscheiden. Warte auf die Rückkehr der Eingabeaufforderung, bevor du fortfährst.
Untersuche nun die vollständige Kandidatenquelle einschließlich abgesagter Einträge:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT * FROM venue_archive.candidate ORDER BY visit_date,visit_id;"
Am 2. Oktober stehen c21 / PrintWorkshop / 5 und c22 / Bookbinding / 2, beide mit confirmed. Für den 3. Oktober gibt es eine Zeile mit cancelled. Das Archiv speichert nur confirmed-Zeilen; die vollständige Ersatzmenge für den 3. Oktober ist daher berechtigterweise leer. Fehlt ein Datum im gefilterten Ergebnis, bedeutet das nicht, dass du die alten Archivdaten dieses Tages unverändert lassen sollst. Freigabe und Filter für bestätigte Zeilen beantworten verschiedene Fragen.
Prüfe, wo die drei echten Tabellen lesen und schreiben. DESCRIBE FORMATTED ergänzt die Spaltendefinitionen um Speichermetadaten: Suche in jedem Ergebnis nach Table Type, Location und InputFormat. Die lange Ausgabe enthält weitere Engine-Details; konzentriere dich vor dem Schreiben auf diese Felder.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "DESCRIBE FORMATTED venue_archive.raw; DESCRIBE FORMATTED venue_archive.candidate; DESCRIBE FORMATTED venue_archive.archive;"
Alle drei sind EXTERNAL_TABLE-Objekte. Der Rohdatenpfad lautet hdfs://localhost:9000/user/labex/venue-archive/raw; der Kandidatenpfad endet auf /user/labex/venue-archive/candidate. Beide verwenden Texteingaben. Das Archiv liegt unter hdfs://localhost:9000/warehouse/external/venue_archive.db/archive, und sein Eingabeformat endet auf OrcInputFormat. Die lokalen Dateien venue/*.csv sind Referenzkopien, nicht das Archiv. Erhalte die vorgegebenen Zuordnungen und Quelldateien.
Verwende vor Änderungen am echten Archiv zwei Übungstabellen: practice_days ist nach Datum partitioniert; practice_whole speichert das Datum als normale Spalte. Anfangs enthalten beide die bestätigten Besuche aus den Rohdaten. Die nächsten Befehle zeigen absichtlich falsche Ergebnisse nur an diesen Übungstabellen.
INSERT INTO hängt Zeilen an. PARTITION(visit_date='2026-10-02') ist eine statische Zielpartition: Das Datumsliteral bestimmt, wohin jede ausgewählte Zeile geschrieben wird. Das SELECT darf deshalb nur die drei Nicht-Partitionsspalten zurückgeben. Seine getrennte WHERE-Bedingung wählt die Quellzeilen aus. Die Angabe des Ziels filtert die Quelle nicht automatisch.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT INTO TABLE venue_archive.practice_days PARTITION(visit_date='2026-10-02') SELECT visit_id,activity,visitors FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed'; SELECT * FROM venue_archive.practice_days WHERE visit_date=DATE '2026-10-02' ORDER BY visit_id;"
Das Ergebnis enthält c21, c22 und das alte v2. Das SQL war erfolgreich, aber der Ersatzvertrag wurde nicht erfüllt. Ein erneutes Anhängen derselben Korrektur würde weitere Duplikate erzeugen.
INSERT OVERWRITE ersetzt die vorhandenen Zeilen des Ziels. Bei der nicht partitionierten Tabelle practice_whole ist das Ziel die gesamte Tabelle. Beobachte, wie die anderen Tage verschwinden:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT OVERWRITE TABLE venue_archive.practice_whole SELECT visit_id,activity,visitors,visit_date FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed'; SELECT * FROM venue_archive.practice_whole ORDER BY visit_date,visit_id;"
Es bleiben nur die beiden Zeilen des 2. Oktober. Eine erfolgreiche Schreiboperation auf die ganze Tabelle kann unbemerkt andere Tage verlieren. Stelle diese Übungstabelle aus ihrer vollständigen Rohdatenquelle wieder her:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT OVERWRITE TABLE venue_archive.practice_whole SELECT visit_id,activity,visitors,visit_date FROM venue_archive.raw WHERE record_status='confirmed'; SELECT * FROM venue_archive.practice_whole ORDER BY visit_date,visit_id;"
Alle fünf ursprünglichen Zeilen sind wieder vorhanden. Kombiniere zuletzt OVERWRITE mit einer statischen Datumspartition in practice_days:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT OVERWRITE TABLE venue_archive.practice_days PARTITION(visit_date='2026-10-02') SELECT visit_id,activity,visitors FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed'; SELECT * FROM venue_archive.practice_days ORDER BY visit_date,visit_id;"
Es gibt sechs Zeilen: den ursprünglichen 1. Oktober, die zwei korrigierten Zeilen des 2. Oktober, den ursprünglichen 3. Oktober und beide Besuche des 4. Oktober. Das alte v2 ist verschwunden. Dies ist der benötigte Schreibbereich für das echte Archiv.
Meldet Beeline einen ungültigen Tabellennamen, hat das SQL das beabsichtigte Objekt nicht gefunden. Prüfe die Schreibweise mit dem folgenden bereits bekannten Lesebefehl und führe den korrigierten Befehl erneut aus. Pfadfehler untersuchst du mit pwd und ls venue; mit dem obigen cd kehrst du zurück. Erstelle Tabellen nicht neu und starte die Umgebungsvorbereitung nicht erneut, um einen Tippfehler zu beheben.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SHOW TABLES IN venue_archive;"
Prüfe vor der Kontrolle dieses Schritts, dass die Übungspartition am 2. Oktober genau c21 und c22 enthält, die Übung zur ganzen Tabelle wieder ihre fünf ursprünglichen Zeilen hat und das echte Archiv noch die ursprünglichen Daten enthält.
Ersetze den freigegebenen Tag mit bestätigten Datensätzen
In diesem Schritt speicherst du den echten Ersatz für den 2. Oktober und führst ihn aus. Arbeite weiter in Terminal unter /home/labex/project.
Die echte Tabelle venue_archive.archive ist eine externe, nicht transaktionale ORC-Tabelle mit visit_date DATE-Partitionen. Ihre Rohdaten- und Kandidatenquellen sind unabhängige externe Tabellen mit durch Kommas getrennten Textdaten. Du darfst nur freigegebene Archivtage ersetzen. Bearbeite keine Quelldateien, ändere keine Tabellendefinitionen oder Speicherorte, ordne keine Partitionen neu zu, erstelle keine zusätzlichen Tage und baue nicht das ganze Archiv neu auf. Der 1. und 4. Oktober müssen ihre ursprünglichen Daten und vorhandenen HDFS-Dateien behalten. Auch das Neuschreiben identischer Zeilen liegt außerhalb der Freigabe.
Untersuche vor dem Schreiben die echte Partitionsliste und die Spaltenanordnung. SHOW PARTITIONS listet registrierte Datumspartitionen auf; DESCRIBE zeigt normale Spalten und anschließend Partitionsinformationen:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SHOW PARTITIONS venue_archive.archive; DESCRIBE venue_archive.archive;"
Die vier Tage sind der 1. bis 4. Oktober. Die normalen Spalten sind visit_id STRING, activity STRING und visitors INT; visit_date DATE ist die Partitionsspalte. Erhalte diese Zuordnung und das ORC-Format.
Speichere dein SQL als bearbeitbare Datei, damit du dieselbe Operation untersuchen, korrigieren und wiederholen kannst. nano ist ein Texteditor in Terminal. Der folgende Befehl öffnet replace-approved-days.sql im aktuellen Arbeitsverzeichnis; da dies eine neue Datei ist, ist der Bearbeitungsbereich zunächst leer:
nano replace-approved-days.sql
Gib die folgenden fünf SQL-Zeilen in nano ein, nicht am Shell-Prompt. Einfache Anführungszeichen begrenzen SQL-Werte, das Semikolon beendet die Anweisung. Höre nach dem letzten Semikolon auf, ohne eine zusätzliche Leerzeile einzufügen; nano ergänzt beim Speichern den abschließenden Zeilenumbruch:
INSERT OVERWRITE TABLE venue_archive.archive
PARTITION(visit_date='2026-10-02')
SELECT visit_id,activity,visitors
FROM venue_archive.candidate
WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed';
Gehe mit den Pfeiltasten zu einem Zeichen, das korrigiert werden muss; Home und End führen zum Anfang und Ende der aktuellen Zeile. Backspace löscht das Zeichen links vom Cursor; Delete löscht das Zeichen unter dem Cursor. Gib an seiner Stelle den korrigierten Text ein. nanos Fußzeile verwendet ^ für Ctrl. Drücke Ctrl+O zum Speichern: Behalte bei File Name to Write den angezeigten Dateinamen bei und drücke Enter. Beende dann mit Ctrl+X. Warte, bis der Shell-Prompt zurückkehrt; SQL gehört in den Editor, während die folgenden Befehle an diesen Prompt gehören.
Lies den gespeicherten Inhalt vor der Ausführung:
cat replace-approved-days.sql
Prüfe beide Datumsangaben der Anweisung: Sowohl das statische Ziel als auch der Quellfilter beziehen sich auf den 2. Oktober. Die Korrektur ist die vollständige bestätigte Menge mit c21 und c22. Du musst keine alten Besuchs-IDs abgleichen und keine einzelnen Zeilen aktualisieren.
Beelines -f liest SQL aus einer Datei. Führe deine gespeicherte Datei aus:
beeline -u jdbc:hive2://localhost:10000/default -n labex -f replace-approved-days.sql
Lies danach alle vier Tage so, wie ein Nutzer der Daten es tun würde:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT visit_date,visit_id,activity,visitors FROM venue_archive.archive ORDER BY visit_date,visit_id;"
Erwarte sechs Zeilen. Der 2. Oktober enthält c21 / PrintWorkshop / 5 und c22 / Bookbinding / 2, ohne v2. Für den 3. Oktober ist vorerst noch das alte v3 vorhanden. v1 vom 1. Oktober sowie v4 und v5 vom 4. Oktober bleiben unverändert.
Die Beeline-Verbindung identifiziert dich als labex. HiveServer2 schreibt die Daten als Dienstbenutzer hive; neue ORC-Dateien können daher hive:bigdata gehören. Du musst weder Besitzer noch Berechtigungen ändern. Der HDFS-NameNode läuft unter seiner eigenen Dienstidentität hdfs.
Hat eine SQL-Anweisung einen Syntaxfehler, prüfe die gespeicherte Datei mit cat und öffne sie dann mit nano replace-approved-days.sql erneut. Suche mit den Pfeiltasten die in der Beeline-Fehlermeldung genannte Anweisung. Korrigiere bei Bedarf Tabellenname, Datumsangaben, Anführungszeichen oder Semikolon und erhalte die anderen SQL-Zeilen. Speichere mit Ctrl+O, Enter und beende dann mit Ctrl+X. Lies die Datei erneut, bevor du -f nochmals ausführst. Falls du versehentlich Daten an diesen freigegebenen Tag angehängt hast, entfernt dieselbe korrekte Partitionsüberschreibung die veralteten und doppelten Zeilen. Diese Wiederherstellung gilt für den freigegebenen Tag; sie erlaubt keinen Neuaufbau eines geschützten Tages.
Ersetze durch eine leere Datensatzmenge und führe die Datei erneut aus
In diesem Schritt leerst du die freigegebene Partition des 3. Oktober. Anschließend führst du die vollständige Korrekturdatei zweimal aus und prüfst, dass das Archiv keine Zeilen ansammelt. Arbeite weiter in Terminal unter /home/labex/project.
Auch eine Absage ist eine Korrektur. Die Freigabeliste enthält den 3. Oktober, aber sein Kandidat hat keine bestätigten Besuche. Führe zuerst die Quellauswahl aus:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT visit_id,activity,visitors FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-03' AND record_status='confirmed';"
Es werden keine Datenzeilen zurückgegeben. Auch das korrekte endgültige Archiv darf keine Zeilen für diesen Tag enthalten. Würdest du den Schreibvorgang überspringen, bliebe das alte v3 erhalten.
Öffne dieselbe Datei erneut. Erhalte die vorhandene Anweisung für den 2. Oktober; du ergänzt eine Anweisung, statt die erste erneut zu kopieren:
nano replace-approved-days.sql
Gehe mit der Pfeiltaste nach unten zur leeren Zeile nach dem Semikolon der ersten Anweisung und bei Bedarf mit End an das Ende dieser Zeile. Drücke an dieser leeren Zeile einmal Enter, um zwischen den Anweisungen eine Leerzeile zu lassen. Gib dann nur die folgenden fünf neuen Zeilen ein. Höre nach dem letzten Semikolon auf, ohne eine weitere Leerzeile einzufügen. Falls du eine unterbrochene Bearbeitung fortsetzt, prüfe zuerst, ob die Anweisung für den 3. Oktober bereits vorhanden ist; korrigiere sie, statt ein Duplikat hinzuzufügen.
INSERT OVERWRITE TABLE venue_archive.archive
PARTITION(visit_date='2026-10-03')
SELECT visit_id,activity,visitors
FROM venue_archive.candidate
WHERE visit_date=DATE '2026-10-03' AND record_status='confirmed';
Speichere mit Ctrl+O, Enter und beende dann mit Ctrl+X. Lies die vollständige gespeicherte Datei am Shell-Prompt:
cat replace-approved-days.sql
Prüfe, dass sie genau zwei Anweisungen enthält: die ursprüngliche für den 2. Oktober und danach die neue für den 3. Oktober. In jeder müssen sowohl das statische Ziel als auch der Quellfilter den für diese Anweisung freigegebenen Tag nennen. Falls etwas nicht stimmt, öffne dieselbe Datei erneut in nano, korrigiere nur die betroffenen Zeilen und speichere und prüfe sie erneut.
Führe diese vollständig gespeicherte Datei zum ersten Mal aus:
beeline -u jdbc:hive2://localhost:10000/default -n labex -f replace-approved-days.sql
Eine statische Überschreibung mit leerem Auswahlergebnis entfernt die alten Zeilen der Zielpartition. Der Tag bleibt registriert. Die Speicher-Engine entscheidet, ob eine leere Partition physische Dateien hat; lege selbst keine CSV- oder ORC-Platzhalterdateien an.
Lies die registrierten Tage und das vollständige Ergebnis:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SHOW PARTITIONS venue_archive.archive; SELECT visit_date,visit_id,activity,visitors FROM venue_archive.archive ORDER BY visit_date,visit_id; SELECT COUNT(*) FROM venue_archive.archive WHERE visit_date=DATE '2026-10-03';"
Alle vier Partitionen sind weiterhin aufgelistet. Das vollständige Ergebnis hat fünf Zeilen: v1, c21, c22, v4 und v5. Der Zähler für den 3. Oktober ist 0. Zwei Tage in einer Freigabeliste bedeuten nicht, dass beide Partitionen Datensätze enthalten müssen.
Führe jetzt dieselbe gespeicherte Datei nochmals aus, ohne sie zu ändern:
beeline -u jdbc:hive2://localhost:10000/default -n labex -f replace-approved-days.sql
Wiederhole die Leseabfrage:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT visit_date,visit_id,activity,visitors FROM venue_archive.archive ORDER BY visit_date,visit_id; SELECT COUNT(*) FROM venue_archive.archive;"
Es bleiben dieselben fünf Zeilen und insgesamt 5. Für die gelieferten Quellen ist dies ein wiederholbarer Ersatz: Es werden keine Duplikate angehängt. Beim Wiederholen können Dateien der freigegebenen Partitionen neu entstehen; die ursprünglichen Dateien der anderen Tage müssen unberührt bleiben.
Mit bekannten HDFS-Befehlen kannst du die ursprüngliche Quelle untersuchen. Hier liest -cat genau die Quelldatei, nicht das abgeleitete ORC-Archiv:
hdfs dfs -cat /user/labex/venue-archive/raw/raw.csv
Sie enthält weiterhin das ursprüngliche v2 und v3. Änderungen an einem abgeleiteten Archiv schreiben seine Rohdatenhistorie nicht um. Auch Kandidaten und Freigabeliste müssen wie geliefert erhalten bleiben. Behalte die SQL-Datei im Arbeitsverzeichnis. Die Prüfungen beobachten aktuelle Hive-Daten, Definitionen, den Umfang und geschützte Dateien; sie führen keine beliebigen gespeicherten SQL-Dateien aus. Die tatsächliche Wiederholung und deine anschließenden Leseabfragen prüfen die gespeicherte Operation.
Zusammenfassung
Du hast Anhängen, den Ersatz einer ganzen Tabelle und den Ersatz einer statischen Partition verglichen. Danach hast du einen vollständigen freigegebenen Tag ersetzt, einen gültigen Ersatz durch eine leere Datensatzmenge angewendet und dieselbe gespeicherte SQL-Datei ohne zusätzliche Zeilen erneut ausgeführt. Die unabhängige Rohdatenhistorie und die anderen Archivtage blieben erhalten.
