More than 1 year has passed since last update.

Microsoft Certified: Azure Data Fundamentals(DP-900)で求められる知識を整理する

Posted at 2021-12-16

以下の資格を取得しました。

DP-900：Microsoft Azure Data Fundamentals

AI-900、AI-100、AZ-900に続いて、今年4つ目の取得となります。

本記事は、資格取得の過程で得た自身の知識の整理、定着化を狙って作成したものです。
今後、Azureを利用される方、資格取得を目指している方のお役に立てれば幸いです。

なお、章立てはDP-900：Microsoft Azure Data Fundamentals試験スキルのアウトライン(2021/10/25更新版)に沿っていますが、一部割愛している箇所がございます。
ご了承ください。

■1.コアデータの概念

概要

1.コアデータワークロードの種類
2.データ分析のコアコンセプト

■1.1.コアデータワークロードの種類

バッチデータとその処理

生データをバッファーに格納してグループで処理すること。
バッチ処理では、新しく受信したデータ要素はグループにまとめられ、後でグループ全体がバッチとして処理される。
利点
- 大量のデータを都合の良いときに処理できる。
- オフピーク時に実行するようにスケジュールできる。
欠点
- データの取り込みから結果の取得までに待機時間が発生する。
- バッチを処理する前に、バッチジョブのすべての入力データの準備ができている必要がある。
- バッチジョブ中に発生するデータ、エラー、プログラムクラッシュの問題により、プロセス全体が停止する。

ストリーミングデータとその処理

新しいデータを受信するたびに処理されること。
リアルタイムでデータが処理される。
バッチ処理とは異なり、次のバッチ処理間隔まで待機する必要がない。
ストリーミングデータ処理は、新しい動的データが継続的に生成されるほとんどのシナリオで役立つ。
即時のリアルタイム応答を必要とするタイムクリティカルな操作に最適である。

バッチデータとストリーミングデータの違い

バッチ処理とストリーミング処理には、データを処理する方法以外にも違いがある。

データスコープ

バッチ処理では、データセット内のすべてのデータを処理できる。
ストリーム処理では、通常、受信した最新のデータ、またはローリング期間内(最後の30秒など)にのみアクセスできる。

データサイズ

バッチ処理は、大規模なデータセットを効率的に処理する場合に適している。
ストリーム処理は、個々のレコードまたは少数のレコードで構成される "マイクロバッチ" を対象としている。

パフォーマンス

バッチ処理の待機時間は数時間。
ストリーム処理は直ちに実行され、待機時間は数秒または数ミリ秒である。

分析

複雑な分析を実行する場合はバッチ処理を使用する。
ストリーム処理は、単純な応答関数、集計、またはローリング平均などの計算に使用される。

リレーショナルデータの特性

リレーショナルデータベースの主な特性

データはすべて表形式である。
エンティティはテーブルとしてモデル化され、エンティティの各インスタンスはテーブル内の行であり、各プロパティは列として定義される。
同じテーブル内のすべての行には、同じセットの列がある。
テーブルには、任意の数の行を含めることができる。
主キーは、テーブルの各行を一意に識別し、2つの行が同じ主キーを共有することはできない。
外部キーは、関連付けられている別のテーブル内の行を参照する。
外部キー列の値ごとに、別のテーブル内の対応する主キー列に同じ値が含まれている行が存在する必要がある。
ほとんどのリレーショナルデータベースは、構造化照会言語 (SQL) をサポートしている。
SQLを使用すると、テーブルの作成、テーブル内の行の挿入、更新、削除、およびデータのクエリを行うことができる。

■1.2.データ分析のコアコンセプト

データの視覚化

視覚化

データの視覚化とは、情報とデータを視覚的に表すことである。
データ視覚化ツールでは、チャート、グラフ、マップなどのビジュアル要素を使用することで、データの傾向、外れ値、およびパターンを特定して理解するための利用しやすい方法が提供される。
Azureを使用する場合、最も一般的なデータ視覚化ツールはPower BIである。
Power BIを使用すると、複数の異なるデータソースに接続し、それらをデータモデルに結合することができる。

レポート

レポートは、組織のさまざまな領域の業績を監視するために、データを情報の概要にまとめるプロセスである。
レポートでは発生した内容を示すが、分析では発生した原因とその対処方法を説明することに重点が置かれる。

ビジネスインテリジェンス(BI)

ビジネスインテリジェンスの目的は、より適切な意思決定をサポートすることである。
ビジネスインテリジェンス(BI)という用語は、ビジネス情報の収集、統合、分析、および提示のためのテクノロジ、アプリケーション、およびプラクティスを指す。
ビジネスインテリジェンスシステムでは、事業運営の履歴、現在、および予測ビューが提供される。
ほとんどの場合、データウェアハウスに収集されたデータが使用されるが、ライブ運用データで作業することもある。
ソフトウェア要素では、レポート、対話型の "詳細な" ピボットテーブル分析、視覚化、および統計データマイニングがサポートされる。
アプリケーションでは、業績管理を含む目的で、販売、生産、財務、およびその他多くのビジネスデータのソースを取り込む。
多くの場合、比較のために同じ業界の他の会社に関する情報が収集される。
同じ業界の他の会社との比較を行うこのプロセスは、"ベンチマーキング" と呼ばれる。

基本的なグラフの種類

棒グラフ：横棒および縦棒グラフを使用すると、さまざまなカテゴリにわたる一連の変数がどのように変化するかを確認できる。
折れ線グラフ: 通常は経時的な一連の値全体の全体的な形が強調される。
散布図: 散布図には、2 つの数値間の関係が示される。
マトリックス: データを要約する表形式の構造である

ツリーマップ: ツリーマップは色分けされた四角形のグラフであり、サイズは各項目の相対値を表す。

分析手法

記述的分析

履歴データに基づいて、何が起きたか、起きているかという質問に答えるのに役立つ。
記述的分析手法では、大規模なデータセットを要約して、結果を利害関係者に説明する。

診断的分析

物事がなぜ発生したか、しているのかという質問に答えるのに役立つ。
診断的分析手法は、より基本的な記述的分析を補完するものである。
記述的分析から得られた結果を利用して、さらに掘り下げて、原因を究明する。

予測的分析

将来何が起こるかという質問に答えるのに役立つ。
予測的分析手法では、履歴データを使用して傾向を特定し、再発する可能性があるかどうかを判断する。
予測的分析ツールは、将来発生する可能性のあることについて貴重な分析情報を提供する。
技法としては、さまざまな統計的技法や、ニューラルネットワーク、デシジョンツリー、回帰などの機械学習技法がある。

処方的分析

目標またはターゲットを達成するためにどんなアクションを実行する必要があるかという質問に答えるのに役立つ。
予測的分析から得られた分析情報を使用して、データドリブンの意思決定を行うことができる。
処方的分析手法では、機械学習戦略を利用して、大規模なデータセット内のパターンを検出する。
過去の意思決定やイベントを分析して、さまざまな結果の可能性を推定することができる。

認知的分析

状況が変化した場合に何が発生する可能性があるかと、そのような状況にどうすれば対処できるかを理解するのに役立つ。
認知的分析では、既存のデータやパターンから推論を引き出し、既存のナレッジベースに基づいて結論を導き出した後、将来の推論 (自己学習のフィードバックループ) のために、これらの結果をナレッジベースに追加することを試みる。

ETL、ELT処理

ETL(Extract(抽出)、Transform(変換)、Load(読み込み))

さまざまなソースからデータを収集し、ビジネスルールに従ってデータを変換して、宛先データストアに読み込むために使用されるデータパイプライン。
生データは保存される前に取得および変換される。
抽出、変換、読み込みの各手順は、操作の継続的なパイプラインとして実行できる。
項目間の依存関係がほとんどない、シンプルなモデルのみを必要とするシステムに適している。
使用例
- 基本的なデータクリーニングタスク
- データの重複除去
- 個々のフィールドの内容の再フォーマット
ETL のよりストリーム指向のアプローチでは、スループットにより重点が置かれる。
ETLプロセスの読み込み時間は非常に長い
多くの場合、時間を節約するために3つのETLフェーズが並列に実行される。
ETLプロセスでは、ロードされているデータを変換するターゲットシステムは必要ない。(変換はETLシステムで行われる)

ELT(Extract(抽出)、Load(読み込み)、Transform(変換))

データが変換される前に格納されるという点でETLとは異なる。
データベース内の複数の項目に依存する複雑なモデルを構築する場合により適している。
多くの場合、定期的なバッチ処理が使用される。
使用可能な広範な処理能力を利用できるため、クラウドに適したスケーラブルなアプローチである。
ELTプロセスでは、ロードされるデータを変換するターゲットシステムが必要である。

データ処理の概念

データ処理ステージは、データが取り込まれ、収集された後に発生する。
データ処理では、未加工の形式でデータを受け取り、クリーニングし、より意味のある形式(テーブル、グラフ、ドキュメントなど)に変換する。
これを使用して、クエリを実行し、視覚化して、コンピューターによって解釈され、組織全体の従業員が使用する必要な形式やコンテキストを作成できる。
データ処理の目的は、生データを1つまたは複数のビジネスモデルに変換することである。

■2.Azureでリレーショナルデータを操作する方法

概要

