なぜ「ちゃんと作った」データ基盤で、リアルタイムの数字が出ないのか？従来DBの課題 | SingleStore解説シリーズ②

トランザクションDB（業務システムが使うDB）はちゃんと動いています。ETLも組みました。DWHもあります。BIツールだって導入済みです。——なのに経営から「今の数字を見せてほしい」と言われると、返答はたいてい「明朝のレポートをご確認ください」になってしまいます。

心当たりのある方は、おそらく少なくないのではないでしょうか。設計が悪かったわけではありません。むしろ丁寧に設計したからこそ、当時の要件にはきちんと合っていました。しかし「今すぐ数字がほしい」という要求が当たり前になった瞬間、この構成の前提が少しずつずれ始めます。

本記事では、従来のデータ基盤構成がリアルタイム分析を阻む構造的な理由を3つの観点から整理し、「何を変えればいいのか」の方向性をお伝えします。

シリーズ他の記事はこちら

多くの現場で運用されているデータ基盤は、概ね以下のような構成です。

業務システムで発生したデータをETLで整形し、DWHに格納して、BIツールで可視化する。この構成は教科書どおりの設計であり、多くの企業で長年きちんと機能してきました。

ただ、この構成が設計された当時の前提を思い出してみてください。「月次レポートを翌月初に確認できればOK」「日次集計が翌朝に出れば十分」——そういう時代に合わせて作られた仕組みなのです。

「システムは正しく動いている。でも今の時代が求める速度に、設計の前提が追いついていない」という状態です。

いわば5年前に作った通勤ルートが、新駅の開業で遠回りになってしまったようなものです。ルート自体が間違っているわけではないけれど、もっと速い道ができたのに旧来のまま走り続けている——そんな感覚に近いかもしれません。

では、この構成のどこに壁があるのか。次の3つの観点から見ていきます。

バッチ中心の構成では、ETL（抽出・変換・ロード）は通常、夜間や早朝にまとめて実行されます。システム負荷の分散やリソースの効率利用を考えれば、合理的な設計判断です。

ところが、バッチが完了した時点がDWH上で参照できるデータの「最新時点」になります。ここに構造的な遅延が生まれるのです。

スーパーの刺身に例えるなら、ETLの実行間隔がデータの「賞味期限」を決めるようなものです。1日1回のバッチなら、データの鮮度は最大24時間遅れになります。市場が動いている最中に「昨日の値動き」を見て判断しなければならない——金融の現場ではこの遅延が実際のリスクに直結します。

大手金融機関の事例では、EOD（End of Day）バッチに数時間から半日を要し、T+1レポート（前日分のレポートを翌営業日に提供）が事実上の限界だったことが報告されています。市場が急変しても、リスクの再計算は翌朝まで待たなければなりませんでした。

「ETLのバッチ頻度が、データ鮮度の上限を物理的に決めている」ということです。

「じゃあバッチを1時間おきにすればいいのでは？」——そう考えたくなりますが、話はそう単純ではないのです。

鮮度の問題に対処しようとすると、多くの現場で次のような対応が積み重なっていきます。

• ETLの実行頻度を上げる（1日1回 → 1時間ごと → 15分ごと）
• CDC（変更データキャプチャ）やストリーミング基盤を追加する
• 中間ステージング層を設けてデータを一時保存する
• 集計済みマートテーブルをDWH内に増やす

対策を打つたびに管理対象のコンポーネントが増えます。コンポーネントが増えればモニタリングの対象も増え、障害の発生ポイントも増え、「どこのデータが正しいのか」という整合性の問題も起きやすくなります。

まるで雨漏りをバケツで受けていたら、バケツの管理が本業になってしまった——そんな状況です。「データパイプラインの保守が仕事の半分を占めている」という声は、データエンジニアの集まりでは驚くほど共感を呼ぶ話ではないでしょうか。

「鮮度を上げようとするたびに、運用コストと障害リスクも増えやすくなる」という構造になっています。

ここまで読んで、「DWHを経由するから遅い。トランザクションDBに直接分析クエリを投げればリアルタイムでしょ？」と思った方もいるかもしれません。確かに論理的にはそのとおりです。でも実際にやると、別の問題が起きてしまいます。

トランザクションDBはOLTP（Online Transactional Processing：オンライン取引処理）に最適化されたシステムです。「1件のレコードを高速に読み書きする」「大量の短いトランザクションを処理する」ことに特化しています。

一方、分析クエリはOLAP（Online Analytical Processing：オンライン分析処理）の世界です。「数百万〜数億行をスキャンして集計する」「複数テーブルを結合する」といった重い処理が中心になります。

居酒屋のカウンターで100人分の宴会料理を作ろうとしているようなものです。カウンターの板前さんは一品ずつ丁寧に仕上げるのが得意です。でも100人前の煮込みを同時に作り始めたら、カウンターのお客さんへの提供が止まってしまいます。

