データウェアハウスアーキテクチャ：従来型とクラウド

こんにちは、Habr！ データウェアハウスアーキテクチャのトピックについて多くのことが書かれていますが、私が偶然偶然見つけた記事のように、まだ簡潔かつ簡潔に、まだ会っていませんでした。



私の翻訳のこの記事に精通していただければ幸いです。 コメントや追加は大歓迎です！









（画像ソース）

はじめに

そのため、データウェアハウスのアーキテクチャは変化しています。 この記事では、従来のエンタープライズデータウェアハウスとクラウドソリューションを、初期コストの削減、スケーラビリティとパフォーマンスの向上と比較します。



データウェアハウスは、企業内のさまざまなソースからデータを収集し、このデータを使用して管理上の意思決定をサポートするシステムです。



企業は、従来のオンプレミスシステムではなく、クラウドベースのデータウェアハウスにますます移行しています。 クラウドデータストレージには、従来のストレージとは多くの違いがあります。

• 物理的な機器を購入する必要はありません。
• クラウドデータウェアハウスは、構成と拡張が高速で安価です。
• クラウドデータウェアハウスは通常、大規模な並列処理を使用するため、複雑な分析クエリをはるかに高速に実行できます。

従来のデータウェアハウスアーキテクチャ

以下の概念は、従来のデータウェアハウスを作成するために使用される確立された設計のアイデアと原則のいくつかを強調しています。

3層アーキテクチャ

多くの場合、従来のデータウェアハウスアーキテクチャは、次のレベルで構成される3層構造です。

• 下位レベル ：このレベルには、フロントエンドアプリケーションに使用されるトランザクションデータベースなど、さまざまなソースからデータを抽出するために使用されるデータベースサーバーが含まれます。
• 中間層 ：中間層には、データを分析および複雑なクエリにより適した構造に変換するOLAPサーバーが含まれます。 OLAPサーバーは、2つの方法で機能します。多次元データ操作を標準のリレーショナルOLAP操作にマッピングする高度なリレーショナルデータベース管理システムとして、または多次元データと操作を直接実装する多次元OLAPモデルを使用する方法です。
• トップレベル ：トップレベルはクライアントレベルです。 この層には、高レベルのデータ分析、レポート、およびデータ分析に使用されるツールが含まれています。

キンボールvs. インモン

データウェアハウスの先駆者であるBill InmonとRalph Kimballは、異なる設計アプローチを提供しています。



Ralph Kimballのアプローチは、特定の企業に属するデータウェアハウスであるデータマートの重要性に基づいています。 データウェアハウスは、レポートと分析を容易にするさまざまなデータマートの単なる組み合わせです 。 Kimballベースのデータウェアハウスプロジェクトは、ボトムアップアプローチを使用します。



Bill Inmonのアプローチは 、データウェアハウスがすべての企業データの集中ストレージであるという事実に基づいています。 このアプローチでは、組織はまず正規化されたデータウェアハウスモデルを作成します。 次に、倉庫モデルに基づいて次元データマートが作成されます。 これは、トップダウンデータウェアハウスアプローチとして知られています。

データウェアハウスモデル

従来のアーキテクチャには、データウェアハウスの3つの一般的なモデルがあります。仮想ストレージ、データショーケース、および企業データウェアハウスです。

• 仮想データウェアハウスは、ユーザーが1つのデータウェアハウスに格納されているかのようにすべてのデータに効果的にアクセスできるように、一緒に使用できる一連の個別のデータベースです。
• データショーケースモデルは 、特定のビジネスラインのレポートと分析に使用されます。 このストレージモデルでは、販売や財務など、特定の事業分野に関連する多数のソースシステムからの集約データ。
• 企業のデータウェアハウスモデルには、組織全体にわたる集計データの保存が含まれます。 このモデルは、データウェアハウスを、すべてのビジネスユニットからの統合データを備えたエンタープライズ情報システムの中心と見なします。

スターvs. スノーフレーク

スタースキームとスノーフレークスキームは、データウェアハウスを構築する2つの方法です。



スタースキーマには、ファクトテーブルに格納される中央データウェアハウスがあります。 グラフは、ファクトテーブルを一連の非正規化ディメンションテーブルに分割します。 ファクトテーブルには、レポートに使用される集計データが含まれ、ディメンションテーブルには保存されたデータが記述されます。



