ByteScope

Parquet Viewer

Pythonなしで .parquet を開く。スキーマと先頭行がすぐ見えて、そのままSQLを実行し、CSVに書き出せます。ファイルはディスクから読むだけで、アップロードはされません。

ファイルはディスクから直接読み込まれ、アップロードされません。解析も SQL クエリもすべてこのタブ内で完結します。ダウンロードされるのは DuckDB エンジンだけで、最初のクエリ時に取得します。

Parquet ファイルをここにドロップ

Parquet、Avro、Arrow IPC、JSON Lines に対応。クリックして選ぶこともできます。

このツールについて

同僚から .parquet ファイルが送られてきて、中身をちょっと確かめたいだけ — どんな列があって、型は何で、行数はどのくらいで、最初の数件はどう見えるのか。普通ならJupyterを立ち上げて pyarrow や pandas を読み込み、30秒で済む疑問のために数分の準備をすることになります。このページはその場面のための Parquet ビューアです。ファイルを放り込めばスキーマ・行グループ・プレビューが並び、集計が必要ならその場でSQLを打てます。.jsonl / .ndjson、Arrow IPC ファイル(.arrow、.feather)、.avro も開けます(一度に1ファイル)。CSVの場合は CSV Explorer をお使いください。

エンジンを読み込む前に見えるもの

Parquet は目次にあたる情報をファイル末尾のフッターに持っているので、このページはその最後の部分 — 512 KB ほど — だけを読み、10 MB でも 1 GB でもスキーマを即座に表示します。見られるのは、各列の名前・物理型・論理型(TIMESTAMP(MICROS, UTC)、DECIMAL(18,2)、ネストした struct / list / map)、null 許可かどうか、総行数、行グループごとの行数とバイト数、列ごとの圧縮コーデック(SNAPPY、ZSTD、GZIP など)、使われているエンコーディング、圧縮前後のサイズと圧縮率、書き込み側が残していれば min/max と null 数の統計、created_by の文字列、そして pandas や Spark のスキーマ JSON といった key/value メタデータ(開くまで折りたたみ)です。続いて先頭 1,000 行のプレビューが仮想テーブルに流れ込みます。ネストした値は JSON として展開でき、タイムスタンプは単位に応じた桁数(ミリ秒は3桁、マイクロ秒は6桁、ナノ秒は9桁)で、UTC 調整済みの列なら末尾に Z を付けて表示します。decimal は浮動小数点を経由せず正確な値のまま、バイナリ列は先頭 32 バイトの16進で表示します。

ブラウザ内で SQL

クエリバーは DuckDB-WASM(DuckDB 1.4)で動きます。初めて SQL を実行するときに約 7 MB のエンジンをダウンロードし、次回以降はブラウザのキャッシュから読み込まれます。Parquet と JSON の拡張はこのサイトから配信しています。ファイルは常にテーブル t として見えるので、既定のクエリは SELECT * FROM t LIMIT 100 です。テンプレートから SUMMARIZE t、count(*)、列ごとの null 比率、ある列の上位 N 件をワンクリックで呼び出せます。結果には所要時間と行数が表示され、画面に保持されるのは最大 10,000 行なので、それ以上が必要なら LIMIT を付けるかエクスポートしてください。結果は CSV か JSONL として 1 回あたり最大 1,000,000 行まで書き出せます(それを超えて切り詰めたときはページが知らせます)。Parquet を開けない相手に CSV で渡すには、これが一番早い方法です。実行中のクエリは Stop ボタンで止められ、エンジンのエラーは言い換えずそのまま表示します。数千万行・1 GB のファイルでも count(*) はメタデータから読むので一瞬、1 列の GROUP BY や全列の SUMMARIZE は数秒から数十秒です。ファイルは必要な部分だけを読み、丸ごとメモリに載せることはありません。

正直な制限