1.リレーショナルデータのワークロード
2.リレーショナルAzureデータサービス
3.リレーショナルデータの基本的な管理タスク
4.SQL言語を使用したデータのクエリ手法

■2.1.リレーショナルデータのワークロード

ワークロード

レコードが頻繁に作成および更新される。
1つのトランザクションで複数の操作を完了する必要がある。
データベースの制約を使用して、リレーションシップが強制的に適用される。
クエリのパフォーマンスを最適化するために、インデックスが使用される。

データ型

データは高度に正規化される。
データベーススキーマが必要であり、強制的に適用される。
データベース内のデータエンティティ間の多対多リレーションシップ。
制約はスキーマで定義され、データベース内の任意のデータに適用される。
データには、高度な整合性が必要である。
- インデックスおよびリレーションシップは、正確に維持される必要がある。
データには、強固な一貫性が必要である。
- 全データがすべてのユーザーおよびプロセスと100%整合性があることを保証した方法で、トランザクションが処理される。
個々のデータエントリのサイズが小規模から中規模である。

リレーショナルワークロードに適したデータを提供する

オンプレミスか、クラウドか
オンプレミスでリレーショナルデータベースをホストする場合、企業では、データベースソフトウェアの購入に加えて、データベースを実行するために必要なハードウェアの維持も必要になる。

組織は、ハードウェアとソフトウェアの維持、修正プログラムの適用、データベースのバックアップと必要な場合の復元、およびプラットフォームの運用を維持するために必要な日常のあらゆる管理全般を実行する責任を負う。

スケーラビリティも問題となる。
システムのスケーリングを行う必要がある場合は、サーバーをアップグレードまたは追加する必要がある。

また、これらのサーバーにデータベースを展開する必要があり、運用が実行されている間にデータベースをオフラインにする必要があるため、非常に大変なタスクとなる。

クラウドでは、ほとんどの場合、ダウンタイムの発生なしに (または最小限のダウンタイムで)、これらの操作の多くをデータセンターのスタッフが処理できる。
ユーザーは、データそのものに集中し、管理上の問題は他の人々に任せることができる(これは、最終的にはAzureの料金として請求される)。

クラウドベースのアプローチでは、仮想テクノロジを使用して、企業のアプリケーションをオフサイトでホストする。
資本的支出はなく、データを定期的にバックアップすることができ、企業は使用するリソースに対してのみ料金を支払うのみである。

クラウドコンピューティングでは、すべてが構成済みであるため、ほぼ瞬時のプロビジョニングが可能である。
そのため、自社の環境に統合された新しいソフトウェアは、企業がサブスクライブしたらすぐに使用できる。
即時プロビジョニングでは、インストールと構成に費やされた時間がすべて排除され、ユーザーはすぐにアプリケーションにアクセスできる。

IaaSか、PaaSか

操作とデータベースをクラウドに移動する場合、通常は、IaaS、PaaS 2つのオプションがある。

IaaSアプローチは、Azure仮想マシン上にSQL Serverをインストールする方式である。

IaaSアプローチは、オペレーティングシステムレベルのアクセスを必要とする移行とアプリケーションに最適である。
SQL仮想マシンは"リフトアンドシフト" 、つまり、オンプレミスのソリューションをクラウド内の仮想マシンに直接コピーすることができる。
システムは、環境の変更を考慮した小規模な構成変更 (ネットワークアドレスの変更など) を除き、新しい場所でも以前と同じように機能する。

一方、PaaSアプローチでは、利用者が仮想インフラストラクチャを作成し、自分でデータベースソフトウェアをインストールして管理する代わりに、PaaSソリューションがそれを行う。

(予定しているデータベースの規模、ユーザーの数、必要なパフォーマンスに基づいて)必要なリソースを指定すると、必要な仮想マシン、ネットワーク、その他のデバイスがAzureによって自動的に作成される。

通常は、データの量と実行中の作業の量の変化に応じて、スケールアップまたはスケールダウン(リソースのサイズと数の増減)をすばやく行うことができる。

このスケーリングはAzureによって処理されるため、利用者が仮想マシンを手動で追加または削除したり、その他の形式での構成を実行したりする必要はない。

Azureで用意されているリレーショナルデータベース用の複数のPaaSソリューション

Azure SQL Database
Azure Database for PostgreSQL
Azure Database for MySQL
Azure Database for MariaDB
など

PaaSにはいくつかの機能上の制限があり、選択したデータベース管理システムのすべての機能を使用できるわけではない。

これらの制限は、多くの場合、セキュリティ上の問題を理由としている。
たとえば、基になるオペレーティングシステムとハードウェアがアプリケーションに公開されない場合がある。

リレーショナルデータ構造

リレーショナルデータベースはテーブルのセットで構成される。
テーブルには、0行(テーブルが空の場合)、またはそれより多い数の行が存在する。
各テーブルには固定された列のセットがある。
テーブル間のリレーションシップは、主キーと外部キーを使用して定義できる。
SQLを使用して、テーブル内のデータにアクセスすることもできる。
一般的なリレーショナルデータベースには、テーブルとは別に、データ編成の最適化やアクセス速度の向上に役立つ、その他の構造体が含まれている。
インデックスを使用すると、テーブル内のデータを検索しやすくなる。
テーブルのインデックスは、書籍の最後に記載される索引のようなものである。
データベースにインデックスを作成する場合は、テーブルの列を指定する。
インデックスには、テーブル内の対応する行へのポインターと併せ、このデータのコピーが並べ替えられた順序で格納される。
WHERE句でこの列を指定するクエリをユーザーが実行すると、データベース管理システムは、このインデックスを使用してテーブル全体を1行ごとスキャンする場合よりも速くデータを取り込むことができる。

一部のリレーショナルデータベース管理システムは、"クラスター化インデックス" もサポートしている。
クラスター化インデックスは、インデックスキーによってテーブルを物理的に再編成する。
ビューは、クエリの結果セットに基づく仮想テーブルである

sample.sql

CREATE VIEW P1Orders AS
SELECT CustomerID, OrderID, Quantity
FROM Orders
WHERE ProductID = "P1"

ビューに対してクエリを実行し、テーブルとほぼ同じ方法でデータをフィルター処理できる。
ビューでは、テーブルを結合することもできる。

■2.2.リレーショナルAzureデータサービス

PaaS、IaaS、およびSaaSソリューション

Azure Data Servicesについて詳しく調べる前に、Azureでデータベースをホストするさまざまな方法を説明するために使用される、いくつかの一般的な用語を理解しておく必要がある。

IaaS

"Infrastructure-as-a-Service(サービスとしてのインフラストラクチャ)" の略。
仮想マシンのセットを作成し、仮想ネットワークを使用してそれらを接続し、さまざまな仮想デバイスを追加できる。
仮想マシン上でDBMSなどのソフトウェアのインストールと構成を行う責任は利用者が負う。
このアプローチは、組織内でシステムを実行する方法と多くの点で似ているが、利用者がハードウェアの購入や保守について心配する必要がないという点が異なる。

PaaS

"Platform-as-a-service(サービスとしてのプラットフォーム)" の略。
利用者が仮想インフラストラクチャを作成し、自分でデータベースソフトウェアをインストールして管理する代わりに、PaaSソリューションがそれを行う。
必要なリソースを指定すると、必要な仮想マシン、ネットワーク、その他のデバイスがAzureによって自動的に作成される。
通常は、データの量と実行されている作業の量の変化に応じて、すばやくスケールアップまたはスケールダウン(リソースのサイズと数の増減)ができる。
このスケーリングはAzureによって処理されるため、利用者が仮想マシンを手動で追加または削除したり、他の形式での構成を実行したりする必要はない。

SaaS

"Software-as-a-Service (サービスとしてのソフトウェア)" の略。
通常、SaaSサービスは、クラウド内の仮想ハードウェア上でインストールおよび実行される特定のソフトウェアパッケージである。
Azure で使用できる一般的な SaaSパッケージには、Microsoft 365(以前の Office 365)などがある。

Azure SQLファミリの製品

Azure 仮想マシン上の SQL Server

利用者はオンプレミスのハードウェアを管理する必要なく、クラウド内で完全なバージョンのSQL Serverを使用できる。
オンプレミスで実行されているシステムから Azure仮想マシンへの移行は、オンプレミスのサーバーから別のサーバーへのデータベースの移動とまったく変わらない。
このアプローチは、移行と、PaaSレベルではサポートされない可能性があるオペレーティングシステム機能にアクセスする必要があるアプリケーションに適している。
ただし、SQL Serverソフトウェアを保守し、データベースを毎日稼働させ続けるためのさまざまな管理タスクを実行する責任は、引き続き利用者が負う必要がある。

Azure SQL Database

