大数据实验报告总结体会_主流大数据技术总结

数据实验报告总结体会_主流⼤数据技术总结
架构师(JiaGouX)我们都是架构师!
架构未来,你来不来?
作者: justcodeit
背景
1. 数据量不断增加,企业需要灵活快速地处理这些数据。
2. 处理器主频和散热遇到瓶颈,多核处理器成为主流,并⾏化计算应⽤不断增加。
3. 开源软件的成功使得⼤数据技术得以兴起。
互联⽹技术的发展让⼤多数企业能够积累⼤量的数据,⽽企业需要灵活快速地从这些数据中提取出有价值的信息来服务⽤户或帮助企业⾃⾝决策。然⽽处理器的主频和散热遇到了瓶颈,CPU难以通过纵向优化来提升性能,所以多核这种横向扩展成为了主流。也因此,开发者需要利⽤多核甚⾄分布式架构技术来提⾼企业的⼤数据处理能⼒。这些技术随着开源软件的成功⽽在业界得到⼴泛应⽤。
下⾯我稍微介绍⼀些⼤数据应⽤中通常出现的⼀些原理或者说是特征。
基本原理分布式:将数据分布到不同的节点(机器),从⽽存储⼤量的数据。⽽分布式同时为并⾏读写和计算提供了基础,这样就能提⾼数据的处理能⼒。为什么不直接使⽤分布式的关系型数据库,⽐如主从模式的mysql?这主要是效率的问题。分布式关系型数据库为了实现分布式事务、线性⼀致性、维护⾃⾝索引结构等功能会对性能造成影响。⽽正如刚刚背景所提到,⼤数据需求重点是快速处理⼤量数据,帮助⽤户和企业的决策。这个决策就包括推荐、监控、数据分析等。这些场景并不⼀定需要数据库这种严格的约束,是OLAP⽽⾮OLTP。所以⼤数据技术会通过解除这些限制⽽提升性能。除了分布式外,还可以利⽤
批量处理:单位是上百MB的数据块⽽⾮⼀条条数据,这样在数据读写时能够整体操作,减少IO寻址的时间消耗。
最终线性⼀致性:⼤数据技术很多都放弃线性⼀致性,这主要是跨⾏/⽂档(关系型模型叫⾏,⽂档型模型叫⽂档)时⾮原⼦操作,在⼀⾏/⼀个⽂档内还是会做到原⼦的。为了读写性能⽽允许跨⾏/⽂档出现读写延迟。
增加数据冗余:规范化的数据能够减少数据量,但在使⽤时需要关联才能获得完整数据,⽽在⼤数据下进⾏多次关联的操作是⼗分耗时的。为此,⼀些⼤数据应⽤通过合并宽表减少关联来提⾼性能。
列式存储:读取数据时只读取业务所关⼼的列⽽不需要把整⾏数据都取出再做进⾏截取,⽽且列式的压缩率更⾼,因为⼀列⾥⼀般都是同类的数据。
可靠性相关
副本:⼤数据存储通常都会有副本设置,这样即便其中⼀份出现丢失,数据也能从副本到。
⾼可⽤:⼤数据应⽤通常都会考虑⾼可⽤,即某个节点挂了,会有其他的节点来继续它的⼯作。
由于这个分享会的标题起得有点⼤,包括存储、搜索、计算三⼤块,⽽且篇幅有限,所以我就只根据这三块中我了解且⽐较流⾏的开源组件来分享,⽽且只讲解⼤概的原理。毕竟下⾯的每个组件的原理和实战都可以各⾃出⼀本五六百页的书了,⽽且还没涉及源码细节的。下⾯⾸先来介绍分布式⽂件系统,就是把我们单台计算机的⽂件系统扩展到多台。HDFS(Hadoop Distributed File System)
架构原理
图中有8台机器或者容器,两个client、5个DataNode、1个NameNode。⼀个分布式⽂本系统,组成:NameNode、DataNode和secondary namenode NameNode:作为master,管理元数据,包括⽂件名、副本数、数据块存储的位置,响应client的请求,接收workers的
heartbeating和blockreport。
DataNode:管理数据(data block,存储在磁盘,包括数据本⾝和元数据)和处理master、client端的请求。定期向namenode发送它们所拥有的块的列表。
口吃矫正器
secondary namenode:备⽤master
Block:默认128MB,但⼩于⼀个block的⽂件只会占⽤相应⼤⼩的磁盘空间。设置100+MB是为了尽量减少寻址时间占整个数据读取时间的⽐例,但如果block过⼤,⼜不适合数据的分散存储或计算。将数据抽象成block,还有其他好处,⽐如分离元数据和数据的存储、存储管理(block⼤⼩固定⽅便计算)、容错等。
油水冷却器
读写流程
写⼊:client端调⽤filesystem的create⽅法,后者通过RPC调⽤NN的create⽅法,在其namespace中创建新的⽂件。NN会检查该⽂件是否存在、client的权限等。成功时返回FSDataOutputStream对象。client对该对象调⽤write⽅法,这个对象会选出合适存储数据副本的⼀组datanode,并以此请求DN分
配新的block。这组DN会建⽴⼀个管线,例如从client node到最近的DN_1,DN_1传递⾃⼰接收的数据包给DN_2。DFSOutputStream⾃⼰还有⼀个确认队列。当所有的DN确认写⼊完成后,client关闭输出流,然后告诉NN写⼊完成。
读取:client端通过DistributedFileSystem对象调⽤open⽅法,同样通过RPC调⽤远程的NN⽅法获取所要查询的⽂件所涉及的blocks所存储的DN位置,⽽且这些位置是按照距离排序的。返回的结果是⼀个FSDataInputStream对象,对输⼊流对象调⽤read⽅法。输⼊流会从距离最近的DN中读取数据,将数据传递到client,读取结束后关闭流。这个机制看上去是很笨重的,有了这个分布式⽂件系统的基础,其他组件就能利⽤这个系统提供的 API 来对数据的存储进⾏优化。在介绍下⼀个组件前,先对主要的主键索引作简单的介绍。
索引
类型
哈希SSTables/LSM树BTree/B+Tree
⼤致原理数据结构:哈希表。
内存:有序集合,例如红⿊树、平衡⼆叉树、跳跃表。
磁盘:⼀个个独⽴⽂件,⾥⾯包含⼀个个数据块。
写⼊:内存维护⼀个有序集合,数据⼤⼩达到⼀定阈值写⼊磁
盘。后台会按照特定策略合并segment。
读取:先查询内存,然后磁盘中的最新segment,然后第⼆
新,以此类推。
数据结构:平衡多叉树。写⼊:通过⼆分查到相应的
叶⼦结点进⾏修改。读取:同上。
优势适合数据经常更新写⼊快, 顺序读取快, 容易压缩读取快,更时间可控
劣势必须存储在内存;范
围查询效率低
随机读取,读取旧数据较慢写⼊较慢
agv驱动器
涉及
数据
Mysql、Redis MongoDB、Elasticsearch、HBase Mysql、MongoDB
主要的主键索引有哈希、LSM、BTree。下⾯主要涉及到LSM树,所以哈希和BTree这⾥就不多说了。LSM树有内存和磁盘两个部分....,以跳跃表为例,⼤致的模型如下图
玻璃栈道施工内存的 MemStore 是⼀个有序集合,数据写⼊会先写⼊这⾥,当⼤⼩达到阈值就会 flush 到磁盘。⽽后台会有程序按⼀定策略对这些⽂件进⾏合并。合并的原因有:减少⼩⽂件,进⽽减少读取时IO来提升读性能。数据合并,⽐如图中第⼆个file有数据a,但现在客户端发送请求要把它删掉或进⾏修改,如果每次删改都要把数据到再调整,就会有⼤量的磁盘IO,所以这些操作⼀般只做标记,等到后续⽂件合并时才真正对数据进⾏修改。还有⼀个原因是调整排序,因为flush后数据只在file内部有序,合并能够调整整体排序。正因为这种结构,所以LSM 的写⼊是很快的,范围读取也快,因为数据已经有序。⽽为了保证不读取到旧版本的数据,所以读取需要从最新的开始遍历,这也导致读取旧数据的效率较低。当然,这⾥⾯还能优化,但细节就不说了。HBase
简介
HBase 就是基于 HDFS API 构建的⼀个可以在线低延迟访问⼤数据的NoSQL数据库。本质上就是给 HDFS 加上⼀个 LSM Tree 索引,从⽽提⾼读写性能。当然,即便优化了,这个⾼性能也是相对⼤数据量⽽⾔。实际上“HBase并不快,只是当数据量很⼤的时候它慢的不明显”。由于是 NoSQL 数据库,所以它有⽂档型数据库的弱项,即基本不⽀持表关联。
特点
适合:
数据量⼤,单表⾄少超千万。对稀疏数据尤其适⽤,因为⽂档型数据库的 null 就相当于整个字段没有,是不需要占⽤空间的。
⾼并发写⼊,正如上⾯ LSM 树所说。
读取近期⼩范围数据,效率较⾼,⼤范围需要计算引擎⽀持。
数据多版本
不适合:
⼩数据
复杂数据分析,⽐如关联、聚合等,仅⽀持过滤
不⽀持全局跨⾏事务,仅⽀持单⾏事务
场景
小牛血清去蛋白注射液对象存储:新闻、⽹页、图⽚
时序数据:HBase之上有OpenTSDB模块,可以满⾜时序类场景的需求
推荐画像:特别是⽤户的画像,是⼀个⽐较⼤的稀疏矩阵,蚂蚁的风控就是构建在HBase之上
消息/订单等历史数据:在电信领域、银⾏领域,不少的订单查询底层的存储,另外不少通信、消息同步的应⽤构建在HBase之上Feeds流:典型的应⽤就是xx朋友圈类似的应⽤
更多适⽤场景可以根据HBase的特点判断
架构原理
这⾥⼤概有10台机器或节点,5个DataNode、两个RegionServer、⼀个Client、Master、ZooKeeper
Client:发送DML、DDL请求,即数据的增删改查和表定义等操作。
ZooKeeper(类似微服务中的注册中⼼)
实现Master的⾼可⽤:当active master宕机,会通过选举机制选取出新master。
管理系统元数据:⽐如正常⼯作的RegionServer列表。
辅助RS的宕处理:发现宕机,通知master处理。
分布式锁:⽅式多个client对同⼀张表进⾏表结构修改⽽产⽣冲突。
Master
处理 client 的 DDL 请求
RegionServer 数据的负载均衡、宕机恢复等
清理过期⽇志飞星晒图机
RegionServer:处理 client 和 Master 的请求,由 WAL、BlockCache 以及多个 Region 构成。
Store:⼀个Store存储⼀个列簇,即⼀组列。
MemStore和HFile:写缓存,阈值为128M,达到阈值会flush成HFile⽂件。后台有程序对这些HFile进⾏合并。
HLog(WAL):提⾼数据可靠性。写⼊数据时先按顺序写⼊HLog,然后异步刷新落盘。这样即便 MemoStore 的数据丢失,也能通过HLog恢复。⽽HBase数据的主从复制也是通过HLog回放实现的。
BlockCache
Region:数据表的⼀个分⽚,当数据表⼤⼩达到⼀定阈值后会“⽔平切分”成多个Region,通常同⼀张表的Region会分不到不同的机器上。
读写过程

本文发布于:2024-09-25 14:24:36,感谢您对本站的认可!

本文链接:https://www.17tex.com/tex/4/265805.html

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

标签:数据   读取   分布式   需要   技术
留言与评论(共有 0 条评论)
   
验证码:
Copyright ©2019-2024 Comsenz Inc.Powered by © 易纺专利技术学习网 豫ICP备2022007602号 豫公网安备41160202000603 站长QQ:729038198 关于我们 投诉建议