Hadoop 分散ファイルシステム (HDFS) の誕生

1. 試してみる

張大鵬さんはインターンシップの仕事を見つけました。仕事の初日、ビル氏は彼にログ分析というタスクを割り当てました。

張大鵬は師匠から数十メガバイトほどのログファイルを受け取りました。それを開いてみると、各行は次のようにほとんど同じように見えました。

212.86.142.33 – - [20/Mar/2017:10:21:41 +0800] “GET / HTTP/1.1″ 200 986 “http://www.baidu.com/” “Mozilla/4.0 (互換; MSIE 6.0; Windows NT 5.1; )”

Zhang Dapang は、これらのログが Web サーバーによって生成され、クライアント IP、アクセス時間、要求された URL、要求処理ステータス、リファラー、ユーザー エージェントなどの情報が含まれていることを知っています。

マスターは、1日の各ページの訪問数（PV）、独立したIPアドレスの数、ユーザーが最も検索したいキーワードの上位10個をカウントする方法を見つけるべきだと言いました。

Zhang Dapang は、これは簡単だ、Linux 上の cat、awk、その他の小さなツールを使えばできる、と考えました。ただし、もっと正式に、お気に入りの Python で、テキストの各行をフィールドに分割し、グループ化して計算するプログラムを記述してみましょう。

待ってください、今のところこのプログラムはこれらのことしかできません。柔軟性があまりなく、スケーラビリティもあまり良くありません。

セグメント化されたフィールドをデータベース テーブルに書き込みますか?

たとえば、access_log(id,ip,timestamp,url, status,referer,user_agent) のように、データベースのグループ関数とカウント関数を使用できます。 SQL は非常に強力なので、好きなように処理できます。

はい、それです！

半日後、張大鵬はプログラムを完成させ、アーキテクチャ図を描いて師匠に見せた。

マスターは一目見て、「悪くない。アイデアは非常に明確で、スケーラビリティも考慮されているので、将来的にさらに多くのニーズに対応できます」と言いました。

そこでこの小さなツールが使われるようになりました。

張大鵬は卒業後、無事に入社しました。

2. 分散型

インターネット、特にモバイルインターネットは急速に発展しました。同社のウェブサイトのユーザー数は急増し、アクセス数も増加し、ログの量も毎時数GBと驚異的な量となっている。張大鵬がインターンシップ中に「誇りに思っていた」小さなプログラムはもう使えなくなり、データベースもそれを収容できなくなってしまった。

データベースに収まらないだけでなく、分析用のスペースは言うまでもなく、Web サーバーにも収まりません。

張大鵬氏はこの問題を解決するために自ら志願した。もちろん、彼は経験豊富な主人ビルを連れてくるほど賢明でした。

二人は会議室に来て議論を始めた。

張大鵬氏はまず計算をしました。マシン 1 台、ハードディスク 1 台、読み取り速度が 75M/s の場合、100T のコンテンツを読み取るのに 10 日以上かかります。しかし、ハードドライブが 100 台ある場合、並列読み取り速度は 75G/s に達し、わずか数十分で 100T のデータを読み出すことができます。それはどれくらい速いですか？

彼はビルにこう言いました。「分散ストレージだけがこの状況を救うことができるようです。マシンをもう数台用意して、log1、log2、log3... ファイルを別のマシンに保存しましょう。」

ビル氏は、「あなたはあまりにも単純に考えすぎています。分散コンピューティングは、単にマシンを追加するだけではありません。マシンのハードディスクが故障したらどうなるでしょうか。ログ ファイルは失われるでしょうか。人気のあるファイルはどうなるでしょうか。アクセス数が非常に多い場合、それに対応するマシンの負荷は非常に高くなります。これは不公平です。」と言いました。

Zhang Dapang 氏は、「最初の問題は簡単に解決できます。バックアップを作成して、各ファイルのコピーを 3 つ保存できます。これにより、障害の可能性が大幅に減少します。おっしゃった 2 番目の問題については、ログ内の人気のあるファイルはどこにあるのでしょうか?」と述べました。

「汎用性を考慮する必要があります。将来的には、分散ファイルシステムで他の処理も処理できるようになります。」