Azure SQL Databaseは、Microsoftによって提供されているPaaSオファリングである。
クラウドにマネージドデータベースサーバーを作成し、そのサーバー上にデータベースをデプロイする。
Azure SQL Databaseには複数のオプションが用意されている
- Single Database
- Elastic Pool：既定で複数のデータベースが同じリソース(メモリ、データストレージ領域、処理能力など)をマルチテナントで共有できるという点がSingle Databaseと異なる。
Azure SQL Databaseは、低コストと管理の最小化を実現するための最適な選択肢となる。
オンプレミスの SQL Serverインストールとの完全な互換性はない。
リンクサーバーがサポートされていない。
暗号化を提供することでデータを保護する。
- 転送中のデータ：トランスポート層セキュリティ
- 保存データ：Transparent Data Encryption
- 使用中のデータ：Always Encrypted
Azure SQL Databaseサーバーレスでは、ワークロードの需要に基づいてコンピューティングが自動的にスケーリングされ、1秒あたりのコンピューティング使用量に対して請求される。
これは、Azure SQL Databaseの単一データベース用のコンピューティングレベルである。
またサーバーレスコンピューティングレベルでは、アイドル期間にデータベースを自動的に一時停止する。
このときはストレージのみに課金され、再びアクティブになると自動的にデータベースが再開される。

Azure SQL Database Managed Instance

Single DatabaseオプションとElastic Poolオプションでは、SQL Serverで使用できる管理機能の一部が制限されるが、Managed Instanceでは、完全に制御可能なSQL Serverのインスタンスがクラウド内で効率的に実行される。
同じインスタンス上に複数のデータベースをインストールできる。
バックアップでは Azure Storage、テレメトリでは Azure Event Hubs、認証では Azure Active Directory、Transparent Data Encryption(TDE)ではAzure Key Vault、およびセキュリティとサポート機能を提供するいくつかの Azure プラットフォームサービスなど、他のAzureサービスに依存する。
通信はすべて暗号化され、証明書を使って署名される。
SQL Database Managed Instanceではリンクサーバーがサポートされるが、データベースに必要な他の高度な機能の一部が使用できない可能性がある。
自動フェールオーバーグループ機能を使用すると、サーバー上のデータベースのグループ、またはマネージドインスタンス内のすべてのデータベースの別のリージョンへのレプリケーションやフェールオーバーを管理できる。
フェールオーバーグループは、プライマリリージョンでの機能停止により、すべてまたは一部のプライマリデータベースが使用できなくなった場合に、1つの単位として別のリージョンにフェールオーバーできるマネージドインスタンス内の、または単一サーバーによって管理されるデータベースの名前付きグループである。

SQL Database Managed Instance、Single Database、Elastic Pool の違い

PostgreSQL用のAzureデータベース、MariaDB用のAzureデータベース、およびMySQL用Azureデータベース

■2.3.リレーショナルデータの基本的な管理タスク

リレーショナルデータサービスのプロビジョニングと展開について

プロビジョニングとは、Azure SQL Databaseなどのサービスプロバイダーによってサービスを作成および構成するために実行される一連のタスクのことである。
サービスプロバイダーにより、バックグラウンドで、サービスを実行するために必要なさまざまなリソース (ディスク、メモリ、CPU、ネットワークなど) が設定される。
これらのリソースがユーザーに割り当てられ、ユーザーがサービスを削除するまで、割り当てられたままになる。
そして課金される。
ユーザーは、必要なリソースのサイズ (ディスク領域、メモリ、コンピューティング能力、ネットワーク帯域幅の量) を決定するパラメーターを指定するだけである。

展開方法

Azureには、サービスのプロビジョニングに使用できるいくつかのツールが用意されている。
- Azure portal
- Azure コマンドラインインターフェイス (CLI)
  - Windows、macOS、Linux のコンピューターで実行できる。
- Azure PowerShell
  - CLI と同様に、PowerShell も Windows、macOS、Linux で使用できる。
- Azure Resource Manager テンプレート
  - デプロイするサービス(1 つまたは複数)を、JSON(JavaScript Object Notation)と呼ばれる形式のテキストファイルで記述する。

・データセキュリティコンポーネント

・基本的な接続の問題(オンプレミスからのアクセス、Azure VNetからのアクセス、インターネットからのアクセス、認証、ファイアウォールなど)

Azure のリレーショナルデータサービスに対する既定の接続では、世界からのアクセスは無効になる
接続を有効にするには、サービスの"ファイアウォールと仮想ネットワーク"ページを使用する。

Azureプライベートエンドポイントは、Azure Private Linkを使用するサービスに、プライベートで安全に接続するためのネットワークインターフェイスである。
プライベートエンドポイントでは、仮想ネットワークのプライベートIPアドレスを使用して、サービスが仮想ネットワークに実質的に組み込まれる。
サービスの[プライベートエンドポイント接続]ページでは、サービスへのアクセスが許可されるプライベートエンドポイントを指定できる。
Azure Active Directory(AD)認証を使用すると、データベースユーザーと他のMicrosoftサービスのIDを一元管理できる。
IDを一元管理すると、1か所でデータベースユーザーを管理できるので、アクセス許可の管理が容易になる。
これらのIDを使用して、リレーショナルデータサービスへのアクセスを構成することができる。
認証や承認とは別に、多くのサービスでは、Advanced Data Securityによって保護が強化されている
Advanced Data Securityでは、Threat ProtectionとAssessmentが実装されている。
Threat Protectionでは、サービスにセキュリティインテリジェンスが追加される。
このインテリジェンスでは、サービスが監視され、有害な可能性がある、またはサービスによって管理されるデータを侵害する可能性がある、異常なパターンが検出される。
Assessmentでは、潜在的なセキュリティの脆弱性が特定され、それを軽減するための措置が推奨される。

クエリツール(Azure Data Studio、SQL Server Management Studio、sqlcmdなど)

Azure Data Studio

Azure Data Studioには、さまざまなデータベースシステムを管理するためのグラフィカルユーザーインターフェイスが用意されている。
現在は、オンプレミスのSQL Serverデータベース、Azure SQL Database、PostgreSQL、Azure SQL Data Warehouse、およびSQL Serverビッグデータクラスターなどへの接続が提供されている。
これは拡張可能なツールであり、他のシステムに接続しているサードパーティの開発者からの拡張機能をダウンロードしてインストールしたり、多くの管理タスクを自動化するのに役立つウィザードを提供したりすることができる。
ノートブックはAzure Data Studioで利用できる新機能であり、テキスト、コード、画像、クエリ結果を含む可能性のあるドキュメントを作成して共有できる。
これらのドキュメントは、データベースの洞察を共有し、簡単に共有できるRunbookを作成するのに役立つ。
元々はデータサイエンスプロジェクトのオープンソースプロジェクトとして実装されていたが、Azure Data Studioは、SQLServerデータベースでも使用できるように実装した。
Azure Data Studioはバックアップを実行できる。
Windows、macOS、およびLinuxで使用可能。

SQL Server Management Studio(SSMS)

SQL Server Management Studioにはグラフィカルインターフェイスが用意されている。
これにより、データに対するクエリの実行、一般的なデータベース管理タスクの実行、およびデータベースのメンテナンスとサポート操作を自動化するためのスクリプトの生成が可能になる。
SQL Server Management Studioの便利な機能として、SQL Server Management Studioによって提供されるほぼすべての機能に対して Transact-SQLスクリプトを生成する機能がある。
これにより、DBAは多くの一般的なタスクをスケジュールして自動化することができる。
Transact-SQLは、トランザクション制御、例外とエラー処理、行の処理、宣言された変数を含め、いくつかの機能を構造化照会言語(SQL)に追加する、Microsoftの一連のプログラミング拡張機能である。
Azure Synapse Analyticsにクエリを実行できる。
Windowsでのみ使用可能。

sqlcmd

sqlcmdユーティリティはコマンドラインから実行する。
Cloud Shellでも使用できる。
サーバー、データベース、および資格情報を識別するパラメーターを指定する。
sqlcmdユーティリティを使用すると、Transact-SQLステートメントやシステムプロシージャ、スクリプトファイルを使用可能なさまざまなモードで入力できる。

SQL Server Data Tools(SSDT)

SQL Server Data Tools(SSDT)は、SQL Serverリレーショナルデータベース、Azure SQLのデータベース、Analysis Services(AS)データモデル、Integration Services(IS)パッケージ、およびReporting Services(RS)レポートを構築するための最新の開発ツールである。
SSDTを使用すると、サーバーインスタンスに接続せずに、プロジェクト内のオブジェクトの定義を追加、変更、または削除することで、オフラインデータベースプロジェクトを作成し、スキーマの変更を実装できる。

■2.4.SQL言語を使用したデータのクエリ手法

データ定義言語(DDL)とデータ操作言語(DML)

データ操作言語(DML)

DMLステートメントを使用して、リレーショナルテーブル内の行を操作する。
4つの主要なDMLステートメント
- SELECT：テーブルから行を選択する/読み取る
- INSERT：テーブルに新しい行を挿入する
- UPDATE：既存の行を編集する/更新する
- DELETE：テーブル内の既存の行を削除する

データ定義言語(DDL)

DDLステートメントを使用して、データベース内のテーブルやその他のオブジェクト(テーブル、ストアドプロシージャ、ビューなど)を作成、変更、および削除することができる。
最も一般的なDDLステートメント
- CREATE：データベース内にテーブルやビューなどの新しいオブジェクトを作成
- ALTER：オブジェクトの構造を変更
- DROP：データベースからオブジェクトを削除
- RENAME：既存のオブジェクトの名前を変更

Azure SQL Database、Azure Database for PostgreSQL、およびAzure Database forMySQLでリレーショナルデータをクエリする

