データウェアハウス（英語: Data Warehouse 、Data Warehouse、DW とも表記）は、保管、分析、レポート作成に使用されるデータシステムです。データウェアハウスの目的は、分析用の統合データ環境を構築し、企業に意思決定支援（Decision Support）を提供することです。

データウェアハウス自体はデータを「生成」せず、そのデータはさまざまな外部システムから取得されますが、同時に、データウェアハウス自体はデータを「消費」する必要がなく、結果はさまざまな外部アプリケーションに公開されます。これが「倉庫」と呼ばれる理由であり、「工場」と呼ばれない理由です。

2. シナリオケース: データウェアハウスはなぜ誕生するのでしょうか?

まず結論を言いましょう。私たちはデータを分析するためにここに来ており、分析結果は企業の意思決定をサポートします。ビジネスでは、情報は常に 2 つの目的で使用されます。

( 1 ) 運用記録の保管、( 2 )分析による意思決定。

データウェアハウスが誕生した理由を説明するために、中国寿保公司 ( chinalife )の開発を例に挙げてみましょう。

2.1 運用記録の保存

中国人寿保険 (グループ) カンパニーは、生命保険、損害保険、自動車保険、年金保険などを含む複数の事業分野を管轄しています。各事業部門の通常の運営には、顧客、保険契約、回収と支払い、保険引受、請求、その他の情報を含む情報の記録管理が必要です。

オンライントランザクション処理システム (OLTP )は、上記のビジネスニーズを正確に満たすことができ、その主なタスクはオンライントランザクション処理を実行することです。基本的な特徴は、フロントが受け取ったユーザーデータを即座にバックグラウンドに転送して処理し、非常に短時間で処理結果が得られることです。リレーショナルデータベース (RDBMS) は、 Oracle 、MySQL 、SQL Server などのOLTP の典型的なアプリケーションです。

2.2 分析的な意思決定

グループのビジネスが継続するにつれて、ビジネスデータはますます増加します。これはまた、運用に関連した多くの混乱を引き起こします。どの保険明細が劣化しているか、または不履行になっているかを判断できるでしょうか? 新規および更新ポリシーを効果的な方法で策定できますか? 請求手続きにおいて不正の可能性はありますか? 現在受け取っているレポートは、特定の事業分野のみに関するものですか? グループ全体レベルのデータは何ですか?

これらの問題を正しく理解し、関連する解決策を策定するためには、やみくもにテーブルを叩きつけることは決して不可能ではありません。最も安全なのは、ビジネスデータをもとにデータ分析を行い、分析結果に基づいた意思決定を支援することです。これをデータドリブンな意思決定と呼びます。

次に、データ分析をどこで実行するかという次の質問に直面します。データベースは大丈夫ですか？

2.3 OLTP 環境で分析を行うことは可能ですか?

はい、ただし必須ではありません。

OLTP システムの中核は、ビジネス指向、ビジネス支援、およびトランザクション支援です。すべての業務は読み取りと書き込みの 2 つの操作に分けることができ、一般的に、読み取りのプレッシャーは書き込みのプレッシャーよりもはるかに大きくなります。OLTP 環境でさまざまな分析を直接実行する場合は、次の問題を考慮する必要があります。

データ分析ではデータの読み取り操作も実行されるため、読み取りの負担が 2 倍になります。
OLTP は数週間または数か月分のデータのみを保存します。
データは異なるシステムの異なるテーブルに分散しており、フィールドタイプの属性は均一ではありません。

分析に含まれるデータのサイズが小さい場合は、ビジネスの閑散期に OLTP システム上で直接分析を実行できます。しかし、OLTP システムの運用に影響を与えることなく、さまざまな規模のデータ分析をより適切に行うためには、統合・統一されたデータ分析基盤を構築する必要があります。

このプラットフォームの目的は単純です。分析指向であり、分析をサポートし、OLTP システムから切り離されています。この需要に基づいて、データウェアハウスのプロトタイプが企業内に登場し始めました。

2.4 データウェアハウスの構築

データウェアハウスの定義にあるように、データウェアハウスは、分析のための統合データ環境を構築することを目的として、保存、分析、レポートに使用されるデータシステムです。この分析指向および分析支援システムを OLAP (Online Analytical Processing) システムと呼びます。データウェアハウスは OLAP の一種です。

China Life Insurance Company は、分析と意思決定のニーズに基づいてデータウェアハウスプラットフォームを構築できます。

3.データウェアハウスの主な特徴

