Azure Data Lake Storage Gen2 の概要

Azure Data Lake Storage Gen2 は Azure Blob Storage 上に構築されており、ビッグ データ分析のための機能セットです。

Azure Data Lake Storage Gen1 と Azure Blob Storage の機能は、Data Lake Storage Gen2 に統合されています。たとえば、Data Lake Storage Gen2 は、スケール、ファイル レベルのセキュリティ、ファイル システム セマンティクスを提供します。また、BLOB ストレージ上に構築されているため、高可用性とディザスター リカバリー機能を備えた低コストの階層型ストレージも利用できます。

企業の大規模データ分析のために特別に開発

Data Lake Storage Gen2 のおかげで、Azure Storage は Azure 上にエンタープライズ データ レイクを作成するための出発点となりました。Data Lake Storage Gen2 は、数百ギガバイトのスループットをサポートしながらペタバイトのデータをサポートするためにゼロから構築されており、大量のデータを簡単に管理できます。

BLOB ストレージを拡張して階層名前空間を含めることは、Data Lake Storage Generation 2 の重要なコンポーネントです。データに効率的にアクセスするために、階層ネームスペースはオブジェクトとファイルをフォルダー階層にグループ化します。スラッシュは、階層ディレクトリ構造をシミュレートするためにオブジェクト ストア名でよく使用されます。Data Lake Storage Gen2 の出現により、この取り決めが現実になりました。ディレクトリの名前変更や削除などのディレクトリに対する操作は、単一のアトミックなメタデータ操作になります。ディレクトリ名プレフィックスを共有するすべてのオブジェクトを列挙して処理する必要はありません。

BLOB ストレージは Data Lake Storage Generation 2 の基盤であり、以下を通じて管理、セキュリティ、パフォーマンスが向上します。

パフォーマンス

分析前にデータをコピーしたり変更したりする必要がないため、パフォーマンスが最適化されます。さらに、BLOB ストレージ上の階層名前空間は、フラット名前空間よりもはるかに優れたディレクトリ管理アクティビティを実行し、ジョブのパフォーマンスを向上させます。

管理

ディレクトリとサブディレクトリを使用してファイルを整理および管理できるため、管理がさらに簡単になります。

安全性

POSIX権限はフォルダーまたは特定のファイルに設定できる ため、 セキュリティを強化できます。

また、Data Lake Storage Gen2 は、安価な Azure Blob Storage をベースとしているため、比較的手頃な価格です。追加機能により、Azure を使用してビッグ データ分析を実行する場合の総所有コストが削減されます。

Data Lake Storage Generation 2 の重要な特徴

• Data Lake Storage Gen2 を使用すると、Hadoop 分散ファイル システム(HDFS) と同等の方法でデータを整理し、アクセスできます。すべての Apache Hadoop セットアップは、データへのアクセスに使用される新しい ABFS ドライバーをサポートします。Azure HDInsight、Azure Databricks、Azure Synapse Analytics は、これらの環境の例です。
• Data Lake Gen 2 のセキュリティ モデルは、ACL と POSIX アクセス許可に加えて、Data Lake Storage Gen 2 に固有のその他の粒度もサポートしています。さらに、Hive や Spark、Storage Explorer などのフレームワークを使用して構成を設定できます。
• コスト効率が高い: Data Lake Storage Gen2 は、低コストのストレージ スペースとトランザクションを提供します。Azure Blob Storage ライフサイクルなどの機能を利用すると、データがライフサイクルを通過するにつれてコストが削減されます。
• ドライバーの最適化: ABFS ドライバーはビッグデータ分析用に調整されています。エンドポイント dfs.core.windows.net は、対応する REST APIを公開します。

スケーラビリティ

