DuckDB as a Pipeline: Findyデータ基盤におけるDuckDBの活用事例

この記事は「ファインディエンジニア #1 Advent Calendar 2025」の24日目の記事です。

沢山のアドベントカレンダー記事が執筆されていますので、年末のお供に是非読んでみてください。

はじめに

ソフトウェアエンジニアの土屋(@shunsock)です。私の所属するデータソリューションチームでは、ファインディ全体のデータ活用を推進するためのデータ基盤を構築しています。

今回、我々はデータ基盤のRDSとBigQueryのテーブル同期システム (EL Pipeline) のリプレースを行い、DuckDBを本番導入しました。本稿では、活用に至った経緯と実際に組みこむにあたる課題、および成果を紹介します。

はじめに
ファインディにおけるテーブル同期システムの立ち位置
リプレイスの背景
- 補足
技術選定
システム設計
- 概要
  - CLIを挟む理由
  - GitHub Actionsからの起動にした理由
- 複数のRDSを転送する
開発運用と成果
開発・運用してみた感想
- 可読性と拡張性が高い
- とはいえまだまだ新興のソフトウェア
まとめ

ファインディにおけるテーブル同期システムの立ち位置

ファインディでは、ウェブアプリケーションをAWS上のECSとRDS、データ基盤をGoogle CloudのBigQueryで作成しています。

このような構成を取っているため、AWSのRDSとGoogle CloudのBigQueryを同期してテーブルを最新にする必要があります。

次の図は、Findy Tools事業部における、現在のデータフローの概念図です。AWS上に存在するRDSのデータをBigQueryに転送していることが分かります。

リプレイスの背景

弊社では従来、OSSのEL(Extract Load) ツール Embulk をECSに載せて長期間運用していました。弊社で利用しているRDBMSやデータウェアハウスに対応している他、社内に知見を持った方が在籍しているためです。

しかし、近年では、 Embulkのエコシステムのレガシー化や長期的なメンテナが不足が課題 となっています。特に、 将来のメンテナンスが不透明な点は、セキュリティインシデントに繋がりかねない ため危惧していました。

また、 Embulkの起動の遅さも課題 にしていました。我々はBigQueryプラグインなどを利用していたため、JVM上でさらにJRuby VMを立ちあげます。このような構成は テーブル同期の遅さに繋がり、ECSの課金額を増やす要因 となっていました。

このように、システムを堅牢にすることと処理スピード向上による料金のコストダウンが今回のプロジェクトの目的でした。

補足

Embulkのメンテナーの方も「オープンソース・プロジェクトのたたみ方」というブログ記事で脆弱性について次のように述べています。

おそらくいくつかの攻撃は既に成功していて、私たちのソフトウェア・サプライチェーンには、悪意のあるコードがとっくに入り込んでいる、と認識しておくべきでしょう。

技術選定

Datastream, Spark, その他 ELTツールなど、複数の移行先候補がありました。その中で、データ規模に応じて次の2つから選定することにしました。

Datastream: ニアリアルタイムでの更新が欲しい場合や大規模データの場合
DuckDB: 小規模データの場合

Datastream

Datastream は Google Cloudが提供するサーバーレスのCDC (Change Data Capture), Replicationツールです。

CDCは、あるソースのシステムを監視し、そのシステムに対する操作をニアリアルタイムで、ターゲットとなるシステムに反映する仕組みのことです。これによりAWSのRDSに対する変更を即座にBigQueryに反映可能です。

DuckDB

DuckDBは高速なアナリティカルデータベースです。s3などのストレージサービスに出力されたログ分析やファイルフォーマットの変換、wasmによるフロントエンドでの活用など広い用途で活用されています。

接続先や出力フォーマットが非常に豊富な他、C++製のマルチスレッドランタイムにより、高速に動作する点が魅力です。

次の写真はDuckDBのPoC時に行なったベンチマークです。小さなテーブルで転送を試したところ、1.5倍程度の高速でした。

ソフトウェア名称	平均	標準偏差	最速	最遅
Embulk	253秒	8秒	242秒	261秒
DuckBD	176秒	30秒	137秒	209秒

補足: 実際にパフォーマンステストを行ったときの様子

Datastream, DuckDB両採用の理由

今回のリプレイスでは、コスト最適化を軸に Datastream と DuckDB の2種類のアプローチを使い分ける構成を採用しました。

DatastreamはフルマネージドでサーバーレスなCDCサービスと強力です。一方で、ニアリアルタイム性が不要な小規模データに対しては機能過多となり、費用面でも割高になります。そこで、リアルタイム性を求めない領域では、より軽量でシンプルに扱えるDuckDBを使って同期を行う方針を取りました。

本記事の以降では、上記のうち、DuckDBによってどのようにテーブル同期システムを構築したか、開発運用で見えた知見を説明します。

システム設計

概要

次の画像は我々のDuckDBによるテーブル同期システムの概念図です。

次のように各種ソフトウェアが起動します。

GitHub Actionsのon_schedule でワークフローが起動
ワークフローがECS Fartate Taskを起動
Fargate Taskがコンテナランタイムを起動
コンテナランタイムの中でCLIアプリケーションが起動
CLIアプリケーションが引数と設定ファイルからSQLを生成
CLIアプリケーションがDuckDBでSQLを実行

CLIを挟む理由

DuckDBを直接起動しない理由は、1回の実行で1テーブルずつ送信できるようにするためと、SQLを直接書かずに設定ファイルをインターフェースにするためです。

実際のユーザーの入力インターフェースは次のようなYAMLです。

dataset_id: lake...
table_name: table_name
select_statement: "hoge, fuga, ..."

GitHub Actionsからの起動にした理由

元々のワークフローはEventBridge Schedulerだったのですが、システム障害時にEventBridgeのcronを変更するなど運用負荷が重い状態でした。DispatcherをGitHub Actionsにすることでボタン操作だけで検証可能にしました。

また、1テーブルずつの送信にしたので、ステージング環境での動作検証も簡単かつ軽量です。ユーザーは次のようなWorkflow Dispatchを起動するだけで動作検証が完了します。

複数のRDSを転送する

現在のFindy Tools事業部のワークフローを見ると分かる通り、複数のRDSを転送する必要がありました。そこで開発用スクリプトを汎用化して動的なビルドやawsコマンドの発火をしています。

開発運用と成果

開発は、私1人で1か月弱でしました。最初の1プロジェクトこそ時間がかかったものの、モノレポ構成にしたおかげで従来1か月かかった新規データソースの追加が1週間程度になりました。

処理速度については、直列稼動から並列稼動へ変更となったため単純な比較は難しいのですが、1テーブルあたり約30秒から約10秒に短縮できました。

すでに他のメンバーからもプルリクエストが届いており、社内でも手応えのある反応を得ています。

開発・運用してみた感想

可読性と拡張性が高い

今回作成したCLIでは次のようなSQLを生成しています。高い拡張性や可読性が良いと改めて感じました。

INSTALL mysql;
LOAD mysql;
ATTACH '' AS mysqldb (TYPE mysql); -- 環境変数から取ってくる
CREATE TABLE users AS
SELECT *
FROM mysqldb.table_name;

INSTALL bigquery FROM community;
LOAD bigquery;
ATTACH '' as bq (TYPE bigquery);
DROP TABLE IF EXISTS bq.lake__system_name.table_name;
CREATE TABLE bq.lake__system_name.table_name AS SELECT * FROM table_name;
DROP TABLE table_name;