オペレーショナルデータウェアハウス (ついに、データウェアハウスが明確になりました)

ついにデータウェアハウスをわかりやすく説明してくれる人が出てきた

著者: 彭峰、宋文鑫、孫浩峰

出典: 華張テクノロジー

データウェアハウスは、管理上の意思決定プロセスをサポートするために使用される、主題指向で統合された、時間によって変化するが比較的安定したデータのコレクションです。データウェアハウスの主な機能は次のとおりです。

会社のビジネスデータモデルを確立します。
会社のデータソースを統合して、クレンジングされ管理されたデータをビジネスデータに関する唯一の真実にします。
上級管理者やビジネスアナリストがビジネス戦略の決定を下すのに役立つ、きめ細かい多次元分析をサポートします。
より高レベルのデータサービスと機械学習アプリケーション向けの履歴データの主なソースを提供します。

データウェアハウスの開発には 40 年近くの歴史がありますが、ビッグデータプラットフォームが登場する前は、主にリレーショナルデータベース (ここでは従来のデータウェアハウスと呼びます) でデータを処理していました。ビッグデータの出現後、データウェアハウスが担うタスクは変わっていませんが、その構築方法、構築内容、技術アーキテクチャは大きく変化しました。この記事ではこれについて簡単に紹介します。

通常、ビジネス運営をサポートするために現在のデータを保存する ODS とは異なり、データウェアハウスは履歴データと要約されたビジネスデータを記録します。多くのシステムでは、ODS に対応する永続データストレージはソースデータレイヤーとも呼ばれ、その意味は同じです。つまり、ビジネスシステムから収集された変更されていない OLTP 操作データセットです。 ODS は、OLTP データのインポート領域であるだけでなく、いくつかの分析ニーズにも対応できます。表 10-2 に、両者の簡単な比較を示します。

表10-2 ODSとデータウェアハウスの比較

従来のデータウェアハウスを紹介し、モデリングを詳細に説明した書籍はすでに多数あるため、ここでは簡単に紹介するだけにします。

データウェアハウスモデルは、概念モデル、論理モデル、物理モデルの 3 つのレイヤーに分かれています。

概念モデルはビジネスを抽象化し、実際のビジネスのデジタル記述を実現します。
論理モデルは、概念モデルを構造化して、その後の分析や管理に使用できるようにします。
物理モデルは、データベースやテーブルの設計など、論理モデルを実際の物理ストレージにマッピングします。

一般的に、データウェアハウスにおけるモデリング作業は主に論理モデル層で行われます。最も一般的な 2 つの方法は、エンティティリレーションシップ(ER) モデリングとディメンションモデリングです。

エンティティリレーションシップモデリングでは、エンティティとリレーションシップの 3NF モデルを使用して、エンタープライズビジネスアーキテクチャを記述します。ビジネスシステム (OLTP) の 3NF モデルは一般に特定のビジネスプロセスを対象としているのに対し、データウェアハウス (OLAP) の 3NF モデルは一般に企業全体のエンティティと関係の抽象化を対象としており、データの集約、統合、一貫性の管理を重視していることは注目に値します。

「データウェアハウスの父」として知られる Bill Inmon は、エンティティリレーションシップモデリングを提唱しています。たとえば、Teradata が金融業界向けに設計した FS-LDM (金融サービス論理データモデル) は、典型的なエンティティリレーションシップモデルです (図 10-2 を参照)。一般的な金融活動を 10 のテーマとそれらの関係性に抽象化してまとめます。 10 のテーマは、当事者、製品、契約、イベント、資産、財務、機関、地域、マーケティング、チャネルです。

図10-2 Teradata FS-LDM

エンティティリレーションシップモデリングの利点は、3NF に準拠し、データの冗長性が少なく、データの統合と管理が容易なことです。ただし、このアプローチは、構築サイクルが長く、設計者が設計および実装する前に企業のグローバルビジネスを深く理解する必要があり、ビジネスの急速な変化にうまく対応できないため、ビッグデータに基づくデータウェアハウスモデリングには推奨されません。

ディメンションモデリングは、データウェアハウスとビジネスインテリジェンスの分野の権威である Ralph Kimball によって提案されました。その中心的な考え方は、ビジネス分析と意思決定のニーズに基づいてモデルを構築することです。