トランザクションDBに重い集計クエリを投げると、CPUとI/Oが逼迫し、受注処理や決済処理といった本番トランザクションにまで影響が波及します。「分析のためにシステム障害を起こす」——これは本末転倒です。

「データの鮮度を優先すると、システムの安定性が犠牲になる。両立が構造的に難しい」ということです。

ここまでの3つの壁は業種を問わず発生しますが、痛みの出方は現場によって少しずつ異なります。

市場データがトランザクションDBに入ってからレポートに反映されるまで6〜12時間かかります。大手金融機関では市場リスクやP&L（損益）のリアルタイム分析が求められ、投資銀行ではウェルスマネジメント向けポートフォリオの即時把握が必要です。さらにカード決済の不正検知やAML（マネーロンダリング対策）分析では、数時間の遅延が文字どおり「見逃し」につながります。市場が急変した際、担当者がExcelで手作業の補正をしながら対応している——「本当のリスク値は翌朝にならないとわからない」という綱渡りが日常化しています。

工場のセンサーデータは大量に取得されています。グローバル製造業では100以上のユースケースでリアルタイムデータを必要とし、IoT分析基盤を構築しています。しかしDWHに届くまでのラグが数時間あれば、設備の異常兆候を検知できるのは「すでに止まった後」です。予兆保全のはずが事後対応になってしまっています。

セール開始直後の売上推移をリアルタイムで追いたい。でも集計は翌朝のバッチ待ちです。大手米国小売では2,800店舗の在庫・発注基盤をリアルタイムで回す必要があり、コネクテッドカー領域でもテレマティクスデータの即時処理が求められています。「今この瞬間、どの商品が動いているのか」「車両の状態はどうか」がわからないまま、判断を翌日に先送りしている現場は少なくありません。

SalesTech・MarTech企業では、BigQueryなど既存DWHの置き換えや補完としてリアルタイム基盤を導入しています。IDグラフの構築やSales Engagementのデータ処理では、「バッチで数時間かけて更新する」サイクルでは顧客接点のタイミングを逃してしまいます。営業やマーケ部門が「今この瞬間のリード情報」を求めているのに、データが追いつかない状況です。

——どのケースも、「データは存在しているのに、必要なタイミングで意思決定に使えない」という共通のもどかしさを抱えています。

「業種が違っても、必要な瞬間にデータが使えないという悩みの構造は共通している」ということです。

ここまで見てきた3つの壁を整理すると、根っこにあるのは1つのジレンマです。

「書き込み（OLTP）と分析（OLAP）を別々のシステムで処理する」という設計前提は、リアルタイム性の要求が高い場面では限界が出やすくなります。

この問題に対して、近年注目されているアプローチがHTAP（Hybrid Transactional/Analytical Processing）という考え方です。業務データの書き込みと分析処理を、1つのエンジンで同時に扱う設計思想であり、ETLを介した「2階建て構造」そのものを見直す発想に立っています。

このアプローチが実装レベルでどう実現されているのか——「1つのエンジンでOLTPとOLAPを両立する」とは具体的に何をやっているのか——については、次回の記事で技術的な仕組みを詳しく掘り下げていきます。

「データの発生地点と分析地点を近づける——ETL経由の迂回をやめることが、リアルタイム分析への第一歩になる」ということです。

いかがでしたでしょうか。この記事では以下の点についてまとめました。

• ETLバッチの実行頻度が、データ鮮度の物理的な上限を決めています。 設計上の制約であり、現構成のままでは超えにくい壁です。
• 鮮度向上のためにレイヤーを追加するほど、複雑性・整合性リスク・運用コストが膨らみます。 対症療法の限界は、いずれ訪れます。
• トランザクションDBに直接分析クエリを投げることは、OLTP/OLAPの特性の違いから本番系へのリスクを伴います。 鮮度と安定性のトレードオフは、従来構成では解消できません。

ここまで読んで、課題を感じた方は、ぜひ自社のデータフローを1枚の図にしてみてください。「ETLのバッチ間隔」と「現場が実際に求めるデータの鮮度」の間に、何時間のギャップがありますか？ そのギャップの大きさが、今の構成を見直す優先度そのものを教えてくれるはずです。

従来の構成が限界を抱えていることはわかりました。ではHTAPという設計思想は、技術的にどうやって「書き込みと分析の同居」を実現しているのでしょうか。行ストアと列ストアを1つのエンジンに同居させるとは具体的にどういうことなのか、そしてそれが本当に業務トランザクションと干渉せずに動くのか——その仕組みの中身を理解できたとき、「なぜこのアプローチが注目されるのか」が腑に落ちるはずです。