Azure SQL Database
次のツールのいずれかを使用して、Azure SQL Databaseに保持されているデータにクエリを実行できる。

Azure portal のクエリエディター
コマンドラインまたはAzure Cloud Shellからのsqlcmdユーティリティ
SQL Server Management Studio
Azure Data Studio
SQL Server Data Tools

Azure Database for PostgreSQL
使用できるツール例

Azure Data Studio
pgAdmin
psql コマンドラインユーティリティ

Azure Database for MySQL
使用できるツール例

mysqlコマンドラインユーティリティ
MySQL Workbench

■3.Azureで非リレーショナルデータを操作する方法

概要

1.非リレーショナルデータワークロード
2.Azureで提供される非リレーショナルデータ
3.非リレーショナルデータの基本的な管理タスク

■3.1.非リレーショナルデータワークロード

非リレーショナルデータの特性

非リレーショナルデータベースの重要な点は、非常に柔軟な方法でデータを格納できることである。
データにスキーマは適用されず、代わりに、データを構造化する方法ではなく、データ自体に焦点が当てられる。
非リレーショナルシステムでは、エンティティの情報は、リレーショナルテーブルではなく、コレクションまたはコンテナーに格納される。
リレーショナルテーブルで見られる通常の列セットではなく、同じコレクション内の2つのエンティティのフィールドのセットが、異なっていても構わない。
各エンティティには一意のキー値が必要である。
コレクション内のエンティティは、通常、キー値の順序で格納される。
アプリケーションで一意キーまたはキーの範囲をクエリ条件として指定できる。
他のフィールドでデータをフィルター処理するには、エンティティのコレクション全体をスキャンし、各エンティティを順番に解析してから、各エンティティにクエリ条件を適用して、一致するものを探す必要がある。
より高度な非リレーショナルシステムでは、リレーショナルデータベースのインデックスと同様の方法で、インデックス付けがサポートされている。
その後のクエリでは、インデックスを使用して、キー以外のフィールドに基づいてデータを識別およびフェッチできる。
非リレーショナルデータベースを設計するときは、データベース管理システムの機能と、それによってサポートされる必要があるクエリの種類を理解しておくことが重要である。

非リレーショナルデータの種類

一般に、非リレーショナルデータは、半構造化と非構造化の2つのカテゴリに分類される。

半構造化データ

半構造化データとは、フィールドが含まれるデータである。
すべてのエンティティでフィールドが同じである必要はなく、エンティティごとに必要なフィールドだけを定義する。
データはアプリケーションで解析および処理できるような形式になっている必要がある。
これを行うための一般的な方法の1つは、各エンティティのデータをJSON(JavaScript Object Notation)ドキュメントとして格納することである。
データがJSONの文法に従っていれば、どのようなフィールドでも自由に定義できる。
アプリケーションでドキュメントを読み取ったら、JSONパーサーを使用してドキュメントをコンポーネントフィールドに分解し、データの個々の部分を抽出できる。

JSONの例

{
  "ID": "1",
  "Name": "Mark Hanson",
  "Telephone": [ 
    { "Home": "1-999-9999999" }, 
    { "Business": "1-888-8888888" }, 
    { "Cell": "1-777-7777777" }
  ],
  "Address": [ 
    { "Home": [
      { "StreetAddress": "121 Main Street" }, 
      { "City": "Some City" },
      { "State": "NY" }, 
      { "Zip": "10110" }
    ] },
    { "Business": [
      { "StreetAddress": "87 Big Building" },
      { "City": "Some City" },
      { "State": "NY" },
      { "Zip": "10111" }
    ] }
  ] 
}


{
  "ID": "2",
  "Title": "Mr",
  "Name": "Jeff Hay",
  "Telephone": [ 
    { "Home": "0044-1999-333333" }, 
    { "Mobile": "0044-17545-444444" }
  ],
  "Address": [
    { "UK": [
      { "StreetAddress": "86 High Street" },
      { "Town": "Some Town" }, 
      { "County": "A County" }, 
      { "Postcode": "GL8888" }, 
      { "Region": "UK" }
    ] },
    { "US": [
      { "StreetAddress": "777 7th Street" }, 
      { "City": "Another City" },
      { "State": "CA" },
      { "Zip": "90111" }
    ] }
  ]
}

他の形式としては、Avro、ORC、Parquetなどがある。
Avro(アブロ)は行ベースの形式で、Apacheによって作成されたものである。
- 各レコードには、レコード内のデータの構造を説明するヘッダーが含まれていおり、ヘッダーはJSONとして格納される。
- データはバイナリ情報として格納される。
- アプリケーションでは、ヘッダー内の情報を使用してバイナリデータを解析し、格納されているフィールドを抽出する。
- Avroは、データを圧縮し、必要なストレージとネットワーク帯域幅を最小限に抑えるのに非常に優れた形式である。
ORC(Optimized Row Columnar(最適化された行の列)形式)では、データは行ではなく列として編成される。
これは、Apache Hiveでの読み書き操作を最適化するために、HortonWorksによって開発された。
- Hiveはデータウェアハウスシステムであり、非常に大規模なデータセットに対する高速なデータ集計とクエリ実行がサポートされている。
- ORCファイルには、データの"ストライプ"が含まれている。
- 各ストライプには、列または列のセットのデータが保持される。
- ストライプには、ストライプ内の行へのインデックス、各行のデータ、および各列の統計情報(件数、合計、最大、最小など)が保持されているフッターが含まれる。
Parquet(パーケイ)は、別の列形式のデータ形式であり、ClouderaとTwitterによって作成された。
Parquetファイルには、行グループが含まれている。
各列のデータは、同じ行グループにまとめて格納される。
各行グループには、1つ以上のデータチャンクが含まれる。
Parquetファイルには、各チャンクに格納されている行のセットを記述するメタデータが含まれている。
アプリケーションでは、このメタデータを使用して、特定の行セットに対する適切なチャンクをすばやく検索し、これらの行に対して指定された列のデータを取得することができる。
Parquetは、入れ子になったデータ型の効率的な格納と処理に特化している。
非常に効率的な圧縮とエンコードスキームがサポートされている。

非構造化データ

非構造化データとは、もともとフィールドが含まれないデータのことである。
例としては、ビデオ、オーディオ、その他のメディアストリームがある。
各項目は、一定の形を持たないバイナリデータのBLOBであり、このデータ内で特定の要素を検索することはできない。
このようなデータは、それ専用に設計されたストレージに格納する場合がある。
Azureでは、通常、ビデオやオーディオのデータはブロックBLOB(Binary Large OBject)としてAzureストレージアカウントに格納する。

正しいデータストアを推奨する

NoSQL(非リレーショナル)データベースは、一般に4つのカテゴリに分類される。

キー値ストア

キー値ストアは、データの挿入とクエリに関して最も単純な(そして、多くの場合は最も速い)種類のNoSQLデータベースである。

キー値ストア内の各データ項目は、キーと値という2つの要素を持っている。
キーにより項目が一意に識別され、値により項目のデータが保持される。
値は、データベース管理システムに対して "非透過的"(値がデータベース管理システムによって非構造化ブロックとしてのみ認識されること)である。
項目はキーの順序で格納される。
書き込み操作は、挿入と削除に限定される。
指定されたキー値に対して1つの項目を取得し、項目の他のプロパティに基づいてクエリを実行する必要がない、大量のデータを格納する場合に適している。
例：AzureのTable Storage、Cosmos DBのTable API

ワークロード
- データアクセスにはディクショナリなどの単一のキーが使用される。
- 結合、ロック、統合は必要ない。
- 集計メカニズムは使用されない。
- 一般に、セカンダリインデックスは使用されない。
データ型
- 各キーが単一の値に関連付けられている。
- スキーマの適用はない。
- エンティティ間にリレーションシップはない。

ドキュメントデータベース

ドキュメントデータベースはキー値ストアの対極を表すものである。

ドキュメントデータベースは、値がドキュメントであるキー/値ストアである。
- この文脈での "ドキュメント" とは、名前付きフィールドと値のコレクションである。
ドキュメントデータベースでは、各ドキュメントに一意のIDがある。
ドキュメント内のフィールドはデータベース管理システムに対して透過的である。
ドキュメントデータベースにはJSON形式でデータが格納される。
または、XML、YAML、JSON、BSONなどの他の形式を使用してエンコードすることもできる。
ドキュメントにはエンティティのデータ全体が含まれる。
ドキュメントストアでは、すべてのドキュメントの構造が同じである必要はない。
この自由形式のアプローチにより、大きな柔軟性が提供される。
Azure Cosmos DBのCore(SQL)APIでは、ドキュメントデータベースの手法が実装されている。

ワークロード
- 挿入や更新の操作は共通である。
- 非オブジェクトリレーショナルインピーダンスは適合しない。
  - ドキュメントには、アプリケーションコードで使用されるオブジェクト構造のほうがより適合する。
- 個々のドキュメントが取得され、単一のブロックとして書き込まれる。
- データは、複数のフィールドにインデックスを必要とする。
データ型
- 非正規化された方法で、データを管理できる。
- 個々のドキュメントデータのサイズは比較的小さい。
- 各ドキュメントの種類で、独自のスキーマを使用できる。
- ドキュメントには、省略可能なフィールドを含めることができる。
  - ドキュメントデータは半構造化されている。まり、各フィールドのデータは、厳密には定義されていない。

