ビッグデータソリューションに基づく高速データレシピ

^{画像ソース}



ビッグデータを扱う作業を議論するとき、分析の問題とコンピューティングのプロセスを整理する問題に最も頻繁に対処します。 同僚と私は、データへのアクセスを加速し、ストレージシステムの負荷を分散するという、異なる種類のタスクに取り組む機会がありました。 以下では、これにどう対処したかについて説明します。



私たちは既存の「材料」から鉄の切れ端とソフトウェアツールを使って「レシピ」を作りました。 最初に、アクセスを高速化するという課題にどのように直面したかを説明します。 次に、鉄片とソフトウェアツールについて検討します。 結論として、作業中に直面しなければならない2つの問題について話しましょう。



問題の説明から始めましょう。

最適化する必要があった環境では、水平方向にスケーラブルなネットワークストレージを使用してデータを保存します。 あなたがこれらの言葉に精通していない場合、心配しないでください、私は今すべてを説明します:)



水平方向にスケーラブルなデータストレージシステム（英語-スケールアウトNAS）は、高速内部ネットワークで相互接続された多くのノードで構成されるクラスターシステムです。 インターネットなどの外部ネットワークを介して、ユーザーはすべてのノードを個別に使用できます。







この図は、3つのノードのみを示しています。 実際、さらに多くの可能性があります。 これがスケールアウトシステムの美しさです。 追加のディスク容量またはパフォーマンスが必要になったらすぐに、新しいノードをクラスターに追加するだけです。



上記のように、各クラスターノードは個別に利用できます。 各ノードで、個別のネットワーク接続（または複数のネットワーク接続）を確立できることが理解されています。 ただし、ユーザーがどのノードを介してクラスターに接続しても、単一のファイルシステムが表示されます。



スケールアウトデータセンターでは、ストレージは次のようになります（クラスターノードはスタイリッシュなラックに積み重ねられます）。











私たちの場合、写真に示したシステムだけがデータストレージに使用されました。EMCのIsilonです。 ほぼ無制限のスケーラビリティのために選択されました。1つのクラスターは最大30ペタバイトのディスク容量を提供できます。 そして、外部からはすべてのスペースが単一のファイルシステムとして利用可能になります。



解決しなければならなかった問題は、Isilonを使用する特定のモデルに関連しています。 最適化された環境では、データはデータ管理システムを介してアクセスされます。 ここでは詳細を説明しません。 これは別の大きなトピックです。 このアプローチの結果についてのみ説明します。 さらに、将来にとって最も重要なことだけに集中するために、全体像を大幅に簡素化します。



私たちの環境でのデータアクセスの簡略図は次のとおりです。







多くのクライアントは、専用サーバーで実行されるデータ管理システムにアクセスします。 お客様は、Isilonから直接データを書き込んだり読み取ったりすることはありません。 これは、データの何らかの操作（暗号化など）を潜在的に実行できる制御システムを介してのみ行われます。



図では、制御システムサーバーはデータストレージシステム（SHD）の1つのノードとのみ通信します。 そして、これは私たちが本当に持っていたものです。 多数のクライアントリクエストのストリームが1つのストレージノードに送られました。 他のノードに他のサーバーまたはクライアントがロードされていない場合、クラスターの負荷は非常に不均衡になる可能性があります。



一般に、Isilonは優れた自動負荷分散機能を提供します。 たとえば、一部のサーバーがIsilonとの接続を確立しようとすると、現時点で負荷が最小のノードによってサービスが提供されます。 もちろん、このようなバランスを可能にするためには、Isilonを適切に構成して使用する必要があります。



ただし、ストレージシステムの自動負荷分散は、ネットワーク接続のレベルでのみ可能です。 たとえば、クラスターのノードに大量の「食いしん坊」化合物が蓄積した場合、ストレージシステムはより多くの空きノードに沿ってそれらを「散布」することができます。 しかし、唯一のロードされた接続の場合、ストレージシステムは無力です。



ここで、アンロードする必要があった唯一の高負荷接続を構成するものについて少し説明します。 これは単なるNFSマウントです。 NFSに慣れていない場合は、ネタバレをご覧ください。



