データウェアハウスとは
DWH(Data Warehouse)は、業務システムなどのデータを収集し、意思決定のための分析に適合する形式で蓄積するデータベースです。
たとえば受注、会計、顧客管理のデータを毎晩収集し、過去数年分の売上高を商品別や地域別に集計する用途で利用します。
利用者はExcelや、集計結果をグラフや表に加工して表示するBI(Business Intelligence)ツールからDWHのデータにアクセスして数字を確認します。
受注や入金を1件ずつ記録する業務システムのデータベースに対し、DWHは大量の過去データを集計して傾向を把握するために設計されています。
各店舗のレジが業務システムのデータベースなら、全店舗の伝票を年度別・品目別に整理して保管する本社の資料室がDWHです。

データレイクは加工前のログや画像を元の形式のまま保管する場所です。
DWHは表形式のデータの集計を主な用途とする点でデータレイクと異なります。
業務システムだけでは過去の推移を集計しにくい
業務システムのデータベースは、受注の登録や在庫の引当を1件ずつ迅速に処理する設計です。
全期間・全件を対象とする分析の集計を同じデータベースで実行すると処理が重くなり、受注の入力画面の応答が遅延することがあります。
業務システムが現在の状態だけを上書きで保持している場合、半年前の担当者や価格を後から確認できません。
受注は販売管理、入金は会計、顧客情報は顧客管理と、データが別々のシステムに分散していることも集計を困難にしています。
DWHはこれらのデータを業務システムとは別の場所に複製し、分析の集計と業務の処理を分離します。
分析処理を業務用のデータベースから分離することで、業務処理と分析処理の双方の性能の向上が期待できます。

効果
- 販売管理、会計、顧客管理のデータを結合した集計を、手作業のファイル突合なしで実行可能
- 必要な履歴を記録する取り込みと保存の方法を設計すれば、業務システムの保持期間に左右されず過去の状態と比較可能
- 分析の集計の負荷を業務システムから分離可能。ただし業務システムからデータを抽出する処理の負荷は別途確認が必要
- 多数の利用者による同時の集計を想定した設計のため、複数の部署が同じ表を同時に参照する用途にも対応可能
コストとリスク
- 取り込み処理の構築と保守。業務システムの項目変更や更改のたびに確認や修正が必要になる場合がある
- 定義の統一と品質の確認。顧客や商品のコードと売上の計上基準を統一し、データの欠損や重複、取り込みの失敗の有無を確認しないと、同じ表を参照しても数字を誤認する
- クラウドの従量課金。Google CloudのDWH製品であるBigQueryは、集計で処理したデータ量に応じて課金するオンデマンド料金を提供。米国の地域の料金表では1TiBあたり6.25ドル、請求先アカウントごとに毎月1TiBまでは無料
- 集計の書き方による請求の増加。オンデマンド料金ではキャッシュが適用されない集計の実行ごとに、処理したデータ量が課金される。全列を参照する集計は1回に処理するデータ量を増加させ、高頻度の自動実行は処理の回数を増加させる
- 運用の担当。取り込み失敗の監視、権限の管理、品質の確認、利用料の監視を誰が担うかを決定し、作業量を見積もる必要がある
- 個人情報の複製。顧客情報の写しが業務システムの外部でも増加するため、閲覧範囲の管理対象が拡大する

DWHを導入するかの判断
検討のきっかけは手作業による突合の負担、業務システムへの集計の負荷、過去の状態と比較する必要の3つです。
いずれにも該当しない場合はDWHを早期に導入する必要はありません。
導入時はすでに利用しているクラウドの従量課金型の製品で、1つの業務領域から小規模に開始するのが妥当です。
基幹システムの集計表とExcelで分析が完結していてもDWHは必要か
基幹システムの集計表とExcelで履歴の保持、処理速度、管理の要件を充足している場合、DWHの導入は急務ではありません。
既存の手段で要件を充足している状態では、DWHで新規に実現できる分析が限定的で、構築と運用の費用を回収しにくいからです。
次のような状態が継続している場合は、導入の検討を開始する目安です。
- 複数のシステムのデータを同じ指標で定期的に手作業で突合している
- 集計の手作業に時間がかかり、作業できる担当者が限られている
- 集計の誤りや部署間の数字の不一致が繰り返し発生している
- Excelの1シートの行数が上限の1,048,576行に接近している
- 組織変更や価格改定の前後で過去の推移を比較する必要がある