列ファミリデータベース

列ファミリデータベースでは、データが行と列に編成されている。
列ファミリデータベースは、データストレージを、列ファミリと呼ばれる関連する列のコレクションに構成するキー/値データストアである。
ORCファイルやParquetファイルがこの構造の例となる。
列ファミリデータベースの真の力は、スパースデータの構築に対する非正規化されたアプローチにある。
最も広く使用されている列ファミリデータベース管理システムは、Apache Cassandraである。
Azure Cosmos DBでは、Cassandra APIにより列ファミリアプローチがサポートされている。

ワークロード
- ほとんどの列ファミリデータベースでは、極めて高速で書き込み操作を実行する。
- 更新および削除の操作は、ほとんど行われない。
- 高いスループットと低い待機時間でのアクセスを提供するように設計されている。
- より大規模なレコード内にある特定のフィールドセットへの簡単なクエリアクセスをサポートしている。
- 極めて高い拡張性。
データ型
- データは、キー列と1つまたは複数の列ファミリで構成されたテーブルに格納される。
- 特定の列は、個々の行別に変更できる。
- 個々のセルにはgetおよびputコマンド経由でアクセスできる。
- スキャンコマンドを使って、複数の行が返される。

グラフデータベース

グラフデータベースには、エンティティのインスタンスと考えることができるノードと、ノード間のリレーションシップを指定するエッジという、2種類の情報が格納される。
グラフデータベースを使用してエンティティを格納することはできるが、最も重視されるのは、これらのエンティティ同士の間にあるリレーションシップである。
グラフデータベースの目的は、アプリケーションでノードとエッジのネットワークを経由するクエリを効率的に実行し、エンティティ間のリレーションシップを分析できるようにすることである。
Azure Cosmos DBでは、Gremlin APIを使用してグラフデータベースがサポートされている。

ワークロード
- データ項目間に多数のホップが関連しているデータ項目間の複雑なリレーションシップ。
- データ項目間のリレーションシップは動的であり、時間と共に変化する。
- オブジェクト間のリレーションシップは最上位の扱いになり、外部キーと走査のための結合は必要ない。
データ型
- ノードとリレーションシップ。
- ノードは、テーブル行またはJSONドキュメントに似ている。
- リレーションシップはノードと同様に重要であり、クエリ言語で直接公開される。
- 複数の電話番号の保持者など、複合オブジェクトは、走査可能なリレーションシップと組み合わせて、個々のより小さなノードに分割される傾向がある。

非リレーショナルデータをいつ使用するかを決定する

非リレーショナルデータベースは、次のシナリオに非常に適している。

IoTとテレマティクス
- これらのシステムでは、通常、頻繁に発生するアクティビティによって大量のデータが取り込まれる。
- 非リレーショナルデータベースを使用すると、この情報を非常にすばやく格納できる。
- その後、Azure Machine Learning、Azure HDInsight、Microsoft Power BIなどの分析サービスで、このデータを使用できる。
- また、データがデータベースに到着するとトリガーされるAzure Functionsを使用して、リアルタイムでデータを処理できる。
小売とマーケティング
- Microsoftでは、Windows StoreおよびXbox Liveの一部として実行される独自のeコマースプラットフォームにCosmosDBが使用されている。
- また、カタログデータの格納用と、注文処理パイプラインでのイベントソーシング用に、小売業界でも使用されている。
ゲーム
- データベース層は、ゲームアプリケーションの重要なコンポーネントである。
- 最近のゲームはモバイル/コンソールクライアントでグラフィック処理を行うが、ゲーム内統計、ソーシャルメディア統合、スコアボードなどの個人向けにカスタマイズされたコンテンツの配信は、クラウドに依存している。
- 多くの場合、ゲームでは、魅力的なゲーム内エクスペリエンスを提供するために、読み取りと書き込みに対して1桁ミリ秒の待機時間が要求される。
- ゲームデータベースは高速であることが必要であり、新しいゲームのリリース時や機能の更新時に、要求レートの急増に対処できる必要がある。
Webアプリケーションとモバイルアプリケーション
- Azure Cosmos DBなどの非リレーショナルデータベースは、Webアプリケーションやモバイルアプリケーションでよく使用されており、ソーシャルインタラクションのモデル化、サードパーティサービスとの統合、充実した個人用エクスペリエンスの構築に適している。
- Cosmos DB SDK(ソフトウェア開発キット)を使用すると、一般的な Xamarinフレームワークを使用して、iOSおよびAndroidのリッチなアプリケーションを構築できる。

■3.2.Azureで提供される非リレーショナルデータ

非リレーショナルワークロード用のAzureデータサービス

Microsoft Azureには、非リレーショナルデータを格納するためのさまざまなテクノロジが用意されている。
各テクノロジには独自の強みがあり、特定のシナリオに適している。

Azure Table Storage
Azure BLOB Storage
Azure File Storage
Azure Cosmos DB

Azure Table Storage

Azure Table Storageは、クラウドに保持されているスケーラブルなキー値ストアである。
テーブルを作成するには、Azureストレージアカウントを使用する。
Azure Table Storageのテーブルでは、項目は "行" と呼ばれ、フィールドは "列" と呼ばれる。
Azure Tableを使用すると、半構造化データを格納できる。
テーブル内のすべての行にはキーが存在する必要があるが、その点を除けば、各行の列は異なっていても構わない。

高速にアクセスできるように、Azure Table Storageではテーブルがパーティションに分割されている。
パーティション分割は、共通のプロパティつまり "パーティションキー" に基づいて、関連する行をグループ化するためのメカニズムである。
同じパーティションキーを共有する行は、一緒に格納される。

テーブル内の列では、最大64KBの数値、文字列、またはバイナリデータを保持できる。
テーブルでは、パーティションキーと行キーを除いて、最大252個の列を保持できる。
行の最大サイズは1MBである。
Azure Table Storageは、膨大な量のデータをサポートすることが意図されている(サイズは最大で数百TB)。
テーブルに行を追加すると、Azure Table Storageによってテーブル内のパーティションが自動的に管理され、必要に応じてストレージが割り当てられる。
Azure Table Storageを使用すると、1つのリージョンで高可用性が提供される。
各テーブルのデータは、1つのAzureリージョン内で3回レプリケートされる。
可用性を高めるには、コストがかかるが、geo冗長ストレージにテーブルを作成できる。
- この場合、各テーブルのデータは、数百マイル離れた別のリージョンにさらに3回レプリケートされる。
Azure Table Storageは、データを保護するのに役立つ。
セキュリティとロールベースのアクセス制御を構成して、データを見る必要があるユーザーまたはアプリケーションだけが、実際にデータを取得できるようにすることができる。

主な利点

スケーリングが簡単。
テーブルに半構造化データを保持できる。
正規化されたリレーショナルデータベースで通常必要とされる、複雑なリレーションシップをマップして維持する必要がない。
行の挿入が高速。
パーティションキーと行キーをクエリ条件として指定した場合、データをすばやく取得できる。

欠点

複数のエンティティにまたがるトランザクション更新は保証されないため、一貫性を考慮する必要がある。
参照整合性はない。
行間のリレーションシップは、テーブルの外部で保持する必要がある。
キー以外のデータでフィルター処理や並べ替えを行うことは困難。

Azure BLOB Storage

Azure Blob Sorageは、大量の非構造化データ(BLOB)クラウドに格納できるサービスである。
Azure Table Storageと同様に、Azureストレージアカウントを使用してBLOBを作成する。

AzureでサポートされているBLOB

ブロックBLOB
- ブロックのセットとして処理される。
- 各ブロックのサイズは可変で、最大値は100MB。
- ブロックは、個別の単位として読み書きできる最小のデータ量。
- 1つのブロックBLOBで最大5万個のブロックを格納でき、最大サイズは4.7TBを超える。
- ブロックBLOBは、あまり変更されない不連続で大きなバイナリオブジェクトを格納するのに最適。
ページBLOB
- 固定サイズ512バイトのページのコレクションとして編成される。
- ランダムな読み書き操作をサポートするように最適化されている。
- 最大8TBのデータを保持できる。
- Azureでは、仮想マシン用の仮想ディスクストレージを実装するために、ページBLOBが使用されている。
追加BLOB
- 追加操作をサポートするために最適化されたブロックBLOB。
- 追加BLOBの末尾にのみブロックを追加できる。
- 既存のブロックの更新または削除はサポートされていない。
- 各ブロックのサイズは可変で、最大値は4MB。
- 追加BLOBの最大サイズは、195GB強。

3つのアクセス層

ホット層(規定値)
- 頻繁にアクセスされるBLOBに使用する。
- BLOBデータは、高パフォーマンスのメディアに格納される。
クール層
- この層はパフォーマンスが低く、ホット層と比較してストレージ料金が安くなる。
- アクセス頻度の低いデータに使用する。
- ホット層でBLOBを作成し、後でクール層に移行することができる。
- クール層からホット層にBLOBを戻すこともできる。
アーカイブ層
- この層では、ストレージコストは最も安くなるが、待機時間は長くなる。
- 失われてはならないけれども、必要になることはあまりない、履歴データ用に意図されている。
- アーカイブ層のBLOB、実質的にオフライン状態で格納される。
- データが使用可能になるまでに数時間かかることがある。
- アーカイブ層からBLOBを取得するには、アクセス層をホットまたはクールに変更する必要がある。
- その後、BLOBは"リハイドレート"される。
- リハイドレーションプロセスが完了した後でのみ、BLOBを読み取ることができる。

