クラウド規模の分析での Azure Data Lake Storage の概要
Azure Data Lake は、高パフォーマンスの分析ワークロード用の非常にスケーラブルで安全なデータ レイクです。 クラウド規模の分析のために、1 つのリソース グループ内にストレージ アカウントを作成できます。 クラウド規模の分析アーキテクチャ データ ランディング ゾーンの概要に関する記事で説明されている storage-rg リソース グループと類似の 1 つのリソース グループ内に 3 つの Azure Data Lake Storage Gen2 アカウントをプロビジョニングすることをお勧めします。
データ ランディング ゾーン内の各ストレージ アカウントは、次の 3 つの段階のいずれかでデータを格納します。
- 生データ
- 強化され、キュレーションされたデータ
- 開発データ レイク
データ アプリケーションは、自動データに依存しないインジェスト サービスを取り込んだストレージ アカウントから、強化され、キュレーションされたデータを使用できます。 データに依存しないエンジンの実装や、運用ソースからデータを取り込むための複雑な接続の利用をしない場合は、ソースに合わせたデータ アプリケーションを作成できます。 このデータ アプリケーションは、外部データ ソースからデータを取り込むときに、データに依存しないエンジンと同じフローに従います。
Data Lake Storage Gen2 では、ファイル レベルとフォルダー レベルでデータを保護する詳細なアクセス制御リスト (ACL) がサポートされます。 アクセス制御リストは、データ製品で次の作業を行うために、組織が認証と承認のための厳格なセキュリティ対策を実装するのに役立ちます。
- 保存時に、暗号化によってデータを安全に保存します。
- Microsoft Entra の統合による Microsoft Entra ユーザーとセキュリティ グループのアクセスの制御。
データ レイクの計画
データ レイクを計画するときは、構造、ガバナンス、およびセキュリティについて該当する考慮事項を常に検討してください。 次のような複数の要因が各データ レイクの構造と組織に影響を及ぼします。
- 格納するデータの種類
- データの変換方法
- データにアクセスするユーザー
- 典型的なアクセス パターン
データ アクセスのニーズに基づいてコンシューマーとプロデューサーをグループ化します。 データ レイク全体の実装とアクセス制御ガバナンスを計画することをお勧めします。
データ レイクにいくつかのデータ資産と、抽出、変換、読み込み (ETL) オフロードなどの自動化されたプロセスが含まれている場合、計画はかなり簡単である可能性が高くなります。 データ レイクに何百ものデータ資産が含まれていて、自動と手動の操作が必要な場合は、データ所有者とのコラボレーションがより多く必要になるため、計画にかかる時間がより長いことが予想されます。
データ スワンプという比喩
データ スワンプとは、ユーザーがほぼアクセスできない、管理されていないデータ レイクです。 データ スワンプは、データの品質とデータ ガバナンスの対策を実装していないときに発生します。 既存のハイブリッド モデルを持つデータ ウェアハウスにデータ スワンプが存在することがあります。
適切なガバナンスと組織によって、データ スワンプが防止されます。 データ レイクの強固な基盤を構築すると、データ レイクを持続的に成功させ、ビジネスの価値を向上させる可能性が高まります。
データ レイクの規模、複雑さ、データ資産の数、およびユーザーや部門の数が増大するにつれて、堅牢なデータ カタログ システムを持つことがますます重要になります。 データ カタログ システムを使用すると、データ レイクの処理、使用、管理中に、ユーザーがデータを検索、タグ付け、分類できるようになります。
詳細については、データ ガバナンスの概要に関する記事を参照してください。
論理データ レイク内のストレージ アカウント
組織で 1 つまたは複数のストレージ アカウントが必要かどうかを検討し、論理データ レイクを構築するために必要なファイル システムを検討します。 1 つのストレージ テクノロジに、複数のデータ アクセス方法が用意されていて、組織全体にわたる標準化に役立ちます。
Data Lake Storage Gen2 は、フル マネージドのサービスとしてのプラットフォーム (PaaS) です。 複数のストレージ アカウントやファイル システムは、データのアクセスや格納があるまで、金銭的コストが発生しません。 各 Azure リソースには、プロビジョニング、セキュリティ、ガバナンス中に、バックアップやディザスター リカバリーなどの管理と運用のオーバーヘッドが関連付けられています。
注意
各データ ランディング ゾーンには、3 つのデータ レイクが示されています。 ただし、要件によっては、生、強化、キュレーションのレイヤーを 1 つのストレージ アカウントに統合できる場合があります。 データ コンシューマーが他の有用なデータ製品を持ち込むことができる、"開発" という別のストレージ アカウントも作成できます。
統合と 3 つのストレージ アカウント アプローチのどちらかに決定するときは、次の要因を考慮してください。
- データ環境の分離と予測可能性
- 生と開発のゾーンで実行されるアクティビティを分離して、重要な意思決定に必要な優れたビジネス価値を持つデータを保持するキュレーションされたゾーンへの潜在的な影響を回避できます。
- ストレージ アカウント レベルの特徴と機能
- ライフサイクル管理オプションまたはファイアウォール規則を、データ ランディング ゾーンとデータ レイク レベルのどちらで適用するかを選択できます。
- 不要なサイロ以外の、複数のストレージ アカウントを作成します。
- 組織全体の可視性や知識の共有が損なわれないように、重複するデータ プロジェクトを避けます。
- 適切なデータ ガバナンス、プロジェクト追跡ツール、およびデータ カタログを配置するようにします。
- 構成されたアクセス許可に基づく複数のレイクにまたがるデータに対するデータ処理ツールとテクノロジの相互作用
- リージョンとグローバルのレイク
- レイク上のグローバルに分散されたコンシューマーまたはプロセスは、地理的な距離によって発生する待機時間の影響を受けます。
- データをローカルに格納することをお勧めします。
- 規制上の制約とデータ主権の観点から、データを特定の地域内に留めることが必要な可能性があります。
- 詳細については「複数リージョンのデプロイ」を参照してください。
複数リージョンのデプロイ
データ所在地ルールまたはユーザーの拠点近くにデータを保持する要件によって制限されるときは、複数の Azure リージョンに Azure Data Lake アカウントを作成することが必要になる場合があります。 これを行うには、1 つのリージョンにデータ ランディング ゾーンを作成し、AzCopy や Azure Data Factory またはサードパーティー製品を使用してグローバル データをレプリケートします。 ローカル データはリージョン内に存在し、グローバル データは複数のリージョンにレプリケートされます。