具体的には、分析対象となる業務プロセスの基本情報（取引ID、顧客ID、店舗ID、商品ID、取引時間、取引金額など）をファクトテーブルに記録し、この業務プロセスに関連する一般情報（顧客情報、店舗情報、商品情報など）をディメンションテーブルに記録します。

エンティティ・リレーションシップ・モデリングとは異なり、ディメンション・モデリングでは、一般的にスター・モデルまたはスノーフレーク・モデルが使用されます。これらのモデルには、一定のデータ冗長性（たとえば、同じトランザクション内の複数の商品レコードで、トランザクション ID、顧客 ID、店舗 ID などが重複する場合があります）があり、3NF に準拠していません。ただし、エンティティリレーションシップモデリングに比べて次の利点があるため、データセンターのデータウェアハウスを構築する場合には、このモデリング方法をお勧めします。

比較的直感的で理解しやすいです。ファクトテーブル内のレコードにより、ビジネスプロセスのほとんどの情報を復元できます。
大量のコンピューティングリソースを消費する大量の結合操作を実行することなく、複雑なクエリをより効率的に処理できます。
ビジネスの変更や拡張を迅速にサポートし、複雑な依存関係を考慮することなく新しいビジネスモデルやディメンションを簡単に追加できます。
すぐに導入して成果を出すことができ、ビジネスシナリオをターゲットにして段階的に拡張していくことも可能です。

理論的には、Hadoop に基づいてデータウェアハウスを構築するための複数の階層化方法があります。一部のシステムには専用のデータレイクがありませんが、ODS をデータウェアハウスの一部として分類します。一部のシステムでは、データマートをデータウェアハウスの一部として分類することもあります。一部のシステムでは、次元データを別のレイヤーとしてカウントします。階層化の方法は異なりますが、一般的なデータウェアハウスの構築プロセスと考え方は原則的に似ています。

この記事では、データウェアハウスの構築を、データレイク、データウェアハウス、データマートの 3 つのレイヤーに簡単に分割します。その中で、データウェアハウス層はさらに詳細データ層(DWD、基本データ層とも呼ばれる) とデータサマリー層(DWS、一般データ層とも呼ばれる) に分けられます。さらに、図 10-3 に示すように、統合されたディメンションデータテーブルとメタデータ/マスターデータ管理システムを使用します。

図10-3 データウェアハウス階層

以下では、データウェアハウスの各レベルの主な機能、データモデル、主なデータ処理方法を紹介します。

多くのデータウェアハウスシステムでは、実際の状況に応じてこれらのレベルの機能を編成できることは注目に値します。たとえば、専用のオリジナル詳細データレイヤーを使用すると余分なスペースが大量に必要になるため、実際のプロジェクトでは、専用のオリジナル詳細データレイヤーを設定する代わりに、データレイク内の ODS をわずかに拡張することがよくあります。 ODS をデータウェアハウスの範囲に単純に計画するシステムもあります。

また、データマートは、ビジネスに特化しており直接使用できる特性を示すために、通常はデータウェアハウスとは区別されますが (そのため、一般的にはアプリケーションデータマートと呼ばれます)、データウェアハウスの構築には、一般的にデータマートが含まれます。実際のところ、名前は重要ではありません。重要なのは、各レイヤーの作業と設計原則を理解することです。

1. 生データ

ビジネスデータの元の詳細な履歴記録は、通常、ビジネスドメインに従って整理されます。場合によっては、このレイヤーは ODS によって直接実行されます。このレイヤーを個別に設定する場合、そのデータモデルは基本的に ODS と一致し、さらに入力時間、更新時間、処理バッチなど、データ処理に必要ないくつかの統合された拡張フィールドが追加されます。

場合によっては、テーブル名の統一、テーブル名の重複排除、いくつかの単純なディメンションテーブルのマージやコード変換など、名前とコードがこのレイヤーで標準化されることがあります。データは、増分的に整理したり、年、月、日ごとに分割したり、または完全に整理して、毎日最新の完全なスナップショットを保存したりできます。

2. 詳細データ

元の詳細データは、ID 変換、フィールドのマージ、ダーティデータ処理、ディメンションデータの標準化、感度低下処理、データ品質の検出など、ビジネスルールに従ってさまざまな方法でクリーンアップされます。