Data Lake Storage Gen 2 または Blob Storage インターフェイスのどちらを介してアクセスしても、Azure Storage は拡張できるように設計されています。数エクサバイトのデータを保存して提供できます。このストレージ ボリュームのスループットは、高い入出力操作/秒 (IOPS) でのギガビット/秒 (Gbps) で測定されます。処理遅延はサービス、アカウント、ファイル レベルで監視され、リクエストごとにほぼ一定のままです。Data Lake Storage Gen 2 または Blob Storage インターフェイスのどちらを介してアクセスしても、Azure Storage は拡張できるように設計されています。数エクサバイトのデータを保存して提供できます。このストレージ ボリュームのスループットは、高い入出力操作/秒 (IOPS) でのギガビット/秒 (Gbps) で測定されます。処理遅延はサービス、アカウント、ファイル レベルで監視され、リクエストごとにほぼ一定のままです。

費用対効果

Data Lake Storage Gen 2 は Azure Blob Storage 上に構築されているため、ストレージ容量とトランザクション コストが低くなります。他のクラウド ストレージ プロバイダーとは異なり、調査のためにデータを移動したり変更したりする必要はありません。価格の詳細については、「Azure Storage の価格」を参照してください。

階層型名前空間などの機能も、多くの分析アクティビティの全体的なパフォーマンスを大幅に向上させます。パフォーマンスの向上により、同じ量のデータを処理するのに必要な計算能力が減り、分析プロジェクト全体の総所有コスト (TCO) が削減されます。

1 つのサービスで複数のアイデアを実現

Data Lake Storage Gen 2 は Azure Blob Storage に基づいているため、同じ共有オブジェクトをいくつかの概念で説明できます。

以下は、同じオブジェクトをさまざまな概念で説明したものです。特に明記されていない限り、次の用語は直ちに同義です。

コンセプト	上位組織	下部組織	データコンテナ
BLOB - 汎用オブジェクト ストレージ	容器	仮想ディレクトリ (SDK のみ - アトミック操作は提供しません)	スポット
Azure Data Lake Storage Gen2 - 分析ストレージ	容器	目次	書類

BLOB ストレージのサポート機能

アカウントは、診断ログ、アクセス層、Blob Storage ライフサイクル管理ポリシーなどの Blob Storage 機能にアクセスできます。ほとんどの BLOB ストレージ機能は完全にサポートされていますが、一部の機能はプレビュー モードでのみサポートされているか、まったくサポートされていません。

Data Lake Storage Gen 2 での各 Blob Storage 機能のサポート方法の詳細については、「Azure Storage アカウントでの Blob Storage 機能のサポート」を参照してください。

サポートされている Azure サービス統合

Data Lake Storage gen2 は、さまざまな Azure サービスをサポートしています。これらは、分析の実行、視覚化の生成、およびデータの取り込みに使用できます。サポートされている Azure サービスの一覧については、「Azure Data Lake Storage Gen2 をサポートする Azure サービス」を参照してください。

サポートされているオープンソース プラットフォーム

Data Lake Storage Gen2 は、いくつかのオープン ソース プラットフォームでサポートされています。完全なリストについては、「Azure Data Lake Storage Gen 2 をサポートするオープン ソース プラットフォーム」を参照してください。

Azure Data Lake Storage Gen 2 のベスト プラクティスを活用する

Azure Data Lake Storage の Gen 2 バージョンは、特定のサービスまたはアカウントの種類ではありません。これは、高スループット分析タスクのためのツールのコレクションです。これらの機能を活用するためのベスト プラクティスと手順については、「Data Lake Storage Gen 2 リファレンス」で説明されています。ネットワーク セキュリティの設定、高可用性の設計、ディザスター リカバリーなど、アカウント管理のその他すべての側面については、Blob Storage のドキュメントを参照してください。

機能の互換性と既知の問題を確認する

Blob Storage サービスを利用するためにアカウントを設定する場合は、次の方法を適用します。