データがグループ化されているため、非正規化されたプロジェクトはそれほど複雑ではありません。 ファクトテーブルは、各ディメンションテーブルにアタッチするために1つのリンクのみを使用します。 より単純な星型の設計により、複雑なクエリの記述が大幅に簡素化されます。









スノーフレークパターンは、正規化されたデータを使用するという点で異なります。 正規化とは、すべてのデータ依存関係が定義され、各テーブルに最小限の冗長性が含まれるように、データを効率的に編成することを意味します。 このようにして、個々の測定テーブルは別々の測定テーブルに分岐します。



スノーフレークスキームは、使用するディスク領域が少なく、データの整合性を維持します。 主な欠点は、データにアクセスするために必要なクエリの複雑さです。各クエリは、対応するデータを取得するために複数のテーブル結合を実行する必要があります。

ETL対 ELT

ETLとELTは、ストレージにデータをロードする2つの異なる方法です。



ETL（抽出、変換、ロード）は、最初にデータソースのプールからデータを取得します。 データは一時的なステージングデータベースに格納されます。 次に、変換操作を実行して、データを構造化し、ターゲットデータウェアハウスシステムに適した形式に変換します。 次に、構造化データがストレージにロードされ、分析の準備が整います。









ELT（抽出、ロード、変換）の場合、データはソースデータプールから抽出された直後にロードされます。 中間データベースはありません。つまり、データはすぐに単一の中央リポジトリにアップロードされます。

データは、ビジネスインテリジェンスおよび分析ツールで使用するためにデータウェアハウスシステムに変換されます。

組織の成熟度

組織のデータウェアハウス構造も、現在の状況とニーズに依存します。



基本構造により、ストレージエンドユーザーはソースシステムから取得したサマリーデータに直接アクセスし、レポートを作成して、このデータを分析できます。 この構造は、データソースが同じタイプのデータベースシステムに由来する場合に役立ちます。









中間領域を備えたストレージは、多くの異なるデータ型と形式の異種データソースを使用する組織における次の論理的なステップです。 ステージング領域は、データを分析およびレポートツールを使用して簡単に要求できる一般的な構造化形式に変換します。









中間構造のバリエーションの1つは、データウェアハウスへのデータマートの追加です。 データマートは、特定の活動分野に関する要約データを保存するため、特定の分析形式でこのデータに簡単にアクセスできます。



たとえば、データマートを追加すると、財務アナリストは販売データに対してより簡単に詳細なクエリを実行し、顧客の行動を予測できるようになります。 データマートは、エンドユーザーのニーズに合わせてデータを調整することにより、分析を容易にします。

新しいデータウェアハウスアーキテクチャ

近年、データウェアハウスはクラウドに移行しています。 新しいクラウドデータウェアハウスは、従来のアーキテクチャに準拠しておらず、それぞれ独自のアーキテクチャを提供しています。



このセクションでは、最も人気のある2つのクラウドストレージであるAmazon RedshiftとGoogle BigQueryで使用されるアーキテクチャについて簡単に説明します。

アマゾン赤方偏移

Amazon Redshiftは、従来のデータウェアハウスのクラウドベースのビューです。



Redshiftでは、1つ以上のノードのコレクションを含むクラスターとしてコンピューティングリソースを準備および構成する必要があります。 各ノードには、独自のプロセッサ、メモリ、およびRAMがあります。 リーダーノードは要求をコンパイルし、要求を実行する計算ノードに渡します。



各ノードでは、データはスライスと呼ばれるブロックに保存されます。 Redshiftは列ストレージを使用します。つまり、各データブロックには、複数の列の値を持つ1つの行からではなく、複数の行の1つの列からの値が含まれます。









RedshiftはMPP（Massively Parallel Processing）アーキテクチャを使用して、各ノードのスライスに割り当てられるチャンクに大きなデータセットを分割します。 計算ノードは各スライスの要求を同時に処理するため、要求は高速です。 Leader Nodeノードは結果を結合し、クライアントアプリケーションに返します。



BIや分析ツールなどのクライアントアプリケーションは、オープンソースのPostgreSQL JDBCおよびODBCドライバーを使用してRedshiftに直接接続できます。 このようにして、アナリストはRedshiftデータでタスクを直接実行できます。



