Apache Druidとは？リアルタイムOLAPの仕組み・取り込み設計から採用判断まで実装者向けに解説

Apache Druidは、大量のイベントデータを取り込みながら、秒以下の応答で集計クエリを返すことを狙って作られた分散データベースです。列指向のセグメントにデータを固め、ビットマップ索引で絞り込みを済ませる構造を取ります。この記事では、セグメント構造と7サービス構成、Kafka取り込みとMSQバッチの使い分け、ClickHouseやTrinoとの違い、採用しない方がよい条件までを実装者の目線で整理しました。

まとめ｜Apache Druid採用の判断軸と向く用途

Druidが効くのは、書き込みが追記中心で、時刻を軸にした絞り込みと集計を、多数の同時利用者へ秒以下で返したい場面に限られます。Webの行動ログ、広告配信のインプレッション、IoTの計測値、監視メトリクスがその典型です。行単位の更新や削除が頻発する業務データ、複数の大きなテーブルを結合して初めて答えが出る分析には向きません。

規模でも分岐します。日次で数万行しか増えない規模なら、分散構成の運用負担のほうが上回るためです。時系列の追記が日次で数千万行を超え、同時アクセスが数十セッション以上になるあたりから費用に見合い始めます。

導入時に最初に固めるのは、セグメント粒度・ロールアップの有無・保持期間の3点。いずれも後から変えると再取り込みが必要になり、データ量が増えたあとでは作業時間が跳ね上がります。

Apache Druidの定義とリアルタイム分析DBとしての立ち位置

Druidを一言でいえば「取り込み中のデータにも即座にクエリを投げられるOLAPデータベース」です。

Druidが埋めるDWH・時系列DB・全文検索エンジンの間のすき間

Druidの設計は、データウェアハウス・時系列データベース・ログ検索システムの3系統から要素を組み合わせたものだと公式ドキュメントが明示しています。DWHからは列指向格納と集計性能、時系列DBからは時刻による分割と保持管理、ログ検索システムからは転置索引による絞り込みを取り入れた構造です。

これが効くのは、絞り込み条件が多次元で、しかも集計が伴うクエリになります。「直近24時間・特定の広告枠・特定の国」で表示回数を合計する問い合わせなら、時刻で読むセグメントを限定し、ビットマップで行を絞り、該当する列だけを読んで合計するためです。集計処理そのものの性質はOLAP分析の考え方と多次元集計の基本を先に押さえると掴みやすくなります。

Druid 37系（2026年8月時点）の到達点と直近リリースの変更点

公式のダウンロードページが安定版として掲示しているのは37.0.0で、リリース日は2026年5月8日です（2026年8月時点）。37系ではクエリのブロックリスト機能、マイナーコンパクション、再取り込みのカスケード実行が入りました。ひとつ前の36系では、Kubernetes向けのDruid Operatorと、ストリーミング取り込みのコストベースなオートスケールが追加されています。

従来のDruid運用はクラスタ構築と取り込みタスクのスケール調整で手が止まりがちでしたが、Operatorとオートスケールでその部分の手作業が減りました。裏を返せば、Kubernetes前提で組める体制がなければ37系の運用面の利点は受け取りにくくなります。

セグメント分割・列指向格納・ビットマップ索引が生む応答速度の内訳

Druidの性能は、格納形式の制約と引き換えに得たものです。内部の置き方を知ると、遅くなるパターンも予測できます。

セグメントの命名規則と300〜700MB・500万行という推奨値

Druidはデータを時刻の区間ごとに切り、その単位をセグメントと呼びます。識別子は「データソース名＋区間の開始＋区間の終了＋バージョン＋パーティション番号」の形式で、区間の粒度は segmentGranularity で決めるものです。

サイズの推奨は公式ドキュメントが明記していて、1セグメント300〜700MBの範囲が望ましいとされています。行数の出発点としては500万行が挙げられていました。日次1億行なら時間粒度で1セグメント約400万行に収まりますが、日粒度で切ると巨大セグメントになり、クエリの並列度が落ちます。

