HaDoop学习1

第一章

读时模式（Read-Time Schema）- 写时模式（Write-Time Schema）

通常与模式演变（Schema Evolution）相关
即在数据表结构发生变化时，已经存在的数据如何适应新的模式？

【读时模式（Read-Time Schema）】
当在读取数据时应用模式变更的逻辑，这被称为读时模式
特别是在分析型数据库（如Hive）中，这种模式比较常见
当查询执行时，如果表结构发生了变化（例如，有新的列添加到表中）
数据库会在读取数据时动态地调整数据以匹配当前的表结构。

这可能涉及到如下处理：

为新添加的列填充默认值
忽略已经删除的列

读时模式下不需要对存储的数据格式做实际的更改，这样可以节省大量时间，减少对存储数据的影响
当读取数据时，Hive 会根据表的当前模式将数据文件中的数据动态投影（project）为合适的结构，即更加灵活化

【写时模式（Write-Time Schema）】
在数据被写入存储系统时立即应用模式变更。
通常涉及到格式化/重写数据以匹配新的模式。

如果向表中添加了一个新列，新数据/存量数据都会包含这个新列的值（实际值/默认值）
写时模式通常意味着数据一旦写入，就立刻按照最新的模式进行对齐
在读取时不需要任何进一步的模式适配

【个人理解】
是否对存量数据有变动？
读模式：没有
写模式：有

RDS和数据是全对齐关系，Hive和数据不是对齐关系，只是强行将数据映射为Hive最新的Schema

第三章

HDFS（Hadoop 分布式文件系统）

一般文件系统的块：1024B，对应的磁盘上一个块512B，当有文件使用600B时，需要两个磁盘块，且其他文件不能使用这两个块
HDFS的块：128MB及更大，，当有文件使用1MB时，需一个磁盘块，其他文件能使用这个块

为什么HDFS的block这么大？
最大化寻址开销，比如磁盘寻址10ms，传输速度100MB/s，为了使寻址时间占传输时间的1%，需要将块设置到100MB+
但不能过大，比如1GB，因为MapReduce的map任务一次只处理一个块的数据，如果集群有多个节点，只有一个节点在处理任务，整个耗时就会上去

HDFS中，一个文件可能有PB级别+的数据，当一个文件被保存到HDFS时，它被切分成一系列的块
每个块通常是128MB，这些块被分散存储在集群中的不同数据节点上。
它允许系统跨多个服务器以分布式方式存储大型文件，为了容错，每个块默认被复制到不同的节点（通常是三个副本）

集群有两类节点：
namenode：管理节点
datanode：工作节点

NameNode不够用时怎么办

水平扩展

NameNode的定位是保存文件系统中每个文件和每个数据块的引用关系
联邦NameNode 将组织为 NameNode volumn1，NameNode volumn12等
每个NameNode管理文件系统命名空间的一部分，它对应一个数据块，存储该文件目录下文件和数据块的引用关系

【联邦 HDFS 的主要特点】
多个独立的NameNode
在联邦 HDFS 架构中，可以运行多个独立的 NameNode，每个 NameNode 管理自己的命名空间和文件系统的元数据。
这意味着每个 NameNode 负责一个命名空间卷（Namespace Volume）

独立命名空间
每个 NameNode 都有自己的命名空间，并且不会与其他的 NameNode 命名空间重叠
这样，整个文件系统的命名空间和系统元数据的容量实际上是多个命名空间卷的汇总。

共享存储资源
尽管每个 NameNode 拥有独立的命名空间，所有的 NameNode 都共享同一套存储正文信息的 DataNode 集群
DataNode 配置为“向每个 NameNode 报告它所存储的数据块信息”。

【联邦 HDFS 的优势】
扩展性：
增加新的 NameNode 可以无缝扩展命名空间，允许更多的文件和目录的存储。

隔离性：
由于每个 NameNode 管理不同的命名空间，所以一个命名空间的故障对其他命名空间的影响更小。

性能：
运行多个 NameNode 实例可以将客户端请求的负载分散到不同的服务器上，从而提高整体的处理能力。

维护灵活性：
部分命名空间可以独立升级或进行维护，而不会影响到整个 HDFS。

联邦 HDFS 允许大型企业和组织以更加灵活和可伸缩的方式管理大规模数据集
这种架构设计通过引入多个 NameNode 实例来满足不断扩张的存储需求，并解决了多租户环境下的数据存储挑战。

【为什么不能纵向扩展】
HDFS的NameNode虽然是设计为可以纵向扩展（或称为垂直扩展）的组件，但却存在一定的限制和瓶颈

内存限制：
NameNode将整个文件系统的元数据（如目录结构、文件属性和文件数据块的位置信息）保存在内存中
以便快速访问
随着集群大小的增长，所需处理的元数据数量也会增加，这最终会超出单个机器可以处理的内存容量
受限于单个服务器内存的物理上限

单点故障风险：
尽管可以通过增加更多的CPU、内存和网络资源来提升单个NameNode的处理能力，但这并不能避免单点故障的问题
如果该NameNode出现故障，整个HDFS将不可用，造成数据无法访问

