Findy株式会社のEL PipelineにおけるDuckDBの活用事例

ツール導入前の課題

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

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

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

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

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

• Datastream
• TROCCO Self Hosted Runner
• Fivetran

• データ量が小さいため、なるべく軽量な実装が可能なこと
• ニアリアルタイム処理は不要であること
• 料金を抑えられること

• 実装の容易さ
• 拡張性の高さ
• 費用の安さ

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

全て解決できました。

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

メンテナンスがされているソフトウェアに移行したことで、セキュリティリスクの低減ができました。

また、テーブル同期を直列から並列に変更したため、単純比較はできないものの、3倍程度の高速化を達成しました。

検証(PoC)で苦労しました。DuckDBのプラグイン側のアーキテクチャの制約で起動失敗したり、バグを踏んだりしました。ドキュメントの精読やメンテナへの質問で一つ一つ解決しました。

DuckDBは実装が簡単で、様々なデータソースと接続できるため、データコネクタとして十分活用できます。

一方で、日本語文献は少なく、新興ソフトウェア特有の課題もあるため、一定のエンジニアリング力が要求されることに注意すると良いでしょう。

新規事業が次々と誕生しているため、活用事例は増えると想定しています。現状は、RDS to BigQueryのみの実装ですが、コネクタを増やす案も出ており、活用の幅が広がる可能性があります。