このレベルのデータモデルでは、ユーザー、製品、トランザクションなどのマスターデータとその標準ディメンションなどのマスターデータとディメンションデータモデルを決定し、ETL を通じて元のデータに対して予備処理を実行し、結果データを対応するクリーニング詳細テーブルに格納する必要があります。

一般的に、このレイヤーは、一部の非構造化データ (ログ、埋め込みデータ) を解析および管理し、サーバーログをユーザーアクセスの詳細リストに解析するなど、それらを構造化された詳細リストに変換する役割も担います。データガバナンス作業のほとんどはこのレイヤーで行われ、このレイヤーのワークロードも最大になります。

このデータのレイヤーのIDとディメンションデータ値は標準化され検証されており、データ分析の主な基礎として使用されます。クリーニングと処理のロジックは比較的複雑であり、処理中にエラーが発生した場合は再計算が必要になることがよくあります。したがって、このデータ層を効果的に管理するには、系統、バージョン、および変更管理が重要です。

3. 集計データ

サマリーデータは、クレンジングされた詳細データに基づいて生成された、きめ細かいサマリー集計結果です。このレベルのデータモデルは、通常、ビジネスニーズに基づいてスターモデルまたはスノーフレークモデルに従って構築された最も細かい粒度の要約であるため、データウェアハウスの分析機能は基本的に決定されます。

たとえば、チャネル、ユーザーの性別、年齢、収入、製品カテゴリ、および参照元ごとに製品の売上を照会する場合、このクエリを処理するための専用の要約ファクトテーブルが必要です。名前は次のようになります。
販売チャネル別、性別、年齢、所得、カテゴリ、リファラー。

このテーブル名には、関係する各ディメンションの値のあらゆる組み合わせが含まれており、日次または時間別の売上に分類されています。各フィールドのディメンション値は、対応するディメンションテーブルの値に対応する標準 ID です。

データウェアハウスのモデリングは主にこの段階で行われ、データウェアハウス分析の制限はここで確立されたデータモデルの機能です。

たとえば、上記のモデルでは、細分化されたデータの集計を使用して、sales_by_channel（先月の Taobao での売上）+ sales_by_referer（Baidu 広告によってもたらされた昨日の売上）などの集計クエリ（ロールアップ）に回答できるほか、「Baidu 広告を通じて 35 歳以上の高所得男性が Taobao で購入した 3C 製品の昨日の売上」などのドリルダウンクエリ（ドリルダウン）にも回答できます。

ただし、地域などの別の次元を追加すると、このモデルは機能しなくなります。この時点でモデルを修正して再計算する必要があります。

この状況では、1 つのアイデアとして、すべてのディメンションを事前に追加できるかどうかが挙げられます。このアプローチの主な問題は、次元の組み合わせの数が増えるにつれて、データエントリの数が急速に増加することです。

ディメンションが 50 個あり、各ディメンションに 100 個の値がある場合、販売レコードによって 5,000 個の要約レコードが生成され、実際の作業シナリオではさらに多くのレコードが生成される可能性があります。このようなソリューションは、膨大な量のデータと長時間かかる ETL タスクに加えて、集計クエリを実行する場合にも非効率的です。

このような高次元の結合データは一般にデータキューブと呼ばれ、その生成と計算の問題に対する従来の解決策が 2 つあります。

まず、ビジネスニーズに基づいて、最もよく使用される組み合わせを手動で決定します。たとえば、上記の表は、sales_by_channel_gender_age_income_referer_region と sales_by_channel_category_referer_region に分割できます。業務部門に他の組み合わせがある場合は、アドホック計算を使用して計算できますが、リアルタイムのやり取りは実現できません。
次に、Kylin のような事前に計算され、動的に計画されたキューブプランナーを使用します。

4. データマート

このレイヤーには通常、業務ドメインに応じて事業部門が設定した特定のトピックの概要表が含まれており、業務運営の状況を反映しています。データマート内のデータは主にサマリーデータファクトテーブルから取得されますが、近年ではデータ分析や機械学習アプリケーションを通じてデータレイクから直接データマートレポートを生成する人も多くなっています。結局のところ、要約詳細テーブルは以前の設計によって制限されます。