データウェアハウスの目的は、分析のための統合データ環境を構築することであり、分析結果は企業の意思決定支援（ディシジョンサポート）を提供します。データウェアハウス自体はデータを「生成」せず、そのデータはさまざまな外部システムから取得されますが、同時に、データウェアハウス自体はデータを「消費」する必要がなく、その結果はさまざまな外部アプリケーションに公開されます。

3.1 主題指向_

データベースの最大の特徴はアプリケーション用のデータの編成であり、各業務システムは互いに分離されている場合があります。一方、データウェアハウスは主題指向です。テーマとは、企業情報システムにおけるデータをより高いレベルで統合、分類、分析、活用するための抽象概念です。論理的には、企業内の特定のマクロ分析分野に関与する分析オブジェクトに相当します。

演算処理 (従来のデータ) によるデータのセグメント化は、意思決定分析には適していません。トピックに基づいて編成されたデータは異なります。それらは独立したフィールドに分割されています。各フィールドには独自の論理的な意味がありますが、互いに重複することはありません。抽象レベルでのデータの完全で一貫性のある正確な説明が提供されます。

3.2 統合された_ _

テーマを決めたら、そのテーマに関連するデータを取得する必要があります。今日の企業におけるトピック関連データは、通常、分散、独立、異種の複数のオペレーティングシステムに分散されています。

したがって、データがデータウェアハウスに入る前に、データを統合および統合して、データの抽出、クリーンアップ、変換、要約を行う必要があります。このステップは、データウェアハウスの構築において最も重要かつ複雑なステップです。完了するタスクは次のとおりです。 :

同じ名前や同義語のフィールド、一貫性のない単位、一貫性のない語長など、ソースデータ内のすべての矛盾を統一する必要があります。
データの合成と計算を実行します。データウェアハウスでのデータ合成作業は、元のデータベースからデータを抽出するときに生成されることもありますが、多くはデータウェアハウス内で生成され、つまりデータウェアハウスに入った後に合成されます。

以下の図は、保険会社の統合データの簡単なプロセスを示しています。データウェアハウス内の「引受」トピックに関連するデータは、いくつかの異なる運用システムから取得されます。これらのシステム内のデータの名前は異なる場合があり、データ形式も異なる場合があります。さまざまなソースからデータウェアハウスにデータを保存する前に、これらの不一致を取り除く必要があります。

3.3 不揮発性と不揮発性（Non-Volatile ）

データウェアハウスはデータを分析するためのプラットフォームであり、データを作成するためのプラットフォームではありません。パターンを作成して変更するのではなく、データウェアハウスを使用してデータ内のパターンを分析します。したがって、データがデータウェアハウスに入ると、データは安定し、変化しません。

オペレーショナルデータベースは主に日常業務に使用されます。通常の業務に影響を与えることなく最新のデータを迅速に取得するには、データベースがリアルタイムで継続的にデータを更新する必要があります。データウェアハウスでは、過去の業務データが保存されていれば、業務ごとにリアルタイムでデータウェアハウスを更新する必要はなく、ビジネスニーズに応じて定期的に新しいデータを一括してデータウェアハウスにインポートします。。

データウェアハウス内のデータは、長期間にわたる履歴データの内容を反映しています。これは、さまざまな時点でのデータベーススナップショットのコレクションと、これらのスナップショットの統計、合成、再編成に基づいてエクスポートされたデータです。

データウェアハウスユーザーが実行するデータ操作のほとんどは、データクエリまたは比較的複雑なマイニングであり、データはデータウェアハウスに一度入力されると、通常は長期間保持されます。一般に、データウェアハウスでは多数のクエリ操作が行われますが、変更や削除の操作はほとんどありません。

3.4 時間-バリアント

データウェアハウスには、特定の日付、週、月、四半期、または年に関連するさまざまな粒度の履歴データが含まれています。データウェアハウスのユーザーはデータを変更できませんが、データウェアハウス内のデータが決して変更されないという意味ではありません。

分析結果は過去の状況のみを反映しており、ビジネスが変化すると、発見されたパターンは適時性を失います。したがって、データウェアハウス内のデータは、意思決定のニーズを満たすために時間をかけて更新する必要があります。この観点から見ると、データウェアハウスの構築はプロジェクトであるだけでなく、プロセスでもあります。

データウェアハウスデータの時間の経過に伴う変化は、次の側面に反映されます。