处理能力瓶颈：
随着集群规模的扩大，单个NameNode需要处理的客户端请求也会增多，这可能导致CPU和网络I/O资源的瓶颈
因而单纯增加内存无法解决所有性能问题

成本效率问题：
纵向扩展通常涉及购买昂贵的高端服务器硬件
随着机器规模的增加，成本将大幅上升，且每次投资所带来的性能提升效果边际递减

HDFS的高可用性方案并不只依赖于NameNode的纵向扩展，而是采用了横向扩展（或称为水平扩展）的策略
引入多个NameNode实例，使用Active/Standby的架构来提高可靠性
通过分布式文件存储和并行计算弹性应对大规模数据处理的需求
这样不仅能解决单点故障问题，还能通过增加更多服务器来提高处理能力和存储容量

NameNode存储元信息的高可用

高可用性架构（High Availability, HA）允许客户端即使在元数据服务器（即NameNode）失效时也能不间断访问文件系统
这是通过运行多个NameNode实例来实现
即使一个NameNode宕机，其他的NameNode实例也可以接管其职责，维持HDFS的持续运行

在高可用性配置中，通常有两个NameNode：
一个是活动的（Active NameNode），另一个是待命的（Standby NameNode）

【共享存储】
Active和Standby NameNodes共享存储设施，以存放文件系统的命名空间和块信息
这通常通过网络文件系统（如NFS）或使用特定的分布式文件系统（如QJM，即Quorum Journal Manager）来实现
共享存储包含对命名空间改动的所有信息，允许Standby NameNode始终拥有最新的状态信息

Quorum Journal Manager (QJM) 群体日志管理
QJM是一种特殊的共享存储，它使用多个（3/5/7）对等的JournalNode来保持NameNode状态的更新
（如果一个故障，并不会影响整个集群，它不使用ZK）
Active NameNode将所有的元数据变化同步写到多个JournalNode上形成的集群
由于使用了对等的存储节点，这可以保证元数据信息不会因单点故障而丢失

【服务端的自动故障转移】
ZooKeeper用于监控Active NameNode的状态
每个NameNode运行一个轻量级的故障转移控制器（failover controller）实体，通过心跳监视宿主NameNode是否失效
当Active NameNode出现问题时，ZooKeeper可以自动触发故障转移过程，将Standby NameNode提升为新的Active状态

网络很慢时导致的故障转移
旧NameNode处理C端的过时请求，新NameNode处理C端的新请求
QJM通过同一时间仅允许一个NameNode向编辑日志中写数据+SSH规避（fencing）命令杀死NameNode
NFS无法做到同一时间仅允许一个NameNode向编辑日志中写数据，它利用STONITH（shoot the other node in the head）一枪爆头来实现（特供断电单元，对主机断电）

【服务端的手动故障转移】
graceful failover
用于演练，让主备有序切换

【客户端的自动故障转移】
客户端配置文件，HDFS URI 使用一个逻辑主机名->一对NameNode地址，客户端类访问每一个地址直到处理完成

【数据节点】
HDFS中的数据节点（DataNode）同时与Active和Standly NameNodes通信
它们会向两个NameNode发送心跳和块报告
一旦故障转移发生，DataNodes会快速识别新的Active NameNode

整个配置旨在确保元数据的一致性和服务的连续性，避免因为NameNode故障导致整个HDFS服务的中断

写数据时的机架

“机架”（Rack）是指将存储数据的物理服务器（通常称为DataNode）在数据中心中组织的一种方式。

在大型分布式系统中，数据中心内服务器通常按照机架进行排列，一个机架包含了多个服务器。

从网络的角度看，一个机架中的服务器共享相同的网络交换机，这意味着它们之间的网络带宽和延迟都是一致的。

在HDFS中，理解数据节点的机架位置对于实现数据的高可用性以及优化数据存储和检索的性能非常重要。

【HDFS会根据机架信息在写入数据的时候自动实现以下目标】
机架感知的数据副本放置策略（Rack-aware Replica Placement Policy）
当一个文件被写入到HDFS时，它会被分割成多个数据块（Block）
为了确保可靠性而在不同的DataNode上存储多个副本
HDFS尝试将至少一个副本放置在不同的机架上
这样即使一个机架完全失效，数据依然可以从其他机架上的副本进行恢复

网络带宽优化
通过在不同的机架之间分散存储数据，HDFS能够优化网络带宽的使用
在跨机架通信时，相比机架内通信会消耗更多的带宽和有更高的延迟
因此在大部分情况下访问本地机架上的数据比访问远程机架的数据更优

故障隔离
将副本放置在不同的机架上可以提高系统对机架故障的韧性
如果一个机架的电源或网络连接失败，尚存放在其他机架上的副本可以继续确保数据的可用性

机架信息通常是通过配置文件或者通过脚本来提供给HDFS的
使得NameNode能够意识到每个DataNode的物理位置
管理员可以使用名为“机架感知”（Rack Awareness）的特性来配置HDFS
这样NameNode就能有效地管理数据块的位置，优化存储和数据恢复过程
在实际的大数据处理场景中，机架感知能显著提升系统的性能和可靠性