サマリーデータファクトテーブルとは異なり、データマートのデータテーブルには、ビジネス属性を直接反映するフィールドが含まれています。たとえば、データマートの顧客注文統計テーブルには、地域名と製品名が含まれます (ただし、必ずしも地域コードと製品コードが含まれるわけではありません)。

これは、データマートのデータテーブルが、さらなる分析のためにビジュアル BI ツールに直接入力されることが多く、地域や製品などのディメンションフィールドでは、クエリ中の結合操作を節約するために、ビジネス属性を直感的に表す名前が直接使用されるためです。

たとえば、前述の売上要約テーブルは次のようなテーブルを生成するかもしれません。
sales_by_channel_referer_region のデータマートレポートは、マーケティング部門がさまざまなチャネルや市場での広告のパフォーマンスを監視するために使用されます。

データマート内のデータは、通常、データアプリケーションのデータソースとなります。たとえば、前述の視覚化 BI ツールでは、データマート内のデータをグラフ形式で表示したり、データキューブ (多次元データ) の形式でデータマート内のデータに対して多次元分析 (ロールアップ、ドリルダウン、スライス、ダイス操作など) を実行したりできます。

データウェアハウスのデータガバナンスは、データ資産の管理レベルと利用効率を向上させることを目的として、実際のビジネス上の問題を解決することを目的としています。これはメタデータによって駆動され、データ標準管理、データ品質管理、データセキュリティ管理のさまざまな段階を接続して、データのライフサイクル全体をカバーする統合された完全なデータガバナンスシステムを形成します。データウェアハウスにおけるデータガバナンスは、主に次の問題を対象としています。

まず、データが散在し、乱雑で、理解しにくいです。多くの企業では、多数の事業ラインがあり、データソースが分散しており、システムを接続できず、情報の孤島が形成されています。データ収集基準が異なり、データがさまざまな業務システムに散発的に保存されるため、グローバルなデータ連携を形成することが困難です。
第二に、データ収集チャネルは単一であり、モデルは後方であり、効率は低く、コストは高くなります。ビジネスの成長はデータの増加をもたらしますが、従来のデータ管理モデルではビッグデータの増加に対応できません。チャネルに関して言えば、従来のデータ収集チャネルは単一、後方、オフラインです。方法面では、多くの企業の情報収集手段は依然として手作業による収集段階にあり、非効率的でコストがかかり、データの不一致を引き起こしています。
3 つ目は、統一されたデータ標準がなく、分析ツールが不足しており、データの使用が困難であることです。一方で、一貫性のないデータ標準により統合が困難になり、グローバルな連携が困難になります。一方、データ分析ツールが不足しているため、データ専門家だけに頼って企業のニーズに応えることは難しく、データのリアルタイムな変化や価値を把握することが困難です。これら 2 つの要因により、データ駆動型のビジネス開発を真に実現し、運用管理レベルを向上させることが困難になっています。
4 番目に、システムは時代遅れであり、データ管理のニーズを満たすことができず、潜在的なデータリスクが生じます。データが爆発的に増加するにつれ、多くの企業は変化するデータ需要に対応できず、規制要件を満たすことが困難になっています。同時に、データの危険性やリスクも存在します。

上記の問題を解決するために、データガバナンスでは一般的に次の機能コンポーネントを提供する必要があります。

メタデータ管理:統合されたメタデータ管理により、さまざまなユーザーのデータリソース使用ニーズを満たし、データ資産の視覚的な管理を実現できます。
データ品質管理:データ品質管理方法を通じて、データの収集、保存、使用は関連する品質要件を満たします。
データセキュリティ管理:偶発的または悪意のある理由によりデータが破壊、変更、または漏洩されないことを保証し、データアクセス権限の制御、データセキュリティサービス、データアクセス監査なども含まれます。
データ標準管理:標準管理、標準表示、標準監視などの機能を含む、データ標準のシステムツールサポートを提供します。
メタデータ管理インターフェース:メタデータクエリ、データの暗号化と復号化、データ資産登録インターフェース、および SSO インターフェースを提供します。
データ管理ポータル:データ資産クエリとデータ品質、データセキュリティ、メタデータ、およびデータ標準の統合ポータルが含まれます。