基幹システムのデータベースにBIツールを直接接続すればよいのか
直接接続の可否は利用者の人数だけでは確定しません。
受注や出荷の処理と同じ計算資源を使用する場合は、1人の重い集計でも業務を停止させるおそれがあります。
直接接続で開始する場合は読み取り専用の権限を使用し、集計の実行時間に上限を設定します。
そのうえで業務時間中に代表的な集計を試行し、業務処理への影響を事前に確認します。
次のいずれかに該当した時点で、業務用のデータベースから分析の処理を分離します。
- 業務処理への影響が発生した
- 複数システムのデータの結合が必要になった
- 過去の状態との比較が必要になった
分離の方法にはDWHのほかに分析専用の複製データベースもあり、要件と費用に応じて選択します。

費用はどの程度で請求の急増は防止できるのか
クラウドの利用料はデータの容量だけでは確定せず、集計の実行回数、1回に処理するデータ量、計算資源の稼働時間、保存と取り込みの方式に応じて変動します。
総額の算定では取り込み処理の構築費と運用の人件費も計上します。
利用料の桁は集計の書き方次第で変化します。
たとえば1TiB、約1.1兆バイトの表の全列を参照する集計を1日10回、30日間自動実行し、キャッシュの適用がなく毎回1TiB分の課金が発生する場合、課金対象は月300TiBです。
毎月の無料枠1TiBを控除した299TiBにBigQueryの料金表の単価6.25ドルを適用すると1,868.75ドルで、月約1,900ドルになります。
仮に参照する列を限定して1回に処理するデータ量が10分の1の0.1TiBになれば、同じ回数でも課金対象は月30TiBで、無料枠の控除後は181.25ドルです。
導入時に製品の上限設定を有効化すると、集計の費用が急増するリスクを低減できます。
ただし、設定ごとに対象の費用が異なり、請求の総額を保証するものではありません。
- BigQueryでは1回の集計で課金するデータ量の上限とプロジェクト全体や各利用者に適用する1日の上限を設定可能。1日の上限は概算で、超過する場合がある
- クラウドのDWH製品であるSnowflakeでは仮想ウェアハウスと呼ぶ計算資源の稼働中だけ計算の料金が課金され、起動や再開のたびに最低60秒分が課金されるため、自動停止の設定が前提。保存の料金や別機能の費用は自動停止の対象外。リソースモニターで停止や通知を設定できる対象は仮想ウェアハウスだけで、別機能の使用量は予算の機能などで別途監視する
- AWSのDWH製品であるAmazon Redshift Serverlessでは予期しない費用に備えて計算資源の最大使用量の設定を推奨。上限への到達時の動作は通知、記録、クエリの停止から選択し、停止を選択すると処理が停止するため、業務への影響も確認する

上限の設定とは別に、月額の予算アラートも設定します。
たとえばGoogle Cloudの予算アラートは通知のみで、課金を自動では停止しません。
通知の受信担当者と利用制限の要否を決定する手順を事前に策定します。
DWHの対象外の用途とDWH製品の選定基準
- 在庫の引当や受注の確定など、即時の応答が必要な業務処理は業務システムのデータベースで処理する
- 画像や音声の元ファイルを大量に保管する用途には、通常はデータレイクなどの安価な保管場所を使用する
- 会計や顧客管理のクラウドサービスの標準レポートで必要な集計が完結し、履歴の保持、処理速度、管理の要件も充足しているなら、DWHの導入は急務ではない
- 製品は既存のクラウドとの接続の容易さを重視しつつ、代表的な集計を試行して処理速度と費用を確認したうえで選定する
よくある誤解
DWHのデータは常に最新である
DWHのデータは通常、業務システムから定期的に転送されます。
参照可能なデータの時点は取り込みの時刻、取り込み対象の期間、送信元のシステムの更新状況、取り込みの成否で確定します。
たとえば前日分の取り込みを毎晩実行する運用では前日までの数字が基本で、取り込みに失敗すると鮮度がさらに低下します。
数分単位の鮮度が必要な業務は、取り込みの方式の変更を含めて費用と比較して決定します。

DWHとデータレイクは二者択一である
データベース、データレイク、DWHは併用するのが一般的です。
売上や在庫の集計が目的の場合は、DWHから開始すれば十分です。
お問合せ
事業の課題や技術的な悩みなどどんなことでもお聞かせください



