win7可以做网站吗,论文明星个人网站建设,全免费源码网,江苏seo外包大家想了解更多大数据相关内容请移驾我的课堂#xff1a; 大数据相关课程 剖析及实践企业级大数据 数据架构规划设计 大厂架构师知识梳理#xff1a;剖析及实践数据建模 剖析及实践数据资产运营平台 Apache Hadoop 软件库是一个框架#xff0c;它允许使用简单的编程模型 大数据相关课程 剖析及实践企业级大数据 数据架构规划设计 大厂架构师知识梳理剖析及实践数据建模 剖析及实践数据资产运营平台 Apache Hadoop 软件库是一个框架它允许使用简单的编程模型实现跨计算机集群的大型数据集的分布式处理。它最初的设计目的是为了检测和处理应用程序层的故障从单个机器扩展到数千台机器这些机器可以是廉价的每个机器提供本地计算和存储而不是依靠硬件提供高可靠性。 Hadoop 中有3个核心组件 分布式文件系统HDFS —— 实现将文件分布式存储在很多的服务器上分布式运算编程框架MapReduce —— 实现在很多机器上分布式并行运算分布式资源调度平台YARN —— 帮用户调度大量的 MapReduce 程序并合理分配运算资源 整个源头是 Google 发的三篇论文 Hadoop 的 MapReduce/HDFS/HBase 分别对应 Google 的 MapReduce/GFS/Big Table HDFS
HDFS是 Hadoop Distributed File System 的简称是 Hadoop 抽象文件系统的一种实现。Hadoop 抽象文件系统可以与本地系统、Amazon S3 等集成甚至可以通过 Web 协议webhsfs来操作。
传统的文件系统是单机的不能横跨不同的机器HDFS 的文件分布在集群机器上例如客户端写入读取文件的直接操作都是分布在集群各个机器上的没有单点性能压力因此 HDFS 的设计本质上是为了大量的数据能横跨成百上千台机器提供高吞吐量的服务同时提供副本进行容错及高可靠性保证计算机节点很容易出现硬件故障而不管是 Google 公司的计算平台还是 Hadoop 计算平台都将硬件故障作为常态通过软件设计来保证系统的可靠性。
使用 HDFS 时用户看到的是一个文件系统而不是很多文件系统比如说要获取 /hdfs/tmp/file1 的数据引用的是一个文件路径但是实际的数据存放在很多不同的机器上作为用户不需要知道这些就好比在单机上我们不关心文件分散在什么磁道什么扇区一样HDFS 为用户管理这些数据。
设计特点
大数据文件非常适合上 T 级别的大文件或者一堆大数据文件的存储如果文件只有几个 G 甚至更小就不太适用假设 HDFS 中块的大小为 64MB备份数量为3—般情况下一条元数据记录占用 200B 的内存那么对于 1GB 的大文件将占用 1GB/64MB x 3 个文件块对于1024个 1MB 的小文件则占用 1024 x 3 个文件块可以看到存储同等大小的文件单个文件越小所需的元数据信息越大占用的内存越大因此 HDFS 适合存储超大文件文件分块存储HDFS 会将一个完整的大文件平均分块存储到不同计算器上它的意义在于读取文件时可以同时从多个主机取不同区块的文件多主机读取比单主机读取效率要高得多流式数据访问一次写入多次读写这种模式跟传统文件不同它不支持动态改变文件内容而是要求让文件一次写入就不做变化要变化也只能在文件末添加内容通过流式的数据访问保证高吞吐量数据靠拢对数据进行计算时采用将计算向数据靠拢的方式即选择最近的数据进行计算减少数据在网络中的传输延迟廉价硬件HDFS 可以应用在普通 PC 机上这种机制能够让一些公司用几十台廉价的计算机就可以撑起一个大数据集群高可靠性硬件故障处理HDFS 认为所有计算机都可能会出问题为了防止某个主机失效读取不到该主机的块文件它将同一个文件块副本分配到其它某几个主机上如果其中一台主机失效可以迅速找另一块副本取文件高可用性Hadoop 2.0 之前NameNode 只有一个存在单点问题单点故障导致整个集群不可用虽然 Hadoop1.0 有 SecondaryNameNodeCheckPointNodeBackupNode 这些来尽量满足 HA但是单点问题依然存在在 Hadoop 2.0 引入了新的 HA 机制集群中会同时运行两个 Namenode一个作为活动的 NamenodeActive一个作为备份的 NamenodeStandby备份的 Namenode 的命名空间与活动的 Namenode 是实时同步的所以当活动的 Namenode 发生故障而停止服务时备份 Namenode 可以立即切换为活动状态而不影响 HDFS 集群服务最终一致性HDFS 是一个松散的一致性检查的模型它主要是为了追加append操作而不是覆盖重写overwrite操作因为覆盖重写的话可能在一次读的操作会读到与其他副本不一致的数据而在追加操作中其中一个副本的不一致也不会导致客户端读到不一致的数据同时 HDFS 在追加操作时采用租用Lease机制即将块的写操作授权给主块服务器primary chunk server另外的副本称为次块服务器secondary chunk server当多个客户端的并发写操作时主块服务器缓存其写的顺序之后联系次服务器进行追加操作
不适用的场景
低延时的数据访问对延时要求在毫秒级别的应用不适合采用 HDFSHDFS 是为高吞吐数据传输设计的因此 HBase 更适合低延时的数据访问大量小文件文件的元数据如目录结构文件 Block 的节点列表Block-node Mapping保存在 NameNode 的内存中 整个文件系统的文件数量会受限于 NameNode 的内存大小 经验而言一个文件/目录/文件块一般占有150字节的元数据内存空间如果有100万个文件每个文件占用1个文件块则需要大约 300M 的内存因此上亿级别的文件数量在现有商用机器上难以支持多方读写HDFS 采用追加append-only的方式写入数据不支持文件任意 offset 的修改文件中的地址与内存中的地址表示不同使用偏移量 File Offset 来表示不支持多个写入器writer
架构
HDFS 主要由 3 个组件构成分别是 NameNode、SecondaryNameNode 和 DataNode。
HDFS 是以 Master/Slave 模式运行的其中NameNode 和 SecondaryNameNode 运行在 Master 节点 上而 DataNode 运行在 Slave 节点上所以 HDFS 集群一般由一个 NameNode、一个 SecondaryNameNode 和许多 DataNode 组成其架构如下图所示
在 HDFS 中文件是被分成块来进行存储的一个文件可以包含许多个块每个块存储在不同的 DataNode 中。当一个客户端请求读取一个文件时它需要先从 NameNode 中获取文件的元数据信息然后从对应的数据节点上并行地读取数据块。
下面介绍 HDFS 架构中 NameNode、SecondaryNameNode 和 DataNode 的功能
NameNode
NameNode 是主服务器负责管理文件系统的命名空间以及客户端对文件的访问。当客户端请求数据时仅仅从 NameNode 中获取文件的元数据信息具体的数据传输不经过 NameNode而是直接与具体的 DataNode 进行交互。
这里文件的元数据信息记录了文件系统中的文件名和目录名以及它们之间的层级关系同时也记录了每个文件目录的所有者及其权限甚至还记录每个文件由哪些块组成这些元数据信息记录在文件 fsimage 中当系统初次启动时NameNode 将读取 fsimage 中的信息并保存到内存中。
这些块的位置信息是由 NameNode 启动后从每个 DataNode 获取并保存在内存当中的这样既减少了 NameNode 的启动时间又减少了读取数据的查询时间提高了整个系统的效率。
元数据
按类型分
文件、目录自身的属性信息例如文件名目录名修改信息等与文件记录的信息的存储相关的信息例如存储块信息分块情况副本个数等记录 HDFS 的 Datanode 的信息用于 DataNode 的管理
按形式分
内存元数据存储于内存上元数据文件存储于磁盘上分为两类用于持久化存储 fsimage 镜像文件是元数据的一个持久化的检查点包含 Hadoop 文件系统中的所有目录和文件元数据信息但不包含文件块位置的信息文件块位置信息只存储在内存中是在 DataNode 加入集群的时候NameNode 询问 DataNode 得到的并且间断地更新edits 编辑日志存放的是 Hadoop 文件系统的所有更改操作文件创建删除或修改的日志文件系统客户端执行的更改操作首先会被记录到 edits 文件中
fsimage 和 edits 文件都是经过序列化的在 NameNode 启动的时候它会将 fsimage 文件中的内容加载到内存中之后再执行 edits 文件中的各项操作使得内存中的元数据和实际的同步存在内存中的元数据支持客户端的读操作也是最完整的元数据。
当客户端对 HDFS 中的文件进行新增或者修改操作操作记录首先被记入 edits 日志文件中当客户端操作成功后相应的元数据会更新到内存元数据中。
因为 fsimage 文件一般都很大GB 级别的很常见如果所有的更新操作都往 fsimage 文件中添加这样会导致系统运行十分缓慢。
HDFS 这种设计实现着手于一是内存中数据更新、查询快极大缩短了操作响应时间二是内存中元数据丢失风险颇高断电等因此辅佐元数据镜像文件fsimage 编辑日志文件edits的备份机制进行确保元数据的安全。
SecondaryNameNode
从字面上来看SecondaryNameNode 很容易被当作是 NameNode 的备份节点其实不然可以通过下图看 HDFS 中 SecondaryNameNode 的作用
NameNode 管理着元数据信息元数据信息会定期保存到 edits 和 fsimage 文件中其中的 edits 保存操作日志信息。
在 HDFS 运行期间新的操作日志不会立即与 fsimage 进行合并也不会存到 NameNode 的内存中而是会先写到 edits 中当 edits 文件达到一定域值或间隔一段时间后触发 SecondaryNameNode 进行工作这个时间点称为 checkpoint。
SecondaryNameNode 的角色就是定期地合并 edits 和 fsimage 文件其合并步骤如下
在进行合并之前SecondaryNameNode 会通知 NameNode 停用当前的 editlog 文件 NameNode 会将新记录写入新的 editlog.new 文件中SecondaryNameNode 从 NameNode 请求并复制 fsimage 和 edits 文件SecondaryNameNode 把 fsimage 和 edits 文件合并成新的 fsimage 文件并命名为 fsimage.ckptoNameNode 从 SecondaryNameNode 获取 fsimage.ckpt并替换掉 fsimage同时用 edits.new 文件替换旧的 edits 文件更新 checkpoint 的时间
最终 fsimage 保存的是上一个 checkpoint 的元数据信息而 edits 保存的是从上个 checkpoint 开始发生的 HDFS 元数据改变的信息。
DataNode
DataNode 是 HDFS 中的工作节点也是从服务器它负责存储数据块也负责为客户端提供数据块的读写服务同时也响应 NameNode 的相关指令如完成数据块的复制、删除等。
另外 DataNode 会定期发送”心跳“信息给 NameNode告知 NameNode 当前节点存储的文件块信息。当客户端给 NameNode 发送读写请求时NameNode 告知客户端每个数据块所在的 DataNode 信息然后客户端直接与 DataNode 进行通信减少 NameNode 的系统开销。
当 DataNode 在执行块存储操作时DataNode 还会与其他 DataNode 通信复制这些块到其他 DataNode 上实现冗余。
机制
HDFS 的分块机制
HDFS 中数据块大小默认为 64MB而一般扇区的大小为 512B一般一个磁盘块由8个扇区组成共4K感谢 timoyyu 指正HDFS 块之所以这么大是为了最小化寻址开销控制定位文件与传输文件所用的时间比例。
假设定位到 Block 所需的时间为 10ms磁盘传输速度为 100M/s如果要将定位到 Block 所用时间占传输时间的比例控制1%则 Block 大小需要约 100M。
如果块足够大从磁盘传输数据的时间会明显大于寻找块的地址的时间因此传输一个由多个块组成的大文件的时间取决于磁盘传输速率。
随着新一代磁盘驱动器传输速率的提升寻址开销会更少在更多情况下 HDFS 使用更大的块。
当然块的大小不是越大越好因为 Hadoop 中一个 map 任务一次通常只处理一个块中的数据如果块过大会导致整体任务数量过小在 MapReduce 任务中Map 或者 Reduce 任务的个数小于集群机器数量降低作业处理的速度。
HDFS 按块存储还有如下好处
文件可以任意大不会受到单个节点的磁盘容量的限制理论上讲HDFS 的存储容量是无限的Block 的拆分使得单个文件大小可以大于整个磁盘的容量构成文件的 Block 可以分布在整个集群因此单个文件可以占据集群中所有机器的磁盘简化文件子系统的设计将系统的处理对象设置为块可以简化存储管理因为块大小固定所以每个文件分成多少个块每个 DataNode 能存多少个块都很容易计算同时系统中 NameNode 只负责管理文件的元数据DataNode 只负责数据存储分工明确提高了系统的效率有利于提高系统的可用性HDFS 通过数据备份来提供数据的容错能力和高可用性而按照块的存储方式非常适合数据备份同时块以副本方式存在多个 DataNode 中有利于负载均衡当某个节点处于繁忙状态时客户端还可以从其他节点获取这个块的副本
HDFS 的副本机制
HDFS 中数据块的副本数默认为3也可以设置更多的副本数这些副本分散存储在集群中副本的分布位置直接影响 HDFS 的可靠性和性能。
一个大型的分布式文件系统都是需要跨多个机架的如上面的架构示意图中HDFS 涉及两个机架。
如果把所有副本都存放在不同的机架上可以防止机架故障从而导致数据块不可用同时在多个客户端访问文件系统时很容易实现负载均衡。
如果是写数据各个数据块需要同步到不同机架上会影响写数据的效率。
在 HDFS 默认3个副本情况下会把第一个副本放到机架的一个节点上第二副本放在同一个机架的另一个节点上第三个副本放在不同的机架上。
这种策略减少了跨机架副本的个数提高了数据块的写性能也可以保证在一个机架出现故障时仍然能正常运转。
HDFS 的读取机制
HDFS 通过 RPCRemote Procedure Call远程过程调用调用 NameNode 获取文件块的位置信息并且对每个块返回所在的 DataNode 的地址信息然后再从 DataNode 获取数据块的副本。
HDFS 读文件的过程如图所示
操作步骤如下
客户端发起文件读取的请求NameNode 将文件对应的数据块信息及每个块的位置信息包括每个块的所有副本的位置信息即每个副本所在的 DataNode 的地址信息都传送给客户端客户端收到数据块信息后直接和数据块所在的 DataNode 通信并行地读取数据块
在客户端获得 NameNode 关于每个数据块的信息后客户端会根据网络拓扑选择与它最近的 DataNode 来读取每个数据块。
当与 DataNode 通信失败时它会选取另一个较近的 DataNode同时会对出故障的 DataNode 做标记避免与它重复通信并发送 NameNode 故障节点的信息。
HDFS 的写入机制
当客户端发送写文件请求时NameNode 负责通知 DataNode 创建文件在创建之前会检查客户端是否有允许写入数据的权限。通过检测后NameNode 会向 edits 文件写入一条创建文件的操作记录。
HDFS 中写文件的过程如图所示
操作步骤如下
客户端在向 NameNode 发送写请求之前先将数据写入本地的临时文件中待临时文件块达到系统设置的块大小时开始向 NameNode 请求写文件NameNode 在此步骤中会检查集群中每个 DataNode 状态信息获取空闲的节点并在检查客户端权限后创建文件返回客户端一个数据块及其对应 DataNode 的地址列表列表中包含副本存放的地址客户端在获取 DataNode 相关信息后将临时文件中的数据块写入列表中的第一个 DataNode同时第一个 DataNode 会将数据以副本的形式传送至第二个 DataNode第二个节点也会将数据传送至第三个 DataNodeDataNode 以数据包的形式从客户端接收数据并以流水线的形式写入和备份到所有的 DataNode 中每个 DataNode 收到数据后会向前一个节点发送确认信息最终数据传输完毕第一个 DataNode 会向客户端发送确认信息当客户端收到每个 DataNode 的确认信息时表示数据块已经持久化地存储在所有 DataNode 当中接着客户端会向 NameNode 发送确认信息如果在第4步中任何一个 DataNode 失败客户端会告知 NameNode将数据备份到新的 DataNode 中
基于 HDFS 的数据库
由结构化、非结构化、半结构化数据引入
结构化数据
指具有固定格式或有限长度的数据如数据库元数据等可以通过固有键值获取相应信息且数据的格式固定如 RDBMS Data。
非结构化数据
指不定长或无固定格式的数据如邮件、Word 文档、图片、声音、视频等等。
文件中的内容是没有固定格式指的是比如一行有8个字段之间用逗号分隔而另一行有6个字段用空格分隔等。
非结构化数据这类信息我们通常无法直接知道他的内容数据库也只能将它保存在一个 BLOB 字段中对以后检索非常麻烦。一般的做法是建立一个包含三个字段的表编号 number、内容描述 varchar(1024)、内容 blob。引用通过编号检索通过内容描述。
非结构化数据又一种叫法叫全文数据。不可以通过键值获取相应信息。
半结构化数据
它是结构化的数据但是结构变化很大如 XMLHTML 等当根据需要可按结构化数据来处理也可抽取出纯文本按非结构化数据来处理。可以通过灵活的键值调整获取相应信息且数据的格式不固定如 json同一键值下存储的信息可能是数值型的可能是文本型的也可能是字典或者列表。
举一个半结构化的数据的例子比如存储员工的简历。不像员工基本信息那样一致每个员工的简历大不相同。有的员工的简历很简单比如只包括教育情况有的员工的简历却很复杂比如包括工作情况、婚姻情况、出入境情况、户口迁移情况、党籍情况、技术技能等等还有可能有一些我们没有预料的信息。
通常我们要完整的保存这些信息并不是很容易的因为我们不会希望系统中的表的结构在系统的运行期间进行变更。
HBase
HBase 是 Hadoop Database即 Hadoop 数据库是一种非关系型数据库 NoSQL它不具备关系型数据库的一些特点例如它不完全支持 SQL 的跨行事务也不要求数据之间有严格的关系同时它允许在同一列的不同行中存储不同类型的数据通常被描述成稀疏的、分布式的、持久化的由行键、列键和时间戳进行索引的多维有序映射数据库主要用来存储非结构化和半结构化的数据。因为 HBase 基于 Hadoop 的 HDFS 完成分布式存储以及 MapReduce 完成分布式并行计算所以它的一些特点与 Hadoop 相同依靠横向扩展通过不断增加性价比高的商业服务器来增加计算和存储能力。
HDFS 为 HBase 提供了高可靠性的底层存储支持Hadoop MapReduce 为 HBase 提供了高性能的计算能力Zookeeper 为 HBase 提供了稳定服务和 failover 机制Hive 为 HBase 提供了高层语言支持使得在 HBase 上进行数据统计处理变的非常简单Sqoop 为 HBase 提供了方便的 RDBMS关系型数据库数据导入功能使得传统数据库数据向 HBase 中迁移变的非常方便
此外HBase 本身可以完全不考虑 HDFS 的我们完全可以只把 HBase 当作是一个分布式高并发 K-V 存储系统只不过它底层的文件系统是通过 HDFS 来支持。换做其他的分布式文件系统也是一样不影响 HBase 的本质甚至如果不考虑文件系统的分布式或稳定性等特性完全可以用简单的本地文件系统甚至内存文件系统来代替。
为什么需要 HBase
Hadoop HDFS 无法处理高速随机写入和读取也无法在不重写文件的情况下对文件进行修改用于实现离线的文件存储。HBase 正好解决了 HDFS 的缺点因为它使用优化的方式构建上层分布式内存快速随机写入和读取用于实现实时数据存储此外随着数据呈指数增长关系数据库无法提供更好性能去处理海量的数据HBase 提供可扩展性和分区以实现高效的存储和检索。
设计特点
数据模型 松散的表 Schema列的名字、数目、长度无需定义数据类型唯一支持字节数组任何可以转换为字节数组的内容都可以作为一个值存储可以是字符串、数字、复杂对象、甚至可以是图像只要它们可以呈现为字节支持多版本 访问方式 实时写入、更新、删除支持批量、异步等方式后台导入直接生成存储格式的文件十分高效设置数据有效期到期自动删除指定主键Row的随机查询有条件为主键或列设定条件的范围查询支持协处理器事务只支持单行、同分区跨行的事务索引主键索引数据强一致性、强持久性牺牲了高可用性程序语言支持原生仅支持 JAVAC、PHP 等非 JAVA 可以通过代理Thrift访问 性能与扩展 水平扩展支持千台物理机级别的规模扩容无需等待数据迁移即扩即用大表自动分裂支持分区在线合并扩展能力依赖表分区Row 设计需要防热点存储层采用 LSM 树相比于 B-Tree读写对等写能力读能力 安全与稳定 存储层默认3副本数据可靠性高支持表快照方便冷备系统内部采用 M-S 架构Master 支持热备Master 故障影响 DDL不影响 DMLSlave 故障影响可用性部分数据区域的 DML 不可用会自动恢复支持双集群数据复制M-M 灾备支持用户认证与授权 数据导入导出 跨系统支持导入、导出 CSV 格式的数据同系统支持 distcp 直接拷贝底层存储文件快速导入使用 Sqoop在 HBase/MySQL/Oracle/Hive 等系统间相互迁移数据
较为重要的
冷热数据分离
HBase 将新数据直接写入内存中如果内存中存储的数据过多就将内存的数据写入 HDFS
热数据是指刚产生的数据先写内存大概率的情况下可以直接从内存中读取冷数据是指先产生的数据将内存中产生很久的数据写入 HDFS 中被读取的概率较小
稀疏性
通常在传统的关系性数据库中每一列的数据类型是事先定义好的会占用固定的内存空间在此情况下属性值为空NULL的列也需要占用存储空间。
而在 HBase 中的数据都是以字符串形式存储的为空的列并不占用存储空间因此 HBase 的列存储解决了数据稀疏性的问题在很大程度上节省了存储开销。所以 HBase 通常可以设计成稀疏矩阵同时这种方式比较接近实际的应用场景。
强扩展性
HBase 的扩展是横向的横向扩展是指在扩展时不需要提升服务器本身的性能只需添加服务器到现有集群即可。
HBase 表根据 Region 大小进行分区分别存在集群中不同的节点上当添加新的节点时集群就重新调整在新的节点启动 HBase 服务器动态地实现扩展。这里需要指出HBase 的扩展是热扩展即在不停止现有服务的前提下可以随时添加或者减少节点。
使用场景对比
对于经常需要修改原有的数据的场景使用 HBase 进行存储对于需要经常进行全表扫描、进行大批量的查询的场景选择 HDFS对于性能要求不高且只需要支持单条数据查询或者小批量数据进行查询的场景两者均可
架构 Client
与 Zookeeper 通信Client 与 HMaster 进行通信进行管理类操作Client 与 HRegionServer 进行数据读写类操作
Zookeeper
保证 HMaster 有一个活着HRegionServer、HMaster 地址存储监控 HRegionServer 状态将 HRegionServer 信息通知 HMaster元数据存储
HMaster
Master 节点为 HRegionServer 分配 HRegion负责 HRegionServer 的负载均衡发现失效的 HRegionServer 并重新分配其上的 HRegionHDFS 上的垃圾文件回收处理用户对表的增删改查操作
HRegionServer
Slaver 节点HBase 中最核心的模块主要负责响应用户 I/O 请求向 HDFS 文件系统中读写数据维护 HMaster 分配给它的 HRegion处理对这些 HRegion 的 I/O 请求HRegionServer 管理一系列 HRegion 对象
HRegion
一个表最开始存储的时候是一个 HRegion一个 HRegion 中会有个多个 HStore每个 HStore 用来存储一个列簇HRegion 会随着插入的数据越来越多进行拆分,默认大小是 10G 一个
HStore
HBase 存储的核心由 MemStore 和 StoreFile 组成每一个 Column Family 对应了一个 HStore用户写入数据的流程为Client 访问 ZKZK 返回 HRegionServer 地址 - Client 访问 HRegionServer 写入数据 - 数据存入 MemStore一直到 MemStore 满 - Flush 成 StoreFile
HLog
在分布式系统环境中无法避免系统出错或者宕机一旦 HRegionServer 意外退出MemStore 中的内存数据就会丢失引入 HLog 就是防止这种情况
数据存储
HBase 是面向列的存储和权限控制的它里面的每个列是单独存储的且支持基于列的独立检索。
进行数据的插入和更新时行存储会相对容易。
而进行行存储时查询操作需要读取所有的数据列存储则只需要读取相关列可以大幅降低系统 I/O 吞吐量。
数据模型
表Table
HBase 中的数据以表的形式存储。同一个表中的数据通常是相关的使用表主要是可以把某些列组织起来一起访问。表名作为 HDFS 存储路径的一部分来使用在 HDFS 中可以看到每个表名都作为独立的目录结构。
行Row
在 HBase 表里每一行代表一个数据对象每一行都以行键Row Key来进行唯一标识行键可以是任意字符串。在 HBase 内部行键是不可分割的字节数组并且行键是按照字典排序由低到高存储在表中的。在 HBase 中可以针对行键建立索引提高检索数据的速度。
列族Colunm Family
HBase 中的列族是一些列的集合列族中所有列成员有着相同的前缀列族的名字必须是可显示的字符串。列族支持动态扩展用户可以很轻松地添加一个列族或列无须预定义列的数量以及类型。所有列均以字符串形式存储用户在使用时需要自行进行数据类型转换。
列标识Column Qualifier
列族中的数据通过列标识来进行定位列标识也没有特定的数据类型以二进制字节来存储。通常以 Column FamilyColunm Qualifier 来确定列族中的某列。
单元格Cell
每一个行键、列族、列标识共同确定一个单元格单元格的内容没有特定的数据类型以二进制字节来存储。每个单元格保存着同一份数据的多个版本不同时间版本的数据按照时间先后顺序排序最新的数据排在最前面。单元格可以用 rowkey,column family:column“” qualifier,timestamp“” 元组来进行访问。/rowkey,column
时间戳Timestamp
在默认情况下每一个单元格插入数据时都会用时间戳来进行版本标识。读取单元格数据时如果时间戳没有被指定则默认返回最新的数据写入新的单元格数据时如果没有设置时间戳默认使用当前时间。每一个列族的单元数据的版本数量都被 HBase 单独维护默认情况下 HBase 保留3个版本数据。
表是 HBase 中数据的逻辑组织方式从用户视角来看HBase 表的逻辑模型如表1所示。HBase 中的一个表有若干行每行有多个列族每个列族中包含多个列而列中的值有多个版本。
表1展示的是 HBase 中的学生信息表 Student有三行记录和两个列族行键分别为0001、0002和0003两个列族分别为 Stulnfo 和 Grades每个列族中含有若干列如列族 Stulnfo 包括 Name、Age、Sex 和 Class 四列列族 Grades 包括 BigData、Computer 和 Math 三列。
在 HBase 中列不是固定的表结构在创建表时不需要预先定义列名可以在插入数据时临时创建。
从表1的逻辑模型来看HBase 表与关系型数据库中的表结构之间似乎没有太大差异只不过多了列族的概念。但实际上是有很大差别的关系型数据库中表的结构需要预先定义如列名及其数据类型和值域等内容。如果需要添加新列则需要修改表结构这会对已有的数据产生很大影响。
同时关系型数据库中的表为每个列预留了存储空间即表1中的空白 Cell 数据在关系型数据库中以“NULL”值占用存储空间。因此对稀疏数据来说关系型数据库表中就会产生很多“NULL”值消耗大量的存储空间。
在 HBase 中如表1中的空白 Cell 在物理上是不占用存储空间的即不会存储空白的键值对。因此若一个请求为获取 RowKey 为0001在 T2 时间的 Stulnfo:Class 值时其结果为空。
与面向行存储的关系型数据库不同HBase 是面向列存储的且在实际的物理存储中列族是分开存储的即表1中的学生信息表将被存储为 Stulnfo 和 Grades 两个部分。
表2展示了 Stulnfo 这个列族的实际物理存储方式列族 Grades 的存储与之类似。在表2中可以看到空白 Cell 是没有被存储下来的。
问题与优化
数据热点
问题描述
在某个时间段内大量的读写请求全部集中在某个 Region 中导致这台 RegionServer 的负载比较高其他的 Region 和 RegionServer 比较空闲那么这台 RegionServer 故障的概率就会增加整体性能降低效率比较差。
原因
数据分配不均衡如一张表只有一个 Region或一张表有多个 Region但是 Rowkey 是连续产生的。
Region有两个重要的属性StartKey 和 EndKey。表示这个 Region 维护的 RowKey 的范围当我们要读写数据时如果 RowKey 落在某个 Start-End Key 范围内那么就会定位到目标 Region 并且读写到相关的数据。
默认情况下当我们通过 HBaseAdmin 来创建一张表时刚开始的时候只有一个 RegionStart-End Key 无边界所有的 RowKey 都写入到这个 Region 里然后数据越来越多Region 的 Size 越来越大大到一定的阀值HBase 就会将 Region 一分为二成为2个 Region这个过程称为分裂Region-Split。
如果我们就这样默认建表表里不断的 Put 数据一般情况我们的 RowKey 还是顺序增大的这样存在的缺点比较明显我们总是向最大的 StartKey 所在的 Region 写数据因为我们的 RowKey 总是会比之前的大并且 HBase 的是按升序方式排序的。所以写操作总是被定位到无上界的那个 Region 中之前分裂出来的 Region 不会被写数据所以这样产生的结果是不利的。
如果在写比较频繁的场景下数据增长太快Split 的次数也会增多由于 Split 是比较耗费资源的且 Split 会使 Server 有一段时间的停顿所以我们并不希望这种事情经常发生。
解决方式
如何能做到呢Rowkey 的散列或预分区就可以办的到。预分区一开始就预建好了一部分 Region这些 Region 都维护着自己的 Start-End Key我们将 RowKey 做一些处理比如 RowKey%i写数据能均衡的命中这些预建的 Region就能解决上面的那些缺点大大提供性能。
MongoDB
MongoDB 是一种文档数据库文档是处理信息的基本单位。一个文档可以很长、很复杂可以无结构与字处理文档类似。它常用于日志的采集和存储小文件的分布式存储类似互联网微博应用的数据存储。
适用场景
网站数据非常适合实时的插入、更新与查询并具备网站实时数据存储所需的复制及高度伸缩性。缓存由于性能很高也适合作为信息基础设施的缓存层在系统重启之后由 Mongo 搭建的持久化缓存可以避免下层的数据源过载大尺寸、低价值的数据使用传统的关系数据库存储一些数据时可能会比较贵在此之前很多程序员往往会选择传统的文件进行存储高伸缩性的场景非常适合由数十或者数百台服务器组成的数据库用于对象及 JSON 数据的存储Mongo 的 BSON 数据格式非常适合文档格式化的存储及查询
不适用的场景
高度事物性的系统例如银行或会计系统传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序传统的商业智能应用针对特定问题的 BI 数据库会对产生高度优化的查询方式对于此类应用数据仓库可能是更合适的选择需要SQL的问题
MapReduce
HDFS 可以为用户整体管理不同机器上的数据任务下达时使用很多台机器处理这就面临了如何分配工作的问题如果一台机器挂了如何重新启动相应的任务、机器之间如何互相通信交换数据以完成复杂的计算等。这就是 MapReduce 的功能。MapReduce 的设计采用了很简化的计算模型只有 Map 和 Reduce 两个计算过程中间用 Shuffle 串联。使用这个模型已经可以处理大数据领域很大一部分问题了。
基本原理
将大的数据分析分成小块逐个分析最后再将提取出来的数据汇总分析最终获得我们想要的内容举例说明 考虑统计一个存储在 HDFS 上的巨大的文本文件我们想要知道这个文本里各个词的出现频率。Map阶段几百台机器同时读取这个文件的各个部分分别把各自读到的部分分别统计出词频产生类似hello, 12100次world15214次等等这样的 Pair这里把 Map 和 Combine 放在一起说以便简化这几百台机器各自都产生了如上的集合然后又有几百台机器启动 Reduce 处理。Reduce 阶段Reducer 机器 A 将从 Mapper 机器收到所有以 A 开头的统计结果机器 B 将收到 B 开头的词汇统计结果实际上不会真的以字母开头做依据而是用函数产生 Hash 值以避免数据串化。因为类似 X 开头的词比其他要少得多会导致各个机器的工作量相差悬殊。然后这些 Reducer 将再次汇总hello12100hello12311hello345881 hello370292。每个 Reducer 都如上处理就得到了整个文件的词频结果。 MapReduce 的简单模型虽然好用但是很笨重。第二代的 Tez 和 Spark 除了引入内存 Cache 之类的新 Feature本质上来说是让 Map/Reduce 模型更通用让 Map 和 Reduce 之间的界限更模糊数据交换更灵活磁盘的读写更少以便更方便地描述复杂算法取得更高的吞吐量。
框架
Hadoop 的集群主要由 NameNodeDataNodeSecondary NameNodeJobTrackerTaskTracker 组成
NameNode记录了文件是如何被拆分成 Block 以及这些 Block 都存储到了那些 DateNode 节点NameNode保存了文件系统运行的状态信息DataNode存储被拆分的BlocksSecondary NameNode帮助 NameNode 收集文件系统运行的状态信息JobTracker当有任务提交到 Hadoop 集群的时候负责 Job 的运行负责调度多个 TaskTracker ap/Reduce 模型更通用让 Map 和 Reduce 之间的界限更模糊数据交换更灵活磁盘的读写更少以便更方便地描述复杂算法取得更高的吞吐量。
框架
Hadoop 的集群主要由 NameNodeDataNodeSecondary NameNodeJobTrackerTaskTracker 组成
[外链图片转存中…(img-3o6vBcPu-1704534366287)]
NameNode记录了文件是如何被拆分成 Block 以及这些 Block 都存储到了那些 DateNode 节点NameNode保存了文件系统运行的状态信息DataNode存储被拆分的BlocksSecondary NameNode帮助 NameNode 收集文件系统运行的状态信息JobTracker当有任务提交到 Hadoop 集群的时候负责 Job 的运行负责调度多个 TaskTrackerTaskTracker负责某一个 Map 或者 Reduce 任务