辞書符号化とビットマップ索引が効くフィルタ処理と集計の実装構造

セグメント内の列は3種類に分かれます。タイムスタンプ列とメトリック列は圧縮した数値配列として持ち、特別な構造を取るのはディメンション列だけです。ディメンション列は、文字列を整数IDへ割り当てる辞書、その辞書で符号化した値の並び、値ごとのビットマップという3つで構成されます。

公式ドキュメントの例では、Page列が2つの値に0と1を割り当て、それぞれ [1,1,0,0] と [0,0,1,1] のビットマップを持ちます。フィルタ条件はビットマップの論理演算だけで解けるため、行を1件ずつ評価する処理が消える仕組みです。条件を絞るほど速くなる挙動は、ここから来ています。

同時に、この構造は苦手な処理も決めています。リクエストIDのような一意に近い高カーディナリティの値をディメンションにすると、辞書もビットマップも肥大するためです。IDは検索キーではなくメトリック側やログ検索基盤へ逃がします。

ロールアップの粒度設計と、データ量削減と引き換えに失う情報の範囲

ロールアップは、取り込み時に同じディメンション組み合わせの行をまとめ、メトリックを事前集計する機能です。粒度を1分にすれば、同一条件の1分間の行が1行に畳まれます。生ログを1年保持する要件でも、ストレージ量が桁で減る場合があるほどです。

失うものははっきりしています。畳んだ時点で個々の行は復元できません。あとから「特定ユーザーの1件の挙動を追いたい」という要望が出ても、その粒度の情報は残っていないためです。実務では直近30日を生粒度、それ以前をロールアップ済みとして保持ポリシーを分けます。なおSQLベースの取り込みでは完全なロールアップが保証される一方、ストリーミング取り込みではベストエフォートになります。

7サービス構成とMaster・Query・Dataの3サーバ分離設計

Druidは単一プロセスではなく、役割の異なるサービス群で動きます。構成要素を把握しないと、障害時にどこを見るか判断できません。公式ドキュメントが挙げるサービスは7種類です。

Coordinator・Overlord・Brokerが担う役割分担の実際

7つのサービスは、それぞれ担当が分かれています。

• Coordinator：セグメントのHistoricalへの割り当てと配置バランスを管理
• Overlord：取り込みタスクの割り当てを制御し、MiddleManagerを統括
• Broker：クエリを受け、各データサーバの部分結果を統合
• Router：3種への入口となるAPIゲートウェイ。Webコンソールも提供
• Historical：deep storageからセグメントを取得して保持し、履歴データを処理
• MiddleManagerとPeon：取り込みを実行。PeonはMiddleManagerが別JVMで起動
• Indexer：上記の代替で単一JVM内のスレッドとして動く。実験的な位置づけ

障害調査で最初に見るのはOverlordとMiddleManagerです。取り込みが止まる原因の多くはタスク側にあり、クエリが遅い場合はBrokerとHistoricalの側を追います。

Historical・MiddleManagerとdeep storageの依存関係

Druidは3つの外部依存を持ちます。deep storageは全Druidサーバから読める共有ストレージで、取り込んだデータの正本が置かれる場所です。クラウドストレージ、HDFS、共有ファイルシステムが該当します。公式ドキュメントはデータサーバが全滅してもdeep storageからブートストラップできると説明しており、これが耐障害性の土台です。

メタデータストアは一般的なRDBMSで、セグメントの利用情報とタスク情報を保持します。ここが失われるとクラスタは自分がどのセグメントを持つべきか判断できません。バックアップ対象としては最優先です。3つ目のZooKeeperは、サービス検出・協調動作・リーダー選出を担当します。

メタデータDBとZooKeeperの構築負荷と縮小構成の選択肢

この依存関係は検証段階では負担になります。評価目的なら、公式が配布するシングルサーバ構成に組み込みDBとローカルディスクのdeep storageを割り当てて1台で立ち上がるためです。ただしその構成は本番では使えません。ローカルディスクをdeep storageにした時点で、耐障害性の前提が崩れます。