Azure File Storage

Azure File Storageでは、サーバーメッセージブロック(SMB)3.0プロトコルを使用してファイル共有が公開される。
これは、既存の多くのオンプレミスアプリケーションで使用されているものと同じファイル共有プロトコルである。
Azure File Storage内の共有へのアクセスは、Azure Active Directory Domain Servicesを通して提供される認証および承認サービスを使用して制御できる。
共有データはリージョン内でローカルにレプリケートされるが、第2のリージョンにgeoレプリケートすることもできる。

Azure File Storageはストレージアカウント内に作成する。
Azure File Storageを使用すると、1つのストレージアカウントで最大100TB のデータを共有できる。
1つのファイルの最大サイズは1TB。
Azure File Storageでは共有ファイルあたり最大2000のコンカレント接続がサポートされている。
Azure portalまたはAzCopyユーティリティなどのツールを使用して、Azure File Storageにファイルをアップロードできる。
Azure File Syncサービスを使用して、ローカル環境にキャッシュされている共有ファイルのコピーを、Azure File Storage内のデータと同期させることもできる。
すべてのデータは保存時に暗号化される。
また、Azure File Storageとアプリケーションの間で転送中のデータの暗号化を有効にすることができる。

2つのパフォーマンスレベル

Standardレベル
- ハードディスクベースのハードウェアがデータセンターで使用される。
- 最大300MB/秒のスループットを提供することが目標とされている。
Premiumレベル
- ソリッドステートディスクが使用される。
- より高いスループットが提供されるが、料金も高くなる。

Azure Cosmos DB

マルチモデルのNoSQLデータベース管理システム。
Azure Cosmos DBのデータベースエンジンのコアタイプシステムは、アトムレコードシーケンス(ARS)ベースである。
最初に、必要なサブスクリプションのAzureリソースグループにAzure Cosmosアカウントを作成してから、その下にデータベース、コンテナー、項目を作成する必要がある。
データとプロビジョニングスループットを管理するには、自分のアカウントで1つまたは複数のAzure Cosmosデータベースを作成し、そのデータベース内に1つまたは複数のコンテナーを作成することができる。
Azure Cosmosコンテナーは、スケーラビリティの基本単位である。
データはパーティション分割されたドキュメントのセットとして管理される。
- ドキュメント：キーによって識別されるフィールドのコレクション。
各ドキュメントのフィールドは異なる場合があり、フィールドには子ドキュメントが含まれることがある。
多くのドキュメントデータベースでは、ドキュメントの構造を表すためにJSON(JavaScript Object Notation)が使用される。
ドキュメントには、小さなバイナリオブジェクトを含めて、最大で2MBのデータを保持できる。
ドキュメントの一部として大きなBLOBを格納する必要がある場合は、Azure Blob Storageを使用し、ドキュメントにBLOBへの参照を追加する。
Cosmos DBでは、データベースとコンテナーでスループットを設定できる。
Cosmos DBには、一連の既知のインターフェイスを使用してこれらのドキュメントにアクセスできるAPIが用意されている。

サポートされているAPI

SQL API
- ドキュメントに対してSQLに似たクエリ言語が提供されており、SELECTステートメントを使用してドキュメントを識別および取得できる。
Table API
- Azure Table Storage APIを使用してドキュメントを格納および取得できる。
- 既存のアプリケーションを変更することなく、Table Storageから Cosmos DBに切り替えることができる。
MongoDB API
- MongoDBは、独自のプログラムインターフェイスを備えた、よく知られているもう1つのドキュメントデータベース。
- MongoDBアプリケーションに変更を加えることなく Cosmos DBデータベースに対して実行できる。
Cassandra API
- Cassandraは、列ファミリデータベース管理システム。
- CassandraデータベースとアプリケーションをCosmos DBに迅速に移行できる。
Gremlin API
- Gremlin APIにより、グラフデータベースインターフェイスがCosmos DBに実装される。

■3.3.非リレーショナルデータの基本的な管理タスク

リレーショナルデータの基本的な管理タスクと同じ考え方でよい。

非リレーショナルデータサービスのプロビジョニングと展開について説明する
Azureポータル、Azure Resource Managerテンプレート、Azure PowerShell、Azureコマンドラインインターフェイス（CLI）などの展開方法を説明する
データセキュリティコンポーネント（ファイアウォール、認証、暗号化など）を特定す
基本的な接続の問題を特定します（オンプレミスからのアクセス、Azure VNetからのアクセス、インターネットからのアクセス、認証、ファイアウォールなど）
非リレーショナルデータの管理ツールを特定する

■4.Azureでの分析ワークロード

概要

1.分析ワークロード
2.最新のデータウェアハウスのコンポーネント
3.Azureでのデータの取り込みと処理
4.Microsoft PowerBIでのデータの視覚化

■4.1.分析ワークロード

###トランザクションワークロード

オンライントランザクション処理（OLTP）ワークロードの特徴
- 大量の書き込みと中程度の読み取り
- 書き込み時のスキーマ
- 正規化されたデータ

データ分析ストア

データ分析ストアは、データの取り込み、保存、および分析のための大規模な並列ソリューションを提供する。
データは、スケーラビリティを最大限に高めるために複数のサーバーに分散される。

ワークロード
- データ分析
- 企業のBI
データ型
- 複数のソースからの履歴データ。
- 通常は、"star"または"snowflake"スキーマで非正規化され、ファクトテーブルおよびディメンションテーブルで構成されている。
- 通常は、スケジュールに基づいて新しいデータと共に読み込まれる。
- 多くの場合、ディメンションテーブルにはエンティティの複数の履歴バージョンが含まれ、"緩やかに変化するディメンション" として参照される。

トランザクションワークロードと分析ワークロードの違い

バッチとリアルタイムの違い

データウェアハウジングのワークロード

データウェアハウスソリューションが必要な時期を判断する

■4.2.最新のデータウェアハウスのコンポーネント

・最新のデータウェアハウジング向けのAzureデータサービス

・最新のデータウェアハウジングアーキテクチャとワークロード

Azure Data Factory

概要

クラウドベースのETLおよびデータ統合サービスを通じて、データの移動と変換を大規模に制御するデータドリブンのワークフローを作成できる。

Azure Data Factoryを使えば、各種のデータストアからデータを取り込むことができるデータ主導型のワークフロー(パイプライン)を作成し、スケジューリングできる。

コンピューティングサービス(Azure HDInsight Hadoop、Azure Databricks、Azure SQL Databaseなど)やデータフローを使用してデータを変換する複雑な ETLプロセスを視覚的に作成できる。
Azure Data FactoryパイプラインはパラメーターをDatabricksノートブックに渡すことができる。

さらに、ビジネスインテリジェンス(BI)アプリケーションから利用できるよう、Azure Synapse Analyticsなどのデータストアに、変換済みのデータを公開することもできる。

Azure Data Factoryを使うと、最終的に、生データを意味のあるデータストアとデータレイクに整理し、より的確な意思決定に活用できる。

データ統合サービス。
1つまたは複数のデータソースからデータを取得し、処理する形式に変換することが目的。
後続の処理のために、取り込んだデータをデータストアに書き込むことができる。
Azure Data Factoryによって実行される作業を操作のパイプラインとして定義する。
Azure Data Factoryは、SSISソリューションをクラウドにリフト&シフトして、すぐに利用できるようにする機能を提供する。

主要コンポーネント

パイプライン
- 1つの作業単位を実行するための複数のアクティビティから成る論理的なグループ。
- パイプライン内のアクティビティがまとまって1つのタスクを実行する。
- アクティビティを個別にではなく、セットとして管理できることがメリット。
アクティビティ
- アクティビティは、パイプライン内の処理ステップを表す。
- データ移動アクティビティ、データ変換アクティビティ、制御アクティビティの3種類のアクティビティがサポートされている。
データセット
- データセットは、データストア内のデータ構造を表している。
- アクティビティ内でデータを入力または出力として使用したい場合は、そのデータをポイントまたは参照するだけで済む。
リンクされたサービス
- データソースへの接続を定義するもので、Data Factoryが外部リソースに接続するために必要な接続情報を定義する。
データフロー
- あらゆるサイズのデータの変換に使用できるデータ変換ロジックのグラフを作成して管理する。
統合ランタイム：Integration Runtime (IR)
- アクティビティとリンクされたサービスとを橋渡しする。
- 異なるネットワーク環境間でデータ統合機能を提供するためにAzure Data FactoryとAzure Synapseのパイプラインによって使用されるコンピューティングインフラストラクチャ。
- 統合ランタイムの種類
  - Azure統合ランタイム
    - データコンプライアンスの要件が厳しく、データが地理的な特定の場所を離れないようにする必要がある場合は、Azure IRを明示的に特定のリージョンに作成し、リンクされたサービスがConnectViaプロパティを使用してこの IR を指すようにすることができる。
  - セルフホステッド(自己ホスト型)統合ランタイム
  - Azure-SSIS
    - 既存のSSISワークロードをリフトアンドシフトするために用いる

