Hadoop 分散ストレージと従来の SQL ストレージの比較とストレージ操作の説明

Google は急速に増加するデータ処理に対処するための一連のアルゴリズムを開発しました。その後、誰かがこのアルゴリズムに基づいたオープンソース ソフトウェア フレームワークを開発しました。それが Hadoop です。ますます多くの組織や個々の開発者がフレームワーク開発の改善に貢献し続けるにつれて、Hadoop は製品ファミリーを形成し、最も成功した分散型ビッグデータ処理フレームワークになりました。

Hadoop が多くの組織に好まれるのは、次の 2 つの主な要因によるものです。1. 通常 10 TB を超える超大規模データ処理。 2. 統計やシミュレーションなどの非常に複雑な計算タスク。

Hadoop は、大規模統計、ETL データ マイニング、ビッグ データ インテリジェント分析、機械学習など、多くのアプリケーション シナリオで重要な役割を果たします。

[[224707]]

Hadoop と従来の SQL リレーショナル データ ストアの違いは何ですか?

Hadoop は読み取り時にスキーマを使用しますが、従来の SQL は書き込み時にスキーマを使用します。従来のデータベースでは、データを保存するときにデータをチェックし、保存 (書き込み) を許可する前にテーブル構造の定義などをチェックする必要があり、そうでない場合はエラーが報告されます。データを読み取るためのインターフェース プログラムを提供してもらえれば、Hadoop は提供されたあらゆるデータ形式を保存します。データは使用時（読み取り時）のみチェックされます。

左側は読み取り時のスキーマ、右側は書き込み時のスキーマです。右側のデータ形式が正しくない場合は、エラーが報告されます。左側はデータの読み取りルールに重点を置いています

Hadoop は分散データベースですが、ほとんどの SQL は集中的に保存されます。

たとえば、WeChat のチャット記録を保存するために、WeChat バックエンドに何千ものサーバー ノードが存在する場合があります。チャット記録が 60 個の異なるサービス ノードに分散されているとします。リレーショナル データベースの場合、複数のテーブル スペースに集中します。

チャット レコードの 1 つを検索する場合、Hadoop は検索タスクを 60 個のノードで実行される複数の負荷分散された検索タスクに分割します。従来の SQL では、すべてのストレージ スペースが走査されるまで、ストレージ スペースを 1 つずつ検索します。検索が完了しなかった場合、検索結果は返されますか? Hadoop に対する答えは「はい」ですが、従来の SQL に対する答えは「いいえ」です。

Hadoop ファミリーの製品である Hive を使用すると、SQL についてあまり知らない顧客でも、基本的に SQL と同じクエリを開発できます。

Hadoop データの書き込み、バックアップ、削除操作

1. データの書き込み

クライアントが HDFS にデータを書き込む場合、主に次の手順に分かれます。

クライアントはデータをローカルの一時ファイルにキャッシュします。

このローカル一時ファイルが HDFS のブロック サイズ制限に達すると、クライアントは Namenode にアクセスし、Namenode はファイル名を HDFS 名前空間に挿入し、対応する保存場所を割り当てます。

Namenode は割り当てられた Datanode と通信して利用可能なストレージの場所を決定し、このストレージの場所の情報をクライアントに返します。

クライアントはローカルの一時ファイルをデータノードに転送します。

ファイルの書き込みが完了し、一時ファイルが閉じられると、既存の一時データがデータノードに転送され、ネームノードにデータの書き込みが完了したことが通知されます。

Namenode はファイルを永続的な一貫性のある状態に変更し、その操作をログ EditLog に記録します。この時点で Namenode がクラッシュすると、ファイル情報が失われます。

上記のプロセスの主な特徴は、書き込まれたデータが最初にローカルにキャッシュされ、ブロック サイズの制限に達したときにデータノードと通信して送信されることです。この利点は、クライアントがデータを書き込んでいる間にネットワーク帯域幅が継続的に占有されることを回避できることです。これは、複数のユーザーによる大量のデータの書き込みを処理する上で重要です。

2. データのバックアップ

データの書き込みには、このデータ ブロックのバックアップが伴います。プロセスは次のとおりです。

クライアントの一時データがブロックに到達すると、ネームノードと通信し、データ ブロックを保存するために使用されるデータノード アドレスのセットを取得します。

クライアントはまずデータ ブロックをデータノードに送信し、データノードはそれを 4kb 単位で受信します。これらの小さな単位をキャッシュ ページ (Linux パイプ ファイルを参照) と呼びます。

データを受信した最初のデータノードは、キャッシュ ページ内のデータを自身のファイル システムに書き込み、一方で、これらのキャッシュ ページを次のデータノードに送信します。

3 のプロセスを繰り返します。2 番目のデータノードはキャッシュされたページをローカル ファイル システムに保存し、3 番目のデータノードに送信します。

HDFS のバックアップ数が 3 に設定されている場合、3 番目のデータノードにはキャッシュ ページのみを保存する必要があります。

上記のプロセスでは、データ ブロックはクライアントから最初のデータノードに流れ、次に 2 番目のデータノードに流れ、2 番目のデータノードから 3 番目のデータノードに流れます。プロセス全体は、途中で一時停止しないパイプライン プロセスです。そのため、HDFS ではこれをレプリケーション パイプラインと呼びます。

クライアントが複数のデータノードに同時にデータを書き込むというアプローチを採用してみませんか?実際、Pipelining という名前から推測できるように、クライアントと Datanode によって使用されるキャッシュ ファイルはパイプライン ファイルであり、つまり 1 回の読み取りのみをサポートします。

3. データの削除

HDFS でのデータ削除も非常に独特です。直接削除されるのではなく、復元のために一旦ごみ箱のような場所（/trash）に置かれます。

ユーザーまたはアプリケーションが削除したいファイルについては、HDFS によって名前が変更され、/trash に移動します。一定の寿命が経過すると、HDFS はそれらをファイル システムから削除し、Namenode は関連するメタデータ情報を変更します。このときのみ、データノード上の関連ディスク領域を節約できます。つまり、ユーザーがファイルの削除を要求した場合、HDFS ストレージ容量の増加はすぐには確認できません。一定の時間がかかります（現在のデフォルトは 6 時間です）。

バックアップデータを削除する必要がある場合があります。たとえば、ユーザーが必要に応じてレプリカの数を減らすと、冗長データのバックアップは次回の Beatheart 通信で削除されます。削除操作を受信したデータノードでは、削除するバックアップ ブロックが最初に /trash に配置され、一定期間後に削除されます。したがって、ディスク容量の確認には一定の遅延が発生します。

では、ファイルを即座に完全に削除するにはどうすればよいでしょうか? HDFS が提供するシェル コマンド bin/hadoop dfs expunge を使用してクリア/ゴミ箱に移動できます。