問題が明確になったので、それをどのように解決したかについて話します。



すでに述べたように、ビッグデータを処理するために設計されたハードウェアとソフトウェアソリューションが役に立ちました。 鉄片は同じアイシロンです。 また、2年以上前に興味深いプロパティが1つ追加されたことは非常に幸運でした。 それなしでは、負荷分散の処理ははるかに困難になります。 問題のプロパティは、HDFSプロトコルのサポートです。 レシピの2番目の成分は、それに基づいています。



この略語と問題の技術的な側面に慣れていない場合は、ウェルカムのネタバレがあります。



当初、IsilonではHDFSインターフェイスがサポートされていなかったため、同僚と私はそれを使用してストレージの負荷を分散できました。 HDFSがIsilonに実装されている理由に興味がある場合は、次のネタバレに進んでください。



次に、HDFSがIsilonの負荷分散にどのように役立つかを見てみましょう。 上でスポイラーで調べた、HDFSでのファイルの記録の例に戻りましょう。 Isilonの場合はどうなりますか？



ファイルに別のブロックを追加するには、クライアントはディレクトリに移動して、このブロックが受信するデータノードのアドレスを見つける必要があります。 Isilonでは、クラスター内の任意のノードにディレクトリとしてアクセスできます。 これは、ノードアドレスを介して直接行われるか、接続の分散を処理する特別なサービスを介して行われます。 ディレクトリを返すアドレスは、現時点で最も負荷の少ないノードに対応しています。 ブロックをHDFSに送信すると、常に最も空きのあるノードにブロックを転送することがわかります。 つまり NFSの場合のように、マウントではなく個別の基本操作のレベルで、非常にきめ細かくバランスが自動的に調整されます。



これに気づき、HDFSをスタンドアロンインターフェイスとして使用することにしました。 ここでの「スタンドアロン」とは、インターフェイスがHadoopから分離して使用されることを意味します。 おそらくこれはこの種の最初の例です。 少なくとも、これまでのところ、HDFSをKhadupovまたはokolokhadupovskihファミリーとは別に使用すべきだとは聞いていません。



その結果、HDFSをデータ管理システムに「固定」しました。 同時に解決しなければならなかった問題のほとんどは、管理システム自体の側にありました。 ここではそれらについては説明しません。 これは別の大きなトピックであり、特定のシステムの詳細に加えて結び付けられています。 しかし、スタンドアロンファイルシステムとしてのHDFSの使用に関連する2つの小さな問題についてお話します。



最初の問題は、HDFSが別の製品に割り当てられていないことです。 Hadoopの一部として配布されます。 したがって、「HDFS標準」または「HDFS仕様」はありません。 本質的に、HDFSはApacheのリファレンス実装として存在します。 そのため、実装の詳細（たとえば、リースをキャプチャおよびリリースするためのポリシー）を知りたい場合は、ソースコードを読むか、すでにこれを行った人を探してリバースエンジニアリングを行う必要があります。



2番目の問題は、HDFSの低レベルライブラリを見つけることです。



ネットワーク上で表面的な検索を行った後、そのようなライブラリが多数あるように見える場合があります。 ただし、実際にはApacheリファレンスJavaライブラリが1つあります。 C ++、C、Python、およびその他の言語用のその他のほとんどのライブラリは、Javaライブラリの単なるラッパーです。



C ++プロジェクトのJavaライブラリを取得できませんでした。 適切なラッパーがあっても。 まず、データ管理システムを小さなHDFSモジュールと一緒にサーバーにドラッグすることは、受け入れがたい贅沢なJavaマシンでした。 第二に、インターネットでは、Javaライブラリーのパフォーマンスについて不満があります。



HDFS用の既製のC ++ライブラリが見つからない場合は、独自のライブラリを作成する必要があります。 そして、これはリバースエンジニアリングの追加時間です。 幸いなことに、ライブラリが見つかりました。



昨年（そしておそらくそれ以前）、HDFSの最初のネイティブライブラリが登場し始めました。 現時点では、CとPythonの2つを知っています。 ハドオフスとスネークバイト 。 おそらく他の何かが現れた。 私は長い間検索を繰り返していません。



