E-MapReduce:EMR V3.20.0～V3.22.0（V3.22.0を除く）でのJindoFSの使用

概要

JindoFSは、オブジェクトストレージサービス（OSS）とローカルストレージの利点を組み合わせたクラウドネイティブのファイルシステムです。 JindoFSはまた、E-MapReduce（EMR）のクラウドコンピューティングのために効率的かつ信頼性の高いストレージサービスを提供する次世代ストレージシステムです。

JindoFSは、ブロックストレージモードとキャッシュモードをサポートしています。

JindoFSは、異種混在マルチバックアップメカニズムを採用しています。 Storage Serviceはデータストレージ機能を提供します。 データはOSSに保存され、高い信頼性が保証されます。 冗長バックアップはローカルクラスターに保存され、読み取り操作が高速化されます。 Namespace Serviceは、JindoFSのメタデータを管理します。 この場合、メタデータはOSSではなくNamespace Serviceからクエリされるため、クエリのパフォーマンスが向上します。 このJindoFSのクエリ方法は、Hadoop Distributed File System（HDFS）のクエリ方法に似ています。

シナリオ

EMRには、EMR OssFileSystem、EMR HDFS、EMR JindoFSの 3 つのストレージシステムがあります。 これらのうち、OssFileSystemとJindoFSはデータをクラウドに保存します。 次の表は、 3 つのEMRストレージシステムの機能と、Alibaba Cloud OSSのHadoopサポートを比較したものです。

JindoFSのブロックストレージモードには、次の機能があります。

• JindoFSは、OSSをストレージバックエンドとして使用することにより、膨大でスケーラブルなストレージ容量を提供します。 ストレージ容量は、EMRクラスターの規模とは無関係です。 ローカルクラスターは、必要に応じてスケールインまたはスケールアウトできます。
• JindoFSは、読み取り操作を高速化するために、一部のバックアップデータをローカルクラスターに保存します。 これにより、特にWrite Once Read Many（WORM）ソリューションの場合、限られたローカルストレージ容量を使用してスループットが向上します。
• JindoFSは、HDFSと同様に効率的なメタデータクエリを提供します。 OssFileSystemと比較して、JindoFSはメタデータクエリで多くの時間を節約します。 さらに、JindoFSは、データとメタデータに頻繁にアクセスする場合のシステムの不安定さを回避します。
• JindoFSは、EMRクラスターでジョブが実行されるときに、最大のデータローカリティを保証します。 これにより、ネットワーク伝送の負荷が軽減され、読み取りパフォーマンスが向上します。

環境を準備する

• EMRクラスターを作成する

  EMR V3.20.0～V3.22.0（V3.22.0を除く）からバージョンを選択します。 オプションサービスから [smartdata] と [bigboot] を選択します。 EMRクラスターの作成方法の詳細については、「クラスターの作成」をご参照ください。 Bigbootは、EMRで分散データ管理サービスとコンポーネント管理サービスを提供します。 Bigbootに基づいて、SmartDataはアプリケーション層にJindoFSを提供します。

  