• アカウントが機能を完全にサポートしているかどうかを確認するには、Azure Storage アカウントの Blob Storage 機能のサポートに関するページを参照してください。Data Lake Storage Gen2 が有効になっているアカウントでは、一部の機能がまったくサポートされていないか、部分的にのみサポートされています。機能サポートは拡大し続けるため、このページで変更がないか頻繁に確認してください。
• 「Azure Data Lake Storage Gen 2 に関する既知の問題」の記事を参照して、使用する機能に制限や具体的な手順があるかどうかを確認してください。
• Data Lake Storage Gen2 対応アカウントに特に適用される推奨事項については、特集記事を参照してください。

文書内で使用されている用語を特定する

コンテンツ セットを切り替えると、語彙が若干変更されていることに気づくでしょう。たとえば、BLOB ストレージの説明の注目のコンテンツでは、「ファイル」の代わりに「Blob」という用語が使用されます。技術的には、ストレージ アカウントにアップロードされたデータはそこで BLOB になります。したがって、この文は正確です。ただし、「ファイル」という用語に慣れている場合、「BLOB」という用語は混乱する可能性があります。ファイルシステムは「コンテナ」とも呼ばれます。これらのフレーズは交換可能なものとして扱います。

プレミアムを考慮する

ワークロードで低い一定の待機時間や高い 1 秒あたりの入出力操作 (IOP) が必要な場合は、Premium ブロック BLOB ストレージ アカウントを検討してください。このようなアカウントでは、データにアクセスできるようにするために高性能ハードウェアが使用されます。ソリッド ステート ドライブ (SSD) は遅延を最小限に抑えるように設計されており、データの保存に使用されます。SSD は、従来のハードドライブよりも優れたスループットを提供します。高度なパフォーマンスでは、ストレージ コストは高くなりますが、トランザクション コストは低くなります。したがって、アプリケーションが多数のトランザクションを実行する場合は、プレミアム パフォーマンスのブロック BLOB アカウントの方がコスト効率が高い可能性があります。

ストレージ アカウントを分析に使用する場合は、Premium ブロック BLOB ストレージ アカウントで Azure Data Lake Storage Gen 2 を使用することを強くお勧めします。Azure Data Lake Storage のプレミアム レベルは、Data Lake Storage 対応アカウントと組み合わせたプレミアム ブロック BLOB ストレージ アカウントです。

データ取り込みを改善する

ソース システムからデータを取り込む場合、ソース ハードウェア、ソース ネットワーク ハードウェア、またはストレージ アカウントへのネットワーク接続がボトルネックになる可能性があります。

 

ソースハードウェア 

Azure 上で仮想マシン(VM) を使用しているか 、オンプレミス デバイス上で使用しているかにかかわらず、適切なハードウェアを慎重に選択してください。より高速なスピンドルを備えたディスク ハードウェアを選択し、ソリッド ステート ドライブ (SSD) を検討してください。ネットワーク ハードウェアには最速のネットワーク インターフェイス コントローラー (NIC) を使用します。Azure D14 VM には十分なネットワーク機能とディスク ハードウェア機能があるため、使用することをお勧めします。

ストレージ アカウントに接続されているネットワーク

ソース データとストレージ アカウントの間のネットワーク接続にボトルネックが存在する場合があります。ソース データがオンプレミスにある場合は、Azure ExpressRoute プライベート リンクの使用が必要になる場合があります。ソース データ (Azure 内の場合) が Data Lake Storage Gen2 対応アカウントと同じ Azure リージョンにある場合、パフォーマンスが最高になります。

可能な限り最大限の並列処理を実現するためのデータ取り込みメカニズムをセットアップする

最適なパフォーマンスを得るために、できるだけ多くの読み取りと書き込みを並行して実行して、利用可能なスループットをすべて使用します。

 

構造化データセット

事前にデータを整理する構造を検討してください。パフォーマンスとコストは、ファイル形式、ファイル サイズ、ディレクトリ構成によって影響を受ける可能性があります。

ファイル形式

