■ 1. 本稿の目的
- スケールアップモデルの主流化:
- スケールアウトを前提としたデータ処理システムから、シンプルで効率的なスケールアップモデルへ主流が移り得る
- DuckDBはその先駆けとなる存在
- 対象読者:
- システム設計や運用コストの最適化を検討するソフトウェアアーキテクト
- アプリケーションデータやログデータなど様々なデータセットを効率的に処理したいデータエンジニア
- クラウドコスト削減や効率的なデータ処理システムを模索するシステム管理者、運用者
- 従来モデルとの対比:
- BigQueryやRedshiftに代表されるスケールアウトモデルは複雑なクラスター構成と管理を要し、費用と運用負荷が増大する
- DuckDBは比較的運用コストの低いシングルノードで動作し、非常に高速なデータ処理を提供する
■ 2. スケールアウトモデルの台頭
- Googleによるスケールアウト革命:
- 2000年代初頭、増加するWebサイト数に対応する検索エンジンを構築するためシステム設計を抜本的に改善した際に発明された
- 高価で高性能なハードウェアではなく、安価で一般的な性能のハードウェアを大量に用い、ソフトウェアで高いスケーラビリティを実現する
- 現在のシステム設計への影響:
- 2024年時点で本格的な実行アーキテクチャを設計する場合、スケールアウトによる拡張性や弾力性は重要なアーキテクチャ特性
- BigQuery、Dataflow、Redshift、Amazon Managed Service for Apache Flinkなど、マネージドサービスにも多く採用されている
■ 3. スケールアウト普及に伴う課題
- 設計と開発の難しさ:
- 複数のハードウェア上でスケールアウト可能な処理の設計やシステムの開発が難しい
- 運用の難しさ:
- 処理をスケールアウトさせるとデータ整合性担保、実行ステータス監視、エラー対応が難しい
- 結果として2024年時点のソフトウェア開発は処理の複雑化や運用負荷の増大に直面している
- 課金体系による制約:
- BigQueryやRedshiftなど一部のクラウドマネージドサービスはスキャンしたデータ量に応じて料金が発生する
- 一処理あたりの費用を考慮しながらクエリを実行しなければならない
■ 4. スケールアップモデルへの回帰
- ムーアの法則によるハードウェア性能改善:
- 1965年に提唱されたムーアの法則のとおり、半導体の性能は指数関数的に向上してきた
- スケールアウトモデルが発明された2000年代初頭からの20数年間で、トランジスタ密度は1000倍に増加した
- 2002年当初は数千台のハードウェアを必要とした処理が、2020年時点ではわずか1台で実現可能となった
- 仮想化技術の発展:
- 2000年代初頭から普及した仮想マシンに加え、コンテナやサーバレスといった仮想化技術も2024年時点では広く一般化している
- パブリッククラウドの普及により、これらを駆使した様々なタイプのコンピューティングリソースが誰でも簡単に調達可能となった
- 高性能なハードウェアであっても、必要な時に必要な分だけ現実的な価格で効率的に利用できる
- 最適解の再考:
- ハードウェアの性能改善を踏まえ、自身のシステムにとってスケールアウトモデルが本当に最適解なのかを考え直す時が来た
- 1台の高性能なハードウェア、または適切に仮想化されたリソースによるスケールアップモデルを採用すべき
- これによりよりシンプルにシステムを設計し、より効率的に処理を実装できる
■ 5. DuckDBの技術的特性
- DuckDBの位置付け:
- 大量のデータセットを単一のローカルマシン上で高速に処理できる、モダンで軽量な組み込み分析データベース
- クエリエンジンの構造:
- 列指向のベクトル化されたクエリエンジンにより、データを並列処理しマルチコアCPUの性能を十分に引き出す
- ストリーミング実行エンジンにより、データソースから部分的にデータを読み取りメモリリソースを効率的に管理する
- 主な特性:
- OLAPに特化し、数百ギガバイトのデータを効率的に処理できる
- 一般的なSQLを利用し、複雑な分析処理でも柔軟かつ簡潔に表現できる
- 異なるデータソースから様々な形式のデータセットを収集し、同一クエリ内でまとめて処理できる
■ 6. DuckDBが注目される理由
- 従来の組み込みデータベースの限界:
- SQLiteに代表される組み込みデータベースはOLTPに特化し、トランザクション制御を必要とする軽量な処理を得意とする
- 行指向のクエリエンジンのため、データ量の増加に伴う性能悪化の懸念がある
- データセットのファイル形式やデータファイル配置先の柔軟性が低く、軽量なアプリケーションなどに用途が限られる
- 従来のDWHの限界:
- BigQueryやRedshiftはOLAPに特化し、列指向ストレージとベクトル化されたクエリエンジンで大量データを高速処理できる
- 大規模なクラスターのセットアップや管理が必要であり、複雑性や運用負荷増大の懸念がある
- スキャン量に応じた課金の製品では費用を計算しながらクエリを実行する必要があり、データ分析業務の効率化を妨げる
- DuckDBの優位性:
- 軽量な組み込みデータベースとしての扱いやすさと、大量データの分析処理を実現する高性能なクエリエンジンを両立する
- 異なるデータソースからの様々な形式のデータセットを一度に取り扱える柔軟性を有する
- OSSであるためどれだけクエリを実行しても料金は発生せず、必要なのは動作環境となるコンピューティングリソースの調達費用のみ
- 2025年1月3日時点のランキングでも注目度の高さが示されている
■ 7. ユースケース: 複数データソースのETLパイプライン
- 従来手法とその課題:
- BigQueryやRedshiftを利用したDWH上での分散クエリ実行が一般的だが、クラスター管理負荷に加え分散クエリの実行単位で費用がかかる
- DataflowやAmazon Managed Service for Apache Flinkによる分散バッチ処理も一般的な手法
- 分散データ処理基盤ではApache Beamのようなプログラミングモデルでの実装が必要で、学習コストや設計、開発負荷が増大する
- DuckDBによる代替策:
- 用途に合わせて仮想マシン、コンテナ、サーバレス環境にDuckDBをデプロイし、ETLパイプラインをSQLで実装する
- 設計、開発、運用負荷を軽量化しながら、異なるデータソースからのデータセットを組み合わせた処理を実現できる
- 拡張機能を利用し、各種データソースからの読み込みやデータシンクへの書き込み処理をSQLで実装できる
■ 8. ユースケース: 大量ログファイルの解析
- 従来手法とその課題:
- S3バケットに蓄えられた大量のアクセスログファイルの処理にはRedshiftやAthenaを利用する方法が一般的
- これらスケールアウトモデルのデータベースは複雑なクラスター管理に伴う運用負荷が大きい
- クエリ実行ごとに費用も嵩む傾向がある
- DuckDBによる代替策:
- DuckDBをEC2の仮想マシン内にデプロイし、DuckDBから直接S3バケットにクエリを実行する
- 運用コストを抑えつつ高速にデータを処理できる
- 具体的な実行方法:
- 仮想マシン内でDuckDB CLIを起動し、read_parquet関数でS3バケット内の複数ファイルを参照して必要なログのみを取得する
- エビデンス提示が必要な場合はCOPY文でデータ形式を指定し、CSVなど別ファイルにクエリ実行結果を出力できる
■ 9. ユースケース: 移行期間中の新旧テーブル比較
- 従来手法とその課題:
- pg_dumpなどで片方のデータベースにテーブルデータを複製する方法が一般的
- dumpファイルの作成やテーブルデータのリストアにかかるオーバーヘッドと作業負荷が大きい
- DWH上での比較もクラスター管理の運用負荷がかかり、フルスキャンによるクエリ実行費用も大きいため良い解決策にならない
- DuckDBによる代替策:
- DuckDBを仮想マシン内にデプロイし、移行前後の各データベースに対して直接クエリを実行する
- テーブルデータ比較前のデータダンプが不要となり、高速かつ簡単に新旧テーブルデータの比較を実現できる
- 具体的な実行方法:
- postgres_scan関数で移行前後の各データベースのテーブルを参照し、単一クエリ内で効率的にデータを比較する
- EXCEPT句を用い、新から旧、旧から新の双方向でデータ差分を抽出する
■ 10. DuckDBを使うべきではない場面
- テラバイト級のデータ分析処理を実行する場面
- 厳格なトランザクション管理や、並列書き込みに対する排他制御を必要とする場面
- ストリーミングデータをリアルタイム、またはニアリアルタイムに処理する場面
- Message QueueやPub/Subモデルの非同期メッセージング用データソース、データシンクを利用する場面
■ 11. 今後の展望
- 他ソフトウェアとの組み合わせ:
- 本稿ではDuckDBの基礎的な使い方と単体利用のユースケースを中心に紹介した
- DuckDBの真価は他のソフトウェアと組み合わせることで発揮される
- Modern Data Stack:
- 単一マシン上での高速なパイプライン処理を実現できるデータ活用基盤
- DuckDB、Meltano、dbt、Apache Supersetの組み合わせで構成する
- BemiDB:
- 分析用途に最適化されたPostgreSQL向けリードレプリカ
- DuckDB、Apache Icebergの組み合わせで構成する
- 今後の取り組み:
- DuckDB本体だけでなく周辺の関連ソフトウェア技術も積極的にキャッチアップし、継続的な情報発信に取り組む