本番設計では、サービスをMaster（CoordinatorとOverlord）、Query（BrokerとRouter）、Data（HistoricalとMiddleManager）の3種類のサーバへ束ねます。最小構成でもMaster2台・Query2台・Data2台の6台程度を見込みます。

Kafka連携のストリーミング取り込みとMSQバッチ投入の使い分け

Druidの取り込みは大きく2系統あり、選び方で運用の手触りが変わります。

supervisor typeがkafkaの構成とexactly-once保証の範囲

ストリーミング取り込みは、常駐するsupervisorがタスクを管理する形で動きます。supervisorの種別は kafka と kinesis の2つで、Druidがブローカーから直接読む構成です。中間にETLプロセスを挟まないぶん、構成要素が1段減ります。

この方式は exactly-once を保証し、遅れて到着したデータも取り込めます。オフセット管理をDruid側が持つため、タスクが落ちて再起動しても二重取り込みにはなりません。Kafka側の設計思想や保持の考え方はApache Kafkaの特徴とメッセージ基盤としての位置づけを押さえておくと、supervisorのパラメータ設計が読みやすくなります。

INSERT・REPLACE文で投入するMSQの適用場面と失敗時の挙動

バッチ側の主流はSQLベースの取り込みです。SQLタスクAPIへ INSERT か REPLACE を投げると、query_controller タスクとして実行されます。パーティションは CLUSTERED BY で指定でき、完全なロールアップが保証される点が特徴です。

注意すべきは失敗時の挙動になります。MSQはコントローラかワーカーのどちらかが落ちるとジョブ全体が終了し、ワーカーを自動で再起動して続行する仕組みは持ちません。数時間かかる再取り込みをMSQで流すなら、期間を分割して投げる組み方にしておきます。

index_parallelのネイティブバッチを選ぶ条件と再実行耐性

もう一方のネイティブバッチは index_parallel をコントローラタスク種別として使い、タスクAPIへspecを投げて実行します。パーティション方式は partitionsSpec で動的・ハッシュ・範囲の3種類から選べる仕様です。

MSQとの実務上の分かれ目は耐障害性にあります。ネイティブバッチはワーカーの失敗から自動で復帰しますが、コントローラが落ちればジョブは終了します。長時間の一括ロードで途中失敗の確率が無視できないならネイティブバッチ、完全なロールアップの一貫性を優先するならMSQという選び方です。

ClickHouse・Trino・DWHとの違いと選定時に効く判断基準

Druidの検討は類似製品との比較で進みます。比較軸を先に固定します。

ClickHouseとの違いが出る同時実行数と取り込み方式の差

ClickHouseも列指向の分析DBですが、設計思想が異なります。単一サーバに機能を集約した構成を基本とし、取り込みはバッチ中心、主索引と副次索引は設計者が管理する形です。Druidは分散シェアードナッシング構成で、ストリーミングとバッチの両方を扱い、索引は自動で作られます。

実務での分かれ目は同時実行数です。少人数が重い分析クエリを流す用途なら、構築も運用も軽いClickHouseのほうが釣り合います。数十から数百のセッションが同時にダッシュボードを叩く用途では、Druidの分散構成が効く場面です。ClickHouseの列指向構造とMergeTreeの実装と読み比べると、同じ列指向でも設計判断がどこで分岐するか見えてきます。

Trino・DWHとの役割分担と、併存させる構成の現実的な組み方

Trinoは自らデータを保持せず、複数のデータソースへ分散SQLを投げるクエリエンジンです。Druidとは競合せず、むしろ併存します。よくある構成は、鮮度と応答速度が要るダッシュボード系をDruidに寄せ、複数ソースをまたぐ探索的な分析をTrinoへ任せる形です。詳細はTrinoの分散SQLクエリエンジンとしての仕組みで整理しています。

