私は Hadoop の新しい学習者です。
Apache HDFS について読んでいるうちに、HDFS がライト ワンス ファイル システムであることを知りました。他の一部のディストリビューション (Cloudera) は追加機能を提供します。この設計上の決定の背後にある合理性を知っておくとよいでしょう。私の謙虚な意見では、この設計は Hadoop に多くの制限をもたらし、限られた一連の問題 (ログ分析に似た問題) に適しています。
専門家のコメントは、HDFS をよりよく理解するのに役立ちます。
HDFS に独自の設計がある主な理由は 3 つあります。
HDFS は、バッチ計算のみをサポートすることを目的とした Google の GFS の設計を惜しみなくコピーして設計されました。
HDFS は当初、バッチ計算以外を目的としたものではありませんでした
高パフォーマンスのバッチ操作とリアルタイムのファイル変更をサポートできる実際の分散ファイル システムを設計することは困難であり、HDFS の最初の実装者の予算と経験レベルを超えていました。
Hadoop を完全な読み取り/書き込みファイル システムとして構築できなかった固有の理由はありません。MapR FS はそれを証明しています。しかし、そのようなことを実装することは、元の Hadoop プロジェクトの範囲と機能の範囲をはるかに超えており、HDFS の元の設計におけるアーキテクチャ上の決定により、この制限を変更することは本質的に不可能です。HDFS では、ファイルの作成、削除、ファイル長の拡張などのすべてのメタデータ操作で NameNode を介したラウンドトリップが必要になるため、重要な要素は NameNode の存在です。MapR FS は NameNode を完全に排除し、クラスタ全体にメタデータを分散することでこれを回避します。
時間の経過とともに、Spark や Flink などの Hadoop 関連システムのワークロードが運用、ほぼリアルタイム、またはリアルタイムの操作に移行するにつれて、真のミュータブル ファイル システムがないことがますます煩わしくなりました。この問題への対応には、
MapR FS. 前述のように... MapR は、POSIX 機能と noSQL テーブルおよびストリーミング API を含む、完全に機能する HDFS の高性能再実装を実装しました。このシステムは、最大規模のビッグ データ システムの一部で何年にもわたってパフォーマンスを発揮しています。
クドゥ。Cloudera は基本的に、HDFS 上に実行可能なミューテーションを実装することを断念し、Kudu を発表しましたが、一般提供の予定はありません。Kudu は、完全に一般的な可変ファイルではなく、テーブルのような構造を実装しています。
Apache Nifi と商用バージョンの HDF。また、Hortonworks は HDFS をほとんどあきらめ、アプリケーションをバッチ (HDFS でサポート) とストリーミング (HDF でサポート) のサイロにフォークする戦略を発表しました。
アイシロン。EMC は、Isilon 製品ラインの一部として HDFS ワイヤ プロトコルを実装しました。これにより、Hadoop クラスターは 2 つのストレージ サイロを持つことができます。1 つは HDFS に基づく大規模で高パフォーマンスで費用対効果の高いバッチ用で、もう 1 つは Isilon を介した中規模の可変ファイル アクセス用です。
他の。HDFS のライト ワンスの性質を改善するために、多くの本質的に機能していない取り組みがあります。これらには、KFS (Kosmix File System) などが含まれます。これらのいずれも、重要な採用はありません。
この設計上の決定は制限を課しますが、HDFS は効率的なストリーミング データ アクセスを念頭に置いて構築されました。Hadoopからの引用- The Definitive Guide :
HDFS は、最も効率的なデータ処理パターンは 1 回書き込み、何度も読み取るパターンであるという考えに基づいて構築されています。通常、データセットはソースから生成またはコピーされ、その後、そのデータセットに対してさまざまな分析が行われます。各分析には、データセットのすべてではないにしても大部分が含まれるため、データセット全体を読み取る時間は、最初のレコードを読み取る際の待ち時間よりも重要です。