データの取り込みにはさまざまな形式を使用できます。データは、tar などの圧縮バイナリ形式で表現できます。go、または人間が判読できる形式 ( JSON、 CSV、XML など) で保存します。データはさまざまなサイズで受信されることもあります。ローカル システムの SQL テーブルから情報をエクスポートするなど、大きなファイル (数テラバイト) がデータを構成することがあります。たとえば、モノのインターネット (IoT) ソリューションからのリアルタイム イベント データは、多数の小さなファイル (サイズは数キロバイト) の形式で送信されることもあります。適切なファイル形式とファイル サイズを選択することで、効率を最大化し、コストを最小限に抑えることができます。

Hadoop は、構造化データの保存と分析のために設計されたさまざまなファイル形式をサポートしています。人気のある形式には、Avro、Parquet、およびOptimized Determinant  (ORC) 形式があります。これらは、マシンが読み取ることができるバイナリ ファイル形式です。ファイル サイズを制御しやすいように圧縮されています。各ファイルには埋め込みスキーマが含まれているため、これらは自己記述的です。データの保存方法は形式によって異なります。Parquet 形式と ORC 形式はデータを列形式で格納しますが、Avro はデータを行ベース形式で格納します。

I/O パターンが書き込み集中型である場合、またはクエリ パターンが大きな行の情報全体をフェッチする傾向がある場合は、Avro ファイル形式を使用することをお勧めします。たとえば、Avro 形式は、Event Hubs や Kafka など、一連のイベントまたはメッセージを書き込むメッセージ バスに適しています。

I/O パターンが読み取り集中型である場合、またはクエリ パターンがレコード内の列の特定のサブセットに焦点を当てている場合は、Parquet および ORC ファイル形式を検討してください。読み取りトランザクションは、完全なレコードを読み取るのではなく、特定の列のみをフェッチするように削減される場合があります。

オープンソースの Apache Parquet は、読み取り中心の分析パイプライン用に設計されたファイル形式です。Parquet の列指向ストレージ形式のおかげで、無関係なデータをスキップできます。クエリは、ストレージから分析エンジンに送信されるデータに固有である可能性があるため、はるかに効率的です。さらに、Parquet は、類似したデータ型 (列) が一緒に保存されるため、データ ストレージのコストを削減できる効率的なデータ エンコードおよび圧縮技術を提供します。ネイティブ Parquet ファイル形式は、Azure Synapse Analytics、Azure Databricks、Azure Data Factory などのサービスでサポートされています。

ファイルサイズ

ファイルが大きいほどパフォーマンスが向上し、コストが削減されます。

HDInsight などの分析エンジンには通常、ファイルごとのオーバーヘッドが含まれます。これには、リスト、アクセス許可の決定、さまざまなメタデータ操作の実行などのアクティビティが含まれます。いくつかの小さなファイルの形式でデータを保存すると、パフォーマンスに悪影響を及ぼす可能性があります。パフォーマンスを向上させるには、データをより大きなファイル (サイズ 256 MB ～ 100 GB) に編成します。一部のエンジンやプログラムは、100 GB を超えるファイルを効率的に処理できない場合があります。

ファイルを拡大することのもう 1 つの利点は、トランザクション コストの削減です。ファイルに 4 MB が含まれているか、数 KB しか含まれていない場合でも、読み取りおよび書き込みアクティビティに対して 4 MB 単位で料金が発生します。価格の詳細については、「Azure Data Lake Storage の価格」を参照してください。

生データは多数の小さなファイルで構成されており、データ パイプラインによる制御が制限される場合があります。ダウンストリーム アプリケーションで使用できるように、小さなファイルを大きなファイルにマージするプログラムをシステムに組み込むことをお勧めします。データをリアルタイムで処理する場合は、Spark Streaming や Azure Stream Analytics などのリアルタイム ストリーミング エンジンと Event Hubs や Apache Kafka などのメッセージ ブローカーを使用して、データをより大きなファイルとして保存できます。小さなファイルを大きなファイルにマージする場合は、後で処理できるように、読み取りに最適化された形式 (Apache Parquet など) でファイルを保存することを検討してください。

ディレクトリ構造

これらは、モノのインターネット(IoT)、バッチ シナリオ、または時系列データの最適化を操作する ときに考慮すべき一般的なレイアウトの一部です。すべてのワークロードには、データの使用方法に関するさまざまな要件があります。

