Share
Embed
Slide 1
Slide 1 text
2025/02/27 Yu Nakamura - chanyou
データエンジニアリング領域における
DuckDBのユースケース
@chanyou0311
Slide 2
Slide 2 text
Yu Nakamura - chanyou
● スタートアップでデータエンジニアとして交通データ分析基盤
の構築‧運⽤を経験
● その後、株式会社タイミーの DRE チームにジョイン
データ基盤の構築‧運⽤に注⼒
● 最近はデータ基盤における Platform Engineering に関⼼があり
ます
● 広島在住。趣味はおうち Kubernetes クラスタ
● YAPC::Hiroshima 2024 のスタッフなど
Slide 3
Slide 3 text
タイミーとは
3
｢働きたい時間｣と｢働いてほしい時間｣を
マッチングするスキマバイトサービス
従来の「求⼈サイト」でも「派遣」でもない
Slide 4
Slide 4 text
タイミーの実績
スキマ
バイト
No.1
※1 ※2 [調査⽅法]インターネット調査 [調査期間]2025年1⽉31⽇〜2025年2⽉4⽇ [調査概要]スキマバイトアプリサービスの
実態調査 [調査委託先]株式会社マクロミル
※3 2024年12⽉時点 ※4 2024年12⽉時点
利⽤率 ‧リピート率
※1 ※2
導⼊事業者数
159,000企業
ワーカー数
1,000万⼈
※4
※3
Slide 5
Slide 5 text
目次
● DuckDB の特徴
● データエンジニアリング領域における
DuckDB の評価
● タイミーにおけるユースケース
● その他に想定されるユースケース
Slide 6
Slide 6 text
1 DuckDB の特徴
Slide 7
Slide 7 text
DuckDB とは？
● OLAP 特化の DB Engine
● SQLite のようなインプロセス型のデータベース
● MIT ライセンスで C++ 実装
Slide 8
Slide 8 text
DuckDB の特徴
● シングルバイナリでセットアップが容易
● クライアントAPIが充実
● 外部データソースの読み書きに対応
Slide 9
Slide 9 text
シングルバイナリでセットアップが容易
● セットアップスクリプトを実⾏するだけ
● バイナリをダウンロードしてパスを通してもよい
https://duckdb.org/docs/installation/index?version=stable&environment=cli&platform=linux&download_method=direct&architecture=x86_64
Slide 10
Slide 10 text
シングルバイナリでセットアップが容易
● duckdb <データベースファイルパス> で起動できる
● ファイルパスを省略すると、インメモリモードで起動する
Slide 11
Slide 11 text
クライアントAPIが充実
● CLI
● C
● Java
● Go
● Node.js
● Python
● R
● WebAssembly
他にも Dart, Rust, Ruby などのクライアントAPIも公開されている
Slide 12
Slide 12 text
Python の場合 DataFrame と相互変換が可能
● クエリ結果を Pandas や Polars の DataFrame に変換できる
● DataFrame に対して DuckDB でクエリを実⾏することも可能
https://duckdb.org/docs/clients/python/overview
Slide 13
Slide 13 text
外部データソースの読み書きに対応
● PostgreSQL や MySQL といった RDBMS に直接クエリを実⾏できる
● CSV, Parquet, Delta, Iceberg といったファイルにクエリを実⾏できる
https://duckdb.org/docs/data/parquet/overview.html https://duckdb.org/docs/extensions/postgres.html
Slide 14
Slide 14 text
外部データソースの読み書きに対応
● S3, GCS, Blob Storage などのオブジェクトストレージに直接クエリを
実⾏できる
https://duckdb.org/docs/extensions/httpfs/s3api.html
Slide 15
Slide 15 text
DuckDB の特徴
● シングルバイナリでセットアップが容易
● クライアントAPIが充実
● 外部データソースの読み書きに対応
Slide 16
Slide 16 text
2 データエンジニアリング領域における
DuckDB の評価
Slide 17
Slide 17 text
DuckDB の Good な点
● 🚀 ⼤量データでも⾼いパフォーマンスで実⾏できる
● 🧰 幅広いデータ形式の読み込みに対応している
● 💰 データ量に依存したクエリ料⾦がかからない
● 🤝 dbt アダプタなど、周辺エコシステムとの親和性が⾼い
Slide 18
Slide 18 text
DuckDB の More な点
● 👮 きめ細かなアクセス制御‧監査ログの取得が難しい
● 💥 DuckDB のデータベースファイルを SSoT として運⽤しようとすると、
途端に破綻する
Slide 19
Slide 19 text
👮 きめ細かなアクセス制御‧監査ログの取得が難しい
● テーブルレベル、⾏レベル、列レベルのアクセス制御が DuckDB 単体では
できない
● 動的なマスキングも難しい
● 監査ログの取得もクライアントの設定次第で、強制が難しい
Slide 20
Slide 20 text
💥 SSoT として運⽤しようとすると、途端に破綻する
● ⽇々更新されるデータベースファイルをリモートで保持する必要がある
○ クライアントでクエリを実⾏するには、ダウンロードが必要
○ 定期的に pull しないとクエリ結果が変わってしまう
Slide 21
Slide 21 text
💥 SSoT として運⽤しようとすると、途端に破綻する
● 分析結果を他⼈に共有しようとすると、さらに煩雑に…
● やがて 20250227_最新版.duckdb といったファイルが⽣まれ、統制の効かないデータ基盤
に…😱
○ 「爆速なExcel」といった位置付けになってしまう
Slide 22
Slide 22 text
データエンジニアリング領域における
DuckDB の位置付けは？
Slide 23
Slide 23 text
データエンジニアリング領域における DuckDB
● これまでの中央集権的なデータウェアハウスを完全に代替するものではない
○ アクセス制御も監査ログも必要だし、容易なコラボレーションも推進し
たい
● 永続性を求めないケースでの相性がよい
○ オブジェクトストレージへのクエリエンジン
○ データの前処理や検証
Slide 24
Slide 24 text
オブジェクトストレージへのクエリエンジン
● オブジェクトストレージに Parquet や Iceberg 形式でデータを保持しておい
て、DuckDB でクエリを実⾏する
● 必要に応じてクエリ結果をオブジェクトストレージに書き戻すこともできる
Slide 25
Slide 25 text
オブジェクトストレージへのクエリエンジン
● 類似ソリューション
○ AWS Athena や BigQuery Omni など
■ 🦆 クラウドにロックインされず、どこでも実⾏できる
○ Pandas などの DataFrame
■ 🦆 Python 実⾏環境が不要で、⼿軽に実⾏できる
Slide 26
Slide 26 text
データの前処理や検証
● データの前処理
○ 複雑な結合‧重複排除
● データの検証
○ データの完全性‧⼀意性‧最新性の検証
● スクリプト内部に閉じた利⽤が想定される
● スクリプト実⾏後にデータが揮発しても問題ない
Slide 27
Slide 27 text
3 タイミーにおける
ユースケース
Slide 28
Slide 28 text
シチュエーション
● S3 に保存された Parquet ファイルを BigQuery にロードするケース
● ロードする前後のデータが完全に⼀致することを保証したい
DuckDB を使って前後のデータの差分が1件もないことを検証した
Slide 29
Slide 29 text
データの⽐較⽅法
● S3 のファイルの読み込みは read_parquet() 関数ですぐ読み込める
● BigQuery はロード後のテーブルを GCS に Parquet 形式でエクスポートして
から read_parquet() で読み込む
○ DuckDB から BigQuery に直接クエリできる Community Extension もあるが、⼀部のフィールドでうまく
クエリできない問題があって⾒送った
● データの⽐較は EXCEPT 句で実⾏できる
Slide 30
Slide 30 text
実装イメージ
異なるデータソースでも1回のクエリで結合できて便利
Slide 31
Slide 31 text
4 その他に想定される
ユースケース
Slide 32
Slide 32 text
データの検証‧スクリプト内での利⽤
● レコードの⼀意性のチェック
● テーブルの鮮度のチェック（最新レコードの⽇時と現在時刻の⽐較）
dbt でも実施できるが、 dbt に依存しない⼿軽な実⾏環境として採⽤できる
Slide 33
Slide 33 text
データの前処理による料⾦コストの削減
● ⽣データをDWHにロードしてからデータを加⼯する ELT パターンが主流
○ ⼤規模になるにつれて Transform のクエリコストがかさみがち
Slide 34
Slide 34 text
データの前処理による料⾦コストの削減
● DuckDB を使うと安価なコンピュータ上でデータの前処理や結合をしてから
DWHにロードする構成が取れる
○ 例）⼤量のログデータから分析対象だけWHEREで絞ってDWHにロードする
○ 例）DWHはBI⽤のマート層だけ保持するようにして、それより前は全部DuckDB
にやらせる
Slide 35
Slide 35 text
ひとりアナリストのデータ基盤として
● データの管理と分析を1名で⾏っている場合は DuckDB の⼿軽さがフィットしそう
○ 分析チームの⽴ち上げフェーズなど
● データの管理者と分析者が分かれたり、複数⼈で分析を⾏うようになると
コラボレーションのハードルが⼀気に⾼くなる
● この場合、DuckDB は「爆速なExcel」といった認識で使うのが良さそう
○ その場限りのローカル分析環境として
Slide 36
Slide 36 text
5 まとめ
Slide 37
Slide 37 text
まとめ
● DuckDB を使うと、データの置き場所や形式を問わずクエリできる
○ 場所や形式を横断したクエリもサクッと実⾏できる
● ガバナンスやコラボレーションを意識した使い⽅は現状難しい
○ 分析⽬的で広く社内で使ってもらうのにはハードルがある
● 永続性を求めないケースでの相性がよい
○ オブジェクトストレージへのクエリエンジン
○ データの前処理や検証
Slide 38
Slide 38 text
https://hrmos.co/pages/timee/jobs/1682251404118319115
データ基盤を通して、プロダクトと組織の成⻑を⼀緒に⽀えましょう！
We're hiring!