DWHとの関係も役割分担で考えます。会計や在庫のように正確性と履歴の一貫性が最優先の領域はDWHに置き、Druidは行動ログや計測値の即時集計に限定するのが基本です。両方に同じデータを持たせて二重管理になる構成は避けます。なお自前運用のインフラ費とエンジニア時間は、商用マネージド版ではライセンス費に置き換わります。構成要素を追える担当が1名しかいない組織なら、自前クラスタは持たない判断が妥当です。

Druidを採用しない方がよい条件と、失敗しやすい設計パターン

Druidの検討で最も費用対効果が高いのは、見送る判断を早く下すことです。

日次数万行規模でDruidが過剰になる、具体的なデータ量の分岐点

日次の追加行数が数十万行に届かない規模なら、Druidは採用しません。この規模ではPostgreSQLに時刻の部分索引を張るか、既存のDWHへ日次で流すほうが、応答速度でも運用費でも上回るためです。最小構成でもサーバは6台前後、外部依存はdeep storage・メタデータDB・ZooKeeperの3つ。この固定費を正当化できる規模に達していないなら、見送りで確定します。

逆の線引きも示します。日次で数千万行が積み上がり、時刻とディメンションでの絞り込み集計に秒以下の応答が要求され、同時アクセスが数十セッション以上ある。この3条件が揃ったときが、検討に載せる下限です。

更新・削除の多い業務データをDruidに載せたときの破綻要因と兆候

受注テーブルや顧客マスタのように、既存行の更新と削除が日常的に走るデータをDruidへ載せる設計は失敗します。Druidのセグメントは不変で、行単位の更新という概念を持たないためです。更新を反映するには該当区間を REPLACE で丸ごと入れ替えるしかなく、更新頻度が高いほど再取り込みが積み上がります。

兆候は取り込みタスクのキューに出ます。再取り込みタスクが日中ずっと走り続け、Historicalのセグメント入れ替えが止まらない状態になったら、載せるデータの選定を誤っています。正しい対処は、更新の走る正本をRDBMSかDWHに置き、Druidには確定済みのイベントだけを流す構成へ戻すことです。

JOIN前提の分析要件でDruidを避けるべき条件と代替の置き方

Druidは結合を扱えますが、大きなテーブル同士の結合を前提にした設計は避けます。単一のデータソースに必要な属性を非正規化して持たせ、絞り込みと集計だけで答えを出す前提の構造だからです。

分析要件に、複数の大きなマスタを結合しなければ答えの出ない問いが3つ以上含まれるなら、Druidは主役に据えません。DWHかレイクハウスを主役にして、Druidは即時性が要る一部の指標だけを非正規化して持つ副系へ格下げします。あるいは取り込み前段のパイプラインで結合を済ませる形です。結合をクエリ時ではなく取り込み時へ押し出せるかどうかが分かれ目になります。

本番投入前に決める設計項目と、運用コスト・監視体制のチェック観点

Druidは後戻りの費用が高い基盤です。取り込みを始める前に確定させておく項目を挙げます。

segmentGranularityとcompactionの初期設定の決め方

segmentGranularity は、1日あたりの行数を推奨値から逆算して決めます。目標は1セグメント500万行前後、ファイルサイズ300〜700MBです。日次1億行なら時間粒度、日次500万行なら日粒度が出発点になります。

ストリーミング取り込みでは小さなセグメントが大量に生まれ、放置するとクエリのオーバーヘッドが増えます。これはcompactionタスクで後から結合する運用です。37系のマイナーコンパクションは、その結合処理の負荷を抑える方向の変更にあたります。初期設定の段階で実行タイミングと対象区間を決めておきます。

保持期間・リテンションルールとdeep storage費用の見積り

保持設計はCoordinatorのリテンションルールで表現します。よく使うのは階層化で、直近の期間はHistoricalに複製2でロード、それ以前は複製1、さらに古い区間はロードせずdeep storageのみへ残す三段構えです。

費用の見積りでは、Historicalのローカルディスク容量とdeep storageの容量を別々に積みます。ロールアップ後の圧縮サイズは取り込み検証で実測してください。机上の圧縮率で決めると、本番稼働後にディスクが先に尽きます。