データウェアハウスのデータ有効期間の制限は、通常、運用データのデータ有効期間の制限よりもはるかに長くなります。
運用システムには現在のデータが保存されますが、データウェアハウス内のデータは履歴データです。
データウェアハウス内のデータは時系列順に追加され、すべて時間属性を持ちます。

4.データウェアハウス、データベース、データマート

4.1 OLTP 、OLAP

オンライントランザクション処理 (OLTP )と呼ばれる運用処理は、データ処理を主な目的とし、特定のビジネス向けのデータベースでの日常的な操作であり、通常は少数のレコードのクエリと変更を行います。ユーザーは、操作の応答時間、データのセキュリティ、整合性、同時にサポートされるユーザーの数などの問題をより懸念しています。従来のリレーショナルデータベースシステム ( RDBMS ) は、データ管理の主な手段として、主に業務処理に使用されます。

分析処理はオンライン分析処理OLAP( On-Line Analytical Processing )と呼ばれ、データ分析が主な目的となります。一般に、経営上の意思決定をサポートするために、特定のトピックに関する履歴データに対して複雑な多次元分析が実行されます。データウェアハウスは OLAP システムの代表例であり、主にデータ分析に使用されます。

OLTP と OLAP をさまざまな角度から比較してみましょう。

	OLTP	OLAP
情報元	現在の日々のビジネスデータのみが含まれます	OLTP や外部ソースを含む複数のソースからのデータを統合する
目的	アプリケーション系、ビジネス系、サポート業務	主題指向、分析指向、分析と意思決定をサポート
集中	現在	主に過去と歴史に向き合う、リアルタイムデータウェアハウス
タスク	読み取りおよび書き込み操作	読み取りは多く、書き込みはほとんどない
反応時間	ミリ秒	秒、分、時間、または日データ量とクエリの複雑さによって異なります
データ量	少量のデータ、MB、GB	ビッグデータ、TP、PB

4.2 データウェアハウスとデータベース

データベースとデータウェアハウスの違いは、実際には OLTP とOLAP の違いです。OLTP システムの典型的なアプリケーションは、一般にデータベースと呼ばれる RDBMSです。もちろん、このデータベースはリレーショナルデータベースを表しており、 Nosql データベースは議論の範囲内にないことをここで強調しておく必要があります。OLAP システムの代表的なアプリケーションは、一般にデータウェアハウスとして知られるDWです。

データウェアハウスは大規模なデータを保存しますが、大規模なデータベースではありません。
データウェアハウスの出現はデータベースに取って代わるものではありません。
データベースはトランザクション指向であり、データウェアハウスはサブジェクト指向です。
通常、データベースにはビジネスデータが保存され、データウェアハウスには通常、履歴データが保存されます。
データベースはデータを取得するように設計されており、データウェアハウスはデータを分析するように設計されています。

4.3 データウェアハウスとデータマート

データウェアハウス ( Data Warehouse )はグループ組織全体のデータを使用するためのものであり、データマート(Data Mart)は単一部門のデータを使用するためのものです。データマートはデータウェアハウスのサブセットと考えることができ、データマートを小規模データウェアハウスと呼ぶ人もいます。データマートは通常、マーケティングや販売などの 1 つの主題領域のみを扱います。これらはより小さく、より具体的であるため、一般に管理と保守が容易であり、より柔軟な構造を持っています。

以下の図では、さまざまな運用システムデータとファイルを含むその他のデータがデータソースとして使用され、 ETL (抽出、変換、読み込み)を通じてデータウェアハウスに入力されます。データウェアハウスとデータマートには異なる対象データが存在します。機能は部門に基づいています。機能は、購買、販売、在庫などの指定されたトピックに向けられており、ユーザーはトピックデータに基づいて、データ分析、データレポート、データマイニングなどのさまざまなアプリケーションを実行できます。

5.データウェアハウスの階層アーキテクチャ

5.1 データウェアハウスの階層化のアイデアと標準

データウェアハウスの特徴は、データ自体は生成せず、最終的にデータを消費しないことです。データウェアハウスに出入りするデータのプロセスに応じた階層化は当然のことのように思えます。各企業は、独自のビジネスニーズに応じてさまざまなレベルに分割できます。しかし、最も基本的な階層化の考え方は、理論的には、オペレーショナルデータレイヤー ( ODS )、データウェアハウスレイヤー( DW ) 、およびデータアプリケーションレイヤー( DA )の3 つのレイヤーに分割されます。実際のアプリケーションでは、企業はこの基本レイヤーに基づいて新しいレイヤーを追加して、さまざまなビジネスニーズを満たすことができます。

