データウェアハウスは、論理的なクエリの実行、正確な予測モデルの構築、組織全体に影響を与えるトレンドの特定に役立ちます。
ベンダーの既成のソリューションを利用する場合でも、ゼロから始める場合でも、新しいデータウェアハウスを成功裏に導入するには、ある程度のウェアハウス設計が必要です。
ここでは、データウェアハウスそのものとその価値、そして組織のニーズを満たすデータウェアハウスを設計する方法について説明します。
データウェアハウスとは
データウェアハウスとは、組織が複数のソースや場所から収集した大量のデータを保存するための一元的な場所のことです。基本的にデータウェアハウスには、企業が分析を実行し、価値あるビジネスインサイトを収集するために必要なすべての重要データが格納されています。データウェアハウスは、ビジネスインテリジェンス（BI）活動を支援するデータの最終目的地なのです。
関連記事：2021年のビジネスインテリジェンスツールトップ17
データウェアハウスの主な利点には、以下のようなものがあります。
- 一貫性：データウェアハウスでは、複数のソースからデータを取得し、クリーニングすることで、すべてのデータ間に新たな整合性を持たせることができます。
- セキュリティ：データウェアハウスは、安定したエンティティであり、時間の経過とともに変化することがないため、セキュリティが確保されています。
- 時間の節約：データウェアハウスは、数秒以内にデータを取得する能力をユーザーに提供するため、組織や個々の従業員の作業時間の節約に役立ちます。
データウェアハウスを活用した例としては、Salesforceでリードの全体的な価値を把握しようとした時が挙げられます。Salesforceのデータをデータウェアハウスに取り込み、スキーマを設定し、クエリを実行すれば、どのマーケティング活動が最も価値の高い見込み客に繋がったのかを知ることができます。
データウェアハウスを設計する8ステップ
それでは、データウェアハウスを構築するための8つのコアステップについて説明します。
- ビジネス要件の定義（または要件収集）
データウェアハウスを設計することは、ビジネス全体に関わることです。データウェアハウスはビジネスのあらゆる分野に影響を与えるため、全ての部門が設計に参加する必要があります。データウェアハウスは、その中に含まれるデータによってのみ機能するため、各部門のニーズと目標をプロジェクト全体と一致させることが非常に重要です。
もし、すべての販売データをマーケティングデータと組み合わせることができなければ、全体的なクエリの結果は、いくつかの重要な要素を欠くことになります。どのリードが価値あるものかを知るには、マーケティングデータにかかっているからです。
すべての部門は、データウェアハウスの目的、それが自分たちにどのような利益をもたらすかを理解する必要があります。
この要件収集の段階では、以下の目的に焦点を当てる必要があります。
- 部門目標とプロジェクト全体の整合性
- ビジネス目標に関連したプロジェクトの範囲
- データ（分析に役立つデータは何か）と現在の技術スタック（データがサイロ化されている/活用されていない場所はどこか）を深く掘り下げることで、将来のニーズと現在のニーズの明確化
- システム障害時の対応プラン(ディザスターリカバリー)の作成
- セキュリティの各レイヤーの検討（脅威の検知、脅威の軽減、ID管理、監視、リスク軽減など）。
- コンプライアンスの必要性の予測と規制リスクの軽減策
上記は、データウェアハウス全体の設計図と言えますが、実際のこのフェーズは、ビジネスニーズを決定し、それをデータウェアハウスに整合させ、データウェアハウスソリューションに全員が賛同するようにすることがコア目的となっています。
- 物理的環境の設定
データウェアハウスは通常、開発、テスト、本番という3つの主要な物理環境を持ちます。これは標準的なソフトウェア開発のベストプラクティスを模倣しており、3つの環境は完全に別々のサーバー上に存在することになります。
なぜ3つに分ける必要があるのか？
- 本番環境に移行する前に、変更点をテストする方法が必要だから。
- セキュリティのベストプラクティスの中には、テスターや開発者が本番データにアクセスできないようにしなければならないものもあるから。
- データに対するテストの実行には、通常、本番環境からの極端なデータセットまたはランダムなデータセットが使用され、これらのテストを大量に実行するためには、独自のサーバーが必要だから。
- 開発環境を持つことは必須であり、開発環境は本番環境やテスト環境と比較して、独特の流動性を持って存在するから。
- 本番環境は作業負荷が非常に高く（ビジネス全体がそれを使っているから。）、その環境でテストや開発を行おうとするとチームメンバーにもサーバーにもストレスがかかるから。
- 3つの環境が稼働していれば、データの整合性を追跡しやすくなり、問題を抑制することも容易になるから。また、ヘッドハンティングの問題もワークロードへのストレスが少なくなり、本番環境とテスト環境のデータフローをエンドユーザーに影響を与えず、停止させることを可能にするから。
- テストを実行すると、しばしばブレークポイントが発生し、サーバー全体がハングアップすることがあり、これを本番環境では絶対に避ける必要があるから。
- テスト環境、開発環境、本番環境はそれぞれ異なるリソースを必要とし、すべての機能を1つのサーバーにまとめようとすると、パフォーマンスが極端に低下する可能性があるから。
BI開発は、決して終わることのない継続的なプロセスであることを忘れてはいけません。これは、ソフトウェア開発ライフサイクルに対するアジャイル/DevOpsアプローチに似ており、絶え間ない変更と適応規模が非常に大きいため、全て個別の環境が必要となります。
環境＝3つと決まっている訳ではなく、特定のビジネスニーズに合わせて更に環境を追加する企業もあります。例えば、品質保証のためにテスト環境とは別のステージング環境を構築することもできます。また、デモ環境や、統合のテストに特化した統合環境もあります。
コアとなる3つの環境は絶対に必要ですが、独自のビジネス目標に合わせて、さらに環境を重ねることができます。
- データモデリングの紹介
データモデリングとは、ウェアハウス内のデータ分布を可視化する作業のことです。青写真のようなイメージです。例えば、家を建てる前に、何がどこにあり、なぜそこにあるのかを知っておきたいのと同じ感じです。
データモデリングは、データ間の関係を可視化するのに役立ち、標準的な命名規則の設定、データセット間の関係の作成、包括的なIT目標に沿ったコンプライアンスとセキュリティプロセスの確立にも有効です。
データウェアハウスの設計において、データモデリングはおそらく最も複雑なフェーズです。そして、企業がウェアハウス設計に使用するデータモデリング技術は数多く存在します。
最も一般的なデータモデリング技法をいくつか紹介する前に、データウェアハウスとデータマートの違いについて説明します。
データウェアハウスは、分析やクエリを実行するためにデータを格納する（またはデータを押し込む）システムです。データマートは、データウェアハウス内の特定のビジネス機能のデータを格納する領域のことです。
例えば、データウェアハウスを丸ごと構築したとしましょう。それは素晴らしいことです。しかし、営業チームと法務チームとでは、そのデータウェアハウスを使用する方法が大きく異なるでしょう。また、特定のワークフローやデータセットは、特定のチームにとってのみ価値があるものです。データマートは、これらのチーム固有のデータセットをすべて保存し、クエリを処理する場所です。
データモデリングは通常、データマートレベルで行われ、データウェアハウスに分岐していきます。これは、データを他のデータとの関連においてどのように保存するかというロジックです。
代表的な3つのウェアハウスのデータモデル
ウェアハウス内の全体的なデータアーキテクチャを導くために、データモデルを選択し開発する必要があります。選択したモデルは、データウェアハウスとデータマートの構造に影響を与え、ETLツールの利用やデータに対するクエリの実行方法に影響を与えます。
- ETLソリューションの選択
ETL（抽出、転送、格納）は、現在の技術スタックや既存のストレージ・ソリューションからデータを取り出し、ウェアハウスに入れるために使用するプロセスです。使用するETLソリューションには、十分な注意を払う(こだわる)必要があります。
ETLは中間的な作業の大部分を担っているため、劣悪なETLプロセスを選択したり開発したりすると、ウェアハウス全体が壊れてしまう可能性があります。最適な速度、優れた視覚化、そして既存のアーキテクチャと新しいウェアハウス間で簡単かつ再現可能で一貫性のあるデータパイプラインを構築する能力が必要です。
そこで、Integrate.ioのようなETLツールが重宝されるのです。Integrate.io は、コンプライアンスと使いやすさのためにデータをクリーニングし、名目化しながら、貴重な技術的アーキテクチャのすべての間に超(ハイパー級に)視覚化されたデータパイプラインを作成します。
ETLプロセスの優劣によって、遅くて使いにくいデータウェアハウスと組織のあらゆるレイヤーで価値を発揮するシンプルで機能的なウェアハウスといった違いが生じることを覚えておいてください。
ほとんどの企業では、システムからデータウェアハウスにデータを取り込むためにETLが使用されます。その対極にある抽出、格納、転送（ELT）は、データのクレンジングと整理が行われる前にデータが直接ウェアハウスにロードされるため、ほとんどのカスタムビルドウェアハウスのパフォーマンスに悪影響を及ぼします。
関連記事：ETLとELT
- オンライン分析処理(OLAP)キューブ
データベース全体をゼロから設計する場合、または自社でOLAPキューブを保守する必要がある場合（基本的には専門の担当者が必要）には、OLAPキューブに対応する必要がある可能性が高いです。
したがって、ベンダー製のウェアハウスソリューション（RedshiftやBigQueryなど）を使用するのであれば、おそらくOLAPキューブを利用する必要はありません（いずれのソリューションでもキューブはほとんど使用されていません*）。
*注：RedshiftやBigQueryのデータマート上にOLAPキューブを構築できるベンダーソリューションもありますが、個人的に使用したことがないためお勧めはできません。
もし、アドホックなレポート作成にOLAPキューブを利用する必要があるBIツール群をお持ちの場合は、OLAPキューブを開発するか、ベンダーのソリューションを使用する必要があるかもしれません。
OLAPキューブとデータウェアハウス
データウェアハウスは、ビジネスデータを分析しやすい形式で保存し、さまざまなビジネスニーズに対応できるようにする場所です。
オンライン分析処理(OLAP)キューブは、データウェアハウスやデータマート内のデータを分析するのに役立ちます。多くの場合、OLAPキューブはレポート作成に使用されますが、それ以外にも様々な使用例があります。
データウェアハウスには複数のデータパイプラインから流入するデータがあるため、OLAPキューブを使用すると、すべてのデータを多次元形式で整理し、迅速かつ簡単に分析できるようになります。
OLAPキューブは、カスタムビルドが必要な場合もあれば、キューブの保守を支援するためのサポートが必要な場合もあります。
以下リソースは、MicrosoftやOracleによって書かれたOLAPキューブについての記事です。ぜひご覧ください。
- フロントエンドの作成
ここまではバックエンドの処理のみでしたが、ここからはフロントエンドについてご説明します。データクエリの結果をユーザーが即座に理解し、活用できるようにするためには、フロントエンドの可視化が必要です。
可視化を支援するツールは、市場に数多く出回っています。TableauやPowerBIなどのBIツールは、BigQueryを使用している場合に最適です。また、カスタムソリューションを開発することも可能ですが、これはかなりの負担になります。
ほとんどの中小企業は、上記のような確立されたBIキットに依存しています。しかし、企業によっては、臨機応変に分析ニーズに対応すべく、独自のBIツールを開発する必要がある場合もあります。例えば、大企業の営業部長は、テリトリー戦略のために特定のBIツールを必要とする場合があります。このツールは、販売目的の範囲を考慮してカスタム開発する必要があるかもしれない。
この段階では、レポート作成に細心の注意を払う必要があります。どの程度の頻度でレポート作成を行う必要があるのか。各自が独自のレポートを作成する必要があるのか。このような質問は、独自の要件に適合するBIツールキットを導き出すのに役立つでしょう。
最も重要なのはシンプルであることです。従業員は、派手な機能や複雑な機能に関心はなく、自分たちに必要な機能さえあれば良いのです。
- クエリの最適化
クエリを最適化するのは複雑なプロセスであり、顧客固有のニーズに合わせて実行する必要があります。一方、一般的で汎用的なルールがいくつかあります。
下記は、我々の経験をもとにしたお勧めです。
- 本番環境、テスト環境、開発環境のリソースをミラーリングしておく：これにより、ある環境から次の環境へプロジェクトをプッシュする際に、サーバーがハングアップするのを防ぐことができます。
- データの取得を最小限にする：結果のカラムだけが必要な場合は、データベース全体に対してSELECTを実行しないでください。代わりに、特定の列をターゲットにしてSELECTクエリを実行します。これは、クエリパワーに別途料金を支払っている場合には、特に重要なことです。
- OLAPベンダーの制限を理解する：BigQueryはハイブリッドSQL言語を使用し、RedShiftはPostgreのフォークをベースに構築されています。ベンダーに組み込まれた小さなニュアンスを知ることは、ワークフローを最大化し、クエリを高速化するのに役立ちます。
- ロールアウトを確立する
ウェアハウスを立ち上げる準備ができたら、教育、トレーニング、ユースケースについて考えます。多くの場合、エンドユーザーがウェアハウス(の機能)を利用し始めるのは、1〜2週間後です（少なくとも規模が大きい場合）。しかし、ロールアウトが完了する前に、十分なトレーニングを行う必要があります。
Integrate.ioの活用法
以上がウェアハウス設計の核となる要素です。これにより、ビジネスのあらゆる場面で具体的な価値を提供する機能的なデータウェアハウスを構築するための要件と手順をマスターしたことでしょう。しかし、1点念頭に置いて頂きたいのは、各々のビジネスニーズによって、このリストに含まれていない別の手順があるかもしれないということです。
Integrate.io は、データウェアハウスとの間でより効率的にデータをやり取りするために様々なソリューションを提供しています。気になっている方・興味のある方は、ぜひこちらからデモをご予約ください！
