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

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

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

出典: 華張テクノロジー

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

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

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