Azure Data Lake Storage Gen2 を詳しくご紹介

執筆者: Jason Hogg (Group Program Manager, R&D Storage)

このポストは、2018 年 6 月 28 日に投稿された A closer look at Azure Data Lake Storage Gen2 の翻訳です。

 

2018 年 6 月 27 日、マイクロソフトは、エンタープライズ クラスの大規模な分析ワークロードをクラウドで実行することに特化した唯一のデータ レイクである Azure Data Lake Storage Gen2 のプレビューを発表しました (英語)。Azure Data Lake Storage Gen2 は、Hadoop 互換ファイル システム、Azure Active Directory、POSIX ベースの ACL などの主な機能を Azure Data Lake Storage Gen1 から引き継ぎ、Azure Blob ストレージに統合しています。このため、Blob ストレージの階層化やデータ ライフサイクル管理などの機能と、Azure Storage の基盤性能、セキュリティ、耐久性が組み合わさり、クラス最高レベルの分析パフォーマンスを実現することが可能になりました。

今回の記事では、この Azure Data Lake Storage Gen2 の特長を詳しくご紹介します。革新的な Hadoop ファイル システムの実装や Azure Blob ストレージとの統合について掘り下げると共に、Azure Data Lake Storage Gen2 がクラウドできわめて低い総所有コストを実現できる理由を解説します。

階層型の名前空間を持つ高忠実度のサーバー側 Hadoop ファイル システム

Hadoop アプリケーションをクラウド ストレージで使用する場合、図 1 のように、Hadoop ファイル システム ドライバーを Hadoop アプリケーションのクライアント側で実行する方法が最も簡単です。このドライバーは、Hadoop ファイル システムの処理を対象プラットフォームのバックエンド処理に変換して、ファイル システムをエミュレートします。しかしこの方法には非効率な要素が多く、正確性にも課題が残ります。たとえば、オブジェクト ストアの実装で、Hadoop クライアントがフォルダーの名前変更などの一般的な Hadoop ジョブ処理を要求すると、REST 要求が大量に実行されることになります。これは、オブジェクト ストアの名前空間は 1 層構造であり、フォルダーという概念がないためです。5,000 個のアイテムを持つフォルダーの名前を変更する場合、クライアントからの REST API の呼び出し回数は、移動先への子オブジェクトのコピーで 5,000 回と元のファイルの削除で 5,000 回の合計 10,000 回になります。これではパフォーマンスが低下し、ジョブの実行時間が大幅に延びてしまいます。また、処理がアトミックではないためにエラーが発生しやすく、エラーが発生した時点でジョブが失敗しデータの整合性が取れなくなるという欠点もあります。

DiagramsForADLSGen2Blog

図 2 は、Azure Data Lake Storage Gen2 が Blob API と共にこのファイル システムのロジックをサーバー側に移行しているようすです。BLOB REST API と新しい Azure Data Lake Storage Gen2 ファイル システムの API のいずれからも同じデータにアクセスすることができます。これにより、名前変更などのファイル システムの操作を 1 回で実行できるようになります。サーバー側では引き続き基盤となる Blob ストレージと 1 層型の名前空間にこれらの要求をマッピングします。図 1 のモデルよりも効率化されており、一部の処理では Hadoop の忠実度も高くなっていますが、まだアトミックであるとは言えません。

ファイル システム サポートのサーバー側への移行に加えて、Azure Blob ストレージに直接統合できるクラウド規模の階層型名前空間を利用することができます。図 3 は、有効な階層型名前空間で、ファイルやフォルダーが高いレベルでサポートされているようすです。これにより、コピーや削除などの操作をアトミックに実行することができます。名前空間の機能は Azure Data Lake Storage Gen2 API と BLOB API のどちらにも対応しており、使用方法も一貫しています。一般提供の開始時には、どちらの API を使用しても、完全に一貫した方法で同じデータにアクセスできるようになります。

Blob ストレージと Azure Active Directory との統合 (英語) (プレビュー)、および RBAC ベースのアクセス制御は、Azure Data Lake Storage Gen2 の大きな特長です。さらに、階層型名前空間を組み合わせることで、ファイルやフォルダーに対するきめ細かい POSIX ベースの ACL を実現しています。Azure Active Directory の統合と POSIX ベースの ACL は、プレビュー期間中にご利用いただけるようになります。

Azure Blob ストレージとの統合

Azure Data Lake Storage Gen2 は Azure Storage プラットフォームに統合されているため、アプリケーションは、BLOB API と Azure Data Lake Storage Gen2 ファイル システム API のどちらを使用してもデータにアクセスすることができます。BLOB API では、Blob ストレージ内の既存資産の活用が可能なため、以前から使用しているマイクロソフトおよびサードパーティ製の大規模エコシステムを引き続き使用することができます。Azure Data Lake Storage Gen2 ファイル システム API は、Hadoop や Spark などの分析エンジンに最適化されています。

他にも、Azure Storage との統合には以下のようなメリットがあります。

  • スケールとパフォーマンスを無制限に拡張できるストレージ アカウント アーキテクチャ。
  • 個々のオブジェクトの読み込みと書き込みの高速化によるスループットと並列実行数の大幅な向上。
  • データ収集中に分析を実行するかどうかの優先順位付けが不要。Azure Storage では、すべてのデータを分析に利用することができます。
  • 優れたデータ保護機能。マイクロソフトやお客様の管理者キーを使用した格納時にもすべてのデータを暗号化します。
  • ゾーン冗長ストレージや geo 冗長ストレージなどの耐久性オプション。アプリケーションの可用性を高めて災害復旧に対応します。
  • Linux との統合。blobfuse を使用して Linux VM に Blob ストレージをマウントし、標準的な Linux シェル コマンドで Azure Data Lake Storage Gen2 を操作することができます。

Azure Storage プラットフォームは確実な一貫性を保っており、書き込み完了をクライアントに通知する前にそのデータの耐久性を保証します。これは、処理の出力を次のジョブの入力として使用するビッグ データ ワークロードにおいて、きわめて重要なことです。整合性の低い結果整合性モデルによくある問題は発生しないため、対策の手間が省け、ビッグ データ アプリケーションの開発を大幅に簡素化することができます。

総所有コストの最小化

Azure Data Lake Storage Gen2 では、Hadoop や Spark などのビッグ データ ワークロードに最適化されたクラウド規模の HDFS との互換性をサポートします。階層型名前空間との統合により、通常オブジェクト ストアにのみ関連付けられるファイル システムの規模やコストのメリットをフルに活用することができます。Blob ストレージの容量あたりの料金以外にも、ストレージ パフォーマンスの改善や複雑なファイル システム処理を 1 回の操作で実行できるため、分析エンジン効率が向上し、分析ジョブの実行コストを削減できるというメリットがあります。また、Blob ストレージの容量あたりの料金、統合された階層化、ライフサイクル管理ポリシーを組み合わせて、Hot、Cool、さらに最も安価な Archive にデータを階層化することでデータの総所有コストを最小化することができます。

Azure Data Lake Storage Gen2 を試す

さらに詳しく知りたい方は、以下をご確認ください。

●       プレビューにサインアップ (英語) して Azure Data Lake Storage をお試しください。

●       Azure Data Lake Storage Gen2 の使用を開始する場合は、こちらのビデオ (英語) をご覧ください。

●       Azure Data Lake Storage Gen2 の主な機能は、こちらのページ (英語) でご確認ください。

●       ADLS Gen2 は、HDInsight でもご利用いただけます。今回の統合の詳細と、Hadoop や Spark などのオープン ソース フレームワークの情報については、こちらの記事 (英語) をお読みください。