Azure データ アーキテクチャ ガイド

このガイドでは、Microsoft Azure でデータ中心のソリューションを設計するための体系的なアプローチについて説明します。 このアプローチは、顧客エンゲージメントから派生した実証済みのプラクティスに基づいています。

はじめに

クラウドによって、データの処理方法や格納方法など、アプリケーションの設計方法は変化しています。 _多言語永続化_ソリューションは、ソリューションのすべてのデータを処理する単一の汎用データベースではなく、特定の機能を提供するために個々に最適化された、複数の専用データ ストアを使用します。 その結果、ソリューション内のデータの観点が変わります。 単一のデータ レイヤーの読み取りと書き込みを行う複数レイヤーのビジネス ロジックはなくなりました。 代わりに、データ パイプラインを中心にして、データがソリューションを経由してどのように流れるか、どこで処理されるか、どこに格納されるか、パイプライン内の次のコンポーネントによってどのように使用されるかを記述するソリューションが設計されています。

本書の構成

このガイドは、データ ソリューションの 2 つの一般的カテゴリである "従来の RDBMS ワークロード" と "ビッグ データ ソリューション" を中心に構成されています。

従来の RDBMS ワークロード。 このワークロードには、オンライン トランザクション処理 (OLTP) とオンライン分析処理 (OLAP) があります。 OLTP システムのデータは、通常、参照整合性を維持するための事前定義スキーマと一連の制約を持つリレーショナル データです。 多くの場合、組織内の複数のソースに属するデータは、ETL プロセスを使用して移動および変換され、データ ウェアハウスに統合されている可能性があります。

従来の RDBMS ワークロード

ビッグ データ ソリューション。 ビッグ データ アーキテクチャは、従来のデータベース システムには多すぎる、または複雑すぎるデータのインジェスト、処理、分析を扱うために設計されています。 データは一括またはリアルタイムで処理されます。 通常、ビッグ データ ソリューションには、キー/値データ、JSON ドキュメント、時系列データなどの大量の非リレーショナル データが関係します。 多くの場合、従来の RDBMS システムは、この種のデータの格納には適していません。 NoSQL という用語は、非リレーショナル データを格納するように設計されたデータベースのグループを指します (多くの非リレーショナル データ ストアは SQL 互換のクエリをサポートしているため、この用語はあまり正確とは言えません)。

ビッグ データ ソリューション

この 2 つのカテゴリは互いに排他的ではありませんし、重複する部分もありますが、説明の組み立て方としては便利であると思われます。 このガイドでは、カテゴリごとに、関連する Azure サービスと、シナリオに適したアーキテクチャを含む一般的なシナリオについて説明します。 さらに、このガイドでは、オープン ソースのオプションを含め、Azure のデータ ソリューション向けのテクノロジの選択肢を比較します。 各カテゴリ内で、シナリオに適したテクノロジの選択に役立つ主な選択基準と機能のマトリックスについて説明します。

このガイドの目的は、データ サイエンスやデータベース理論を教えることではありません。このようなテーマについては関連する書籍を参照してください。 このガイドの目標は、シナリオに適したデータ アーキテクチャまたはデータ パイプラインを選択し、要件に最適な Azure サービスとテクノロジを選択できるようにすることです。 既に念頭に置いているアーキテクチャがある場合は、そのままテクノロジのオプションに進んでください。