データウェアハウスの特徴、定義、用途、必要性、構成する要素、主要なデータウェアハウスサービス、データベース・データマート・データレイクとの違い、メリット、解決できる課題、活用事例、導入する際の注意点について解説します。
データウェアハウスの基本情報について、下記の順に解説します。
・データウェアハウスの特徴
・データウェアハウスの定義
・データウェアハウスの仕組み・構造
・データウェアハウスの必要性
・クラウドデータウェアハウスの台頭
・主要なデータウェアハウス製品
データウェアハウスは、直訳すると「データの倉庫」という意味です。データをただ蓄積するのではなく、利活用するための倉庫である、という点が重要になります。
通常のデータベース（RDB）が、データベースごとの目的に沿って更新を前提として運用されるのに対し、データウェアハウスは、データの蓄積と分析を目的としているため、膨大なデータを取り扱えるようカラム指向やMapReduceといった仕組みを採用して、処理速度を高めています。
業務用のデータベースから、ETLツールなどを介してデータをデータウェアハウスへ集約し、整理された大量のデータをもとに分析を実施することで、全体の関係性や傾向を把握するのに役立ちます。
データウェアハウスに集約されたデータは、時系列や主題ごとに整理され、扱いやすい形で保持される点も特徴です。また、データウェアハウスに集約されたデータは、削除・更新することも通常ありません。
データウェアハウスの概念は、アメリカのコンピューターサイエンティストWilliam Inmonが、1990年に著作の中で下記の通り提唱しています。
なお、構築されたシステムのうち、どこまでをデータウェアハウスと呼ぶかは環境や利用者によって異なります。
一般的に、情報を分析して意思決定支援を行うためのデータベース、およびそのようなデータベースを含む意思決定支援システム全体（BIツール）のことを、データウェアハウスと呼びます。
データウェアハウスは、更新の必要のない履歴データの取り扱いに長けています。基幹系システムから、トランザクションを抽出して再構成・再蓄積することで、データ分析がはかどるのです。
【データウェアハウスにより集約できるデータ例】
・トランザクションシステム
・業務データベース
・基幹業務アプリケーションからのリレーショナルデータ
一方で、サービスの予約履歴のような、常に最新のスケジュール管理が必要となるデータや、確定していない変更の余地のあるデータの保存には向きません。
データウェアハウスは、次の要素で構成されます。
・データを保存するRDB
・分析に必要なデータ準備（データプレパレーション）のためのETLソリューション
・統計分析、レポート、データマイニング機能
・データを視覚化して提示するクライアント分析ツール
・その他の分析アプリケーション
データウェアハウスの実装は、データ量が特定のボリューム（既存のRDBで管理が難しいボリューム）に達したときに考えるものだと誤解されている節があります。
しかし、データウェアハウスはデータを蓄積するだけの入れ物ではなく、効率的なデータ分析に必要なデータプレパレーションの要素も含んでいます。
「データウェアハウスさえあればビジネスにおける意思決定を行う上で必要なインサイトを十分に得られる」、という環境を構築することが理想です。
そのためには、データを集約するための大容量のデータベースだけでなく、データを使いやすい形に整理・成形するETLソリューションが欠かせません。また、集約されたデータから、業務ごと・部署ごとに適切なインサイトを得るには、専門家でなくても使いこなせるような使い勝手の良い分析ツールが必要です。
つまり、データウェアハウスにとって、データを集約するための大容量のデータベースはあくまでも一要素である、と言うことができるでしょう。
データウェアハウスは、1980年代後半に登場して以来、長らくオンプレミスサーバー上に構築されていました。しかし、近年はクラウドデータウェアハウスが低コストで利用できるようになり、主流になっています。
クラウドデータウェアハウスには、従来のデータウェアハウスと比較して次の利点があります。
・スケーラビリティが確保されている
・フルマネージドで管理が容易
・コストを削減＆予測できる
・環境構築の時間を短縮できる
近年主流となっているクラウドデータウェアハウス製品は次のようなものです。
・Redshift（AWS）
・BigQuery（Google）
・Snowflake（Snowflake社）
それぞれのサービスの特徴を簡単にご紹介します。各サービスの詳細は別記事にて解説していますので、興味のある方はぜひそちらも合わせてご覧ください。
Redshiftは、Amazon Web Services（AWS）が提供するデータウェアハウスです。数あるクラウドデータウェアハウスサービスの中でも、Redshiftはスタンダードのひとつと言えます。
2020年時点で数万社が利用するサービスであり、Amazonの分析基盤としても活用されています。
Redshiftの詳細については下記記事をご覧ください。
BigQueryは、Google Cloud Platform（GCP）で提供される、費用対効果に優れたマルチクラウドデータウェアハウスです。
Googleが社内用に開発した「Dremel（ドレメル）」という大規模なクエリを実行するサービスを、外部ユーザー向けに利用できるようにしたもので、2006年に社内運用を開始し、2012年にBigQueryとしてリリースされました。
C-Store、Monet DBなどに続き、市場に出回った最初のメジャーなデータウェアハウスの1つです。
BigQueryの詳細については下記記事をご覧ください。
Snowflakeは、Snowflake社の提供する、クラウドベースで動くSaaS型データウェアハウスです。従来のデータウェアハウスに比べて柔軟性が高く、AWS・Azure・GCPなどのクラウドサービス上で動作します。
RedshiftやBigQueryと比較して後発のサービスであり、後発優位性を活かした独自のアーキテクチャを構築している点が特徴です。
Snowflakeの詳細については下記記事をご覧ください。
データウェアハウスと合わせて語られることの多い概念・用語について、それぞれとの違いを中心に解説します。
データウェアハウスが更新性のないデータの集約に適しているのに対し、データベース（RDB）は、追加や更新の可能性のあるデータの取り扱いに適しています。
データベースに蓄積したデータのうち、確定したものを定期的にデータウェアハウスに集約することで、データの散在やサイロ化を防ぎデータ品質を維持する、といった使い分け方が考えられます。
データウェアハウスが「倉庫」であるのに対し、データマートは「小売店」を表しています。名前の通り、データマートは、データウェアハウスをユーザー別や目的別に整理し、使いやすい形に切り出したものです。
データ量の増加などが原因で、データウェアハウスのままでは十分なデータ活用がされない場合、データマートとして一部のデータを切り出すことによってデータ利用率が高まる可能性があります。
詳細は記事後半にて、「データウェアハウスの導入・活用の注意点」でも解説します。
データレイクは、データウェアハウスでは保持の難しい非構造化データを集約するための「データの湖」です。
データを集約するという点ではデータウェアハウスと共通していますが、データウェアハウスがデータ分析という目的が明確であるのに対し、データレイクは目的が定まっていないデータもすべて集約するという点が異なります。
本来、データウェアハウスもそういったデータをすべて集約するためのものですが、増加し続けるデータ量に対してすべてを保存するのは難しい状況になりつつあり、コスト削減のためにデータウェアハウスに集約したデータの一部を削除するといったケースも存在します。
そうした状況において、データレイクは過去のデータを確実に蓄積するためのソリューションとして有効な手段と言えるでしょう。
データレイクの詳細は下記記事もご覧ください。
データウェアハウスの特徴や用途を踏まえて、導入することで得られるメリットを改めてまとめます。データウェアハウスの導入によって得られる主なメリットは次の通りです。
・情報に基づく意思決定
・大量の履歴記録を保持・分析できる
・多数のソースのデータを統合できる
・データの品質、一貫性、正確性を維持できる
・取引・分析の両システムのパフォーマンスを向上できる
データを集約し、利活用するソリューションを取り入れることで、企業の蓄積した情報に基づいた合理的な意思決定ができるようになります。
データベース単体では蓄積の難しい、細かく大量のトランザクションデータを保持することができます。容量不足により過去データが維持できない、といった課題の解決にもつながるでしょう。
目的に応じたデータベースや、Excelやスプレッドシートなど分散したソースのデータを統合できることで、データの散在やサイロ化を防ぎます。
データを集約し、同一のETLプロセスを経ることにより、データ品質やデータの一貫性、正確性を一定に保つことができます。
品質の低いデータをもとにした意思決定は、ビジネスにかえって悪影響を及ぼす可能性もあるため、データ品質の維持・向上は非常に重要です。
分析処理をトランザクションデータベースから分離することで、平時に利用するデータベースはトランザクションに集中することができ、トランザクションと分析のそれぞれのパフォーマンス向上が見込めます。
ここからは、クラウドデータウェアハウスの主要サービスとしてあげた3サービスの事例を中心に、データウェアハウスの活用事例を紹介します。
米国のハンバーガーチェーン・マクドナルドは、Redshiftを導入してビジネスの成長を加速させました。
マクドナルドがサービスを提供する顧客数は、1日あたり6,900万人に及びます。これらのビッグデータからビジネスのインサイトを迅速に得るためには、大容量で高速なデータベースが不可欠でした。
そこで、Redshiftを含むAWSのシステムを活用してデータ分析環境を構築した結果、当初のパフォーマンス目標を66％超過し、POSシステム経由で毎秒8,600件のトランザクション処理を実現しました。
グローバルデータおよび分析担当ディレクターであるAbhi Bhatt氏は、「Redshift のおかげで、当社は安心してより多くのデータと分析のワークロードを AWS で実行し、お客様のニーズの増大に対応できるようになりました」 と語ります。
参考：
[レポート] ANT383 – Teradata から Amazon Redshift への移行: マクドナルドのベストプラクティス #reinvent | DevelopersIO
米国の製薬会社Pfizer（ファイザー）はRedshiftの導入により、以前使用していたデータウェアハウスに比べておよそ10倍のパフォーマンスでクエリを実行できるようになりました。
ハイパフォーマンスなデータウェアハウジングにより、製造装置が生成した数百万行のデータ（1行あたりのデータポイント数は1,600）を、ほぼリアルタイムでデータサイエンティストに提供する分析環境を実現。
加えて、スケールアップやスケールアウト自在の拡張性・柔軟性を活かして製造工程の最適化を図ることにより、製造効率を向上させることができました。
規制機関に対応するためのデータ収集とデータプレパレーションにかかっていた時間は、およそ5分の1に短縮できたといいます。
米国のIntercomは、12億7,500万USDの評価額と2億4,000万USDを超える資金調達を集める、カスタマーサポートプラットフォームを提供する急成長しているスタートアップ企業です。
マーケティングからWebセールス、問い合わせ対応といった顧客とのコミュニケーション全般をカバーするツールで、企業の良好な顧客関係をサポートします。あらゆるビジネスに対して適切な機能を提供するために、Intercomでは70TBという膨大な量のデータを利用しています。
こうしたビッグデータを取り扱うのにRedshiftはうってつけであり、導入によって拡張や予算の維持が容易になったといいます。
無料の教育ウェブサイトやアプリ、有料の資格試験を提供する言語教育プラットフォーマーであるDuolingoは、Redshiftを使用して、アプリ内で発生するイベントからユーザーの学習傾向を分析しています。
毎日数十億件のイベントをRedshiftにロードし、数百テラバイトのデータが存在しており、データエンジニアリングマネージャーのPaul Vickers氏は「これが今後、毎年倍増する」と予測しています。
米国のバイオ技術企業であるモデルナは、mRNA薬をより速く、より低コストで提供するため、AWSの使用を早期に開始しました。
RedshiftをSSOT（Single Source of Truthe）として活用する一方で、バックアップをS3に保存するという環境を構築しています。
容量に配慮する必要がなくなったことに加え、バックアップやリカバリといった処理が容易であることから、IT部門を保有する必要がなくなりました。
参考：
株式会社すかいらーくは、全国3,000店舗・年間延べ4億人のユーザーを抱える総合ファミリーレストラン企業です。
すかいらーくでは、以前からデータウェアハウスを利用していたものの、マーケティング部門で必要となるレシート明細レベルの分析に数時間かかり、仮説・検証のサイクルを週に数回しか行えず、分析精度を高められないことが課題となっていました。
そこで、Redshiftを含むAWSの活用によりデータ分析環境を構築。オンプレミスなら1年以上かかってもおかしくないところを、およそ3ヶ月強で構築しました。
その結果、それまで数時間かかっていたデータ集計が数分程度まで短縮したほか、広告費を前シーズン比3億円削減、売上高40億円成長といった成果を実現しています。
参考：
無印良品を展開する良品計画は、2013年に導入した会員制サービス「MUJI passport」や、無印良品ネットストアで得られた数十億件におよぶビッグデータの分析基盤としてRedshiftを活用しています。
MUJI passportでは、来店を示すチェックインや、SNSを利用した商品の口コミ投稿、さらに商品へのリクエストなどによっても貯まるよう設定されており、この仕組みにより「顧客がどれだけ時間を使ったか」を可視化しています。
参考：
全国588店舗の回転寿司チェーンを展開する株式会社あきんどスシローは、商品原価率約50%と、業界水準を大きく上回る原価率で事業展開しています。そのため人件費やITコストをできる限り抑える必要があり、早期から信頼性の高いシステム構築に取り組んでいました。
そして、2013年後半から、Amazon RDS for SQL ServerとRedshiftを活用した本格的なデータウェアハウスを構築しています。
さらに、店舗で稼働する「すしテクノロジー（すし皿に搭載されたICタグや、顧客の来店状況、着席状況を管理する技術）」からのデータ収集においては、Amazon Kinesisを使用した「KineSushi」という仕組みも構築しました。
こうした取り組みの成果もあり、スシローは回転寿司企業の売上高ランキングで6年連続日本一を達成しています。
参考：
不動産を取り扱う株式会社オープンハウスは、BigQueryを含むGoogle Cloud Platformの各種ツールを活用して業務改善した結果、年間約4万2,000時間の工数削減を見込んでいます。
具体的には、物件資料のオビ付けと呼ばれる業務を自動化したほか、機械学習による広告キャンペーンの評価などを実施しました。
分析基盤をBigQueryに統一することで、直接契約につながったか否かという観点で集客を評価できるようになったといいます。
参考：
株式会社オープンハウス：業務改善による年間約 4 万 2,000 時間の工数削減に AI Platform 、BigQuery を活用｜Google Cloud ブログ
コンサルティング事業、人材・キャリア支援事業、知的情報プラットフォーム事業を展開するアスタミューゼ株式会社は、BigQueryにより2億件近い非正規データに対する分析速度の向上を実現しています。
従来は一般的なRDB（リレーショナルデータベース）と全文検索エンジンを用いてデータ分析を行なっていたのに対し、分析基盤をGoogle Cloud Platformに移行してBigQueryを利用するようになったところ、200～300倍高速化したとのことです。
参考：
アスタミューゼ株式会社：2 億件近い非正規データを BigQuery で高速分析。コンサルティング事業 SaaS 化も視野に｜Google Cloud ブログ
事業者向け間接資材のオンライン通販サイト「モノタロウ」を運営する株式会社MonotaRO は、BigQueryを駆使した新しいデータ分析基盤を構築することで、総計100億レコードに及ぶデータの活用を推進しています。
それまでオンプレミス環境で保持していたデータをBigQueryに移行することで、扱えるデータ量が10倍に、生み出される分析レポート数も10倍に、そしてデータ分析に取り組むメンバー数が4倍に拡大したとのこと。
数億ものレコードを対象とするため、従来はデータ分析に約2時間かかっていました。同様の処理を、BigQuery移行後は2～3分で終了できるようになり、それまで毎月30程度だった分析レポート数が、月に300レポートまで増大しました。
参考：
株式会社MonotaROの導入事例｜Google Cloud
株式会社MonotaRO の導入事例：BigQuery を駆使した新しいデータ分析基盤構築で、全社的にさらなるデータ活用を推進｜Google Cloud ブログ
JapanTaxi株式会社は、タクシー配車アプリ「JapanTaxi」のデータ分析基盤を、BigQuery を活用して構築しました。
BigQueryを導入した結果、従来の仕組みで発生していたアドホック分析時の待ち時間が減少したそう。
フルマネージドなため、メンテナンスなど維持管理の手間を考える必要がなく、2名のエンジニアで分岐基盤を運用できているとのことです。
参考：
JapanTaxi株式会社の導入事例｜Google Cloud
JapanTaxi株式会社の導入事例：BigQuery を活用して、国内最大級のタクシー配車アプリ『JapanTaxi』を支えるデータ分析基盤を構築｜Google Cloud ブログ
スーパーマーケットやドラッグストアにおける購買情報をもとに、データマーケティングサービスを提供する株式会社True Dataは、より効率的なデータ分析を提供するため、オンプレミスの社内システムをBigQueryへ移行しました。
同社の保有する約5,000万人の20～30億件に及ぶ購買データに対し、迅速に分析を行なううえでスピードは必要不可欠であり、多くの選択肢との比較検討の末にBigQueryへの移行を決定。
その結果、スピードが速くなったのに加え、データの集約も手軽になり使い勝手は劇的に改善し、従来の10倍以上の効率で作業を進められるようになったとのことです。
同社では、最終的に営業チームも含めた全てのスタッフがBigQueryを使えるようになることを目標として掲げています。
参考：
株式会社True Data の導入事例: BigQuery の導入で業務効率を 10×10×10＝1000 倍に?｜Google Cloud Platform Japan Blog
個人向け・ビジネス向けの家計簿サービスを提供・展開する株式会社マネーフォワードは、BigQueryの導入により、ログ解析の効率化とコスト削減を実現しました。
BigQueryを始めとするGoogle Cloud Platformを導入した効果について、「PFM サービスは、1 日あたり 4,000 万件程度のログがアップロードされるので、この大量のログを検索したり、解析したりする場合、BigQuery は他社のサービスに比べて高速、かつ、安価に利用できます。」と語っています。
参考：
マネーフォワードの Fintech サービスを GCP が強力にサポート。BigQuery と GCS でログ解析の効率化とコスト削減を実現。｜Google Cloud ブログ
関西電力のグループ会社の一つであるK4 Digital株式会社は、DX推進に先駆けてGoogle Cloud Platformを採用し、BigQueryを中心とした分析基盤を構築します。
関西電力では年間数千億レコードが発生しており、これらの大量のデータを経済的かつスピーディーに処理するために、新しいデータ分析基盤の構築は不可欠なアプローチでした。
BigQueryを使った分析基盤の紹介や、分析のしやすさを広めることで、データドリブンな会社へ移っていくことを目指すとのことです。
参考：
クレジットカード事業、インターネットバンキングなどの金融事業を展開するアメリカの「Capital One」は、Snowflakeの導入によりパフォーマンスが4～6倍ほど向上しました。
同社は、数百TBのデータと20万以上のテーブルを抱えており、それらに対して数千人のユーザーが同時にクエリを実行する複雑な環境でした。
これに対して、Snowflakeは仮想ウェアハウスのマルチクラスター化によるスケールアウトで対応。金融機関として必須の、セキュリティやリスク要件を満たしていたことも導入要因のひとつです。
参考：
Capital One Joins Snowflake’s Series D Funding Round｜Snowflake
Capital One – Enabling the Future of Banking with Snowflake｜Snowflake
Amazonも出資する、ロンドンに本拠を置くフードデリバリー企業「Deliveroo」は、Snowflakeの導入によりリアルタイムな意思決定を実現しています。
それまで同社では、週末の繁忙期から週明けの月曜の朝にかけて、ETLと分析の処理が重なり作業負荷が増大し、経営陣は繁忙期のデータをリアルタイムに見られず、アナリストは翌週の計画を立てられないという課題が発生していました。
この課題を、Snowflakeの半構造化データのネイティブサポートや仮想ウェアハウスによるマルチクラスターが解消します。現在は、物流アルゴリズムを利用した配送効率化に役立てる施策も実施中とのことです。
参考：
インドのフードデリバリープラットフォーム・Swiggyは、Snowflakeを使用してクエリが20％高速化しました。
同社のプラットフォームには、160,000件以上のレストランと、25万人以上の配送パートナーが参加しており、顧客からの注文は毎月数百万件におよびます。
Snowflakeは、こうした複雑かつ膨大なクエリの最適化にも活躍します。
参考：
Swiggy: 20% Faster Queries for Food Delivery Platform with Snowflake｜Snowflake
データウェアハウスの導入を検討する際の注意点として、データウェアハウス環境を構築しただけでデータ分析がはかどるわけではない、という点は留意しておくべきでしょう。
データウェアハウスに集約したデータを分析し、意思決定に役立つインサイトを得るためには、次の要素が欠かせません。
・適切なデータソースとの接続
・適切なETLプロセスを経ること
・適切なデータマートの作成
・データ品質に対する継続的なレビュー
それぞれ解説します。
データソースが不足した状態でデータ分析を実施しても、有益なインサイトは得づらいでしょう。
意思決定支援として十分な分析結果が得られない場合は、接続したデータソースが誤っているか、あるいは不十分であることが考えられます。そのデータソース以外に、行いたい分析に適したデータソースがないか検討してみましょう。
データ品質向上のために、適切なETLプロセスを経ることも欠かせません。適切なETLプロセスとは、例えば次のようなものです。
・バリデーション
データが論理的な制約の範囲内に収まっているかのチェック。日付の有効性、郵便番号と住所の一致など。
・クレンジング
破損データ、重複データをチェックし、削除ないし報告する。
・ハーモナイゼーション
データを単一のフォーマットに統一する。気温を華氏/摂氏に変換する、日付フォーマットをMM/DDに統一するなど。
・エンリッチメント
他のソースからのデータとレコードを統合する。
データ量が膨大になると、データウェアハウスのままでは扱いづらい場合があります。その他にも、アクセスする部署・チームが増えると、データを扱いきれないユーザーも出てくるでしょう。
そうした場合は、限定的なビューをデータマートとして切り出すことで、より多くの人がアクセスしやすい環境を構築できます。営業チームには営業数値を、オペレーションチームにはオペレーションデータを、といった形です。
適切なデータマートの作成は、閲覧の制限にもつながり、セキュリティ向上効果も見込めます。
分析結果をもとに仮説を立て、実行に移して成果を検証する、といったサイクルを回しながら、随時データ品質に対してレビューを行うことも重要です。
元データとストアされたデータの間に不一致はないか、適切なデータソースが接続されているか、データマートは現場の求めるものになっているか、仮説を検証するうえでデータ品質は十分なものになっているか、など。
レビューをあげやすい仕組みづくりも合わせて検討すると良いでしょう。
自社の抱える課題や既存システムにより、構築すべき最適なデータ分析環境は異なります。業種によっては、顧客情報や機密データなど、セキュリティリスクを特定して適宜マスクする必要もあるでしょう。
マクロセンドは、データ自動収集システム、データレイク・DWH基盤構築、セルフデータプレパレーションツールの提供等、企業の状況・要望に合わせたデータ活用・DXを支援するサービスを行っております。興味のある方は、以下のサービス記事もご確認ください。
「データ分析環境を構築したいものの、自社の環境にどのサービスが適しているのかよくわからない」という場合や、「データ分析基盤を構築したものの活用しきれていない」といった場合も、ぜひご相談ください。
2021年6月4日
サービスに関するお問い合わせ
マクロセンドはこれまで、様々な業界のあらゆる課題を柔軟に解決してまいりました。
これまでに弊社が蓄積した知見・技術をもとに、お客様に寄り添ったご提案をさせていただきます。