• JindoFSを構成する
  SmartDataによって提供されるJindoFSは、OSSをストレージバックエンドとして使用します。 したがって、JindoFSを使用する前に、OSSに関連するパラメーターを構成する必要があります。 EMRは、次の 2 つの構成方法を提供します。1. EMRクラスターの作成後にBigbootに関連するパラメーターを変更し、SmartDataを再起動して構成を有効にします。 2. EMRクラスターの作成時にカスタム構成を追加します。 この場合、EMRクラスターの作成後、関連サービスはカスタムパラメーターに基づいて再起動されます。

  • EMRクラスターの作成後にパラメーターを初期化する
    • oss.access.bucket は、OSSバケットの名前を指定します。
    • oss.data-dir は、OSSバケット内のJindoFSのディレクトリを指定します。 ディレクトリは、JindoFSのストレージバックエンドとしてのみ機能します。 ディレクトリに生成されたデータは破損できません。 JindoFSがデータを書き込むときに、ディレクトリは自動的に作成されます。 事前にディレクトリを作成する必要はありません。
    • oss.access.endpoint は、OSSバケットが存在するリージョンを指定します。
    • oss.access.key は、OSSバケットへのアクセスに使用するAccessKey IDを指定します。
    • oss.access.secret は、OSSバケットへのアクセスに使用するAccessKeyシークレットを指定します。

    EMRクラスターと同じリージョンにあるOSSバケットにデータを保存することをお勧めします。 これにより、高パフォーマンスと安定性が保証されます。 この場合、OSSバケットはEMRクラスターからのパスワードなしアクセスを許可するため、AccessKey IDとAccessKeyシークレットを構成する必要はありません。

    次の図に示すように、BigbootのJindoFSに関連するすべてのパラメーターを構成できます。 赤で囲まれたパラメーターは必須です。

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

    JindoFS構成を保存してデプロイします。 JindoFSを使用するには、SmartDataのすべてのコンポーネントを再起動します。

    
  • EMRクラスターの作成時にカスタム構成を追加する
    EMRクラスターの作成時にカスタム構成を追加できます。 AccessKeyペアを使用せずにOSSにアクセスするために、OSSバケットと同じリージョンにEMRクラスターを作成するとします。 次の図に示すように、[カスタムソフトウェア設定] をオンにします。 oss.data-dir と oss.data-dir を含む次の構成を「詳細設定」セクションのフィールドに追加します。

    [
        {         
        "ServiceName":"BIGBOOT",
        "FileName":"bigboot",
        "ConfigKey":"oss.data-dir",
        "ConfigValue":"jindoFS-1" // JindoFSのディレクトリを指定します
        },
        {
        "ServiceName":"BIGBOOT",
        "FileName":"bigboot",
        "ConfigKey":"oss.access.bucket",
        "ConfigValue":"oss-bucket-name" // OSSバケットの名前を指定します
        }
    ]

    

JindoFSを使用する

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

ディスク容量の使用量を制御する

JindoFSは、OSSをデータストレージバックエンドとして使用するため、大量のデータを保存できます。 ただし、ローカルディスクの容量は限られています。 JindoFSは、ローカルディスクのコールドデータを自動的に削除します。 Alibaba Cloudは、node.data-dirs.watermark.high.ratio パラメーターと node.data-dirs.watermark.low.ratio パラメーターを使用して、ローカルディスクの容量の使用量を調整します。 両方のパラメーターの値は 0 ～ 1 の範囲で、容量の使用率を示します。 JindoFSは、デフォルトですべてのデータディスクの合計ストレージ容量を使用します。 node.data-dirs.watermark.high.ratioパラメーターは、各ディスクの容量の使用量の上限を指定します。 JindoFSによって使用される容量が上限に達した場合、ディスクに保存されているアクセス頻度の低いデータは解放されます。 node.data-dirs.watermark.low.ratioパラメーターは、各ディスクの容量の使用量の下限を指定します。 ディスクの容量の使用量が上限に達した後、ディスクの容量の使用量が下限に達するまで、アクセス頻度の低いデータが解放されます。 上限と下限を構成して、JindoFSにディスク容量を調整および割り当てることができます。 上限が下限よりも大きいことを確認してください。

ストレージポリシーを構成する

JindoFSは、さまざまなストレージニーズに対応するために複数のストレージポリシーを提供します。 次の表に、ディレクトリで使用可能な 4 つのストレージポリシーを示します。

JindoFSは、ディレクトリのストレージポリシーを構成するためのコマンドラインツールAdminを提供します。 デフォルトのストレージポリシーはWARMです。 新しいファイルは、親ディレクトリに構成されているストレージポリシーに基づいて保存されます。 ストレージポリシーを構成するには、次のコマンドを実行します。

jindo dfsadmin -R -setStoragePolicy [path] [policy] // ディレクトリのストレージポリシーを設定します

ディレクトリに構成されているストレージポリシーを取得するには、次のコマンドを実行します。

jindo dfsadmin -getStoragePolicy [path] // ディレクトリのストレージポリシーを取得します

Adminツールは、コールドデータをアーカイブするためのarchiveコマンドを提供します。

このコマンドを使用すると、ローカルブロックを明示的にエビクトできます。 Hiveがテーブルを日ごとにパーティション分割するとします。 パーティション分割されたテーブルで 1 週間前に生成されたデータにアクセスされる頻度が低い場合は、定期的にそのデータが保存されているディレクトリでarchiveコマンドを実行できます。 その後、ローカルクラスターに保存されているバックアップはエビクトされますが、OSSのバックアップは保持されます。

次のarchiveコマンドを実行します。

jindo dfsadmin -archive [path] // 指定されたパスのデータをアーカイブします