5.2 Alibaba データウェアハウスの 3 層アーキテクチャ

データウェアハウスの階層化の考え方と各レイヤーの機能的重要性をよりよく理解するために、以下は Alibaba が提供するデータウェアハウスの階層化アーキテクチャ図に基づく分析です。Alibaba Data Warehouse は、下から上にODS 、DW 、DAという非常に古典的な 3 層アーキテクチャを採用しています。メタデータ管理とデータ品質監視を通じて、データウェアハウス全体のデータのフロープロセス、依存関係、ライフサイクルを制御できます。今は突っ込んだ議論はせず、マクロ的な理解だけをしておきます。

5.2.1 ODS 層（オペレーションデータストア）

運用データ層は、ソースデータ層、データ導入層、データ一時記憶層、一時キャッシュ層とも呼ばれます。この層は、未処理の生データをデータウェアハウスシステムに保存し、ソースシステムと構造的に一貫しており、データウェアハウスのデータ準備領域です。基本データをデータウェアハウスに導入し、データソースシステムから分離し、基本データの履歴変更を記録することを主に担当します。

5.2.2 DW 层（Data Warehouse）

データウェアハウスレイヤーは、 ODS レイヤーのデータから処理されます。主に、データの処理と統合を完了し、一貫したディメンションを確立し、分析と統計用に再利用可能な詳細なファクトテーブルを構築し、公開粒度インジケータを要約します。具体的な内部部門は次のとおりです。

Common Dimension Layer ( DIM ): ディメンションモデリングの概念に基づいて、企業全体の一貫したディメンションが確立されます。
パブリックサマリー粒度ファクトレイヤー ( DWS 、DWB ): 分析の対象オブジェクトをモデリングドライバーとして使用し、上位層のアプリケーションおよび製品のインジケーター要件に基づいて、パブリックサマリー粒度ファクトテーブルが構築され、モデルは広いテーブルによって物理化される
詳細粒度ファクトレイヤー ( DWD ) :詳細ファクトテーブルの特定の重要なディメンション属性フィールドを適切に冗長化します。つまり、ワイドテーブル処理です。

5.2.3 DA 層（またはADS層）

データアプリケーション層はエンドユーザー向けであり、製品やデータ分析に提供されるデータをカスタマイズするためのビジネス向けです。フロントエンドレポート、分析チャート、KPI 、ダッシュボード、OLAP トピック、データマイニング、その他の分析が含まれます。

5.3 階層化の利点

階層化する主な理由は、データを管理する際にデータをより明確に制御できるようにするためであり、詳細には主に次の理由があります。

明確なデータ構造

各データレイヤーにはスコープがあるため、テーブルを使用するときに見つけて理解しやすくなります。

データリネージの追跡

簡単に言うと、私たちが最終的に企業に提示するのは、直接使用できるビジネステーブルですが、多くのソースから取得されており、ソーステーブルの 1 つに問題があった場合、迅速かつ正確に対応できるようにしたいと考えています。問題を特定し、その害の範囲を理解します。

開発の重複を減らす

データの階層化を標準化し、共通の中間層データを開発すると、膨大な反復計算を削減できます。

複雑な問題を単純化する

複雑なタスクを複数のステップに分解して完了します。各層は 1 つのステップのみを処理するため、比較的単純で理解しやすいです。また、データに問題があった場合でも、すべてのデータを修復する必要はなく、問題のある段階から修復すればよいため、データの精度を維持することも容易です。

生データの例外をマスクする

ビジネスの影響を保護し、ビジネスを一度変更した後にデータに再アクセスする必要はありません。

5.4 ETL 、ELT

5.4.1 背景

データウェアハウスはさまざまなデータソースからデータを取得し、データウェアハウス内でのデータ変換とフローはETL ( Extraction 、Transfer 、Load )のプロセスと考えることができます。しかし、実際の運用では、データをウェアハウスにロードするにはETL と ELTという 2 つの異なる方法があります。

5.4.2 コンセプト

ETLの抽出、変換、ロード

データはまず、データソースのプール(通常はトランザクションデータベース) から抽出されます。データは一時ステージングデータベース( ODS ) に保存されます。次に、変換操作が実行され、データが構造化され、ターゲットのデータウェアハウスシステムに適した形式に変換されます。構造化データはウェアハウスにロードされ、分析できるようになります。

ELTの抽出、読み込み、変換

