データ レイクのゾーンとコンテナー
データ構造をデータ レイクに配置する前に、そのデータ構造を計画することが重要です。 計画があれば、セキュリティ、パーティション分割、処理を効果的に使用できます。
データ レイクの概要については、「クラウド規模の分析での Azure Data Lake Storage の概要」を参照してください。
概要
3 つのデータ レイク アカウントは、一般的なデータ レイクのレイヤーに合わせる必要があります。
| レイク番号 | レイヤー | コンテナー番号 | コンテナー名 |
|---|---|---|---|
| 1 | Raw | 1 | ランディング |
| 1 | Raw | 2 | 準拠 |
| 2 | 強化 | 1 | 標準化 |
| 2 | Curated | 2 | データ製品 |
| 3 | 開発 | 1 | 分析サンドボックス |
| 3 | 開発 | # | Synapse プライマリ ストレージ番号 |
上の表は、データ ランディング ゾーンごとの推奨される標準的なコンテナー数を示しています。 このレコメンデーションの例外は、コンテナー内のデータに異なる論理的な削除ポリシーが必要な場合です。 これらの要件によって、より多くのコンテナーが必要かどうかが決まります。
注意
各データ ランディング ゾーンには、3 つのデータ レイクが示されています。 データ レイクは 3 つのデータ レイク アカウント、複数のコンテナー、フォルダーにまたがっていますが、これはデータ ランディング ゾーンの 1 つの論理データ レイクを表しています。
要件によっては、生、強化、キュレーションのレイヤーを 1 つのストレージ アカウントに統合することもできます。 データ コンシューマーが他の有用なデータ製品を持ち込むための、"development" という名前の別のストレージ アカウントを維持してください。
データ レイク アカウントの分離の詳細については、「論理データ レイク内のストレージ アカウント」を参照してください。
階層型名前空間の機能を使用して Azure Storage を有効にします。これにより、ファイルを効率的に管理できます。 階層型名前空間機能により、アカウント内のオブジェクトとファイルが、ディレクトリおよび入れ子になったサブディレクトリの階層に編成されます。 この階層は、コンピューター上のファイル システムと同じ方法でまとめられます。
データに依存しないインジェスト エンジンまたはオンボード アプリケーションが新しいレコード システムを登録すると、生、エンリッチ、標準化データ レイヤーのコンテナー内に必要なフォルダーが作成されます。 ソース アライン済みデータ アプリケーションがデータを取り込む場合、データ アプリケーション チームがフォルダーとセキュリティ グループを作成するには、データ ランディング ゾーン チームが必要です。 サービス プリンシパル名またはマネージド ID を正しいグループに配置し、アクセス許可レベルを割り当てます。 データ ランディング ゾーン チームとデータ アプリケーション チームのために、このプロセスをドキュメント化します。
チームの詳細については、「Azure でのクラウド規模の分析のチームについて理解する」を参照してください。
各データ製品には、データ製品チームが所有するデータ製品コンテナー内に 2 つのフォルダーが必要です。
標準化コンテナーのエンリッチされたレイヤーには、ソース システムごとに 2 つのフォルダーがあり、分類別に分かれています。 この構造により、チームはセキュリティとデータ分類が異なるデータを個別に格納し、異なるセキュリティ アクセスを割り当てることができます。
標準化コンテナーには、機密以下のデータ用の一般的なフォルダーと、個人データ用の機密フォルダーが必要です。 アクセス制御リスト (ACL) を使用して、これらのフォルダーへのアクセスを制御します。 すべての個人データを削除してデータセットを作成し、一般的なフォルダーに保存できます。 個人データ用の "機密" フォルダー内に、すべての個人データが含まれる別のデータセットを作成できます。
ACL と Microsoft Entra グループの組み合わせにより、データ アクセスを制限します。 これらのリストとグループでは、他のグループがアクセスできるものとできないものをコントロールします。 データ所有者とデータ アプリケーション チームは、データ資産へのアクセスを承認または拒否できます。
詳細については、データ アクセス管理に関するページと「制限付きデータ」を参照してください。
警告
一部のソフトウェア製品では、データ レイク コンテナーのルートをマウントすることがサポートされていません。 この制限のため、生、キュレーション、強化、開発の各レイヤーの各データ レイク コンテナーには、複数のフォルダーに分岐する単一のフォルダーが含まれている必要があります。 フォルダーのアクセス許可は慎重に設定してください。 ルートから新しいフォルダーを作成するときに、親ディレクトリの既定値の ACL によって、子ディレクトリの既定値の ACL とアクセス ACL が決まります。 子ファイルの ACL には既定の ACL がありません。
詳細については、Azure Data Lake Storage Gen2 でのアクセス制御 (ACL) に関するページを参照してください。
生レイヤーまたはデータ レイク 1
生レイヤーは、自然な元の状態でデータを保存する貯留層に例えられます。 ろ過されておらず、浄化されていません。 データを、JSON や CSV などの元の形式で格納することができます。 または、Avro、Parquet、Databricks Delta Lake などの圧縮ファイル形式でファイルの内容を列として格納すると、コスト効率が高い場合があります。
この生データは変更不可です。 生データはロック ダウンしたままにしておきます。また、コンシューマーにアクセス許可を (自動または手動で) 付与する場合は、読み取り専用になっていることを確認します。 このレイヤーは、ソース システムごとに 1 つずつフォルダーを使用してまとめることができます。 各インジェスト プロセスに、それに関連付けられているフォルダーのみへの書き込みアクセス権を付与します。
ソース システムから生ゾーンにデータを読み込む場合は、以下を行うことを選択できます。
- 完全なデータ セットを抽出するための完全な読み込み。
- 変更されたデータのみを読み込むための差分読み込み。
選択した読み込みパターンをフォルダー構造で示すことにより、データ コンシューマーの使用を簡略化します。
各ソース アライン済みデータ アプリケーションまたは自動インジェスト エンジン ソースのソース システムからの生データは、全体フォルダーまたは差分フォルダーに配置されます。 各インジェスト プロセスには、関連付けられているフォルダーのみへの書き込みアクセス権が必要です。
完全な読み込みと差分読み込みの違いは次のとおりです。
完全読み込み - 次の場合、ソースからの完全なデータをオンボードします。
- ソース側のデータ ボリュームが小さい。
- ソース システムで、データが追加、更新、または削除されたかどうかを識別するタイムスタンプ フィールドが維持されていない。
- ソース システムが、毎回データ全体を上書きする。
差分読み込み - 次の場合、ソースからの増分データをオンボードします。
- ソース側のデータ ボリュームが大きい。
- ソース システムで、データが追加、更新、または削除されたかどうかを識別するタイムスタンプ フィールドが維持されている。
- ソース システムが、データの変更に関するファイルを作成して更新する。
生データ レイクは、ランディングと適合のコンテナーで構成されます。 各コンテナーでは、その目的に固有の 100% 必須のフォルダー構造が使用されます。
ランディング コンテナーのレイアウト
ランディング コンテナーは、認識されたソース システムからの生データ用に予約されています。 データに依存しないインジェスト エンジンまたはソースアライン済みデータ アプリケーションがデータを読み込みます。これは変更されず、元のサポートされている形式です。
.
|-Landing
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------{date (ex. rundate=2019-08-22)}
|------Full
生レイヤー適合コンテナー
生レイヤーには、データ品質に適合したデータが含まれます。 データがランディング コンテナーにコピーされると、データ処理とコンピューティングがトリガーされ、そのデータをランディング コンテナーから適合コンテナーにコピーします。 この最初のステージでは、データがデルタ レイク形式に変換されて入力フォルダーに配置されます。 データ品質が実行されると、合格したレコードが出力フォルダーにコピーされます。 失格したレコードは、エラー フォルダーに配置されます。
.
|-Conformance
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
|------Full
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
ヒント
分析プラットフォームを最初から再構築する必要があるシナリオについて考えてみましょう。 ダウンストリームの読み取りデータ ストアを再構築するために必要な最も詳細なデータを検討してください。 主要なコンポーネントに関する事業継続とディザスター リカバリーのプランがあることを確認してください。
エンリッチされたレイヤーまたはデータ レイク 2
エンリッチされたレイヤーは、ろ過層に例えられます。 不純物を除去し、濃縮することもできます。
標準化コンテナーには、レコードのシステムとマスターが保持されます。 フォルダーは、最初にサブジェクト領域別に、次にエンティティ別にセグメント化されます。 データは、分析での消費に最適化された、マージされたパーティション テーブルで利用できます。
標準化コンテナー
.
|-Standardized
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------General
|--------{date (ex. rundate=2019-08-22)}
|-------Sensitive
|--------{date (ex. rundate=2019-08-22)}
注意
このデータ レイヤーは、シルバー レイヤーまたは読み取りデータ ソースと見なされます。 このレイヤーのデータには、データ品質、デルタ レイク変換、データ型のアラインメント以外の変換は適用されていません。
次の図は、ソース データから標準化コンテナーへのデータ レイクとコンテナーのフローを示しています。
キュレーション レイヤーまたはデータ レイク 2
キュレーション レイヤーは、消費レイヤーです。 データ インジェストや処理ではなく、分析用に最適化されています。 キュレーション レイヤーでは、非正規化されたデータ マートまたはスター スキーマにデータが保存される場合があります。
標準化コンテナーからのデータが、データ コンシューマーに提供される価値の高いデータ製品に変換されます。 このデータには構造があります。 データ サイエンス ノートブックのようにそのまま、または Azure SQL Database などの別の読み取りデータ ストアを通じて、コンシューマーに提供できます。
データベース エンジン内でディメンショナル モデリングを行う代わりに、Spark や Data Factory などのツールを使用して行います。 レイクを唯一の信頼できる情報源にする場合、このツールの使用が重要なポイントになります。
レイク外でディメンショナル モデリングを行う場合は、一貫性を保つため、モデルをレイクに公開し直す必要があります。 このレイヤーは、データ ウェアハウスの代わりではありません。 通常、パフォーマンスは応答性の高いダッシュボードやエンド ユーザーおよびコンシューマーによる対話型分析には十分ではありません。 このレイヤーは、大規模で一時的に用意したクエリや解析を実行する内部のアナリストやデータ サイエンティスト、または時間に依存するレポートを必要としない上級アナリストに最適です。 データ ウェアハウスよりもデータ レイクの方がストレージ コストが低いため、詳細で低レベルのデータをレイクに保持する方が費用効率が高い場合があります。 集計データはウェアハウスに格納します。 Spark または Azure Data Factory を使用して、これらの集計を生成します。 これらをデータ ウェアハウスに読み込む前にデータ レイクに保持します。
通常、このゾーンのデータ資産は高度に管理され、十分に文書化されています。 部門または職務によってアクセス許可を割り当て、コンシューマー グループまたはデータ マート別にアクセス許可をまとめます。
データ製品コンテナー
.
|-{Data Product}
|---{Entity}
|----{Version}
|-----General
|-------{date (ex. rundate=2019-08-22)}
|------Sensitive
|-------{date (ex. rundate=2019-08-22)}
ヒント
Azure SQL Database などの別の読み取りデータ ストアにデータを配置する場合は、キュレーション データにこのデータのコピーがあることを確認します。 データ製品のユーザーはメインの読み取りデータ ストアまたは Azure SQL Database インスタンスに誘導されますが、データ レイクでもデータを使用できるようにすると、追加のツールを使用してデータを探索することもできます。
開発レイヤーまたはデータ レイク 3
データ コンシューマーは、標準化コンテナーに取り込まれたデータと共に、他の有用なデータ製品を取り込むことができます。
このシナリオでは、データ プラットフォームで、これらのコンシューマー用に分析サンドボックス領域を割り当てることができます。 サンドボックスでは、取り込んだキュレーション データとデータ製品を使用して、価値のある分析情報を生成できます。 たとえば、データ サイエンス チームが新しいリージョンの最善の製品配置戦略を決定する場合、そのリージョンの類似製品から、顧客の人口統計や使用状況データなどの他のデータ製品を取り込むことができます。 チームは、このデータから得られる価値の高い売上分析情報を使用して、製品市場の適合性とオファリング戦略を分析できます。
Note
分析サンドボックス領域は、個人または少人数のコラボレーターのグループのための作業領域です。 サンドボックス領域のフォルダーには、運用ソリューションの一部としてこの領域を使用しようとするのを防ぐ特別なポリシー セットがあります。 これらのポリシーにより、使用可能なストレージの合計と、データを保存できる期間が制限されます。
通常、これらのデータ製品の品質と精度は不明です。 これらもデータ製品として分類されますが、一時的なものであり、このデータを使用するユーザー グループにとってのみ意味があるものです。
これらのデータ製品が成熟したら、企業はこれらのデータ製品をキュレーション データ レイヤーにレベル上げすることができます。 データ製品チームが新しいデータ製品に対する責任を維持できるように、キュレーション データ ゾーンの専用フォルダーをチームに提供してください。 このフォルダー内に新しい結果を保存し、組織全体の他のチームと共有することができます。
Note
作成するすべての Azure Synapse ワークスペースで、データ レイク 3 を使用して、プライマリ ストレージとして使用するコンテナーを作成してください。 このコンテナーにより、Azure Synapse ワークスペースがキュレーションおよび強化の各ゾーンのスループット制限に干渉しないようになります。
製品と分析サンドボックスへのデータ フローの例
次の図は、この記事の情報をまとめたものであり、データ製品と分析サンドボックスにデータがどのように流れるかを示しています。
