行业网站建设多少钱,岳阳网站开发建设,教育集团网站设计策划书,月亮花园wordpress第一章
读时模式#xff08;Read-Time Schema#xff09;- 写时模式#xff08;Write-Time Schema#xff09;
通常与模式演变#xff08;Schema Evolution#xff09;相关 即在数据表结构发生变化时#xff0c;已经存在的数据如何适应新的模式#xff1f;
【读时模…第一章
读时模式Read-Time Schema- 写时模式Write-Time Schema
通常与模式演变Schema Evolution相关 即在数据表结构发生变化时已经存在的数据如何适应新的模式
【读时模式Read-Time Schema】 当在读取数据时应用模式变更的逻辑这被称为读时模式 特别是在分析型数据库如Hive中这种模式比较常见 当查询执行时如果表结构发生了变化例如有新的列添加到表中 数据库会在读取数据时动态地调整数据以匹配当前的表结构。
这可能涉及到如下处理
为新添加的列填充默认值忽略已经删除的列
读时模式下不需要对存储的数据格式做实际的更改这样可以节省大量时间减少对存储数据的影响 当读取数据时Hive 会根据表的当前模式将数据文件中的数据动态投影project为合适的结构即更加灵活化
【写时模式Write-Time Schema】 在数据被写入存储系统时立即应用模式变更。 通常涉及到格式化/重写数据以匹配新的模式。
如果向表中添加了一个新列新数据/存量数据都会包含这个新列的值实际值/默认值 写时模式通常意味着数据一旦写入就立刻按照最新的模式进行对齐 在读取时不需要任何进一步的模式适配
【个人理解】 是否对存量数据有变动 读模式没有 写模式有
RDS和数据是全对齐关系Hive和数据不是对齐关系只是强行将数据映射为Hive最新的Schema
第三章
HDFSHadoop 分布式文件系统
一般文件系统的块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 volumn1NameNode 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向编辑日志中写数据它利用STONITHshoot 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就能有效地管理数据块的位置优化存储和数据恢复过程 在实际的大数据处理场景中机架感知能显著提升系统的性能和可靠性
HDFS副本的选择
第一个副本replic放置在运行客户端的节点上如果客户端在机架外则随机选择一个节点跳过太满的节点 第二个副本放置在其他机架的某个节点 第三个副本放置在和第二个副本相同机架的随机某个节点
