E-MapReduce:SmartData (E-MapReduce 3.20.0 から 3.22.0 未満)

概要

JindoFS は、OSS とローカルストレージを組み合わせたクラウドネイティブファイルシステムです。 E-MapReduce の次世代ストレージシステムとして、コンピューティングエンジンに効率的で信頼性の高いストレージを提供します。

JindoFS には、ブロックストレージモードとキャッシュモードの 2 つのストレージモードがあります。

JindoFS は、ローカルストレージと OSS の両方を活用する異種マルチバックアップメカニズムを使用します。 Storage Service は、高いデータ信頼性のために OSS を主要なストレージバックエンドとして使用し、読み取りを高速化するためにローカルストレージを冗長バックアップとして使用します。 メタデータはローカルの Namespace Service によって管理され、HDFS に匹敵するメタデータ操作パフォーマンスを実現します。

適用シナリオ

E-MapReduce は現在、E-MapReduce OssFileSystem、E-MapReduce HDFS、E-MapReduce JindoFS の 3 つのビッグデータストレージシステムを提供しています。 このうち、OssFileSystem と JindoFS はクラウドストレージソリューションです。 次の表は、これら 3 つのストレージシステムとオープンソース OSS のそれぞれの特徴を示しています。

JindoFS ブロックストレージモードには、次のようないくつかの特徴があります。

• 大容量で弾力性のあるストレージ容量。 OSS をストレージバックエンドとして使用することで、ストレージはローカルクラスターに制限されず、ローカルクラスターは自由に弾力的にスケールできます。
• ローカルクラスターのストレージリソースを活用してデータ読み取りを高速化できます。 一定のローカルストレージ能力を持つクラスターに適しており、限られたローカルストレージを活用してスループットを向上させることができます。 特に、1 回書き込み複数回読み取りのシナリオで効果的です。
• メタデータ操作効率が高く、HDFS に匹敵します。 OSS ファイルシステムのメタデータ操作の遅延や、高頻度アクセス時に発生する可能性のある不安定性の問題を効果的に回避できます。
• ジョブ実行時のデータローカリティを最大限に確保し、ネットワーク転送の負荷を軽減し、読み取りパフォーマンスをさらに向上させます。

前提条件

• 3.20.0 以上 3.22.0 未満の E-MapReduce バージョンを選択します。オプションサービスセクションで、[SmartData] と [Bigboot] を選択します。詳細については、「クラスターの作成」をご参照ください。Bigboot サービスは、分散データ管理やコンポーネントの監視などのコアプラットフォームサービスを提供します。SmartData サービスは Bigboot をベースにしており、アプリケーションに JindoFS ファイルシステムを提供します。

  
• クラスターの設定
  SmartData が提供する JindoFS ファイルシステムは、OSS をストレージバックエンドとして使用します。 JindoFS を使用する前に、次のいずれかの方法で必要な OSS パラメータを設定します。 クラスター作成後に Bigboot のパラメータを変更して SmartData を再起動するか、クラスター作成時にカスタム設定を追加して、指定したパラメータでサービスを起動します。

  • 方法 1：クラスター作成後の設定
    • oss.access.bucket は、OSS バケットの名前を指定します。
    • oss.data-dir は、JindoFS が OSS バケット内で使用するディレクトリを指定します。 注：このディレクトリは JindoFS ストレージバックエンドとして機能します。 含まれるデータを手動で変更しないでください。 また、JindoFS 専用に使用してください。 このディレクトリを OSS に事前に作成する必要はありません。 JindoFS は、最初にデータを書き込むときに自動的に作成します。
    • oss.access.endpoint は、バケットが配置されているリージョンを指定します。
    • oss.access.key は、OSS ストレージバックエンドの AccessKey ID を指定します。
    • oss.access.secret は、OSS ストレージバックエンドの AccessKey シークレットを指定します。

    最適なパフォーマンスと安定性を得るには、E-MapReduce クラスターと同じリージョンにある OSS バケットを使用してください。 これにより、AccessKey ID や AccessKey シークレットを設定することなく、認証情報なしでアクセスできます。

    すべての JindoFS 設定は Bigboot コンポーネントにあります。 次の図は、必要な項目を赤色で強調表示しています。

    
    説明 JindoFS は複数の名前空間をサポートしています。 ここでは、例として test という名前の名前空間を使用します。

    設定が完了したら、保存してデプロイします。 次に、SmartData サービスのすべてのコンポーネントを再起動して、JindoFS の使用を開始します。

    
  • 方法 2：クラスター作成時の設定
    E-MapReduce クラスターの作成時にカスタム設定を追加できます。 たとえば、認証情報なしで同じリージョンの OSS バケットへのアクセスを有効にするには、図に示すように [カスタムソフトウェア設定] を選択し、次の JSON を追加して oss.data-dir と oss.access.bucket を設定します。

    [
        {         
        "ServiceName":"BIGBOOT",
        "FileName":"bigboot",
        "ConfigKey":"oss.data-dir",
        "ConfigValue":"jindoFS-1"
        },
        {
        "ServiceName":"BIGBOOT",
        "FileName":"bigboot",
        "ConfigKey":"oss.access.bucket",
        "ConfigValue":"oss-bucket-name"
        }
    ]

    

JindoFS の使用

hadoop fs -ls jfs:///
hadoop fs -mkdir jfs:///test-dir
hadoop fs -put test.log jfs:///test-dir/

ディスク容量ウォーターマーク制御

JindoFS は、大容量ストレージのためにバックエンドとして OSS を使用しますが、ローカルディスク容量は限られています。 JindoFS は、node.data-dirs.watermark.high.ratio と node.data-dirs.watermark.low.ratio の 2 つのウォーターマークパラメータに基づいて、コールドデータバックアップを自動的にエビクトします。 どちらのパラメータも、ディスク総容量に対する比率 (0 から 1 の小数) として設定されます。 ディスク使用率が高ウォーターマークに達すると、JindoFS は使用率が低ウォーターマークまで低下するまでデータをエビクトします。 低ウォーターマークの値は、高ウォーターマークよりも低く設定する必要があります。

ストレージポリシーの適用

次のコマンドを実行して、ディレクトリにストレージポリシーを設定します。

jindo dfsadmin -R -setStoragePolicy [path] [policy]

次のコマンドを実行して、ディレクトリのストレージポリシーを確認します。

jindo dfsadmin -getStoragePolicy [path]