データ品質保証ツールとしてのDuckDB

タイミーでは、データウェアハウスとしてBigQueryを採用し、あらゆるデータを集約・統合することでデータ活用を推進しています。

データのユースケースによっては高い品質が求められるため、重複や欠損がないかなど、様々な観点からデータ品質テストを実施し、その保証に努めています。

特に、S3に保存されたParquetファイルをBigQueryへロードする際には、データが1行も欠損することなく完全に転送されることを保証する必要がありました。 これを実現するために S3上のParquetファイルとBigQueryテーブルのデータを突き合わせ、完全性を検証するデータテスト（完全性のテスト）で DuckDB を採用しました。

ツール導入前の課題

DuckDB 導入前のデータ完全性テストでは、転送前後のデータ比較において、計算コストの観点から統計量を比較する手法を主に採用していました。

この方法は全レコード・全カラムに対して欠損が全くないことを厳密に保証することが難しく、近似的な比較に留まっていました。

どのような状態を目指したか

上記の課題を解決するため、転送元と転送先のデータが完全に一致することを保証できる状態を目指しました。

具体的にはセル単位での厳密なデータ比較を実現し、データの完全性をより高い精度で担保できる状態を目指しました。

• Pandas

• 複数データソースへの対応: 異なるデータソース（例: S3上のParquet、BigQuery）に対して、同様のインターフェースでクエリを実行できること。
• パフォーマンス: 大量のデータに対しても、実用的な時間内で比較処理を実行できる高いパフォーマンスを有していること。
• クエリの簡潔性: データ比較のロジックを、SQLなどを用いて簡潔かつ直感的に記述できること。
• 実行環境の整備の容易さ: 依存関係が少なく、実行環境のセットアップやメンテナンスが容易であること。

最終的にDuckDBの採用を決定した主なポイントは以下の通りです。

複数データソースへのシームレスなアクセスとパフォーマンス

DuckDBは、S3上のParquetファイルやBigQueryのデータを扱う際に、高いパフォーマンスを維持しながら統一的なSQLでクエリを実行できる点が、今回のユースケースに非常にマッチしていました。

SQLによる簡潔な比較ロジック

EXCEPT 句など、標準的なSQL構文を用いることで、データ間の差分検出ロジックを非常に簡潔に記述できる点が魅力でした。

導入の手軽さ

シングルバイナリで動作し、依存モジュールのメンテナンスコストが低い点が、Pandasなどの他の候補と比較して優位でした。実行環境の整備が容易であることは、迅速な導入と運用負荷の軽減に繋がると判断しました。

改善したかった課題はどれくらい解決されたか

DuckDBを導入したことで、従来の統計量比較による近似的な保証しかできなかったデータ完全性テストの課題を解決できました。

S3上のParquetファイルとBigQueryテーブル間で、セル単位での厳密なデータ比較が可能となり、データの完全性を高いレベルで保証できるようになりました。

どのような成果が得られたか

• 厳密な完全性テストの実現: S3上のParquetファイルとBigQueryテーブル間で、セル単位での厳密なデータ比較が可能となり、データの完全性を高いレベルで保証できるようになりました。
• 複数データソースへの容易なアクセス: ローカルファイル、S3、GCSなど、データの保存場所に関わらず、read_parquet()関数のような統一的な方法でデータを読み込めるため、生産性高く開発できました。
• 高いパフォーマンスと安定性: 100GB程度のParquetファイルの完全性テストが、I/O処理を含めて10分以内に完了するなど、非常に高いパフォーマンスで安定して実行できています。これにより、デイリーでのデータ転送時など、頻繁なチェックにも対応可能となりました。

BigQuery Community Extensionの挙動

当初、DuckDBのBigQuery Community Extensionを利用してBigQueryに直接クエリを実行することを試みましたが、一部の文字列型のフィールドでカラムが正常に読み取れない事象が発生しました。 エラーメッセージが明確ではなく原因特定が難航したため、今回のケースではこのExtensionの利用は見送りました。

代替案として、BigQueryからGCSにParquetファイルとしてエクスポートし、そのファイルをDuckDBで読み込む方式を採用しました。

今回のデータ完全性テストでの成功体験を踏まえ、今後DuckDBの活用を以下のように広げていきたいと考えています。

• 他のデータテストへの展開: 完全性テスト以外にも、一意性テスト、有効性テスト、整合性テストなど、様々なデータ品質に関わるテストのエンジンとしてDuckDBの利用を検討していきたいです。
• 更新頻度の低い大規模なデータの分析用途: 2025年3月にDuckDB UI機能がリリースされて、よりユーザーフレンドリーにデータを扱えるようになりました。静的だが大量データの手元での分析と相性がよさそうなので、有用性を検証していきたいです。