「わかりました。ファイルを小さな断片に分割して、複数のマシンに分散します。これで完了です。バックアップするときに、各断片を 3 回バックアップするだけで問題は解決します。」

(注: 3 部のコピーが必須です)

「では、どのように使用すればよいのでしょうか。クライアントは、ファイルの最初のブロックをサーバー 1 から、2 番目のブロックをサーバー 4 から、3 番目のブロックをサーバー 2 から取得するだけでは不十分です。さらに、クライアントがこの「乱雑な」情報を保持すると非常に煩わしくなります。」ビルが提起した疑問は致命的だった。

「これは...」と Fatty Zhang は長い間考えていました。「抽象化を行う必要があるようです。分散ファイル システムは、ファイルのセグメント化をクライアントに対して透過的にするための抽象化レイヤーを提供する必要があります。クライアントは、ファイルがどのようにセグメント化されているか、またはセグメント化されたファイルがどのサーバーに保存されているかを知る必要はありません。ファイル /logs/log1 のパスを知っていれば、詳細を気にすることなく、ファイルを読み書きできます。」

「よし、理解できたようだ。抽象化を通じてクライアントにシンプルなビューを提供し、ローカル ファイルのように使用できるようにする必要がある。」ビルはすぐに昇華させました。

「しかし」張大鵬は突然、ある問題を思いつきました。「このような分散ファイルシステムは、ファイルの末尾にコンテンツを継続的に追加する場合にのみ適しているようです。特定の位置に移動してから新しいデータを書き込むなど、ランダムに読み書きしたい場合は、非常に面倒になります。」

「これについては私たちにできることは何もありません。何事にも長所と短所があります。現在のシステムは、一度書き込んで何度も読み取ることができるシナリオに適しています。」

3. メタデータ

「しかし、」ビルは続けた。「ファイルがどのブロックに分割されているか、これらのブロックがどのサーバーに配置されているか、システムがどのサーバーを持っているか、サーバーがどれだけのスペースを持っているか、これらはすべてメタデータです。これらを保存するためのサーバーを具体的に見つける必要があります。このサーバーをメタデータ ノードと呼ぶのはどうでしょうか。または、簡単に言えば、ネームノードと呼ぶことができます。それはシステム全体の執事のよ​​うなものです。」

「では、データを保存するサーバーを DataNode と呼んで区別できるようにしましょう。誰でも使用できるクライアントを作成できます。このクライアントは NameNode にクエリを実行してファイル ブロックと保存場所を特定できるため、誰でも読み書きできます。」

ビルはホワイトボードに現在のデザインを示す図を描きました。

「緑の点線はデータの読み取りと書き込みの流れを意味しますよね？でも、オレンジ色の点線は何ですか？」張大鵬は尋ねた。

「この状況について考えてみてください。データノード マシンがクラッシュすると、そのマシン上のすべてのファイル ブロックの読み取りや書き込みができなくなります。Namenode はどのようにしてこれを知ることができるのでしょうか。また、データノード マシンのディスク容量が不足している場合、管理者である Namenode もこれを知る必要があるのでしょうか。」

「ああ、Datanode と Namenode は定期的に通信する必要がある。これは面倒だ。専用の通信プロトコルを設計する必要がある!」太っちょ張は少しイライラしていました。

「分散システムとはこのようなものです。課題は数多くあります。マシンが故障したり、ネットワークがダウンしたり... 普通の安価なマシンで高い信頼性を実現するのは困難です。」

4. ファイルを読む

「読み書きのプロセスをさらに洗練させましょうか？」ビルは提案した。

「とてもシンプルだと思います。たとえば、ファイルを読み取るには、クライアントはファイル名を Namenode に伝えるだけで、Namenode がすべてのデータを返すようになります。そうですよね? この方法では、クライアントは Datanode に対して透過的なままなので、すばらしいです!」

ビルは真剣に首を横に振った。 「いいえ、すべてのデータが Namenode を通過すると、ボトルネックになります。複数のクライアントからの同時アクセスをサポートできません。TB レベル、さらには PB レベルのデータも処理する必要があることを忘れないでください。」

