当前位置：首页 > news >正文

大数据技术笔记

news 来源：原创 2025/5/30 15:25:16

大数据技术概述

本章初步介绍大数据领域技术涉及的一些基础理论，如分布式、存储、网络等知识。

分布式理论

大数据意味数据量大，那么存储和计算数据的节点就不大可能只有一个，而是采用分而治之的思想在多个节点中存储和计算，提高处理大量数据的能力，所以大数据的组件和系统一般是分布式集群，由多个节点构成+内部的系统很容易就达到上千台节点的规模。而分布式系统有三个特性，分别是可用性、数据一致性和分区容忍性。由于三者相互联系和牵制，比如数据在多节点之间同步需要一定时间，如果在这段时间内系统依然可用，那么就使得数据允许不一致；如果希望系统时刻保持数据一致，那么系统在同步这段时间内就需要暂停对外使用也就是放弃可用性，所以分布式系统这三个特性只能取其二，这就是业界著名的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数量。