ELT を使用すると、データはソースデータプールから抽出された直後にロードされます。専用の一時データベース( ODS )はありません。つまり、データは単一の集中リポジトリに即座にロードされます。データは、ビジネスインテリジェンスツール( BIツール )で使用できるようにデータウェアハウスシステムで変換されます。ビッグデータ時代のデータウェアハウスの特徴は非常に明白です。

6.シナリオ分析: Meituan-Dianping のホテルおよびホテルのデジタル倉庫構築の実践

6.1 アーキテクチャの変更

美団点評のワイン・旅行事業グループ内では、従来の共同購入から、予約や直接接続などのより豊富な商品形態に事業が移行しており、ビジネスシステムも急速に変化を繰り返しており、拡張性、安定性、使いやすさに影響を与えています。データウェアハウスでは、ユーザビリティに対してより高い要件が求められます。これに基づいて、Meituan は階層的かつテーマ別のアプローチを採用し、階層構造を継続的に最適化および調整しています。下の図は技術アーキテクチャの変化を示しています。

第 1 世代のデータウェアハウスモデルでは、当時の Meituan のビジネスシステム全体が比較的単一の製品形態 (共同購入) をサポートしており、ビジネスシステムにはすべてのビジネスカテゴリのデータが含まれていたため、プラットフォームが基本レイヤーを処理することが非常に重要でした。さまざまなビジネスラインの使用をサポートするには、プラットフォームが統合されて構築されていることが適切であるため、現段階では、チャイナワイナリーは比較的単純なデータマート、いわゆる小規模データウェアハウスのみを確立しています。

第 2 世代のデータウェアハウスモデルは、データマートの構築からホテル用のデータウェアハウスを直接構築することに変わり、ホテル独自のビジネスシステムのデータを処理する唯一のプロセッサーになりました。

Meituan と Dianping の統合に伴い、Liquor Travel 独自のビジネスシステムが比較的頻繁に再構築され、第 2 世代のデータウェアハウスモデルの安定性に大きな影響を及ぼしており、元の次元モデルがそのような状況に適応することは非常に困難です。急速な変化。中心的な問題は、使用されているビジネスシステムとビジネスラインの関係が複雑であり、ビジネスシステム間の違いが明らかであり、頻繁に変更されることです。

そのため、 ODS と多次元詳細レイヤーの間にデータ統合レイヤーが追加され、ビジネス主導のアプローチからテクノロジー主導の方法でデータウェアハウスの基本レイヤーが構築されました。この基本レイヤーを使用するための最も基本的な出発点は、Meituan のサプライチェーン、ビジネス、データの多様性にあります。ビジネスとデータが比較的単一で単純な場合、このレベルのアーキテクチャソリューションはおそらく適用できなくなります。

6.2 テーマの構築

実際、銀行、製造、電気通信、小売などの一部の伝統的な業界には、よく知られた BDWM (銀行データ)モデルなど、比較的成熟したモデルがいくつかあり、それらはすべて同様の業界の企業を通じて開発されています。 30 年間にわたるデータウェアハウスの構築で蓄積された経験は、継続的に最適化され、一般化されています。

しかし、美団が事業を展開するO2O業界には、参考にできる成熟したデータウェアハウスのテーマやモデルが存在しないため、美団は2年間の探索と構築を経て、現状により適した以下の7つのテーマをまとめました。 (将来的にはさらに増える可能性があります)。新しい) 。

6.3 全体的なアーキテクチャ

技術的およびビジネスのテーマを決定すると、データウェアハウスの全体的な構造が比較的明確になります。Meituan Liquor and Travel Data Warehouse の 7 つのテーマは基本的に 6 層構造で構築されており、テーマの分割はビジネスの観点に基づいており、階層的な分割はテクノロジーに基づいており、本質的にビジネスの組み合わせに基づいています。およびテクノロジー全体的なデータウェアハウスアーキテクチャ。

注文のトピックを例に挙げます。注文テーマを構築する過程で、美団は構造的な考え方に従い、まずサプライチェーンごとに注文関連のエンティティ (データ統合中間層) を構築し、次に適切な抽象化を行って、関連する注文を分解します。エンティティはマージされて注文エンティティ (データ統合レイヤー) を生成し、その後、一部のディメンション情報がデータ統合レイヤーの注文エンティティに基づいて拡張されて、後続のレベルの構築が完了します。

ビッグデータ Hive データウェアハウスの概要

1. データウェアハウスの概念