次の方法で共有


クラウド規模の分析とに関してよく寄せられる質問

クラウド規模の分析に関して寄せられた一般的な質問を以下に示します。

ストレージ アカウント

3 つの個別のストレージ アカウントが必要であるのはなぜですか? 1 つだけ用意し、レイヤー (未加工、調整済み、キュレーション済み) ごとに 3 つのコンテナーを使用することはできませんか?

現在のほとんどの Data Analytics パターンは、未加工、調整済み、キュレーション済みの 3 つのレイヤーで存在します。 それらは同じストレージに保持できますが、大規模な実装になると、ロールベースのアクセス制御 (RBAC) およびアクセス制御リスト (ACL) のアクセス許可の数が単一のストレージ アカウント内で使用が許可されている数を超えるという問題が発生します。 個別のストレージ アカウントを複数使用すれば、ほとんどの実装でこの問題を回避できます。

他の理由については、「クラウド規模の分析での Azure Data Lake Storage の概要」で説明されています。

Databricks

製品ごとに Azure Databricks ワークスペースを展開する必要がありますか?

ランディング ゾーン内では、共有製品 Azure Databricks の分析およびデータ サイエンス ワークスペースの使用をお勧めします。

この決定は、データ プラットフォーム運用チームの管理オーバーヘッドを削減するために行われています。 Azure Databricks には、Azure ポリシーに統合されていないスタンドアロン ポリシーのセットがあります。 大規模な環境では、セットアップする Azure Databricks ワークスペースが大きくなると、管理オーバーヘッドも増大します。 たとえば、ポリシーおよびサポートされている Apache Hive バージョンの維持、ADB バージョンの更新、外部 Apache Hive メタストアの適用などが挙げられます。 中央プラットフォーム チームが Databricks ワークスペースのいずれかに特定の設定を適用するための方法はありません。 ランディングゾーン内に製品チームで共有するワークスペースを設けることをお勧めします。これにより、データ プラットフォーム運用チームは必要なクラスターポリシーと初期化スクリプトを定義できるようになります。

ランディング ゾーンとプライベート エンドポイント間で VNet ピアリングを使用することをお勧めします。 Azure Databricks の場合は、VNet インジェクションを使用します。 すべてのエンドポイントへの直接の見通し線があるため、接続の問題はありません。

次の手順

Azure でのクラウド規模の分析を使用した取り込みプロセス