データガバナンスのプロセスでは、一般的に、データの収集、データの標準、データの整理と変換、データの使用などの問題を解決する必要があります。ここでは主にデータ標準とデータ品質に関する関連作業を紹介します。

データ標準とは、内部および外部でのデータの使用と交換の一貫性と正確性を保証する規範的な制約を指します。データ標準には通常、標準分類、標準情報項目 (標準コンテンツ)、および関連する公開コード (国コードや郵便番号など) の 3 つの要素が含まれます。

データ標準は、一般的に、基本データ標準と指標データ標準に分けられます。

基本的なデータ標準には、通常、データディメンション標準、マスターデータ標準、論理データモデル標準、物理データモデル標準、メタデータ標準、共通コード標準などが含まれます。
指標データ標準は、一般的に、基本指標標準と計算指標（複合指標とも呼ばれる）標準に分けられます。基本指標には一般にディメンション情報は含まれず、特定のビジネスおよび経済的な意味を持ちます。計算指標は通常、2 つ以上の基本指標から計算されます。

データ標準管理とは、データ標準を開発および実装するための一連の活動を指します。主な活動は次のとおりです。

データ標準化の必要性を理解する。
データ標準システムと仕様を構築します。
データ標準化の実施ルートと計画を策定し策定する。
データ標準の管理方法と実装プロセス要件を策定する。
データ標準の実装を促進するためのデータ標準管理ツールを構築する。
データ標準化作業の進捗状況を評価します。

データ標準管理の目標は、統一されたデータ標準を策定して公開し、制度的制約、システム制御などの手段を組み合わせることで、企業のビッグデータプラットフォームのデータの完全性、有効性、一貫性、標準化、および開放性を確保し、データ資産管理活動の参照基盤を提供することです。

多くの業界規制機関が業界データ標準を編成し、公開しています。例えば、中国銀行保険監督管理委員会は2018年5月に「銀行金融機関のデータガバナンスガイドライン」を発行しました。ビッグデータプラットフォームやデータミドルプラットフォームを構築する場合、ほとんどの銀行はこのデータ標準の内容を理解し、データミドルプラットフォームの構築に組み込む必要があります。

では、データ標準をデータミドルプラットフォームの構築にどのように統合すればよいのでしょうか?

一般的には、データ標準で記述されたデータが従わなければならないルール、例えばデータ値の範囲、データ項目間の関係性や制限などをコードで表現し、システムは管理が必要なデータセットに対してこれらのチェックコード（直接パッチコードもあります）を継続的に実行し、問題があればエラーを報告します。これにより、データシステム内のデータが仕様に準拠していることが保証されます。

多くの場合、これらの標準を満たすには、コードを直接記述する必要はなく、専用のデータガバナンスツールの DSL を使用してデータ品質ルールを構成する必要があります。

データ標準の作成は業界と密接に統合されており、通常、これらのデータ品質タスクを実装するための専用のデータガバナンスツールがあるため、ここでは詳しく説明しません。

04 データクレンジング

データガバナンスにおける最も重要なステップの 1 つは、データのクリーニングです。データクリーニングには 2 つの目的があります。1 つはデータ品質の問題を解決すること、もう 1 つはデータをマイニングに適したものにすることです。データクリーニングの結果は、さまざまなダーティデータを適宜処理し、データ統計、データマイニングなどに使用するための標準的でクリーンな連続データを取得することです。データ品質の問題には、一般に次の状況が含まれます。

データが不完全です。たとえば、患者の属性には性別、出身地、年齢などが欠落しています。
データは一意ではありません。たとえば、異なるソースからのデータが重複している可能性があります。
データは信頼できるものではありません。たとえば、同じインジケーターに、異なる値を持つ複数のソースからのデータが含まれる場合があります。
データは違法です。例えば、年齢が 150 歳を超えるなど、取得したデータが常識に反している場合などです。
データの不一致。たとえば、異なるソースからの異なる指標が実際には同じ意味を持つ場合などです。

データ品質の問題に対処するには、一般的に次の方法があります。

