大数据技能笔记

打印 上一主题 下一主题

主题 929|帖子 929|积分 2787

大数据技能概述

本章初步先容大数据范畴技能涉及的一些基础理论,如分布式、存储、网络等知识。
分布式理论

大数据意味数据量大,那么存储和盘算数据的节点就不大可能只有一个,而是接纳分而治之的思想在多个节点中存储和盘算,提高处置处罚大量数据的能力,以是大数据的组件和系同一般是分布式集群,由多个节点构成+内部的体系很容易就到达上千台节点的规模。而分布式体系有三个特性,分别是可用性、数据一致性和分区容忍性。由于三者相互接洽和管束,比如数据在多节点之间同步需要一定时间,如果在这段时间内体系依然可用,那么就使得数据允许不一致;如果希望体系时间保持数据一致,那么体系在同步这段时间内就需要停息对外使用也就是放弃可用性,以是分布式体系这三个特性只能取其二,这就是业界闻名的CAP理论。在大多数场景下,CAP理论会退化成BASE理论,即基本可用、软状态和最终一致性。基本可用是服务在功能上的降级,保持服务的对外可用,但是一部分功能不可用。软状态是指数据从一个状态到一个目标状态的时间允许存在一个“中间状态”。最终一致性是说数据同步后即使一开始在体系中不一致,但是随着时间的推移,最终会到达一个一致的状态。
存储和网络

这两者是常见的盘算机资源,大数据意味着数据量大,自然所需要的磁盘存储和网络带宽也大。在分布式体系中,数据会分散到各个集群节点中存储。为保证数据的可靠性,也就是制止某块硬盘坏了数据就丢失了的情况,数据每每会有多个副本并分散到不同节点中存储。数据也不是完整地存在一个位置,而是会分成多个block存储在不同数据节点。网络是另外一个分布式体系重要且不可或缺的资源,由于节点之间的通讯都需要经过网络。网络不可制止地成为数据运输的桥梁,网络的可靠性直接影响了分布式体系的可用性。网络的重要性在CAP理论分区容忍性中也得到体现。

盘算

数据存储到磁盘后,在产生代价之前是需要经过盘算和分析的。源数据每每不会直接产生代价,而是在举行一定的数据分析和盘算后才会有一定的代价体现。数据杂乱无章地落到磁盘,那么怎样准确地取出来呢?当然需要有一个组件是能够存储数据的明确位置的,这样当有数据读取的哀求进来,会先到元数据组件中查询完整数据在节点中的存储位置,然后客户端再去对应的节点服务器中读取,实际上这就是HDFS的做法。 我觉得在深入理解大数据各个组件之前需要对大数据体系的一些概念有初步的相识,比如大数据是怎样处置处罚海量数据的盘算和从中创造代价,关键就是分布式地数据盘算,通过数据建模、数据分析等方法对数据举行演算,最终产生数据背后的代价信息。以是,数据大多数情况下首先需要布局化存储,也就是像关系型数据库那样由包含多个字段的表存储,然后提供一些算子函数比方map,reduce举行盘算,这样数据分析职员为得到期望的数据就可以写由map、reduce等算子构成的程序去盘算。但是这样其实是比力麻烦的,由于究竟要写程序,对于没有编程基础太弱的数据分析师要求比力高,以是像Hive、Spark就提供告终构化数据分析语言也就是SQL举行查询,数据分析师只要写SQL就可以举行取数的操作。

调理体系、综合应用

大数据体系并不是只有存储和盘算的模块,真正提供用户代价的是丰富多样的数据应用。主要的数据应用有数据仓库、数据可视化体系等。数据仓库是基于某种主题聚合了历史数据,并对数据做过滤、聚合和盘算,形成的分层的数据组件。数据平台上运行着各类数据任务,任务之间的依赖和执行一般依靠调理体系。调理体系支持用户将一系列任务建立成具有依赖关系的DAG图,任务按照一定的次序在固定的时间运行。

Google三大论文

Google三大论文-GFS

