So fragen Sie eine lokale Datendatei per SQL ab

Laden Sie eine CSV-, TSV-, JSON-, NDJSON- oder Parquet-Datei und fragen Sie sie per SQL ab: Die Seite übergibt die Datei an eine DuckDB-Engine, die im Browser-Tab selbst läuft, stellt sie als Tabelle data bereit und zeigt das Ergebnis Ihrer SELECT- oder WITH-Anweisung in einer Tabelle, die Sie exportieren können. Die Engine ist DuckDB-Wasm 1.32.0 in einem Web Worker — die Dateibytes gehen an diesen Worker und sonst nirgendwohin.

Der Zuschnitt ist bewusst eng: eine Datei zur Zeit, nur lesende Anweisungen und eine Vorschau von höchstens 200 Zeilen. Genau das deckt die Aufgaben ab, für die so eine Seite aufgerufen wird — die Schemaprüfung vor einem Import, ein GROUP BY über einen exportierten Bericht oder ein erster Blick in eine Parquet-Datei, für die kein Desktop-Programm installiert ist — ohne dass dafür eine Datenbank aufgesetzt wird.

Wählen Sie unter Lokale Datendatei eine Datei aus und drücken Sie Ausgewählte Datei laden. Der Dialog akzeptiert .csv, .tsv, .json, .ndjson, .jsonl, .parquet und .txt, wobei eine .txt-Datei als kommagetrennte CSV gelesen wird. Sobald die Engine die Datei gelesen hat, nennt die Statuszeile sie: „orders.csv steht in der lokalen Tabelle data bereit. Führen Sie unten eine SELECT-Abfrage aus.“
Schreiben Sie eine Anweisung gegen data in das Feld, oder behalten Sie das voreingestellte SELECT * FROM data LIMIT 100. Mit Beispieldaten laden testen Sie das Werkzeug ohne eigene Datei: Es lädt vier Zeilen einer kleinen CSV (id, name, team, monthly_events) und eine GROUP-BY-Abfrage darauf, die drei Zeilen liefert.
Mit Abfrage ausführen läuft die Anweisung im Browser ab. Die Ergebnistabelle zeigt die Spaltennamen, die die Engine zurückgibt, und bis zu 200 Zeilen; die Leiste darüber nennt Datei, Spaltenzahl und die Zahl der Zeilen auf dem Bildschirm — ein Wert wie 200+ heißt, dass das Ergebnis länger war als die Vorschau.
Mit Sichtbares CSV exportieren speichern Sie genau die angezeigten Zeilen samt Kopfzeile als kivtools-query-results.csv; Abfrage zurücksetzen stellt die Standardanweisung wieder her und leert die Tabelle. Die Export-Schaltfläche bleibt gesperrt, bis eine Abfrage Zeilen geliefert hat.

Wo die Abfrage läuft, was das Werkzeug liest und woher die 200-Zeilen-Grenze kommt

Formate, die Tabelle data und die SELECT-Regel

CSV und TXT laufen über den CSV-Leser, TSV über denselben Leser mit Tabulator als Trennzeichen, JSON und NDJSON/JSONL über den JSON-Leser und Parquet über den Parquet-Leser; die Spaltentypen werden also aus der Datei abgeleitet und nicht von Ihnen vorgegeben. Alles landet in einer View namens data, und eine weitere geladene Datei ersetzt sie: Es gibt keine zweite Tabelle und keinen Join über zwei Dateien.

Akzeptiert werden nur Anweisungen, die mit SELECT oder WITH beginnen. DROP TABLE data und DELETE FROM data werden abgewiesen, bevor die Engine sie sieht, mit der Meldung „Zur Sicherheit führt Data Lab nur SELECT- und WITH-Abfragen aus.“ Ein einzelnes Semikolon am Ende ist in Ordnung, aber ein Klick führt eine Anweisung aus: SELECT 1; SELECT 2 endet in einem Parser Error, und eine nicht unterstützte Endung wie .xlsx wird mit einer Meldung abgelehnt, die die unterstützten Formate nennt.

Die 200-Zeilen-Vorschau ist eine Anzeigegrenze, keine Abfragegrenze

Was Sie eingeben, wird als SELECT * FROM (<Ihre Abfrage>) AS kivtools_visible_result LIMIT 201 ausgeführt, und die Seite stellt höchstens 200 der zurückgegebenen Zeilen dar. Fragen Sie eine 1.000-Zeilen-Parquet-Datei mit SELECT * FROM data ab, meldet die Statuszeile „200 Zeilen angezeigt (auf 200 begrenzt)“ und die Kennzahlen zeigen 200+; mit eigenem ORDER BY salary DESC LIMIT 5 erhalten Sie genau fünf Zeilen.

Sichtbares CSV exportieren schreibt das, was die Tabelle zeigt — eine Kopfzeile plus dieselben Zeilen, bis zu 200, mit CRLF-Zeilenenden — und nicht das vollständige Ergebnis; eine gruppierte Ausgabe mit fünf Zeilen ergibt daher fünf Datenzeilen. Für mehr müssen Sie in der Anweisung gruppieren oder zuschneiden: Die Vorschau ist zum Lesen gedacht, nicht zum Ausleiten ganzer Dateien.

Was eine fehlgeschlagene Abfrage verrät

Fehlertexte kommen von der Engine selbst und werden so angezeigt, wie sie eintreffen. Ein falsch geschriebener Spaltenname ergibt Binder Error: Referenced column “nope” not found in FROM clause! Candidate bindings: “name”, “monthly_events”; eine fehlende Tabelle ergibt Catalog Error: Table with name nowhere does not exist!; fehlerhafte Syntax ergibt einen Parser Error mit markierter Stelle; eine abgeschnittene Parquet-Datei ergibt Invalid Input Error: No magic bytes found at end of file.

Eine fehlgeschlagene Anweisung lässt das vorherige Ergebnis stehen und beschädigt die Sitzung nicht — die nächste Abfrage läuft normal, und die Datei bleibt geladen. Weil Fehler als Meldungstext erscheinen und nicht als kaputte Seite, können Sie eine Anweisung im Feld schrittweise verbessern, ohne die Seite neu zu laden oder die Datei erneut auszuwählen.

Geschwindigkeit, erster Download und Datenschutz

In Chrome war eine 6 MB große CSV mit 200.000 Zeilen nach etwa einer Viertelsekunde abfragbar, und ein GROUP BY sowie eine Fensterfunktion darauf kamen in derselben Größenordnung zurück; eine Parquet-Datei mit 1.000 Zeilen und 13 Spalten brauchte für den ersten Parquet-Lesevorgang ein paar Sekunden. Der erste Besuch der Seite lädt die Engine herunter — 34 MB WebAssembly plus Apache-Arrow-Module —, bevor die erste Abfrage läuft; spätere Besuche starten sie in etwa einer Sekunde aus dem Browser-Cache.

Ausgewählte Dateien werden im Tab gelesen: Die Bytes werden beim Web Worker registriert, der die Engine beherbergt, und weder Datei, eingegebene Anweisung noch Ergebniszeilen werden an VoriTools gesendet. Mit geöffnetem Netzwerk-Panel erzeugt eine Abfrage gegen eine geladene Datei überhaupt keine Anfrage. Die Kehrseite: Das Werkzeug kann keine Datei von einer URL holen, und eine Frage, die zwei Dateien braucht, muss in zwei Durchgängen beantwortet werden.

CSV, JSON und Parquet mit SQL abfragen