Data Warehouseに沼った話

Data Warehouse


こんにちは。FLINTERS BASE 開発部 小杉です。

今回の記事は「梅雨にも負けない!ブログ祭り☔️」としての投稿です。

この会社に入社して早くも2年ですが、今回は未経験のデータエンジニアとしてキャリアを歩み始めた僕が、常日頃から疑問に感じていた「Data Warehouse」について配属後学びになったこと、自分が成長できたことをテーマに書きたいと思います。

Data Warehouseとは一体なんなのか

配属前のData Warehouseの理解

僕の配属前におけるData Warehouseに対する認識は、次のようなものでした。

  • Data Warehouseとは名前の通り、データの倉庫を意味するものである
  • 非構造化データや生データなど全てを保持するData Lakeから抽出をし、分析用として構造化されたデータを格納する
  • Data Warehouseのデータを通じて特定の目的用途に応じてData Martを作成する際に利用される

ざっくりとしたイメージとしては正しいと思うのですが、これを意識するあまり、僕はData Warehouseとは一体何なのかと頭を悩ませることになります。

配属後の疑問

僕が配属された組織では、データのサイロ化という課題を解消するために、既にデータの統合管理を行うサービスがオンプレミスで構築されていました。

これによりSSoT(Single Source of Truth)が組織的に実現されていることに僕は「すごい!」と驚いたと同時に、次の疑問が生まれます。

 

... 一体どれがData Warehouseなんでしょうか?というかData Warehousingとは?

 

前述のイメージを持っていた僕は、要するにAWS S3のようなストレージにデータを全部突っ込んでおいて、RedshiftやBigQueryとかをData Warehouseとして使うような形式をだと思っていました。つまり、データ分析基盤としては一つにまとまりつつも、Data LakeとData WarehouseとData Martっていう別々のシステムが稼働しているだろうと。

ただ、実際は統合基盤上にビジネスサイドのユーザーもData Martを作っていたりしたので、この曖昧さが自分の中のモヤモヤとしてありました。

加えて、実際の業務をしている時に「Data Warehousing」という言葉を聞くことが多くありましたが、既に構成が存在するものに対して「Warehousingする」という感覚が自分の中にイメージとしてなく、結局何すんの?状態でした。

Data WarehouseとData Warehousingの定義

上述の疑問に対して考える前に、一度言葉の定義を確認してみようと思います。

ここでは、DAMA-DMBoK 2ND EDITIONで記載されている「11章 Data Warehousing and Business Intelligence」からData Warehouse、Data Warehousingの定義を引用します。

Data Warehouse

Data Werehouseは以下の2つの主要なコンポーネントの組み合わせから成り立っています:

  1. 統合された意思決定をサポートするデータベース
  2. さまざまな運用および外部ソースからデータを収集、クレンジング、変換、保存するために使用される関連するソフトウェアプログラム

また、履歴要件、分析要件、および BI 要件をサポートするために、Data Warehouseには、そのWarehouseからのデータのサブセットコピーである依存関係のあるData Martも含まれる場合があります。

最も広義なコンテキストでは、Data Warehouseには、BI目的のデータ配信をサポートするために使用されるデータストアまたは抽出が含まれます。

なるほど、イメージとしてはデータを保存するデータベースに、データの処理をする様々なコンポーネントを含んだものをData Warehouseと定義できそうですね。より広く言えばさらにビジネス要件に近しい処理やData Martまで含むことができそうな気がします。

Data Warehousing

Data Warehousingは、Data Warehouse内のデータを維持管理するための抽出、クレンジング、変換、制御、およびロードの運用プロセスとみなします。

このプロセスは、ビジネスルールを適用し、適切なビジネスデータの関係性を維持することにより、運用データ上で統合され、ヒストリカルなビジネスコンテキストを実現することに重点を置いています。

英語版を日本語に直しているので、ちょっと解釈が難しいですが、意味的にはビジネス背景を考慮しながら、その要件を実現するために、Data Warehouseをどう構築、運用していくかというプロセスであると言えそうです。

Bill InmonとRalph KimballのData Warehousingアプローチ

Data Warehousingについてもう少し理解を深めるために、Data Warehouseを構築する際の2つの代表的なアプローチを簡単に紹介します。

Bill Inmonのアプローチ

InmonのData Warehouse構築のアプローチは以下のポイントが挙げられます。

  • トップダウンアプローチ: InmonはData Warehouseの構築をトップダウン方式で進めることを提唱しました。まず、全社的なデータモデルを設計し、その後、個別のData Martを構築します
  • 企業全体のData Warehouse: このアプローチでは、企業全体のData Warehouse(EDW:Enterprise Data Warehouse)を構築し、そこに全てのデータを集約します
  • 正規化されたデータモデル: Data Warehouseの中心には正規化されたデータモデル(3NF:第三正規形)があり、これによりデータの一貫性と冗長性の排除を図ります
  • データの統合: 様々なソースからデータを統合し、一つの一貫性のあるデータベースとして管理します
  • 歴史データの保存: Data Warehouseは、長期間にわたるデータを保存するためのものとして設計されており、過去のデータも保持します

Ralph Kimballのアプローチ

KimballのData Warehouse構築のアプローチは以下のポイントが挙げられます。

  • ボトムアップアプローチ: Kimballはボトムアップ方式を提唱しました。最初に個別のData Martを構築し、それらを統合して全体のData Warehouseを形成します
  • Data Mart中心: Data Warehouseは、特定のビジネスプロセスや部門ごとに設計されたData Martを中心に構築されます
  • ディメンションモデリング: Kimballのアプローチでは、Data Martはディメンションモデリング(スター・スキーマやスノーフレーク・スキーマ)を採用し、ユーザーがデータを簡単に理解しやすい形にします
  • ユーザーのニーズに応じた設計: Data Warehouseはユーザーのニーズに応じて設計され、迅速にビジネスの質問に答えるための柔軟性を持ちます
  • インクリメンタルな開発: このアプローチは段階的に開発が進むため、短期間での価値提供が可能です

DMBoK 2ND EDITIONには、より詳細なアーキテクチャが描かれていますが、以下はイメージを簡易的に捉えるために、ざっくりとしたアーキテクチャとして書いてみました。

InmonはまずData Warehouseを構築してからData Martへ広げていくイメージ。

KimballはData Martを構築し、それをDW BUSと呼ばれる共通化により統合してData Warehouseとして扱うイメージですね。

InmonとKimballのアプローチイメージ

Data Warehouseをどう解釈すべきか

さて、これまでの内容をまとめると

Data Warehouseとは、

  • 他のシステムからデータを保存、蓄積しており、統合されている
  • 分析のために、データを処理する様々なコンポーネントを保有している

であり、また、様々なビジネス背景に基づき、Data Warehouseを構築するアプローチのことをData Warehousingとまとめることができると思います。

自分が感じていたモヤモヤの正体

Data Warehousingについては上記の意味合いであったと理解できました。

その上で、

 

... 一体どれがData Warehouseなんでしょうか?

 

という疑問の答えはKimballのアプローチでData Mart先行でデータ基盤が統合されていたからでした。

加えて、これからData Warehouseとして統合されていく過程にあるので、中々自分の中で腹落ちさせることが難しかったように思えます。

今後はData Warehousingの方法論などをより深く見ていくことで、自分の利用しているデータ基盤の実態をより深く知ることができたら良いなと思っています。

参考文献