Data Lake は、大量のデータをネイティブの生形式で保持するストレージ リポジトリです。 データ レイクはコスト効率が高く、テラバイトとペタバイト単位のデータを処理するため、大規模で多様なデータセットの処理に適しています。 通常、データはさまざまなソースから取得され、リレーショナル テーブルなどの構造化データ、JSON、XML、ログ ファイルなどの半構造化データ、画像、オーディオ、ビデオなどの非構造化データを含めることができます。
データ レイクは、すべてのデータ型を元の変換されていない状態で格納し、データが必要な場合にのみ変換を適用します。 このアプローチは、スキーマオンリードと呼ばれます。 これに対し、 データ ウェアハウス では構造が適用され、データの取り込み時に変換が適用されます。 この方法は、書き込み時スキーマと呼ばれます。
Data Lake の一般的なユース ケースは次のとおりです。
データインジェストと移動: クラウド サービス、モノのインターネット (IoT) デバイス、オンプレミス システム、ストリーミング ソースからデータを収集して、1 つのリポジトリに統合します。
ビッグ データ処理: 分散処理フレームワークを使用して、大量の高速データを大規模に処理します。
分析と機械学習: 探索的分析、高度な分析、AI モデルのトレーニングをサポートし、大規模で多様なデータセットに対する微調整を行います。
ビジネス インテリジェンス (BI) とレポート: レイク データの精選されたサブセットをウェアハウスまたは BI ツールに統合することで、ダッシュボードとレポートを有効にします。
データのアーカイブとコンプライアンス: 長期的な保持、監査可能性、規制コンプライアンスのための履歴または未加工のデータセットを格納します。
データ レイクの利点
将来使用するために生データを保持します。 Data Lake は生形式でデータを格納するため、将来の使用のために長期的な可用性が確保されます。 このアプローチは、データからの潜在的な分析情報が事前にわかっていない可能性があるビッグ データ環境で特に価値があります。 生の状態を失うことなく、必要に応じてデータをアーカイブすることもできます。
セルフサービス探索: アナリストとデータ サイエンティストは、データに直接クエリを実行して、パターンを実験および検出できます。
柔軟なデータサポート: 構造化形式を必要とするウェアハウスとは異なり、データ レイクは構造化データ、半構造化データ、非構造化データをネイティブに処理します。
スケーラブルでパフォーマンスが高い: 分散アーキテクチャでは、データ レイクは大規模にデータを取り込んで処理します。 多くの場合、大量のワークロードで従来の抽出、変換、読み込み (ETL) パイプラインを上回ります。 次の方法で、これらのパフォーマンス上の利点を得ることができます。
並列 処理: Apache Spark などの分散コンピューティング エンジンは、データをパーティション分割し、多数のノード間で変換を同時に実行します。 従来の ETL フレームワークは、多くの場合、順次または限られたマルチスレッド処理に依存します。
スケーラビリティ: 分散システムは、必要に応じてコンピューティング ノードとストレージ ノードを弾力的に追加することで、水平方向にスケーリングします。 従来の ETL パイプラインは、通常、1 つのホストを垂直方向にスケーリングすることで、リソースの制限を迅速に満たします。
ハイブリッド アーキテクチャの基礎: 多くの場合、データ レイクは、未加工のストレージと構造化されたクエリ パフォーマンスを組み合わせたレイクハウス アプローチでウェアハウスと共存します。
最新の Data Lake ソリューションは、次の 2 つのコア コンポーネントで構成されます。
ストレージ: 持続性、フォールト トレランス、無限のスケーラビリティ、多様なデータ型の高スループット インジェストを提供します。
処理: Azure Databricks の Spark エンジンや Microsoft Fabric などがこれらのソリューションを動かします。 これらのエンジンは、大規模な変換、分析、機械学習をサポートします。
成熟したソリューションには、データの品質、検出可能性、コンプライアンスを維持するためのメタデータ管理、セキュリティ、ガバナンスが組み込まれています。
一般的なデータ レイク アーキテクチャ
一般的なAzure データ レイク アーキテクチャは、インジェスト、変換、および消費の各段階を進むデータを整理する複数のレイヤーで構成されています。
一般的なレイヤーは次のとおりです。
生 (ブロンズ) レイヤー: 取り込まれたデータを、変換を最小限に抑えながら元の形式で格納します。
クレンジング (シルバー) レイヤー: 分析と機械学習のワークロード用に最適化された検証済みおよび変換されたデータが含まれます。
キュレーション (ゴールド) レイヤー: チームがレポート、ダッシュボード、およびダウンストリーム データ アプリケーションに使用する集計およびビジネス対応のデータセットを格納します。
medallion アーキテクチャと呼ばれるこの階層化された設計により、データの品質、ガバナンス、パフォーマンスが向上します。
データ レイクを使用する場合
探索的分析、高度なデータ サイエンス、機械学習のワークロードには、データ レイクを使用することをお勧めします。 データ レイクは生の形式でデータを保持し、スキーマの読み取りをサポートするため、チームは多様なデータ型を試し、従来のウェアハウスではキャプチャできない可能性のある分析情報を明らかにできます。
データ ウェアハウスのソースとしてのデータレイク
データ レイクは、ソース システムから生データを取り込んでレイクに読み込むデータ ウェアハウスのアップストリーム ソースとして機能できます。 Fabric Data Warehouseのような最新のウェアハウスでは、組み込みの超並列処理 (MPP) SQL エンジンを使用して、extract、読み込み、変換 (ELT) を使用して、その生データを構造化された形式に変換します。 このアプローチは、ETL エンジンがデータを抽出して変換してからデータをウェアハウスに読み込む従来の ETL パイプラインとは異なります。 どちらの方法も、ユース ケースに応じて柔軟性を提供します。 データの品質、パフォーマンス、およびリソース使用率のバランスを取り、分析用にウェアハウスが最適化されていることを確認します。
イベント ストリーミングと IoT のシナリオ
データ レイクは、イベント ストリーミングと IoT のユース ケースに有効です。高速データは、スキーマの上限なしで大規模に保持する必要があります。 データ レイクでは、リレーショナル イベント ストリームと非リレーショナル イベント ストリームを取り込んで格納し、低待機時間で大量の小さな書き込みを処理し、大規模な並列スループットをサポートできます。 これらの機能により、データ レイクは、リアルタイム監視、予測メンテナンス、異常検出などのアプリケーションに適しています。
次の表は、データ レイクとデータ ウェアハウスを比較したものです。
| 特徴 | データ レイク | データ ウェアハウス |
|---|---|---|
| データの種類 | 生、非構造化、半構造化、構造化 | リレーショナル スキーマに編成された構造化およびキュレーションされたデータ |
| 検索性能 | クエリのパフォーマンスは処理エンジンに依存し、変換はクエリ時に発生する可能性があります (スキーマの読み取り時) | 構造化データに対する高パフォーマンスの分析クエリ用に最適化 (スキーマの書き込み時) |
| Latency | クエリ時の処理が原因で待機時間が長くなる | 前処理された構造化データによる低待機時間 |
| データ変換ステージ | 変換はクエリ時に行われ、全体的な処理時間に影響します | ETL または ELT プロセス中に変換が発生する |
| スケーラビリティ | 大量の多様なデータに対する拡張性とコスト効率が高い | 拡張性はありますが、コストが高くなります。特に大規模な場合 |
| Cost | 生データのストレージコストが低いため、ストレージ コストが削減されます。 コンピューティング コストは、データが処理または照会されるときに発生します。 | 分析ワークロード専用のコンピューティングとパフォーマンスの最適化により、コストが高くなります |
| ユース ケースの適合 | ビッグ データ、機械学習、探索的分析に最適です。 medallion アーキテクチャでは、チームはレポートにゴールド レイヤーを使用します。 | BI、レポート、構造化データ分析に最適 |
データ レイクの課題
スケーラビリティと複雑さ: 生データ、非構造化データ、半構造化データのペタバイト単位の管理には、堅牢なインフラストラクチャ、分散処理、慎重なコスト管理が必要です。
処理のボトルネック: データ量と多様性が増加すると、変換とクエリのワークロードによって待機時間が発生する可能性があります。これには、慎重なパイプライン設計とワークロード オーケストレーションが必要になります。
データ整合性リスク: 強力な検証と監視がないと、エラーや不完全なインジェストによって、湖のコンテンツの信頼性が損なわれる可能性があります。
データの品質とガバナンス: さまざまなソースと形式により、標準の適用が複雑になります。 メタデータ管理、カタログ化、ガバナンス フレームワークは重要です。
大規模なパフォーマンス: クエリのパフォーマンスとストレージの効率は、レイクの拡大に伴って低下する可能性があります。これには、パーティション分割、インデックス作成、キャッシュなどの最適化戦略が必要になります。
セキュリティとアクセス制御: 機密データの誤用を防ぐために、さまざまなデータセットにわたって適切なアクセス許可と監査を確保するには、計画が必要です。
検出: 適切なカタログ化がなければ、湖は貴重な情報が存在するが、アクセスできないか誤解されている データ沼地 に陥る可能性があります。
テクノロジの選択
Azureで包括的なデータ レイク ソリューションを構築する場合は、次のテクノロジを検討してください。
Azure Data Lake Storage は、Azure Blob Storageとデータ レイク機能を組み合わせて、Apache Hadoop と互換性のあるアクセス、階層型名前空間の機能、および効率的なビッグ データ分析のためのセキュリティ強化を提供します。 大量の構造化データ、半構造化データ、非構造化データを処理します。
Azure Databricks は、Spark の長所とAzure エコシステムへの深い統合を組み合わせたクラウドベースのデータ分析と機械学習プラットフォームです。 データ エンジニア、データ サイエンティスト、アナリストが大量のデータを取り込み、処理、分析、モデル化できるコラボレーション環境を提供します。
Azure Data Factory は、クラウドベースのデータ統合と ETL サービスです。 クラウドでもオンプレミスでも、さまざまなソース間でデータ ワークフローを移動、変換、調整するために使用できます。
Fabric は、データ移動、データ サイエンス、リアルタイム分析、BI を単一のサービスとしてのソフトウェア (SaaS) エクスペリエンスに統合するエンドツーエンドのデータ分析プラットフォームです。
各Fabric テナントは、OneLake と呼ばれる 1 つの論理データ レイクで自動的にプロビジョニングされます。 OneLake はData Lake Storage上に構築され、構造化データと非構造化データを処理できる統合ストレージ レイヤーを提供します。
貢献者
Microsoftはこの記事を保持します。 この記事を書いたのは、以下の寄稿者です。
主執筆者:
- Avijit Prasad | クラウド コンサルタント
その他の共同作成者:
- Raphael Sayegh |クラウド ソリューション アーキテクト
次のステップ
- OneLake とは
- データレイクストレージへの入門
トレーニング: Data Lake Storage の導入 - Azure HDInsight クラスターでData Lake Storageを使用します
- ストレージにアクセスするには、Unity カタログでマネージド ID Azure使用します
- Data Factory を使用してデータをData Lake Storageに読み込みます
Microsoft Purview Data Lake Storage
関連リソース
Azure - 中小企業向けの最新データ ウェアハウス