バッチ作業のスケジュール設定

IoT ワークロードでは、多くの商品、デバイス、企業、顧客からの大量のデータを取り込むことができます。ディレクトリ レイアウトは、下流ユーザーに組織的で安全かつ効率的なデータ処理を提供するために、時間内に計画する必要があります。次の設計は、検討すべき広範なテンプレートとして機能します。

{Region}/{SubjectMatter(s)}/{yyyy}/{mm}/{dd}/{hh}/

たとえば、英国の航空機エンジンの着陸テレメトリ構造は次のようになります。

UK/Planes/BA1293/Engine1/2017/08/11/12/

この例では、ディレクトリ構造の末尾に日付を追加することで、エリアとトピックをユーザーとグループにさらに簡単に制限できます。日付構造が優先される場合、これらのフィールドとテーマを保護することはより困難になります。たとえば、英国のデータまたは特定の航空機のみへのアクセスを制限したい場合は、時間ごとのディレクトリの下にある複数のディレクトリに対して個別の承認をリクエストする必要があります。さらに、この配置では、時間の経過とともにディレクトリの数が急速に増加します。

バッチタスクの構造

「in」ディレクトリへのデータの追加は、頻繁に行われるバッチ処理手法です。データの処理が完了すると、新しいデータは「out」ディレクトリに配置され、他のプロセスがそれを使用できるようになります。このディレクトリ構造は、単一のファイルを調べるだけでよく、必ずしも大規模なデータセットにわたる大規模な並列実行を必要としないタスクに使用されることがあります。有用なディレクトリ構造には、上記の IoT 構造 (組織、製品、プロデューサーなど) など、エリアやトピックなどの親ディレクトリがあります。処理の整理、フィルター検索、セキュリティ、自動化を改善するには、構造を設計するときに日時を考慮してください。データがアップロードまたはダウンロードされる頻度によって、データ構造の粒度のレベルが決まります。

データの破損や予期しないフォーマットにより、ファイル処理が失敗することがあります。このような場合、追加の分析のためにファイルをそこに移動できるように、ディレクトリ構造に /bad フォルダーがあると便利な場合があります。バッチ タスクでは、レポートを監視したり、これらの問題ファイルをユーザーに警告したりして、ユーザーが手動で対処できるようにすることもできます。次のようなテンプレートの配置を考慮してください。

