目次
第 3 章 分散ファイル システム HDFS
1. 分散ファイルシステム
分散ファイルシステム：ネットワークを介して複数のホストにファイルを分散保存することを実現するファイルシステムです。
HDFS: Google の GFS のオープンソース実装
1.1 コンピュータクラスタの基本アーキテクチャ
クラスタ内のコンピュータ ノードはラック上に配置され、各ラックには 8 ～ 64 個のノードを格納できます。同じラック上の異なるノードはネットワークを通じて相互接続され、異なるラックは別のレベルのネットワークまたはスイッチによって相互接続されます。
[ラック上に複数のサーバーがあり、ラックはネットワークを介して相互接続され、ラックはスイッチまたは LAN を介して相互接続されます]
1.2 分散ファイルシステムの構造
ストレージの考え方:
OS のファイル システムは、ディスク領域を 512B のディスク ブロックに分割し、保存するときにファイルをブロックに分割します。各ブロックはディスク ブロックの整数倍になります。分散ファイル システムでもブロックが使用され、そのブロックは非常に大きくなります [HDFS の各ブロックは 64 MB]。OS ファイル システムとは異なり、ファイルがデータ ブロックより小さい場合、ブロック全体の記憶領域を占有することはありません。
物理的構造:
分散ファイルシステムは、コンピュータクラスタのノードをネームノード[マスターノード]とデータノード[スレーブノード]に分割します。
| ノード |
関数 |
説明する |
| 名前ノード |
1. ファイルとディレクトリの作成、削除、名前変更を担当します。 2. データノードとファイルブロック間のマッピング関係を管理する |
ネームノードにアクセスすることによってのみ、クライアントはデータブロックの保存場所を見つけてそれを読み取ることができます。 |
| データノード |
1. データの保存と読み取りを担当します |
保存時: 保存場所はネームノードによって割り当てられ、クライアントは対応するデータノードにデータを直接書き込みます。 読み込み時：クライアントはネームノードからデータノードとファイルブロックのマッピング関係を取得し、対応する位置にあるファイルブロックに直接アクセスします。 |
注意事項
マルチコピー ストレージでは、ファイル ブロックが複数のコピーにコピーされて異なるノードに保存され、同じファイル ブロックのコピーが異なるラックに分散されます。
ノード障害が発生した場合、コンピューティング プロセス全体を再起動することなく、コピーをすぐに呼び出すことができます。
適用範囲
分散ファイル システムは大規模なデータ ストレージ向けに設計されており、主に大規模なファイル (TB レベル) の処理に使用されますが、小規模なファイルを処理する場合には利点がないだけでなく、システムの拡張とパフォーマンスに重大な影響を与えます。システム
2.HDFS
2.1 HDFSの特徴
アドバンテージ
安価なハードウェア デバイスとの互換性: ハードウェア障害の迅速な検出と自動回復メカニズムにより、ハードウェア エラーが発生した場合でもデータの整合性を実現できます。
ストリーミング データの読み取りと書き込みを実現します。ランダムに読み書きできないデータ シーケンスのシーケンシャル、大量、高速、継続的な到着を実現します。
大規模なデータセットをサポート: GB、TB シンプルなファイルモデルをサポート: 1 回書き込み、多数読み取り
強力なクロスプラットフォーム互換性: JVM サポート後すぐに使用できます。
制限事項
低レイテンシのデータ アクセスには適していません: 大規模なデータのバッチ処理、ストリーミング データの読み取り、高スループット、高レイテンシ。
多数の小さいファイルを効率的に保存できない: ストレージの問題: ファイルのメタデータ [情報] はネーム ノードのメモリに保存され、多数の小さいファイルはネーム ノードのスペースを増加させ、検索効率が低下します。低い。処理の問題: MapReduce は小さなファイルを処理し、大量の Map スレッドを生成するため、コストが高すぎます。
マルチユーザーによる書き込みやファイルの任意の変更はサポートされていません。ファイルには書き込みできるのは 1 人だけであり、ランダムな書き込み操作ではなく追加操作のみが可能です。
2.2 HDFSのアーキテクチャ
| 構造 |
関数 |
説明する |
特徴 |
| 名前ノード |
HDFS では、より優れたパフォーマンスを持つマシンが唯一のネーム ノードとして選択され、分散ファイル システムのネームスペースの管理を担当し、FsImage と EditLog という2 つのコア データ構造を保存します。 ネーム ノードは、ブロックが配置されているデータ ノードの位置情報を記録しますが、永続的なストレージではなく、起動するたびに FsImage をロードし、EditLog を段階的に実行します。また、新しい FsImage と新しい空の EditLog も作成します。 クライアントから送信されたファイル名に従って、ファイル データ ブロックに対応するデータ ノードの位置情報を返します。 |
FsImage は、ファイル システム ツリーと、ツリー内のすべてのファイルとディレクトリのメタデータを維持するために使用されます。 EditLog は、ファイルの作成、削除、名前変更などのすべての操作を記録します。 操作中、操作は fsImage に直接書き込まれるのではなく、EditLog に書き込まれます。 |
ネーム ノードは起動時にセーフ モードに入ります。このモードでは、外部からは読み取り操作のみが可能で、書き込み操作は実行できません。起動が完了すると、通常状態になり、外部読み取りおよび書き込み操作が提供されます。 アクセス プロセス全体を通じて、ネーム ノードはデータの送信には関与しないため、各ファイルのデータは異なるデータ ノード上で同時にアクセスできます。データがネーム ノードから流出しないようにしながら、中央サーバーの返却が減り、管理が簡素化されます。 |
| セカンドネームノード |
EditLog と FsImage のマージ操作を完了して、EditLog のサイズを削減します。 ネームノードのチェックポイントとしてメタデータ情報を保存 |
EditLog ファイルが大きすぎてネーム ノードの起動が遅くなり、セーフ モードが長時間続くことを防ぐために、2 番目のネーム ノードが使用されます。 時々、2 番目のネーム ノードはネーム ノードと通信して E と F をマージする操作を完了します。同時に、新しい F を作成して元の E を実行し、元の F を置き換えて、新しい E を作成します。マージ中の操作を記録し、元の E を置き換えます。 ネームノードに障害が発生した場合、2番目のネームノードからシステムリカバリを実行できます。 |
マージ中にネームノードに障害が発生し、回復できないメタデータが失われます。したがって、2 番目のネーム ノードは単なるチェックポイントであり、ホット バックアップにはできません。 |
| データノード |
ファイルの保存と読み取り、クライアントとネームノードのスケジューリングに従ってデータの保存と取得を担当します。 保存されたデータブロックのハートビートとリスト情報を定期的にネームノードに送信し、デッドノードにはIOリクエストが割り当てられません。 |
データ ノードのファイルはローカル Linux システムに保存されます。 |
|
| 名前空間 |
HDFS は従来の階層ファイル システムを使用し、ディレクトリとファイルの作成と削除をサポートし、ファイルの名前変更と転送をサポートします。 HDFS は、ディスク クォータ、ファイル アクセス許可、ソフト接続およびハード接続などの機能をサポートしていません。 |
HDFS 名前空間にはディレクトリ、ファイル、ブロックが含まれます 名前空間管理は、HDFS でのファイル システム ブロックの作成や変更などの基本的な操作をサポートする名前空間のみです。 |
HDFS クラスター全体には名前空間が 1 つだけあり、一意の名前ノードによって管理されます。 |
| 同意書 |
HDFS のすべての通信プロトコルは TCP/IP に基づいています。 |
HDFS アーキテクチャの制限
1. ネームスペースの制限: ネーム ノードはメモリに格納され、保持できるファイルの数はメモリのサイズによって制限されます。
2. パフォーマンスのボトルネック: ファイル システム全体のスループットは、単一のネーム ノードのスループットによって制限されます。
3. 可用性: ネームノードに障害が発生すると、クラスター全体が使用できなくなります。
4. 分離の問題: 一意の名前ノードは異なるアプリケーションを分離できない
2.3 HDFS のストレージ原理
| 方法 |
説明する |
特徴 |
| 冗長ストレージ |
HDFS は冗長ストレージに複数のコピーを使用し、データ ブロックの複数のコピーが異なるデータ ノードに分散されます。 |
1. データ転送を高速化するために、複数のクライアントが異なるコピーからファイルを同時に読み取ります。 2. データエラーとエラー検出の複数のコピーを簡単にチェックできます。 3. 強力な信頼性、データ損失を引き起こしにくい |
| データアクセス |
データ ストレージ: デフォルトで 3 つのコピー、同じラックの異なるノードに 2 つ、別のラックに 1 つ データ読み取り: HDFS は、データ ノードが配置されているラックを返す API を提供します。クライアントがデータを読み取るとき、最初に同じラック上のコピーを読み取るか、別のラックのコピーをランダムに選択します。 データ レプリケーション: パイプライン レプリケーション。 |
パイプラインのレプリケーション: クライアントが HDFS にファイルを書き込む場合、まずファイルをローカルに書き込み、次に HDFS に従ってファイルをブロックに分割します。各ブロックはネーム ノードへの書き込みリクエストを開始し、ネーム ノードはデータ ノードのリストを返します。次に、クライアントはリストのノード 1 に 4KB [仮説] データを書き込み、そのリストをノード 1 に渡し、ノード 1 はノード 2 に接続要求を送信し、4KB データとリストをノード 2 に送信する、というように続きます。ファイルの書き込みと同時にデータのコピーも完了します |
| データエラーと回復 |
ネーム ノード エラー: 方法 1: ネーム ノードのメタデータ情報を、リモートにマウントされたネットワーク ファイル システムと同期します。方法 2: 2 番目の名前ノード。 データ ノード エラー: 方法 1: ハートビートを定期的に送信します。方法 2: ノードにより、コピーの数が冗長シルバーよりも少なくなり、新しいコピーが生成されます。 データ エラー: MD5 および SHA-1 検証。ファイルを作成するときに、情報が抽出され、検証のために同じレベルの隠しファイルに書き込まれます。NameNode は定期的にチェックし、エラーのあるブロックを再複製します。 |
ハードウェアエラーがよくある ネーム ノード エラー: 方法 1 と 2 を組み合わせると、ネーム ノードがクラッシュしたときに、最初にネットワーク ファイル システムにアクセスしてバックアップ メタデータを取得し、それを回復のために 2 番目のネーム ノードに入れてから、2 番目のネーム ノードをネーム ノードとして使用します。。 データ ノード エラー: HDFS と他の分散 FS の最大の違いは、バックアップ データの場所を調整できることです。 |
第 4 章、分散データベース HBase
HBase：针对谷歌BigTable的开源实现，是一个高可靠，高性能，面向列，可伸缩的分布式数据库，主要用来存储非结构化和半结构化的松散数据。
BugTable：一个支持大规模海量数据、分布式并发数据处理效率极高、易于扩展且支持动态伸缩，适用于廉价设备，适合读操作不适合写操作的分布式存储系统
一、HBase和Hadoop
1.1 HBase与Hadoop生态的关系
| Hadoop生态 |
与HBase的功能 |
| Zookeeper |
作为协同服务，为HBase提供了稳定服务和failover【失败恢复机制】 |
| Pig和Hive |
为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单 |
| Sqoop |
为HBase提供了方便的RDBMS（关系型数据库）数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。 |
| HDFS |
为HBase提供了高可靠性的底层存储支持，提供海量数据存储能力 |
| Hadoop MapReduce |
为HBase提供了高性能的计算能力 |
1.2 Hbase和HDFS
HBase本质是一个高并发的分布式数据库，其底层文件系统可以是任何分布式文件系统，在HDFS基础上提供了随机写入功能。。
HDFS的视角看，HBase就是它的客户端。
HBase本身并不存储文件，它只规定文件格式以及文件内容，管理的是数据本身，实际文件存储由HDFS实现，管理的是记载着这些数据的文件。
HBase不提供机制保证存储数据的高可靠，数据的高可靠性由HDFS的多副本机制保证。
HBase-HDFS体系是典型的计算存储分离架构。
Hadoop 已有 HDFS 和 MapReduce，为什么需要 HBase?
HDFS面向批量访问模式，不是随机访问模式
Hadoop可以很好地解决大规模数据的离线批量处理问题，但是，受限于Hadoop MapReduce编程框架的高延迟数据处理机制，使得Hadoop无法满足大规模数据实时处理应用的需求
传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题(分库分表也不能很好解决)
传统关系数据库在数据结构变化时一般需要停机维护;空列浪费存储空间
二、 Hbase特点
2.1 HBase与传统关系数据库
| 方面 |
传统关系数据库 |
HBase |
| 数据类型 |
采用关系模型，具有丰富的数据类型和存储方式 |
采用更简单的数据模型，将所有数据【结构化/非结构化】存储为未解释的字符串，由用户编写程序解析字符串成为不同类型。 |
| 数据操作 |
提供设计多表连接的增删查改操作 |
只提供单表增删查清空等操作，无法改，只能追加 |
| 存储模式 |
基于行模式存储，元组被连续存储在磁盘页中，读取数据时顺序查扫描，然后筛选所需属性。【无论查找几个属性都会查找整行后筛选，容易浪费磁盘空间和内存带宽】 |
基于列存储，每个列族由几个文件保存，不同列族的文件是分离的。可以降低I/O开销，支持大量用户并发查询【不需要处理无关列/属性】；同一个列族的数据会被一起压缩，相似度高的数据会得到更高的压缩比。 |
| 数据索引 |
可针对不同列构建复杂的多个索引，提高访问性能 |
只有一个索引--行键，因设计巧妙 ，查询时系统不会慢下来，且在Hadoop框架下，MapReduce可以快速高效生成索引表 |
| 可伸缩性 |
横向扩展困难，纵向扩展优先 |
分布式数据库横向扩展灵活，轻易增加减少硬件实现性能伸缩 |
| 数据维护 |
更新时会替换旧值，旧值不复存在 |
更新操作生成新版本，仍保留旧版本 |
2.2 HBase数据模型
HBase实际上是一个稀疏【有些列/列族的内容为空】、多维、持久化存储的映射表。采用行键，列族，列限定符和时间戳进行索引，每个值都是未解释的字节数组byte[]。
表：HBase采用表来组织数据，表由行和列组成，列划分为若干个列族。用户在表中存储数据，每一行都有一个可排序的行键和任意多的列。
行：每个表都由若干行组成，每个行由行键来标识。
列族：一个表被分组成许多“列族” 的集合，它是基本的访问控制单元。一个列族中可以包含任意多个列，同一个列族里面的数据存储在一起。
列限定符：列族里的数据通过列限定符（或列）来定位。列支持动态扩展，可以很轻松地添加一个列，无需预先定义列的数量以及类型。
单元格：通过行、列族和列限定符确定一个“单元格”，单元格中存储的数据没有数据类型，总被视为字节数组。
时间戳：每个单元格都保存着同一份数据的多个版本，采用时间戳进行索引。
数据坐标：【行键、列族、列限定符和时间戳】
2.3 Hbase视图
概念视图来看，HBase中每个表是有许多行组成的，可通过四维坐标查找单元格的数据。
物理视图来看，在物理存储层面，采用基于列的存储方式，属于同一个列族的数据保存在一起，不同列族分别存放，与列族一起存放的还有时间戳和行键。空列不会被存储，被请求时返回null。
三、 HBase实现原理
3.1 HBase功能组件
| 功能组件 |
功能 |
特点 |
| 库函数 |
连接到每个客户端 |
|
| Master主服务器 |
Master服务器负责管理和维护HBase分区信息【一个表被分为哪些Region，每个Region被存放到哪个Region服务器上】，同时也负责维护Region服务器列表。 Master还处理模式变化，如表和列族的创建。 |
客户端并不是直接从Master获取数据，而是获取Region存储位置信息后，直接从Region读取数据。 HBase客户端并不依赖于Master而是使用ZooKeeper来获取Region位置信息，所以Master负担很小 |
| 许多的Region服务器 |
Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求 |
当表中的行增加到一定阈值时会被等分成两个Region，Master将Region分配到不同的服务器上，一个Region服务器可维护约1~1000个Region |
3.2 Region的定位
三级寻址结构：
| 层次 |
名称 |
作用 |
| 第一层 |
Zookeeper文件 |
记录了-ROOT-表的位置信息 |
| 第二层 |
-ROOT-表 |
记录了.META.表的Region位置信息 -ROOT-表只能有一个Region。通过-ROOT-表，就可以访问.META.表中的数据 |
| 第三层 |
.META.表 |
记录了用户数据表的Region位置信息，.META.表可以有多个Region，保存了HBase中所有用户数据表的Region位置信息 |
3.3 HBase运行机制
| 结构 |
功能 |
| 客户端 |
包含访问HBase的接口，并在缓存中维护着已访问过的Region位置信息，用来加快后续数据访问过程。 |
| Zookeeper服务器 |
可帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，就避免了Master的“单点失效”问题。 |
| Master服务器 |
主服务器Master主要负责表和Region的管理工作： 管理用户对表的增加、删除、修改、查询等操作 实现不同Region服务器之间的负载均衡 在Region分裂或合并后，负责重新调整Region的分布 对发生故障失效的Region服务器上的Region进行迁移 |
| Region服务器 |
HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求。 用户读写数据过程 ：用户写入数据时，被分配到相应Region服务器去执行用户数据首先被写入到MemStore和HLog中只有当操作写入HLog之后，commit()调用才会将其返回给客户端当用户读取数据时，Region服务器会首先访问MemStore缓存，如找不到，再去磁盘上面的StoreFile中寻找 缓存的刷新：系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在HLog里面写入一个标记。每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件。每个Region服务器都有一个自己的HLog 文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的HLog文件，开始为用户提供服务。 StoreFile的合并：每次刷写都生成一个新的StoreFile，数量太多，影响查找速度调用Store.compact()把多个合并成一个合并操作比较耗费资源，只有数量达到一个阈值才启动合并 |
| Store |
多个StoreFile合并成一个单个StoreFile过大时，又触发分裂操作，1个父Region被分裂成两个子Region |
| HLog |
分布式环境必须要考虑系统出错。HBase采用HLog保证系统恢复。 HBase系统为每个Region服务器配置了一个HLog文件，它是一种预写（Write Ahead Log）。用户更新数据必须首先写入日志后，才能写入MemStore缓存，并且，直到MemStore缓存内容对应的日志已经写入磁盘，该缓存内容才能被刷写到磁盘。 Zookeeper会实时监测每个Region服务器的状态，当某个Region服务器发生故障时，Zookeeper会通知Master。Master首先会处理该故障Region服务器上面遗留的HLog文件，这个遗留的HLog文件中包含了来自多个Region对象的日志记录。 |