小規模検証から本番へ広げる手順と、外部委託する場合の分担の決め方

検証から本番までは、次の順序が事故を減らします。

1. シングルサーバ構成で1週間分の実データを取り込み、セグメントサイズと圧縮後容量を実測する
2. 想定クエリを10本ほど書き、応答時間と同時実行時の劣化を測る
3. 実測値からsegmentGranularityとロールアップ粒度を確定し、再取り込みで検証する
4. 3サーバ分離構成へ移し、deep storageとメタデータDBを本番相当に差し替える
5. 取り込み遅延・タスク失敗率・セグメント数・Historicalのディスク使用率を監視項目に設定する

このうち1から3は、Druid固有の知見がないと判断を誤りやすい部分です。社内に運用経験がない場合、設計と初期構築を外部に任せ、定常運用を内製へ引き取る分担が現実的になります。一創では取り込み設計から監視設計までを含むデータ分析基盤構築・MLOps構築支援を提供しており、既存のDWHとの役割分担を含めて検討できます。

よくある質問

Apache Druidの検討時に実務でよく挙がる質問をまとめます。

Apache Druidは無料で使えますか？

Apache Druidはオープンソースソフトウェアで、Apache License 2.0のもとで無償で使えます。ソフトウェア自体のライセンス費用は発生しません。ただし実費はかかります。最小構成でもサーバが6台前後、加えてdeep storage用のオブジェクトストレージ、メタデータ用のRDBMS、ZooKeeperが必要になるためです。

Druidの学習コストはどのくらいですか？

SQLで問い合わせる部分だけなら、DWHの経験があるエンジニアは数日で書けるようになります。負担が大きいのは運用側です。7種類のサービスの役割、セグメントのライフサイクル、取り込みタスクの状態遷移を理解しないと障害対応ができません。設計と構築に慣れるまでは数週間から数か月を見込むのが妥当でしょう。

小規模なデータでもDruidを使う意味はありますか？

日次の追加行数が数十万行に満たない規模では、意味が薄いと判断します。この規模ならRDBMSの索引設計か、既存DWHへの日次ロードのほうが応答速度と運用費の両方で有利です。Druidを選ぶ理由になるのは、データ量よりも「取り込みから数秒で見えること」と「多数の同時アクセスに秒以下で応えること」が要件に書かれている場合になります。

DruidにBIツールを接続できますか？

接続できます。DruidはSQLインターフェースとJDBCドライバを提供しており、SQLで問い合わせられるBIツールから参照できる作りです。相性がよいのは絞り込み条件を固定したダッシュボード用途。一方で、BIツールが自動生成する結合の多いクエリをそのまま投げると、Druidの構造と噛み合わずに遅くなります。BIから使うなら、参照先のデータソースを非正規化した幅広テーブルとして設計しておきます。

Druidの日本語情報は十分にありますか？

日本語の解説記事は限られており、設計判断に必要な情報の多くは公式ドキュメントの英語版にあります。バージョン差の大きい製品なので、日本語記事を参照する際は対象バージョンの確認が必要です。2026年8月時点の安定版は37.0.0で、36系以降も運用面の変更が続いています。数年前の記事の手順はそのまま通らない前提で読むと安全でしょう。

関連記事

• データレイクハウスとは？データレイク・DWHとの違いとアーキテクチャ：Druidを置く前段の基盤構成を比較する下地になります
• データパイプラインとは？種類・構成要素と冪等性から考える設計判断：取り込み前段で再実行に耐える設計を組む考え方です
• データウェアハウス（DWH）とは？仕組み・製品比較・選び方：役割分担を決める前にDWH側の得意領域を確認できます
• Apache Pinotとは？超低遅延OLAPの仕組み・star-tree索引とupsert設計から採用判断まで解説：同じリアルタイムOLAPでも、同時実行数と更新要件で選定がどう分かれるかを比較できます。