• {Region}/{SubjectMatter(s)}/In/{yyyy}/{mm}/{dd}/{hh}/
• {Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/
• {Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/

たとえば、マーケティング会社は、北米の顧客から顧客最新情報の抜粋を毎日受け取ります。処理の前後では、次のコード スニペットのようになります。

• NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
• NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv

バッチ データが Hive や従来の SQL データベースなどのデータベースに直接処理される一般的なシナリオでは、出力は Hive テーブルまたは外部データベースの別のフォルダーに保存されるため、/in または /out ディレクトリは必要ありません。たとえば、各ディレクトリはコンシューマから毎日データの取得を受け取ります。その後、Azure Data Factory、Apache Oozie、Apache Airflow などのサービスによって毎日の Hive または Spark ジョブが起動され、データが処理されて Hive テーブルに書き込まれます。

時系列データ構造

Hive ワークロードの時系列データのパーティション プルーニングにより、一部のクエリがデータの一部のみを読み取るようになり、パフォーマンスが向上する可能性があります。

時系列データを取り込むパイプラインは通常、ファイルを名前付きフォルダーに整理します。一般的に日付順に並べられたデータの例を次に示します。

• /DataSet/YYYY/MM/DD/datafile_YYYY_MM_DD.tsv

日付と時刻の詳細はファイル名とフォルダーで確認できることに注意してください。

日付と時刻の一般的な形式は次のとおりです。

• /DataSet/YYYY/MM/DD/HH/mm/datafile_YYYY_MM_DD_HH_mm.tsv

繰り返しになりますが、フォルダーとファイルの整理方法についての決定は、ファイル サイズが大きくなり、各フォルダー内のファイル数が管理しやすくなるように最適化する必要があります。

セキュリティを設定する

まず、「BLOB ストレージのセキュリティに関する考慮事項」の記事の推奨事項を確認してください。ファイアウォールの内側でデータを保護し、悪意のある削除や偶発的な削除を防止し、ID 管理の基盤として Azure Active Directory (Azure AD) を使用する方法に関するベスト プラクティスのアドバイスが得られます。

次に、Data Lake Storage Gen 2 が有効になっているアカウントに固有の推奨事項については、「Azure Data Lake Storage Gen 2」ページの「アクセス制御モデル」セクションを参照してください。この記事では、Azure ロールベースのアクセス制御 (Azure RBAC) のロールとアクセス制御リスト (ACL) を使用して、階層ファイル システム内のディレクトリとファイルにセキュリティ アクセス許可を適用する方法について説明します。

導入、導入、評価

データは、さまざまなソースからさまざまな方法で Data Lake Storage Gen2 対応アカウントに取り込むことができます。

アプリケーションのプロトタイプを作成するために、HDInsight クラスターや Hadoop クラスターだけでなく、小規模なアドホック データセットからも大量のデータを取り込むことができます。ソフトウェア、ハードウェア、センサーなどのさまざまなソースによって生成されたストリーミング データを受信できます。ツールを使用して、このデータをイベントごとにリアルタイムで記録および処理し、イベントをバッチでアカウントに書き込むことができます。ページ要求履歴などの詳細を含む、Web サーバーのログを取り込むこともできます。データ アップロード コンポーネントを大規模なビッグ データ アプリケーションに統合する柔軟性が必要な場合は、カスタム スクリプトまたはプログラムを使用してログ データを送信することを検討してください。

アカウントでデータが利用可能になると、そのデータに対して分析を実行したり、視覚化を作成したり、ローカル コンピューターや別のリポジトリ (Azure SQL Database や SQL Server インスタンスなど) にデータをダウンロードしたりすることもできます。

監視テレメトリー

サービスの運用には、使用状況とパフォーマンスの監視に細心の注意が必要です。例には、頻繁に発生するプロセス、大幅な遅延が発生するプロセス、またはサービスを制限するプロセスが含まれます。

ストレージ アカウントのすべてのテレメトリ データには、Azure Monitor の Azure Storage ログを通じてアクセスできます。この機能を使用すると、ログを別のストレージ アカウントにアーカイブし、そのストレージ アカウントを Log Analytics および Event Hubs にリンクできます。メトリック、リソース ログ、およびそれらに対応する構造のコレクション全体を表示するには、「Azure Storage Monitoring Data Reference」にアクセスしてください。

アクセス方法に応じて、ログを好きな場所に保存できます。たとえば、ログにほぼリアルタイムでアクセスし、ログ内のイベントを Azure Monitor の他のメトリックと結合する機能が必要な場合は、ログを Log Analytics ワークスペースに保存できます。次に、KQL とオーサリング クエリを使用してログをクエリし、ワークスペース内の StorageBlobLogs テーブルを一覧表示します。

ほぼリアルタイムのクエリと長期保持のためにログを保存する場合は、Log Analytics ワークスペースとストレージ アカウントにログを送信するように診断設定を設定できます。

Splunk などの他のクエリ エンジンを介してログを取得する場合は、ログを Event Hubs に送信し、Event Hubs から任意の宛先にログを取り込むように診断設定を設定できます。

結論は

Azure Data Lake Storage Gen1 と Azure Blob Storage の機能は、Data Lake Storage Gen2 に統合されています。たとえば、Data Lake Storage Gen2 は、スケール、ファイル レベルのセキュリティ、ファイル システム セマンティクスを提供します。また、これらの機能は BLOB ストレージ上に構築されているため、高可用性/ディザスター リカバリー機能を備えた低コストの階層型ストレージも利用できます。