この記事では、パフォーマンスの最適化、コストの削減、Data Lake Storage が有効な Azure Storage アカウントのセキュリティ保護に役立つベスト プラクティスのガイドラインについて説明します。
ドキュメントの検索
Azure Data Lake Storage は、専用のサービスまたはアカウントの種類ではありません。 これは、高スループットの分析ワークロードをサポートする一連の機能です。 Data Lake Storage のドキュメントでは、これらの機能を使用するためのベスト プラクティスとガイダンスについて説明されています。 ネットワーク セキュリティの設定、高可用性の設計、ディザスター リカバリーなど、アカウント管理のその他のすべての側面については、Blob Storage のドキュメントのコンテンツを参照してください。
機能のサポートと既知の問題を評価する
Blob Storage の機能を使用するようにアカウントを構成する場合は、次のパターンを使用します。
アカウントで機能が完全にサポートされているかどうかを判断するには、「Azure ストレージ アカウントにおける Blob Storage 機能のサポート」を参照してください。 一部の機能は、Data Lake Storage が有効なアカウントではまだサポートされていないか、部分的にしかサポートされていません。 機能のサポートは常に拡張されているため、この記事の更新について定期的に確認してください。
「Azure Data Lake Storage に関する既知の問題」の記事を参照して、使用する予定の機能に関する制限事項や特別なガイダンスがあるかどうかを確認します。
Data Lake Storage が有効なアカウントに固有のガイダンスについては、機能に関する記事を確認してください。
ドキュメントで使用されている用語を理解する
コンテンツ セット間を移動すると、わずかな用語の違いがわかります。 たとえば、BLOB ストレージのドキュメントで紹介されているコンテンツでは、ファイルではなく BLOB という用語が使用されます。 技術的には、ストレージ アカウントに取り込むファイルは、アカウント内の BLOB になります。 そのため、その用語が正しくなります。 ただし、"ファイル" という用語に慣れている場合、"BLOB" という用語によって混乱が生じる可能性があります。 ファイル システムを指してコンテナーという用語が使われることもあります。 これらの用語は同義と見なします。
Premium を検討する
ワークロードで低い一貫性のある待機時間が必要な場合、または 1 秒あたりに大量の入力出力操作 (IOPS) が必要な場合は、Premium ブロック BLOB ストレージ アカウントの使用を検討してください。 この種類のアカウントを使用すると、高パフォーマンスのハードウェアを介してデータを使用できるようになります。 データは、低待機時間のために最適化されたソリッドステート ドライブ (SSD) に格納されています。 SSD は従来のハード ドライブと比べ、スループットが高くなります。 Premium パフォーマンスの方がストレージ コストは高くなりますが、トランザクション コストは低くなります。 したがって、ワークロードで多数のトランザクションを実行する場合、Premium パフォーマンス ブロック BLOB アカウントは経済的である可能性があります。
ストレージ アカウントを分析に使用する場合は、Premium ブロック BLOB ストレージ アカウントと共に Azure Data Lake Storage を使用することを強くお勧めします。 Premium ブロック BLOB ストレージ アカウントと Data Lake Storage 対応アカウントを組み合わせて使用する方法は、Azure Data Lake Storage の Premium レベルと呼ばれています。
データの取り込みを最適化する
ソース システムからデータを取り込むとき、ソース ハードウェア、ソース ネットワーク ハードウェア、またはストレージ アカウントへのネットワーク接続によってボトルネックが発生する可能性があります。
元のハードウェア
Azureでオンプレミスのマシンまたは仮想マシン (VM) を使用しているかどうかに関係なく、適切なハードウェアを慎重に選択します。 ディスク ハードウェアの場合は、ソリッド ステート ドライブ (SSD) の使用を検討し、より高速なスピンドルを備えるディスク ハードウェアを選択します。 ネットワーク ハードウェアの場合は、可能な限り最速のネットワーク インターフェイス コントローラー (NIC) を使用します。 Azureでは、適切に強力なディスクとネットワーク ハードウェアを備えた Azure D14 VM を使用します。
ストレージ アカウントへのネットワーク接続
ソース データとストレージ アカウントの間のネットワーク接続によって、ボトルネックが発生する場合があります。 ソース データがオンプレミスの場合は、Azure ExpressRouteで専用リンクを使用することを検討してください。 ソース データが Azure にある場合、データが Data Lake Storage が有効なアカウントと同じ Azure リージョンにあるときにパフォーマンスは最適となります。
データ インジェスト ツールの最大並列化処理の構成
最適なパフォーマンスを得るには、可能な限り多くの読み取りと書き込みを並列で実行することで、使用可能なすべてのスループットを使用します。
次の表に、一般的なインジェスト ツールの主要な設定の概要を示します。
| ツール | 設定 |
|---|---|
| DistCp | -m (マッパー) |
| Azureデータファクトリー | 並列コピー |
| Sqoop | fs.azure.block.size, -m (マッパー) |
| AzCopy | AZCOPY_CONCURRENCY_VALUE |
インジェスト ツールのより包括的な一覧については、「 移行ツールの選択」を参照してください。
注
取り込み操作の全体的なパフォーマンスは、データの取り込みに使用しているツールに固有の他の要因によって異なります。 最新のガイダンスについては、使用する予定の各ツールのドキュメントを参照してください。
アカウントは、あらゆる分析シナリオで必要とされるスループットを提供するようにスケーリングできます。 既定では、Data Lake Storage が有効なアカウントは、既定の構成で十分なスループットを提供し、幅広いカテゴリのユース ケースのニーズを満たすことができます。 既定の制限に達した場合は、Azure サポートに問い合わせて、より多くのスループットを提供するようにアカウントを構成してください。
構造体のデータセット
データの構造を事前に計画することを検討してください。 ファイル形式、ファイル サイズ、ディレクトリ構造は、すべてパフォーマンスとコストに影響します。
ファイル形式
さまざまな形式でデータを取り込むことができます。 データは、JSON、CSV、XML などの人間が判読できる形式で表示することも、 .tar.gzなどの圧縮バイナリ形式として表示することもできます。 データのサイズはさまざまです。 データは、オンプレミス システムからの SQL テーブルのエクスポートのデータなど、大きなファイル (数テラバイト) で構成できます。 データは、モノのインターネット (IoT) ソリューションのリアルタイム イベントからのデータなど、多数の小さなファイル (数キロバイト) の形式で表示されることもあります。 適切なファイル形式とファイル サイズを選択すれば、効率とコストを最適化できます。
Hadoop では、構造化データを格納および処理するために最適化された一連のファイル形式をサポートしています。 一般的な形式としては、Avro、Parquet、Optimized Row Columnar (ORC) があります。 これらの形式はすべて、コンピューターが判読できるバイナリ ファイル形式です。 これらは、ファイル サイズを管理できるように圧縮されています。 各ファイルにはスキーマが埋め込まれているため、自己記述型になります。 これらの形式の違いは、データの格納方法です。 Avro では行ベースの形式でデータが格納され、Parquet および ORC 形式では列形式でデータが格納されます。
I/O パターンの書き込み負荷が高い場合、またはクエリ パターンが複数行のレコード全体を取得することを優先する場合は、Avro ファイル形式を使用します。 たとえば、Avro 形式は、複数のイベントまたはメッセージを連続して書き込む Event Hubs や Kafka などのメッセージ バスに適しています。
I/O パターンの読み取り負荷が高い場合、またはクエリ パターンがレコード内の列のサブセットに重点を置いている場合は、Parquet および ORC ファイル形式を使用します。 レコード全体を読み取るのではなく、特定の列を取得するために読み取りトランザクションを最適化できます。
Apache Parquet は、読み取り負荷の高い分析パイプライン用に最適化されたオープンソースのファイル形式です。 Parquet の列指向ストレージ構造を使用すると、関連のないデータをスキップできます。 ストレージから分析エンジンに送信するデータの範囲を絞ることができるので、クエリの方がはるかに効率的です。 また、類似のデータ型 (列の場合) が一緒に格納されるため、Parquet ではデータ ストレージ コストを削減できる効率的なデータ圧縮とエンコード スキームをサポートしています。 Azure Synapse Analytics、Azure Databricks、Azure Data Factoryなどのサービスには、Parquet ファイル形式を利用するネイティブ機能があります。
ファイル サイズ
ファイル サイズを大きくすると、パフォーマンスが向上し、コストが削減されます。
通常、HDInsight などの分析エンジンには、一覧表示、アクセスの確認、さまざまなメタデータ操作の実行などのタスクを含むファイルごとのオーバーヘッドがあります。 データを多数の小さなファイルとして格納する場合、この選択はパフォーマンスに悪影響を与える可能性があります。 一般的に、データを大きなサイズ (256 MB から 100 GB のサイズ) のファイルに整理するとパフォーマンスが向上します。 エンジンとアプリケーションの中には、サイズが 100 GB を超えるファイルを効率的に処理できないものもあります。
ファイル サイズを大きくすると、トランザクションのコストを削減することもできます。 読み取り操作と書き込み操作は 4 MB 単位で課金されるため、ファイルに 4 MB が含まれているかどうかに関係なく、操作に対して課金されます。 価格の情報については、「Azure Data Lake Storage の価格」を参照してください。
場合によっては、データ パイプラインで小さなファイルを多数含む生データの制御が制限されることがあります。 一般に、システムには、ダウンストリーム アプリケーションで使用するために、小さなファイルを大きなファイルに集約するための何らかのプロセスが必要です。 リアルタイムでデータを処理する場合は、リアルタイム ストリーミング エンジン (Azure Stream Analytics や Spark ストリーミングなど) をメッセージ ブローカー (Event Hubs や Apache Kafka など) と共に使用して、より大きなファイルとしてデータを格納できます。 小さいファイルを大きなファイルにまとめるときは、ダウンストリーム処理のために Apache Parquet などの読み取り最適化形式で保存することを検討してください。
ディレクトリの構造
各ワークロードには、データの使用方法に関して異なる要件があります。 ただし、モノのインターネット (IoT)、バッチ シナリオ、または時系列データ用に最適化する場合は、これらの一般的なレイアウトを検討してください。
IoT の構造
IoT ワークロードでは、多数の製品、デバイス、組織、顧客にまたがる大量のデータを取り込む可能性があります。 ダウンストリーム コンシューマー向けに、組織、セキュリティ、および効率的なデータ処理用のディレクトリ レイアウトを事前に計画します。 考慮する一般的なテンプレートは、次のようなレイアウトになります。
- {Region}/{SubjectMatter(s)}/{yyyy}/{mm}/{dd}/{hh}/
たとえば、英国の飛行機のエンジンのランディング テレメトリは次のような構造になります。
- UK/Planes/BA1293/Engine1/2017/08/11/12/
この例では、ディレクトリ構造の末尾に日付を指定することで、ACL を使用して、より簡単に特定のユーザーとグループに対してリージョンと主題をセキュリティで保護できます。 日付構造を先頭に指定すると、これらのリージョンと主題をセキュリティで保護することが大幅に難しくなります。 たとえば、英国のデータまたは特定の飛行機のみにアクセスを提供する場合は、時間ごとのディレクトリの下にある多数のディレクトリに対して個別にアクセス許可を適用する必要があります。 また、この構造の場合、時間が経過するにつれてディレクトリの数が指数関数的に増加します。
バッチジョブの構造
バッチ処理で一般的に使用される方法は、データを "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 テーブルまたは外部データベース用の別のフォルダーに既に格納されているため、インディレクトリまたは出力ディレクトリは必要ありません。 たとえば、顧客からの毎日の抽出データは、顧客ごとの対応するディレクトリに格納されます。 その後、Azure Data Factory、Apache Oozie、Apache エアフローなどのサービスは、毎日の 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 管理の基礎としてMicrosoft Entra IDを使用する方法に関するベスト プラクティス ガイダンスを見つけます。
次に、Data Lake Storage が有効なアカウントに固有のガイダンスについて、「Azure Data Lake Storage のアクセス制御モデル」の記事を確認します。 この記事は、Azure のロールベースのアクセス制御 (Azure RBAC) ロールをアクセス制御リスト (ACL) とともに使用して、階層ファイル システム内のディレクトリとファイルにセキュリティ アクセス許可を適用する方法を理解するのに役立ちます。
取り込み、処理、分析
さまざまなソースからさまざまな方法で、Data Lake Storageが有効なアカウントにデータを取り込むことができます。
たとえば、HDInsight と Hadoop クラスターから大量のデータ セットを取り込んだり、アプリケーションのプロトタイプを作成するために、アドホック データの小さなセットを取り込んだりできます。 アプリケーション、デバイス、センサーなど、さまざまなソースによって生成されるストリーミング データを取り込むことができます。 この種類のデータでは、ツールを使用してイベントごとにリアルタイムでデータをキャプチャして処理し、イベントをバッチでアカウントに書き込みます。 ページ要求の履歴などの情報を含む Web サーバー ログを取り込むこともできます。 ログ データの場合は、大規模なビッグ データ アプリケーションの一部としてデータアップロード コンポーネントを柔軟に含めることができるように、それらをアップロードするカスタム スクリプトまたはアプリケーションを記述することを検討してください。
アカウントでデータを使用できるようになると、そのデータに対して分析を実行したり、視覚エフェクトを作成したり、データをローカル コンピューターやその他のリポジトリ (Azure SQL データベースや SQL Server インスタンスなど) にダウンロードしたりすることができます。
以下の表では、データの取り込み、分析、視覚化、ダウンロードに使用できるツールを推奨しています。 この表のリンクで、各ツールの構成方法と使用方法に関するガイダンスを参照してください。
| 目的 | ツールとツールの使用ガイド |
|---|---|
| アドホック データの取り込み | Azure portal、Azure PowerShell、Azure CLI、REST、Azure Storage Explorer、Apache DistCp、AzCopy |
| リレーショナルデータの取り込み | Azureデータファクトリー |
| Web サーバーのログの取り込み | Azure PowerShell、Azure CLI、REST、Azure SDK (.NET、Java、Python、Node.js)、Azure Data Factory |
| HDInsight クラスターから取り込む | Azure Data Factory、Apache DistCp、AzCopy |
| Hadoop クラスターから取り込み | Azure Data Factory、Apache DistCp、WANdisco LiveData Migrator for Azure、Azure Data Box |
| 大きなデータ セットの取り込み (数テラバイト) | Azure ExpressRoute |
| データの処理と分析 | Azure Synapse Analytics、Azure HDInsight、Databricks |
| データの視覚化 | Power BI、Azure Data Lake Storage のクエリ アクセラレーション |
| データをダウンロードする | Azure portal、PowerShell、Azure CLI、REST、Azure SDK (.NET、Java、Python、Node.js)、Azure Storage Explorer、AzCopy、Azure Data Factory、Apache DistCp |
注
この表には、Data Lake Storage がサポートされる Azure サービスの完全な一覧が反映されているわけではありません。 サポートされているAzure サービスとそのサポート レベルの一覧については、Azure Data Lake StorageをサポートAzureサービスを参照してください。
テレメトリを監視する
サービスの使用とパフォーマンスの監視は、サービスの運用化の重要な部分です。 テレメトリの例としては、頻繁な操作、待機時間の長い操作、サービス側の調整を引き起こす操作などがあります。
Azure MonitorのAzure Storage ログを使用して、ストレージ アカウントのすべてのテレメトリにアクセスできます。 この機能により、ストレージ アカウントと Log Analytics およびイベント ハブが統合され、ログを別のストレージ アカウントにアーカイブすることもできます。 メトリックとリソース ログとそれに関連するスキーマの完全な一覧については、監視データリファレンスAzure Storage参照してください。
ログを格納する場所は、ログにアクセスする方法によって異なります。 たとえば、ほぼリアルタイムでログにアクセスし、ログ内のイベントをAzure Monitorの他のメトリックと関連付けることができる場合は、Log Analytics ワークスペースにログを格納します。 その後、KQL を使用してログに対してクエリを実行し、ワークスペースに StorageBlobLogs テーブルを列挙するクエリを作成できます。
ほぼリアルタイムのクエリと長期的なリテンション期間の両方のログを格納する場合は、Log Analytics ワークスペースとストレージ アカウントの両方にログを送信するように診断設定を構成します。
Splunk などの別のクエリ エンジンを使用してログにアクセスする場合は、イベント ハブにログを送信し、イベント ハブから選択した宛先にログを取り込むように診断設定を構成します。
Azure MonitorでAzure Storage ログを有効にするには、Azure ポータル、PowerShell、Azure CLI、およびAzure Resource Manager テンプレートを使用します。 大規模なデプロイの場合は、修復タスクを完全にサポートするAzure Policyを使用します。 詳細については、ciphertxt/AzureStoragePolicy を参照してください。