整个GFS是被设计成由一个master和多个chunkserver组成的分布式文件体系。Master是一个目录服务,用于接受来自客户端的哀求查询目标文件。Chunkserver是实际存储数据的节点。Master会通过查找元数据找到目标文件的位置,包罗目标chunkserver和详细block(文件块)的位置。为了防止文件数据丢失以及提高并发读的效率,chunkserver上每个文件块数据都默认生存三个副本,不会由于一个chunkserver挂掉而数据丢失。客户端拿到了chunk地点的chunkserver信息后,客户端就可以直接去找其中的chunkserver去获取自己所要的数据了。由于master是单节点,在master由于硬件缘故原由挂掉之后数据会有丢失的风向。为了提高master的高可用性,GFS就设计了备用的几个master,数据写入master的时间举行同步复制,也就是数据也同步写入几个备用的master中。另外,为了提高master的并发能力,GFS还设计多个可读的影子master,数据写入master后也异步地写到影子master,然后影子master就能分担客户端的读哀求。从以上机制看,这个master有三种角色,分别是目录服务、同步复制的主节点和异步复制的主节点。
在办理分布式写入的网络瓶颈问题上,GFS接纳了流水线式的网络传输。客户端将写哀求发给同个机架上一个副本服务器A(可能是主副本也可能是次副本),然后再由A传输数据给离它最近的另一个副本(而不是都由客户端举行发送由于那样客户端的网络出口会成为瓶颈)。
详细的数据写入流程是这样的。客户端向Master发起一个写数据的哀求,包含数据的整个巨细。Master在收到哀求之后,根据数据的巨细以及当前各个chunserver的存储情况,将数据切分成块,然后决定将各个块及其副本存到哪一些chunserver,最终给客户端返回这些chunserver的信息。客户端接着就直接向这些chunserver发起写数据哀求了,然后chunserver通过流水线的方式复制副本。
相应的数据读取流程也是客户端先跟Master交互,也就是向Master发起数据查询,传入文件路径的参数。Master查询到该数据在哪些cunserver上之后就将这些信息返回给客户端。客户端在吸收到这些信息之后就直接向chunserver发起读取数据的哀求了。
由于GFS的元数据管理,它在处置处罚大文件读写场景时会很有上风,但是在处置处罚大量小文件的时间就存在劣势,由于文件数多,而每一个文件都需要存储元数据,以是整体会占用比力大的空间,而且查询性能也会有所下降。

Google三大论文-MapReduce
MapReduce是设计为盘算HDFS上数据的一个框架,它分成Map和Reduce两个阶段。Map是对输入数据做一个映射操作,将数据转化成key-value的情势,而Reduce是规约动作,对map阶段生成的数据做聚合的盘算,将相同key的数据合并,最终再输出结果数据。这样的盘算框架用于实现分布式grep、URL统计、word count等操作,开发过程只需要实现map和Reduce。
执行MapReduce的架构包含Master和Worker两种角色,Master负责任务的剖析和分发,Worker则负责任务的执行。在Worker节点宕机的情况下,也就是有Worker节点失效,Master会将原失效节点上的任务无论是已失败的照旧未执行的都转移到其他Worker继承执行。而对于Master堕落的情况,则是根据备份的checkpoint启动一个新的master。
每个MapReduce过程Map阶段和Reduce阶段都需要从磁盘拉取数据和将数据落到磁盘中,以是MapReduce的性能比力差。
​​​​​​​Google三大论文-BigTable

BigTable旨在打造一款高性能、弹性伸缩、方便运维的分布式数据库。以往的关系型数据比方MySql集群也可以扩展和缩小规模,以此来应对业务的扩张和紧缩。但是在MySql集群上加节点和下节点都需要人工去操作,而且涉及到数据的频仍迁移。比方原来通过对业务数据取模的方式来选择MySql节点,在增长两台之后,取模的方式有所变化,这时间原来存储的数据都需要重新举行取模盘算然后迁移到新的节点上,而且MySql不存在一个服务能够做这些事。BigTable的设计思想就是使的集群的伸缩自发地适应,比如加了几个节点后Master会根据各个Tablet的情况来切分数据、移动数据。如果是下掉一两个节点,Master也会根据当前Tablet server的负载情况迁移数据过来。整个过程运维职员只需要举行从集群加入或删减节点的操作。
那么BigTable是怎么举行数据切分与合并的呢?每一个TabletServer管理了多个Tablet,各存储一部分范围内的数据。单个Tablet中数据是有序的,每一行数据都带有一个行键,作为排序的依据。每个Tablet有最大存储容量,凌驾最大存储容量就会被切分;如果有大量数据被删除,一些小的Tablet也会被Master合并。TabletServer可以扩容,Master即可向它分配Tablet。
BigTable还有另外一个组成组件Chubby,在它的实现Hbase中对应的是Zookeeper,是一个元数据存储模块,也是负责主节点选取、主从切换的重要角色。客户端从元数据管理组件Chubby中查询到各个TabletServer的信息,然后直接向它们发起哀求举行读写了,也就是读写过程不需要经过Master。Chubby的另外一个功能是确保集群中只有一个Master。Chubby支持客户端Master去注册一个临时节点,这个临时节点和客户端的生命周期相同,可以用来监控Master的状态;另外一个Backup Master去监听这个节点,一旦丢失,它就会替补上,去注册使自己成为Master,所有的TabletServer都从这个目录的这个临时节点得知当前Master是哪台。
BigTable怎样实现改善高并发场景下的读写性能?根据论文的解读,主要有三点。第一,数据先写缓存,之后在一定条件下再溢写磁盘;缓存memtable使用跳表的数据布局,提高数据查询和插入效率。第二,在内存中设置BloomFilter,过滤掉不存在于SSTable中的行键,并使用局部性原理,使得大部分查询结果可以在缓存中找到,而无需访问磁盘。最后,定期背景合并SSTable,以淘汰读哀求需要访问的SSTable数目。


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

光之使者

金牌会员
这个人很懒什么都没写!
快速回复 返回顶部 返回列表