Azure Data Lake Storage

大量の生データのリポジトリ。
データは未加工で未処理であるため、読み込みと更新は非常に高速だが、データは効率的な分析に適した構造ではない。
処理され、分析の実行に適した形式に変換される前の、取り込んだデータのステージングポイントと考えることができる。
Azure Data Lake Storageは、基本的に Azure Blob Storageの拡張であり、ほぼ無制限のファイルシステムとして編成されている。
Data Lake Storage Gen2は、数百ギガバイトのスループットを安全に処理しながら、エクサバイト規模のさまざまな種類および量のデータを処理するよう設計されている。
このため、Data Lake Storage Gen2はリアルタイムソリューションとバッチソリューションの両方の基礎として使用できる。

特性

ファイルをディレクトリとサブディレクトリに整理してファイル編成を改善することができる。(階層的な名前空間)
- BLOBストレージでは、ディレクトリ構造を模倣することしかできない。
Portable Operating System Interface(POSIX)のファイルとディレクトリのアクセス許可をサポートしており、データに対してより細かいロールベースのアクセス制御(RBAC)を有効にすることができる。
- セキュリティプリンシパルは、Azureリソースへのアクセスを要求しているユーザー、グループ、サービス、または管理対象IDを表すオブジェクトであり、これらのセキュリティプリンシパルのいずれかに、ロールを割り当てることができる。
Hadoop分散ファイルシステム(HDFS)と互換性がある。
- Hadoopは非常に柔軟でプログラム可能な分析サービスであり、大量のデータを調べるために多くの組織で使用されている。

データの冗長性
- ローカル冗長ストレージ(LRS)を使用して1つのデータセンター内に、またはgeo冗長ストレージ(GRS)オプションを使用してセカンダリリージョンに、データの冗長性を提供するAzure Blobレプリケーションモデルを使用している。

Azure Databricks

Azure Databricksは、Microsoft Azureクラウドサービスプラットフォーム用に最適化されたData Analyticsプラットフォームである。
Azure Databricksには、データ集中型アプリケーションを開発するための3つの環境が用意されている。

Databricks SQL

データレイクでSQLクエリを実行したり、複数の視覚化の種類を作成してさまざまなパースペクティブからクエリ結果を探索したり、ダッシュボードを構築して共有したりするための、使いやすいプラットフォームが提供される。

Databricks Data Science エンジニアリング

Apache Sparkに基づく分析プラットフォームであり、単に "ワークスペース" と呼ばれることもある。

データエンジニア、データサイエンティスト、機械学習エンジニア間のコラボレーションを可能にする対話型ワークスペースを提供する。

ビッグデータパイプラインに使用されるデータ(生データまたは構造化データ)は、Azure Data Factoryを介して一連のバッチに分けてAzureに取り込まれるか、Apache Kafka、Event Hubs、IoT Hubを使ってほぼリアルタイムでストリーム配信される。

このデータは、長期永続保管を目的としたデータレイク(Azure Blob Storageまたは Azure Data Lake Storage)に到達する。

分析ワークフローの一環として、Azure Databricksを使用して複数のデータソースからデータを読み取り、それをSparkを使用して画期的な分析情報へと変えることができる。

Databricks Machine Learning

実験の追跡、モデルのトレーニング、機能の開発と管理、機能とモデルの提供のための管理サービスを組み込んだ、統合されたエンドツーエンドの機械学習環境である。

ビッグデータ処理、ストリーミング、機械学習を実現するために、Azureで実行される Apache Spark環境である。
大量のデータを非常に高速に使用して処理できる、非常に効率的なデータ処理エンジン。
多数のSparkライブラリがあり、SQL処理や集計などのタスクを実行し、データを使用して機械学習モデルを構築およびトレーニングするために使用できる。
一連のバッチタスクとして送信する前に、処理を段階的に定義およびテストできるグラフィカルユーザーインターフェイスが用意されている。
R、Python、Scalaなどの言語を使用して、Databricksスクリプトを作成し、データのクエリを実行することができる。
Databricksは様々なデータソースへのコネクトが用意されている。
- Databricksスノーフレーク(Snowflake)コネクタを使用して、スノーフレークに対してデータの読み取りと書き込みを行うことができる。
- スノーフレーク(Snowflake)スキーマは、スタースキーマのバリエーションであり、ディメンションテーブルの正規化を特徴としている。
- 「スノーフレーク」は、スタースキーマのディメンションテーブルを正規化する方法である。
- スノーフレークスキーマはスタースキーマに似ている。
- しかし、スノーフレークスキーマでは、ディメンションは複数の関連するテーブルに正規化されるが、スタースキーマのディメンションは非正規化の状態で、各ディメンションは単一のテーブルで表される。
- 複雑なスノーフレーク形状は、スノーフレークスキーマのディメンションが複雑で、複数のレベルの関係があり、子テーブルに複数の親テーブルがある場合に現れる。
スタースキーマ

スノーフレークスキーマ

Azure Synapse Analytics

Azure Synapse Analyticsは統合型の分析プラットフォームであり、データウェアハウス、ビッグデータ分析、データ統合、視覚化を1つの環境に結合したものである。

エンタープライズデータウェアハウスで使用されるSQLテクノロジ、ビッグデータのためのSparkテクノロジ、ログおよび時系列分析に使用されるData Explorer、データ統合とETLおよびELTのためのPipelines、Power BI、CosmosDB、AzureMLなどの他のAzureサービスとの緊密な統合の長所を組み合わせたものである。

概要

大量のデータを非常に高速に処理するように設計されている分析エンジン。
フラットファイル、Azure Data Lake、その他のデータベース管理システムなどの外部ソースからデータを取り込み、このデータを分析処理に適した形式に変換および集計できる。
このデータに対して複雑なクエリを実行し、レポート、グラフ、およびチャートを生成することができる。
Azure Synapse Analyticsは、超並列処理(MPP)アーキテクチャを使用しており、このアーキテクチャには、1つの制御ノードと、複数の計算(コンピューティング)ノードのプールが含まれている。
- 制御ノードはアーキテクチャの頭脳であり、すべてのアプリケーションと対話するフロントエンドとなる。
  - MPPエンジンは制御ノードで実行され、並列クエリを最適化および調整する。
  - 処理要求を送信すると、制御ノードによってより小さな要求に変換され、データの個別のサブセットに対して並行して実行される。
- 計算(コンピューティング)ノードは計算能力を提供する。
  - 処理されるデータは、ノード全体に均等に分散される。
Azure Synapse Analyticsは2つの計算(コンピューティング)モデル(SQLプール、Sparkプール)をサポートしている。
SQLプール
- 各計算(コンピューティング)ノードでは、Azure SQL DatabaseとAzure Storageを使用してデータの一部を処理する。
- Transact-SQLステートメントの形式でクエリを送信すると、Azure Synapse Analyticsによって実行される。
- 通常のSQL Serverデータベースエンジンとは異なり、Azure Synapse Analyticsではさまざまなソースのデータを受信できる。
- これを行うために、Azure Synapse AnalyticsにはPolyBaseというテクノロジが使用されている。
- PolyBaseを使用すると、リレーショナルソースと非リレーショナルソース (区切り付きテキストファイル、Azure Blob Storage、Azure Data Lake Storageなど) からデータを取得できる。
- 読み込んだデータをSQLテーブルとしてSynapse Analyticsサービス内に保存できる。

Sparkプール
- Notebooksで書いたコードで構成されるSparkジョブを実行する。
- Notebooks用のコードは、C#、Python、Scala、またはSpark SQL (Transact-SQLとは異なる方言のSQL)で書くことができる。
Azure Synapse SQL
- データウェアハウスおよびデータ仮想化のシナリオを実装できる分散クエリシステム。
- サーバーレスと専用の両方のリソースモデルが用意されている。
Azure Synapse Pipelines
- Azure Data Factory の機能を利用するクラウドベースの ETL およびデータ統合サービス
Azure Synapse Link
- クラウドネイティブのハイブリッドトランザクションと分析処理 (HTAP) の機能。
- 運用データにアクセスでき、リアルタイムに近い分析を実行できる。
Azure Synapse Studio
- すべてのAzure Synapse Analytics機能にアクセスできる単一のWeb UI。

Azure Analysis Services

Azure Analysis Servicesを使用すると、表形式モデルを構築し、オンライン分析処理(OLAP)クエリをサポートすることができる。
Azure SQL Database、Azure Synapse Analytics、Azure Data Lake、Azure Cosmos DBなど、複数のソースのデータを組み合わせることができる。
Analysis Servicesは、データソースを接続し、データを結合、フィルター、および集計するクエリを定義するために役立つグラフィカルデザイナーが含まれており、Analysis Services 内からこのデータを調べることができる。
Azure Analysis Servicesは、Azure Synapse Analyticsと機能の面で重複している部分が多いが、より小規模な処理に適している。
多くのシナリオでは、Synapse Analytics Analysis Servicesを併用することでメリットが得られる。
Synapse Analyticsのスケーラビリティにより、テラバイト単位のデータを処理し、より小さいサイズに削減して、このデータの多くを要約および集計する、より小さくて簡潔なデータセットに変換することができる。
次に、Analysis Servicesを使用してこの情報の詳細な調査を実行し、Power BIでこのような問い合わせの結果を視覚化できる。