このプロジェクトでは、Hadoofusを使用しました。 使用中ずっと、2つのエラーのみが見つかりました。 最初の-シンプル-は、ライブラリがC ++コンパイラによって構築されていないという事実につながりました。 2つ目はより不愉快です。マルチスレッドを使用したデッドロックです。 非常にまれにしか現れなかったため、問題の分析が複雑になりました。 両方のエラーは現在解決されています。 まだデッドロックの欠如の完全なテストに取り組んでいますが。



HDFSの使用に関連する他の問題を解決する必要はありませんでした。



一般に、Isilon用のHDFSクライアントの作成は、「標準」HDFS用のクライアントの作成よりも簡単であることに注意してください。 間違いなく、「標準」のHDFSクライアントは問題なくIsilonで動作します。 その逆は真実である必要はありません。 Isilon専用にHDFSクライアントを記述する場合、タスクは単純化されます。



例を考えてみましょう。 HDFSでデータブロックを読み取る必要があるとしましょう。 これを行うために、クライアントはディレクトリに戻り、このブロックを取得できるデータノードを尋ねます。 一般に、このような要求に応じて、カタログは1つのノードではなく、このブロックのコピーが保存されている複数のノードの座標を返します。 クライアントがリストの最初のノードから応答を受信できない場合（たとえば、このノードが落ちた場合）、応答するノードが見つかるまで、2番目、3番目などになります。



Isilonの場合、このようなシナリオについて考える必要はありません。 Isilonは常に単一ノードのアドレスを返します。これは確かに役立ちます。 これは、Isilonノードが「落下」できないという意味ではありません。 最後に、少なくともxでノードを無効にすることができます。 ただし、何らかの理由でIsilonがノードを失った場合、そのアドレスをクラスター内の別の（生き残っている）ノードに渡すだけです。 そのため、フォールトトレランスのシナリオは既にハードウェアに既に組み込まれており、ソフトウェアに完全に実装する必要はありません。



これで、私たちの「レシピ」についての物語は完全であると考えることができます。 結果についていくつかの単語を追加するだけです。



私たちの環境では、NFSを使用した場合と比較して、生産性の償却後の利益は約25％です。 この数字は、「自分自身」を比較することによって得られたものです。どちらの場合も、同じ機器と同じソフトウェアでパフォーマンスを測定しました。 異なるのは、ファイルシステムにアクセスするためのモジュールのみでした。



読み取り操作のみを考慮すると、個々のファイルをダウンロードするときに25％の増加も見られます。 データ記録の場合、償却されたゲインについてのみ話すことができます。 すべての単一ファイルの書き込みは、NFSを使用した場合よりも遅くなります。 これには2つの理由があります。

• HDFSはマルチスレッドファイルの記録をサポートしていません
• データ管理システムには、上記のHDFSの制限により、単一ファイルの迅速な記録を許可しない機能があります。

ファイルの記録がデータ管理システムでより最適に編成されている場合、別の転送で記録の25％の増加が期待できます。



特定の各ファイルのアップロードを遅くしても、それほど動揺しませんでした。 ピーク負荷でのスループットは私たちにとって最も重要です。 さらに、私たちと同様の環境では、データの読み取りは書き込みよりもはるかに頻繁に行われます。



結論として、HDFSをインターフェイスとして使用した場合のIsilonの負荷の変化を説明する図を示します。



スクリーンショットは、両側で2GBファイルを転送するときのクラスター負荷を示しています（ファイルは14回連続でダウンロードおよびダウンロードされました）。 NFSを使用している場合、左側の青い高いピークが得られます。 読み取りと書き込みは単一のマウントを介して行われ、この場合の負荷全体は1つのクラスターノードが負担します。 右側のマルチカラーの低いピークは、HDFSを介した作業に対応しています。 これで、クラスター内のすべてのノード（3個）に負荷が「分散」されていることがわかります。











おそらくそれだけです。



すべてが常に高速かつ確実に動作するようにします！