「はい、深く考えていませんでした！」 Zhang Dapang 氏は、古いものの方がまだ最高だとため息をつき、すぐに考えを変えました。「ファイルを読み取るときに、Namenode はファイルのブロックと、ブロックが配置されている Datanode のリストのみを返します。このようにして、クライアントはファイルを読み取る Datanode を選択できます。」

「しかし、ブロックのコピーが 3 つあるのですが、どれを選択すればよいでしょうか?」ビルは尋ねた

「一番近いものに違いない。うーん、遠いと近いをどう定義すればいいんだろう？」太っちょ張は困惑した。

「『距離』という概念を定義することはできる」とビルは言った。

クライアントとデータノードは同じマシン上にある: 距離は0で、最も近い

クライアントとデータノードは同じラック内の異なるマシンです。距離は2で、少し離れています。

クライアントとデータノードは同じデータセンター内の異なるラックに設置されています: 距離4、少し離れています

「分散システムがこんなに難しいとは思いませんでした。インターンシップ中に取り組んだプログラムよりも桁違いに難しいです！」

そうは言っても、Zhang Dapang はファイルの読み取りのフローチャートを描きました。

(注: 図は 1 つのブロックの読み取りのみを示しており、ファイルの他のブロックの読み取りは継続されます)

5. ファイルに書き込む

「ファイルの書き込みも同様です」と張大鵬は鉄は熱いうちに打つつもりだった。 「ネームノードに、データを書き込むことができる 3 つのデータノードを見つけて、それをクライアントに返します。クライアントは、これらの 3 つのデータノードへの書き込み操作を開始できます。」

「10G のファイルがあるとします。クライアントにデータノードに 3 回書き込ませて、30G のトラフィックを使用させますか?」ビルはすぐに重要な疑問を提起しました。

「他に何ができるでしょうか? 複数のバックアップを保持する必要があります!」

「解決策はあります。3 つのデータノードでパイプラインを形成できます。最初のデータノードにのみデータを送信し、このパイプラインでデータを「流す」と、最初のデータノードが 2 番目のデータノードにバックアップを送信し、2 番目のデータノードが同じバックアップを 3 番目のデータノードに送信します。」

(注: 実際のファイル書き込みはより複雑で、詳細がさらにあります。ここではパイプラインのみに焦点を当てます。)

「非常に興味深いですね。クライアントは書き込み要求を 1 回だけ送信し、データの複製は連携して動作するデータノードによって処理されます。」張太っちょは深く感銘を受けた。ビル師匠の頭脳は本当によく働きます。

「また、」ビルは言いました。「私たちの設計では、大きなハウスキーパーであるネームノードは、単一点障害のリスクがあります。バックアップノードを作成したほうがよいでしょう。」

張大鵬は強く同意した。

6. 終わり？始める？

「このシステムに名前を付けましょうか？ Distrubted File System (略して DFS) はどうでしょうか？」張大鵬は言った。

「あまりに俗っぽい。Hadoop と呼びましょう。これは私の息子のおもちゃの象の名前です。じゃあ、Hadoop 分散ファイル システム、HDFS と呼びましょう。」ビルの提案は張大鵬の予想を超えていた。

「さて、HDFS ができたので、大量のログを保存できるようになりました。これらのファイルを読み取り、さまざまなユーザー アクセスをカウントするプログラムを作成できます。」

「プログラムをどこに置くつもりですか？」

「もちろん、HDFS の外部のマシンに配置され、データは HDFS クライアントを通じてアクセスされます。」

「100TB のデータが HDFS 内の多数のマシンから読み込まれ、1 台のマシンで処理されるなんて、なんて遅いのでしょう。計算を分散し、計算プログラムをできるだけデータの近くに配置すると、より高速化できます。」

「分散コンピューティング？」

「はい、Mapreduce について聞いたことがありますか?」

張大鵬は首を振った。「これは一体何だ？」

「また次回お話しましょう！」

追記: この記事では、HDFS のいくつかの主要な設計概念を紹介します。これは非常に単純化されたケースであり、データの整合性やノード障害などの詳細は考慮されていません。

【この記事は51CTOコラムニスト「Liu Xin」によるオリジナル記事です。転載する場合は著者のWeChat公開アカウントcoderisingを通じて許可を得てください]

この著者の他の記事を読むにはここをクリックしてください