Comment exécuter une requête SQL sur un fichier local

Chargez un fichier CSV, TSV, JSON, NDJSON ou Parquet, puis interrogez-le en SQL : la page confie le fichier à un moteur DuckDB qui s’exécute dans l’onglet, l’expose comme la table data et affiche le résultat de votre instruction SELECT ou WITH dans un tableau exportable. Le moteur est DuckDB-Wasm 1.32.0 dans un Web Worker — les octets du fichier vont à ce worker et nulle part ailleurs.

Le périmètre est volontairement étroit : un fichier à la fois, des instructions en lecture seule et un aperçu de 200 lignes au maximum. C’est ce qu’il faut pour les usages habituels d’une telle page — vérifier un schéma avant d’importer un dump, faire un GROUP BY sur un rapport exporté ou jeter un premier coup d’œil à un Parquet sans lecteur installé — sans monter une base de données.

Choisissez un fichier sous Fichier de données local puis cliquez sur Charger le fichier sélectionné. Le sélecteur accepte .csv, .tsv, .json, .ndjson, .jsonl, .parquet et .txt, un fichier .txt étant lu comme un CSV séparé par des virgules. Une fois le fichier lu par le moteur, la ligne d’état le nomme : «orders.csv est prêt dans la table locale data. Exécutez une requête SELECT ci-dessous.»
Saisissez une instruction sur data dans la zone, ou gardez la valeur par défaut SELECT * FROM data LIMIT 100. Le bouton Charger des exemples de données charge quatre lignes d’un petit CSV (id, name, team, monthly_events) et une requête GROUP BY qui renvoie trois lignes, pour essayer l’outil sans fichier.
Cliquez sur Exécuter une requête : l’instruction s’exécute dans le navigateur. Le tableau affiche les noms de colonnes renvoyés par le moteur et jusqu’à 200 lignes, et la bande au-dessus indique le fichier, le nombre de colonnes et les lignes à l’écran — une valeur comme 200+ signale un résultat plus long que l’aperçu.
Exporter le CSV visible enregistre exactement les lignes affichées, en-tête compris, sous le nom kivtools-query-results.csv ; Réinitialiser la requête rétablit l’instruction par défaut et vide le tableau. Le bouton d’export reste inactif tant qu’une requête n’a pas renvoyé de lignes.

Où tourne la requête, ce que l’outil lit et d’où vient la limite de 200 lignes

Formats, table data et règle du SELECT uniquement

CSV et TXT passent par le lecteur CSV, TSV par ce même lecteur avec une tabulation comme séparateur, JSON et NDJSON/JSONL par le lecteur JSON et Parquet par le lecteur Parquet : les types de colonnes sont donc déduits du fichier et non déclarés par vous. Tout arrive dans une vue nommée data, et charger un autre fichier la remplace — il n’y a pas de seconde table ni de jointure entre deux fichiers.

Seules les instructions commençant par SELECT ou WITH sont acceptées. DROP TABLE data et DELETE FROM data sont refusés avant même d’atteindre le moteur, avec le message «Par sécurité, Data Lab exécute uniquement des requêtes SELECT et WITH.» Un point-virgule final isolé ne gêne pas, mais un clic exécute une seule instruction : SELECT 1; SELECT 2 se termine par une Parser Error, et une extension non prise en charge comme .xlsx est refusée avec un message qui liste les formats acceptés.

L’aperçu de 200 lignes est une limite d’affichage

Ce que vous saisissez est exécuté sous la forme SELECT * FROM (<votre requête>) AS kivtools_visible_result LIMIT 201, et la page dessine au plus 200 des lignes renvoyées. Demandez SELECT * FROM data sur un Parquet de 1 000 lignes : la ligne d’état affiche «200 lignes affichées (limité à 200)» et les compteurs indiquent 200+. Avec votre propre ORDER BY salary DESC LIMIT 5, vous obtenez exactement cinq lignes.

Exporter le CSV visible écrit ce que montre le tableau — une ligne d’en-tête et ces mêmes lignes, jusqu’à 200, avec des fins de ligne CRLF — et non le résultat complet : un résultat groupé de cinq lignes produit cinq lignes de données. Pour aller plus loin, agrégez ou découpez dans l’instruction : l’aperçu sert à lire, pas à extraire tout un fichier du navigateur.

Ce qu’une requête en échec vous apprend

Les messages d’erreur viennent du moteur lui-même et s’affichent tels quels. Une colonne mal orthographiée donne Binder Error: Referenced column “nope” not found in FROM clause! Candidate bindings: “name”, “monthly_events” ; une table absente donne Catalog Error: Table with name nowhere does not exist! ; une syntaxe cassée donne une Parser Error avec la position marquée ; un Parquet tronqué donne Invalid Input Error: No magic bytes found at end of file.

Une instruction en échec laisse à l’écran le résultat précédent et n’abîme pas la session : le clic suivant sur Exécuter une requête fonctionne normalement et le fichier reste chargé. Comme les échecs arrivent sous forme de texte et non de page cassée, vous pouvez corriger l’instruction dans la zone sans recharger la page ni rechoisir le fichier.

Vitesse, premier téléchargement et confidentialité

Dans Chrome, un CSV de 6 Mo contenant 200 000 lignes est devenu interrogeable en un quart de seconde environ, et un GROUP BY comme une fonction de fenêtrage sur ce fichier ont répondu dans le même ordre de grandeur ; un Parquet de 1 000 lignes et 13 colonnes a demandé quelques secondes lors de sa première lecture. La première visite télécharge le moteur — 34 Mo de WebAssembly plus les modules Apache Arrow — avant la première requête, et les visites suivantes le démarrent depuis le cache du navigateur en une seconde environ.

Les fichiers choisis sont lus dans l’onglet : les octets sont enregistrés auprès du Web Worker qui héberge le moteur, et ni le fichier, ni l’instruction saisie, ni les lignes du résultat ne partent vers KivTools. Panneau réseau ouvert, exécuter une requête sur un fichier chargé ne produit aucune requête réseau. La contrepartie : l’outil ne peut pas récupérer un fichier depuis une URL, et une question qui demande deux fichiers se traite en deux passes.

Interroger CSV, JSON et Parquet en SQL