Redshiftは構造化データのみをロードできます。 Amazon S3やDynamoDBなどの事前統合システムを使用して、SSH接続でローカルホストからデータを転送するか、Redshift APIを使用して他のデータソースを統合することにより、Redshiftにデータをロードできます。

Google BigQuery

BigQueryアーキテクチャはサーバーを必要としないため、Googleはコンピューターリソースの割り当てを動的に制御します。 したがって、すべてのリソース管理の決定はユーザーから隠されています。



BigQueryを使用すると、顧客はGoogle Cloud Storageやその他の読み取り可能なデータソースからデータをダウンロードできます。 代替手段はストリーミングデータです。これにより、開発者はデータが利用可能になったときに、リアルタイムでデータウェアハウスにデータをラインごとに追加できます。



BigQueryはDremelと呼ばれるクエリエンジンを使用し、わずか数秒で数十億行のデータをスキャンできます。 Dremelは、超並列クエリを使用して、Colossusの基になるファイル管理システム内のデータをスキャンします。 Colossusは、クラスターと呼ばれるノードと呼ばれるさまざまなコンピューティングリソース間で64メガバイトの断片にファイルを配布します。

Dremelは、Redshiftに似た列データ構造を使用します。 ツリーアーキテクチャは、数千のマシンにリクエストを数秒で送信します。



単純なSQLコマンドを使用して、データクエリを実行します。

パノラマ

Panoplyは、包括的なデータ管理としてのサービスを提供します。 独自の自己最適化アーキテクチャは、機械学習と自然言語処理（NLP）を使用して、ソースから分析へのデータ転送をモデル化および合理化し、データから値を可能な限りゼロに近づけます。



Panoply Intelligent Data Infrastructureには次の機能が含まれています。

• クエリとデータの分析-ユースケースごとに最適な構成を決定し、時間をかけて調整し、インデックスを作成し、キー、ディスクキー、データタイプ、退避、パーティション化を並べ替えます。
• ベストプラクティスに従っていないクエリ（ネストされたループや暗黙的なキャストを含むクエリなど）を識別し、実行時間またはリソースの一部を必要とする同等のクエリに書き換えます。
• クエリパターンに基づいてサーバー構成を長期的に最適化し、どのサーバーセットアップが最適に機能するかを調査します。 このプラットフォームは、サーバーの種類をシームレスに切り替え、全体的なパフォーマンスを測定します。

クラウドストレージを超えて

クラウドベースのデータウェアハウジングは、従来のアーキテクチャアプローチに対する大きな改善です。 ただし、ユーザーは設定時に多くの問題に直面します。

• クラウドベースのデータウェアハウスへのデータのアップロードは簡単ではなく、大規模なデータパイプラインには、ETLプロセスの構成、テスト、およびサポートが必要です。 プロセスのこの部分は通常、サードパーティのツールによって実行されます。
• 更新、挿入、削除は複雑になる可能性があるため、クエリのパフォーマンスが低下しないように慎重に行う必要があります。
• 半構造化データの処理は困難です-リレーショナルデータベース形式で正規化する必要があり、大規模なデータフローの自動化が必要です。
• 通常、 ネストされた構造はクラウドデータウェアハウスではサポートされていません。 ネストされたテーブルを、データウェアハウスが理解できる形式に変換する必要があります。
• クラスターの最適化 。 Redshiftクラスターを設定してワークロードを実行するためのさまざまなオプションがあります。 ワークロード、データセット、またはクエリの種類が異なると、異なる構成が必要になる場合があります。 最適なパフォーマンスを実現するには、構成を常に確認し、必要に応じて追加で構成する必要があります。
• クエリの最適化 -カスタムクエリはベストプラクティスに従っていない可能性があるため、時間がかかります。 データウェアハウスが期待どおりに動作するように、ユーザーまたは自動化されたクライアントアプリケーションと連携してクエリを最適化できます。
• バックアップと復元 -データウェアハウスプロバイダーはデータをバックアップするための多くのオプションを提供しますが、構成するのは簡単ではなく、監視と細心の注意が必要です。

元のテキストへのリンク： panoply.io/data-warehouse-guide/data-warehouse-architecture-traditional-vs-cloud