データの整合性:データを直接完了します。情報を直接補完する方法がない場合は、ID番号を使用して性別、出身地、生年月日、年齢などを推測するなど、他の情報を介して補完することができます。また、前のデータと次のデータを使用してデータを補完することもできます。たとえば、時系列にデータが欠落している場合は、前のデータと次のデータの平均を使用できます。欠損データが多い場合は、スムージングなどの処理を利用できます。
データの一意性:重複するレコードを削除し、 1 つのみ保持します。データベースの主キーまたはルールによって重複を排除できます。複雑な重複状況でデータを重複排除するための一連のルールを記述します。たとえば、異なるチャネルからの顧客データを同じキー情報に基づいて照合し、マージして重複を排除することができます。
データの権限:さまざまなチャネルの権限レベルを設定し、最も権限のあるチャネルのデータを使用します。
データの正当性:必須の法的ルールを設定します。これらのルールの範囲外のデータは最大値に設定され、無効とみなされて破棄されます。たとえば、フィールドタイプの法的ルールでは、日付フィールドの形式は年-月-日です。フィールドコンテンツの法的ルールでは、性別は男性、女性、または不明です。
データの一貫性:指標システム (測定)、次元 (グループ化、統計的基準)、単位、頻度、データなどを含むデータシステムを確立します。

一般的に、データをデータマイニングに適したものにする方法はいくつかあります。

高次元データの次元を削減:主成分分析とランダムフォレスト法が一般的に使用されます。
低次元データを処理します。集約、平均化、合計、最大値、最小値、離散化、クラスタリング、カスタムグループ化などの方法を通じて抽象化します。
無関係で冗長な情報を処理する:無関係で冗長なフィールドを削除します。
複数の指標値の処理:最大値/最小値の取得、平均値の取得など、複数の指標値の正規化。

著者について: Peng Feng、Zhiling Cloud Technology の共同創設者兼 CEO。彼は武漢大学でコンピューターサイエンスの学士号と修士号を取得し、メリーランド大学でコンピューターサイエンスの博士号を取得しています。彼の主な研究分野は、半構造化データのストリーミング用の高性能クエリエンジンです。彼は、SIGMOD、ICDE、TODS などのトップデータベースカンファレンスやジャーナルで数多くの画期的な論文を発表しています。彼は2011年にTwitterに入社し、ビッグデータプラットフォームのチーフエンジニア兼同社のアーキテクチャ委員会のビッグデータ責任者として、同社のビッグデータプラットフォームとパイプラインの構築と管理を担当しています。
Zhiling Cloud Technology の共同創設者兼 CTO、Song Wenxin 氏。彼は武漢大学でコンピューターサイエンスの学士号と修士号を取得し、ニューヨーク州立大学ストーニーブルック校でコンピューターサイエンスの博士号を取得しています。彼は Ask.com と EA (Electronic Arts) で働いていました。 2016年に中国に戻り、智玲雲科技有限公司を共同設立し、智玲雲技術チームを結成し、BDOSビッグデータプラットフォームオペレーティングシステムを開発しました。
Zhilingyun Technologyのマーケティングディレクター、Sun Haofeng氏。 CSDNコンテンツオペレーションズの元副編集長。クラウドコンピューティング、ビッグデータ、人工知能、ブロックチェーンなどの技術分野に注力しており、クラウドコンピューティング、ネットワーク技術、ネットワークストレージに関する深い理解を持っています。彼はメディア業界での豊富な経験と専門的なネットワークセキュリティ技術のスキルを持っています。彼は、エンタープライズレベルの IT 市場コミュニケーション、プロモーション、宣伝、執筆の分野で 15 年以上の経験を持っています。彼は業界で影響力のある記事を数多く執筆しています。

この記事は「クラウドネイティブデータミドルプラットフォーム: アーキテクチャ、方法論、および実践」から抜粋したもので、発行元によって承認されています。

さらに読む: 「クラウドネイティブデータセンター: アーキテクチャ、方法論、実践」

推薦： Twitter のビッグデータプラットフォームの元チーフエンジニアが執筆したこの本は、シリコンバレーと国内の経験を統合し、クラウドネイティブデータミドルウェアプラットフォームのアーキテクチャ、選択、方法論、実装パスを包括的に説明しています。国内外の専門家が共同で推奨しています。

<<: 運用データの翻訳 (DAU とは何ですか? 洗練された運用データ分析でよく使用される英語の略語については、この記事をお読みください)

>>: 企業にとっての業務データ分析の重要性（知恵の光：取引におけるデータ分析の重要性と応用）