エンジンは CPU 1 コアで動きます。このサイトではブラウザのマルチスレッドモードを有効にできないためで、大きな GROUP BY や join は同じマシンのデスクトップ版 DuckDB よりはっきり遅くなります。メモリはブラウザの制限 — 32 ビット WebAssembly ヒープでおよそ 4 GB — に縛られるので、巨大なソートや join は失敗することがあり、その場合はエンジン自身のエラーが表示されます。モジュラー暗号化された Parquet は開けません。Iceberg や Delta Lake は Parquet の上に乗るテーブル層で、ここでは解釈しません。開けるのはデータファイル単体で、テーブルのディレクトリではなく、複数ファイルの選択もまだ非対応です。Arrow IPC と Avro は現時点ではスキーマとメタデータのみで、行プレビューと SQL はありません。古い Spark がオーバーフロー付きで書いた INT96 タイムスタンプは、日付ではなくエポックからのナノ秒数として表示されることがあります。15 桁を超える DECIMAL の min/max 統計は近似値で、≈ 印が付きます。Parquet への書き出しはまだなく、結果は CSV か JSONL で出ます。

プライバシー

ファイルは File.slice でディスクから直接読みます。何もアップロードされず、データもクエリもブラウザの外に出ません。外部への通信は、初回の SQL 実行時に公開 CDN の cdn.jsdelivr.net から DuckDB エンジンのコードを取得する 1 回だけで、以後はキャッシュされます。

よくある質問

Python なしで Parquet ファイルを開くには?

このページにドロップするだけです。スキーマ・行グループ・コーデック・統計・メタデータがフッターから即座に表示され、先頭 1,000 行がスクロールできる表に読み込まれます。pyarrow もノートブックもインストールも不要で、ファイルはあなたのディスクから読まれるのでアップロードもされません。

ファイルはどこかにアップロードされますか?

いいえ。ブラウザが File.slice でファイルを読み、フッターの解析も行のプレビューも SQL の実行も、すべてタブの中で行われます。ダウンロードされるのは DuckDB エンジン本体(約 7 MB)だけで、初めてクエリを実行したときに公開 CDN から取得します。データもクエリもお使いのマシンから出ていきません。

最初の SQL で約 7 MB をダウンロードするのはなぜ?どこから?

スキーマとプレビューにはエンジンが要りませんが、SQL は WebAssembly にコンパイルした DuckDB が実行します。そのコードが約 7 MB あり、初めて Run を押したときに公開 CDN の cdn.jsdelivr.net から取得して、以降の訪問のためにブラウザがキャッシュします。Parquet と JSON の拡張はこのサイトから配信します。ダウンロードされるのはエンジンだけで、ファイルがどこかへ送られることはありません。

大きな GROUP BY が手元の DuckDB より遅いのはなぜ?

デスクトップ版 DuckDB は搭載コアすべてに処理を分散します。ここではエンジンが 1 コアで動きます。このサイトではブラウザのマルチスレッド WebAssembly モードを有効にできないためです。単純なスキャンや、メタデータから読む count(*) は速いのですが、数千万行に対する重い GROUP BY・ソート・join は、その何分の一かではなく数秒から数十秒かかります。

Parquet を CSV に変換するには?

ファイルを開いて SELECT * FROM t のようなクエリを実行し、結果を CSV としてエクスポートします。1 回の書き出しは最大 1,000,000 行で、それより大きい結果はそこで切り詰められ、ページがその旨を表示するので、WHERE や LIMIT で分割して書き出してください。JSONL のエクスポートも同じ手順です。Parquet への書き戻しはまだできません。

Iceberg や Delta Lake のテーブルを丸ごと開けますか?

いいえ。Iceberg と Delta Lake は多数の Parquet ファイルを束ねるメタデータ層で、このページは一度に 1 つのデータファイルを開くだけで、テーブルのマニフェストは読みません。テーブルのフォルダから個々の .parquet ファイルを選べば、そのスキーマと行を確認できます。複数ファイルの選択もまだ非対応です。

Arrow、Feather、Avro のファイルにも対応していますか?

スキーマとメタデータについては対応しています。Arrow IPC ファイル(.arrow、.feather)や .avro をドロップすれば列名と型が表示されます。これらの形式では、行のプレビューと SQL は今のバージョンでは使えません。JSONL / NDJSON はフル対応で、先頭行からスキーマを推定し、プレビューも SQL も使えます。

タイムスタンプがエポックからのナノ秒数で表示されるのはなぜ?

古い Spark はオーバーフローしうる INT96 タイムスタンプを書き出していて、そうした値は信頼できる日付に変換できないため、ページは推測せず生の数値を表示します。正しく書かれたタイムスタンプは単位ごとの固定桁数 — ミリ秒 3 桁、マイクロ秒 6 桁、ナノ秒 9 桁 — で表示され、UTC 調整済みの列には Z が付きます。