AzureHDInsight

Azure HDInsightは、Azure環境で Sparkなどのテクノロジのプラットフォームを提供するビッグデータ処理サービスである。
HDInsightには、一連のコンピューターに処理を分散するクラスターモデルが実装されている。
このモデルは、ノードによってAzure SQL DatabaseではなくSpark処理エンジンが実行されていることを除いて、Synapse Analyticsで使用されるモデルと似ている。
Azure HDInsightは、Azure Synapse Analyticsと組み合わせて、またはその代わりに使用できる。
Sparkと同様に、HDInsightは、Apache Kafkaや Apache Hadoop処理モデルなどのストリーミングテクノロジをサポートしている。

Azure Stream Analytics

概要

Azure Stream Analyticsは、複数のソースからの大量の高速ストリーミングデータを同時に分析および処理するように設計された、リアルタイムの分析および複合イベント処理エンジンである。

パターンやリレーションシップは、デバイス、センサー、クリックストリーム、ソーシャルメディアフィード、アプリケーションなどのいくつかの入力ソースから抽出された情報内で識別できる。

これらのパターンを使用してアクションを起動し、アラートの作成、レポート作成ツールへの情報のフィード、または後で使用するための変換されたデータの保存などのワークフローを開始できる。

また、Stream AnalyticsはAzure IoT Edgeランタイムでも使用できる。
これにより、IoTデバイス上のデータを処理できるようになる。

Azure Stream Analyticsジョブは、入力、クエリ、および出力で構成される。
Stream Analyticsは、Azure Event Hubs(Apache KafkaからのAzure Event Hubsを含む)、Azure IoT Hub、または Azure Blob Storageからデータを取り込む。
SQLクエリ言語に基づくクエリを使用して、ストリーミングデータの一定期間にわたるフィルター処理、並べ替え、集計、および結合を容易に行うことができる。
各ジョブには変換されたデータの1つまたは複数の出力が含まれるため、分析した情報に応じてどのような処理を実行するかを制御できる。
例：

Stream Analyticsは、参照データの格納レイヤーとしてAzure Blob StorageおよびAzure SQL Databaseをサポートする。

■4.3.Azureでのデータの取り込みと処理

データ読み込みの一般的な方法

データの取り込みは、データウェアハウジングソリューションの最初の部分であり、それは間違いなく最も重要な部分である。
この時点でデータが失われると、結果として得られる情報が不正確になり、ビジネス上の意思決定の基礎となる可能性のある事実を表すことができなくなる可能性がある。
ビッグデータシステムでは、データの取り込みは、進行中の可能性のある大量のデータをキャプチャするのに十分な速度であり、このデータをタイムリーに処理するのに十分な計算能力を備えている必要がある。

Azureは、データの取り込みに使用できるいくつかのサービスを提供している。

Azure Data Factory
PolyBase
SQL Server Integration Services
Azure Databricks
など

AzureData Factoryのコンポーネント(パイプライン、アクティビティなど)

Azure Data Factoryは、オンプレミスとクラウドの両方で、さまざまなソースから生データを読み込むことができるデータの取り込みと変換のサービスである。
Data Factoryは、データを取り込むときに、データウェアハウスなどのリポジトリにデータをロードする前に、データをクリーンアップ、変換、および再構築できる。
データがデータウェアハウスに入ると、それを分析できる。
Azure Synapse Analyticsのデータ統合機能は、Azure Data Factoryに基づいており、Azure SynapseStudio内から使用できる。

Data Factoryには、データエンジニアに完全なエンドツーエンドのプラットフォームを提供する一連の相互接続されたシステムが含まれている。
静的データをロードできるが、ストリーミングデータを取り込むこともできる。
Data Factoryは、オーケストレーションエンジンを提供する。
オーケストレーションは、他のサービスを指示および制御し、それらを相互に接続して、それらの間でデータが流れるようにするプロセスである。
Data Factoryは、オーケストレーションを使用して、さまざまなサービスを使用して複雑な操作を実行する一連のタスクを組み合わせて自動化する。

Azure Data Factoryは、リンクされたサービス、データセット、パイプラインなど、さまざまなリソースを使用する。

リンクされたサービスは、DataFactoryがソースまたは宛先に接続するために必要な情報を提供する。
たとえば、Azure BlobStorageリンクサービスを使用してストレージアカウントをDataFactoryに接続したり、Azure SQLDatabaseリンクサービスを使用してSQLデータベースに接続したりできる。
データセットは、取り込み（入力）または保存（出力）するデータを表す。
データに構造がある場合、データセットはデータの構造を指定する。
すべてのデータセットが構造化されているわけではない。
データセットは、リンクされたサービスを使用して入力または出力に接続する。
パイプラインは、タスクを一緒に実行するアクティビティの論理的なグループである。
パイプラインのアクティビティは、データに対して実行するアクションを定義する。
パイプラインは手動で実行することも、トリガーを使用して後で実行するように調整することもできる。
トリガーを使用すると、計画されたスケジュールに従って、または繰り返しの間隔で、またはAzureでのファイルの到着などのイベントが発生したときに、パイプラインが発生するようにスケジュールできる。

データ処理オプション

Azure Synapse Analytics

Azure Databricks

Databricksは、Azure Blobストレージ、Azure Data Lake Store、Hadoopストレージ、フラットファイル、データベース、データウェアハウスなど、さまざまな種類のストレージに保持されているデータを処理でき、ストリーミングデータも処理することができる。
Databricksは、ドライバーに基づく拡張可能なアーキテクチャーを使用する。
処理エンジンはApache Sparkによって提供される。
ノートブックを使用してDatabricksアプリケーションを作成する。

Azure HDInsight

HDInsightは、SynapseAnalyticsと同様のクラスター化モデルを使用する。
HDInsightは、Azure DataLakeストレージを使用してデータを保存する。
HDInsightを使用して、Hadoop Map / Reduce、Apache Spark、Apache Hive、Apache Kafka、Apache Storm、Rなどのフレームワークを使用してデータを分析できる。

Azure Data Factory

■4.4.Microsoft PowerBIでのデータの視覚化について説明する

Power BIはソフトウェアサービス、アプリ、コネクタのコレクションで、これらを組み合わせることで、関連性のないデータソースから、まとまりがあり、実体験的な対話型洞察を得ることができる。

Excelスプレッドシートや、クラウドベースとオンプレミスのハイブリッドデータウェアハウスのコレクションなど、さまざまなデータを使える。

Power BIを使うと、ご利用のデータソースへの接続、重要事項の視覚化と検出、必要に応じた任意のユーザーまたはすべてのユーザーとの共有を、簡単に実行できる。

Power BIの構成要素

Power BI Desktopと呼ばれる Windowsデスクトップアプリケーション
Power BIサービスと呼ばれるオンラインのSaaSサービス
Windows、iOS、Androidデバイス向けの Power BIモバイルアプリ

ページ付けされたレポートの役割

Power BIレポートはデータセットのマルチパースペクティブ表示である。
データセットからのさまざまな結果や分析情報がビジュアルによって表される。
レポートでは、単一のビジュアルを使用することも、各ページでさまざまなビジュアルを使用することもできる。
レポートは、レポートを配布して "ビジネスユーザー" と共有する Power BI "デザイナー"によって作成される。
Power BI Report Builderは、ページ付けされたレポートを作成できるツールである。

インタラクティブ(対話型)レポートの役割

Power BIでは、ビジネスに合わせてカスタマイズした対話型レポートを作成できる。
対話型のデータビジュアライゼーションで魅力的なレポートを作成できる。
レポートページ上の関連する視覚エフェクトをクロス強調表示およびクロスフィルター処理する。
同じ1つのレポートページにある視覚化は、相互に「つながって」おり、1つの視覚化で1つ以上の値を選択すると、同じ値を使う他の視覚化が自分の選択内容に基づいて変更される。
既定では、レポートページ上の1つのビジュアルでデータポイントを選択すると、そのページ上の他のビジュアルに対してクロスフィルター処理またはクロス強調表示が行われる。
ページ上のビジュアルがどのように相互作用するかは、レポートデザイナーによって設定される。
デザイナーには、視覚的な相互作用のオンとオフを切り替えるオプションと、既定のクロスフィルター処理、クロス強調表示、および詳細表示の動作を変更するオプションがある。

ダッシュボードの役割

Power BIダッシュボードは、他のユーザーと共有できる1つのページからのビジュアルのコレクションである。
ダッシュボードは、多くの場合キャンバスと呼ばれる単一のページに収まる必要がある。
ダッシュボードを他のユーザーまたはグループと共有できる。
他のユーザーまたはグループは、Power BIサービスまたはモバイルデバイスを使用しているときにダッシュボードを操作できる。

PowerBIでのワークフロー

Power BIでの一般的なワークフローは、Power BI Desktopでデータソースに接続し、レポートを作成することから始まる。

次に、そのレポートを Power BI Desktopから Power BIサービスに発行し、それを共有することで、Power BIサービスとモバイルデバイスのビジネスユーザーがレポートを表示して操作できるようにする。

■参考資料

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up