大数据存储技术docx要点.docx

大数据存储技术docx要点.docx

《大数据存储技术docx要点.docx》由会员分享，可在线阅读，更多相关《大数据存储技术docx要点.docx（24页珍藏版）》请在冰豆网上搜索。

大数据存储技术docx要点

大数据存储技术

刘雷1，杜鹏程2，贺俊铭3，孔庆春4，张莉莉5

1,2,3,4,5（清华大学计算机科学与技术系,北京100084）

Abstract：

Bigdataanalysiscomparedwiththetraditionaldatawarehouseapplications,withalargeamountofdataandcomplexqueryanalysis,etc.Bigdatastoragebecauseofitsitselfexists4vcharacteristics,thetraditionalstoragetechnologycannotmeettheneedsoflargedatastorage,dataresourcesthroughtheETLtechnologywasextractedfromthesourcesystem,andisconvertedintoastandardformat,thenusingNoSQLdatabasefordatabaseaccessmanagement,makefulluseofthenetworkcloudstoragetechnologyenterprisestoragecostsaving,efficiencyadvantage,throughadistributednetworkfilesystemtostoredatainformationintheInternetnetworkresources,usingvisualoperatinginterfacetosatisfytheuser'sdataprocessingrequirementsatanytime.

Keywords:

Dataacquisition（ETL）,dataaccess（NoSQL）,cloudstorage,distributedfilesystems,visualization

摘要:

大数据分析相比于传统的数据仓库应用，具有数据量大、查询分析复杂等特点。

大数据存储由于其本身存在的4V特征，传统的存储技术不能满足大数据存储的需要，通过ETL技术数据资源被从源系统中提取，并被转换为一个标准的格式，再使用NoSQL数据库进行数据库存取管理，充分利用网络云存储技术节约企业存储成本，提高效率的优势，通过分布式网络文件系统将数据信息存储在整个互联网络资源中，并用可视化的操作界面随时满足用户的数据处理需求。

关键词:

数据采集（ETL）、数据存取（NoSQL）、云存储、分布式文件系统、可视化

1引言

在学术界，Nature早在2008年就推出了BigData专刊[1]。

计算社区联盟（ComputingCommunityConsortium）在2008年发表了报告《Big9DataComputing:

Creatingrevolutionarybreakthroughsincommerce,science,andsociety》[2]，阐述了在数据驱动的研究背景下，解决大数据问题所需的技术以及面临的一些挑战。

Science在2011年2月推出专刊《DealingwithData》[3]，主要围绕着科学研究中大数据的问题展开讨论，说明大数据对于科学研究的重要性。

美国一些知名的数据管理领域的专家学者则从专业的研究角度出发，联合发布了一份白皮书《ChallengesandOpportunitieswithBigData》[4]。

该白皮书从学术的角度出发，介绍了大数据的产生，分析了大数据的处理流程，并提出大数据所面临的若干挑战。

业界通常用Volume、Variety、Value和Velocity（简称为“4V”，即数据体量巨大、数据类型繁多、价值密度低和处理速度快）四个特征来显著区分大数据与传统数据。

大数据技术是一个整体，没有统一的解决方案，本文从大数据生命周期过程的角度讨论了ETL技术、NoSQL、云存储、分布式系统、数据可视化等5个部分。

2ETL技术

随着信息化进程的推进，人们对数据资源整合的需求越来越明显。

但面对分散在不同地区、种类繁多的异构数据库进行数据整合并非易事，要解决冗余、歧义等脏数据的清洗问题，仅靠手工进行不但费时费力，质量也难以保证；另外，数据的定期更新也存在困难。

如何实现业务系统数据整合，是摆在大数据面前的难题。

ETL数据转换系统为数据整合提供了可靠的解决方案。

ETL是Extraction-Transformation-Loading的缩写，中文名称为数据提取、转换和加载。

ETL负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。

它可以批量完成数据抽取、清洗、转换、装载等任务，不但满足了人们对种类繁多的异构数据库进行整合的需求，同时可以通过增量方式进行数据的后期更新。

ETL体系结构体现了主流ETL产品的主要组成部分[5]，其体系结构如图1：

图1ETL体系结构

ETL过程中的主要环节就是数据抽取、数据转换和加工、数据装载[6]。

为了实现这些功能，各个ETL工具一般会进行一些功能上的扩充，例如工作流、调度引擎、规则引擎、脚本支持、统计信息等。

2.1数据抽取

数据抽取是从数据源中抽取数据的过程[7]。

实际应用中，不管数据源采用的是传统关系数据库还是新兴的NoSQL数据库，数据抽取一般有以下几种方式：

2.1.1全量抽取

全量抽取指的是ETL在集成端进行数据的初始化时，首先由业务人员或相关的操作人员定义抽取策略，选定抽取字段和定义规则后，由设计人员进行程序设计；将数据进行处理后，直接读取整个工作表中的数据作为抽取的内容，类似于数据迁移，是ETL过程中最简单的步骤，其简单性主要适用于处理一些对用户非常重要的数据表。

2.1.2增量抽取

增量抽取主要发生在全量抽取之后。

全量抽取之后，对上次抽取过的数据源表中新增的或被修改的数据进行抽取，称之为增量抽取。

增量抽取可以减少对抽取过程中的数据量，提高抽取速度和效率，减少网络流量，同时，增量抽取的实现，对异构数据源和数据库中数据的变化有个准确的把握。

信息抽取不是仅仅从大量的文献集或数据集中找出适合用户需要的那篇文献或部分内容，而是抽取出真正适合用户需要的相关信息片段，提供给用户，并找出这些信息与原文献直接的参考对照。

2.2数据转换和加工

从数据源中抽取的数据不一定完全满足目的库的要求，例如数据格式的不一致、数据输入错误、数据不完整等等，还要对抽取出的数据进行数据转换和加工。

数据转换是真正将源数据库中的数据转换为目标数据的关键步骤，在这个过程中通过对数据的合并汇总过滤以及重新格式化和再计算等，从而将操作型数据库中的异构数据转换成用户所需要的形式[8]。

数据的转换和加工可以在ETL引擎中进行，也可以在数据抽取过程中利用数据库的特性同时进行。

（1）ETL引擎中的数据转换和加工[9]

ETL引擎中一般以组件化的方式实现数据转换。

常用的数据转换组件有字段映射、数据过滤、数据清洗、数据替换、数据计算、数据验证、数据加解密、数据合并、数据拆分等。

这些组件如同一条流水线上的一道道工序，它们是可插拔的，且可以任意组装，各组件之间通过数据总线共享数据。

有些ETL工具还提供了脚本支持，使得用户可以以一种编程的方式定制数据的转换和加工行为。

（2）在数据库中进行数据加工

关系数据库本身已经提供了强大的SQL、函数来支持数据的加工，如在SQL查询语句中添加where条件进行过滤，查询中重命名字段名与目的表进行映射，substr函数，case条件判断等等。

相比在ETL引擎中进行数据转换和加工，直接在SQL语句中进行转换和加工更加简单清晰，性能更高。

对于SQL语句无法处理的可以交由ETL引擎处理。

2.3数据装载

将转换和加工后的数据装载到目的库中通常是ETL过程的最后步骤。

装载数据的最佳方法取决于所执行操作的类型以及需要装入多少数据。

当目的库是关系数据库时，一般来说有两种装载方式。

（1）SQL装载

直接SQL语句进行insert、update、delete操作。

（2）采用批量装载方法

如bcp、bulk、关系数据库特有的批量装载工具或API。

大多数情况下会使用第一种方法，因为它们进行了日志记录并且是可恢复的。

但是，批量装载操作易于使用，并且在装入大量数据时效率较高。

使用哪种数据装载方法取决于业务系统的需要。

3NoSQL技术[10]

在大数据时代，web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。

关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。

对于大型的SNS网站，每天用户产生海量的用户动态，对于关系数据库来说，在庞大的表里面进行SQL查询，效率是极其低下乃至不可忍受的。

此外，在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像webserver和appserver那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。

对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？

所以上面提到的这些问题和挑战都在催生一种新型数据库技术的诞生，这就是NoSQL技术。

3.1NoSQL与关系型数据库设计理念比较

关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。

而非关系型数据库以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。

3.2NoSQL技术特点

易扩展性：

NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。

数据之间无关系，这样就非常容易扩展。

也无形之间，在架构的层面上带来了可扩展的能力。

大数据量，高性能：

NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。

这得益于它的无关系性，数据库的结构简单。

一般MySQL使用QueryCache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。

而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。

灵活的数据模型：

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。

而在关系数据库里，增删字段是一件非常麻烦的事情。

如果是非常大数据量的表，增加字段简直就是一个噩梦。

这点在大数据量的web2.0时代尤其明显。

高可用：

NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。

比如Cassandra，HBase模型，通过复制模型也能实现高可用。

3.3CAP原理

分布式数据系统的三要素：

一致性（Consistency），可用性（Availability）、分区容忍性（Partitiontolerance）。

CAP原理：

在分布式系统中，这三个要素最多只能同时实现两点，不可能三者兼顾。

对于分布式数据系统，分区容忍性是基本要求。

对于大多数web应用，牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。

3.4几种主流NoSQL数据库

而互联网庞大的数据量和极高的峰值访问压力使得以增加内存、CPU等节点性能的垂直伸缩方案（Scale-UP）走入死胡同，使用大量廉价的机器组建水平可扩展集群（ScaleOut）成为绝大多数互联网公司的必然选择；廉价的机器失效是正常的，大规模的集群，节点之间的网络临时阻断也是常见的，因此在衡量一致性、可用性和分区容忍性时，往往倾向先满足后两者，再用其他方法满足最终的一致性。

在衡量CAP时，Bigtable选择了CA，用GFS来弥补P，Dynamo选择了AP，C弱化为最终一致性（通过Quorum或者read-your-write机制）。

3.4.1BigTable[11]

（1）BigTable简介

Bigtable是一个分布式的结构化数据存储系统，它被设计用来处理海量数据：

通常是分布在数千台普通服务器上的PB级的数据。

Google的很多项目使用Bigtable存储数据，包括Web索引、GoogleEarth、GoogleFinance等。

（2）数据模型

Bigtable是一个稀疏的、分布式的、持久化存储的多维度排序Map。

Map的索引是行关键字、列关键字以及时间戳；Map中的每个value都是一个未经解析的byte数组。

（row:

string,column:

string,time:

int64）-->string。

一个存储Web网页的例子的表的片断：

●行名：

”n.www”

●contents列族：

存放的是网页的内容

●anchor列族：

存放引用该网页的锚链接文本。

●“anchor:

”列表示被引用

●“anchhor:

my.look.ca”列表示被my.look.ca引用

●（”n.www”,”anchor:

my.look.ca”,t8）->”CNN.com”

（3）技术要点

●基础：

GFS,Chubby,SSTable。

—BigTable使用Google的分布式文件系统（GFS）存储日志文件和数据文件

—Chubby是一个高可用的、序列化的分布式锁服务组件

—BigTable内部存储数据的文件是GoogleSSTable格式的。

●元数据组织：

chubby->metadata->tablet。

—元数据与数据都保存在GoogleFS中，客户端通过Chubby服务获得表格元数据的位置

●数据维护与访问：

masterserver将每个tablet的管理责任分配给各个tabletserver，tablet的分布信息都保存在元数据中，所以客户端无须通过master来访问数据，只需要直接跟tabletserver通信。

●Log-structured数据组织：

写操作不直接修改原有的数据，而只是将一条记录添加到commitlog的末尾，读操作需要从log中merge出当前的数据版本。

具体实现：

SSTable,Memtable。

（Memtable即内存表：

将新数据或常用数据保存在内存表，可以减少磁盘IO访问）

（4）特点

●适合大规模海量数据，PB级数据；

●分布式、并发数据处理，效率极高；

●易于扩展，支持动态伸缩，适用于廉价设备；

●适合于读操作，不适合写操作;

●不适用于传统关系数据库。

3.4.2Dynamo[12]

（1）Dynamo简介

Dynamo最初是Amazon所使用的一个私有的分布式存储系统。

（2）设计要点

P2P的架构：

这区别于GoogleFS的SingleMaster架构，无须一个中心服务器来记录系统的元数据。

Performance（性能）,Availability（可用性）,Durability（数据持久性）三者的折衷，可以根据应用的需求自由调整三者比例

（3）技术要点

将所有主键的哈希数值空间组成一个首位相接的环状序列,对于每台机器，随机赋予一个哈希值，不同的机器就会组成一个环状序列中的不同节点，而该机器就负责存储落在一段哈希空间内的数据。

数据定位使用一致性哈希；对于一个数据，首先计算其的哈希值，根据其所落在的某个区段，顺时钟进行查找，找到第一台机，该机器就负责存储在数据的，对应的存取操作及冗余备份等操作也有其负责，以此来实现数据在不同机器之间的动态分配。

对于一个环状节点比如M个节点，比如一份数据需要保持N个备份，则该数据落在某个哈希区间内发现的第一个节点负责后续对应的N-1个节点的数据备份（注意M>=N），Vectorlock，允许数据的多个备份存在多个版本，提高写操作的可用性（用弱一致性来换取高的可用性）分布式存储系统对于某个数据保存多个备份，数据写入要尽量保证备份数据同时获得更新Dynamo采取数据最终一致性,在一定的时间窗口中，对数据的更新会传播到所有备份中，但是在时间窗口内，如果有客户读取到旧的数据，通过向量时钟（VectorClock）。

容错：

SloppyQuorum,hintedhandoff,Merkletree,SloppyQuorum马虎仲裁，并非采用严格的数据一致性检查，用于实现最终一致性。

hintedhandoff，节点故障会恢复时，可动态维护系统可用性，使系统的写入成功大大提升。

使用Merkletree为数据建立索引，只要任意数据有变动，都将快速反馈出来。

网络互联:

Gossip-basedmembershipprotocol，一种通讯协议，目标是让节点与节点之间通信，实现去中心化。

（4）特点

高可用：

设计上天然没有单点，每个实例由一组节点组成，从应用的角度看，实例提供IO能力。

一个实例上的节点可能位于不同的数据中心内,这样一个数据中心出问题也不会导致数据丢失。

总是可写：

hintedhandoff确保在系统节点出现故障或节点恢复时，能灵活处理

可根据应用类型优化可用性、容错性和高效性配置去中心化，人工管理工作少可扩展性较差：

由于增加机器需要给机器分配DHT（分布式hashtable）算法所需的编号，操作复杂度较高，且每台机器存储了整个集群的机器信息及数据文件的MerkleTree信息，机器最大规模只能到几千台。

4大数据基础设施-分布式文件系统

分布式文件系统（DFS，DistributedFileSystem）使用户更加容易访问和管理物理上跨网络分布的文件。

DFS为文件系统提供了单个访问点和一个逻辑树结构，通过DFS，用户在访问文件时不需要知道它们的实际物理位置，即分布在多个服务器上的文件在用户面前就如同在网络的同一个位置。

4.1成熟架构

早期比较成熟的网络存储结构大致分为三种：

直连式存储（DAS：

DirectAttachedStorage）、网络连接式存储（NAS：

NetworkAttachedStorage）和存储网络（SAN：

StorageAreaNetwork）。

●在直连式存储DAS中，主机与主机之间、主机与磁盘之间采用SCSI总线通道或FC通道、IDE接口实现互连，将数据存储扩展到了多台主机，多个磁盘。

随着存储容量的增加，SCSI通道将会成为IO瓶颈。

●网络连接式存储NAS一种连接到局域网的基于IP的文件系统共享设备。

NAS系统拥有一个专用的服务器，安装优化的文件系统和瘦操作系统，该OS专门服务于文件请求。

一个NAS设备是专用、高性能、高速、单纯用途的文件服务和存储系统。

●存储网络SAN是指存储设备相互连接且与一台服务器或一个服务器群相连的网络。

一个SAN网络由负责网络连接的通信结构、负责组织连接的管理层、存储部件以及计算机系统构成。

与NAS偏重文件共享不同，SAN主要是提供高速信息存储。

网络存储通信中使用到的相关技术和协议包括SCSI、RAID、iSCSI以及光纤信道。

随着全球非结构化数据快速增长，针对结构化数据设计的这些传统存储结构在性能、可扩展性等方面都难以满足要求，进而出现了集群存储、集群并行存储、P2P存储、面向对象存储等多种存储结构。

●集群存储，简而言之就是将若干个普通性能的存储系统联合起来来组成“存储的集群”。

集群存储采用开放式的架构，具有很高扩展性，一般包括存储节点、前端网络、后端网络三个构成元素，每个元素都可以非常容易地进行扩展和升级而不用改变集群存储的架构。

集群存储通过分布式操作系统的作用，会在前端和后端都实现负载均衡。

●集群并行存储采用了分布式文件系统混合并行文件系统。

并行存储容许客户端和存储直接打交道，这样可以极大地提高性能。

集群并行存储提高了并行或分区I/O的整体性能，特别是读取操作密集型以及大型文件的访问。

获取更大的命名空间或可编址的阵列。

通过在相互独立的存储设备上复制数据来提高可用性。

通过廉价的集群存储系统来大幅降低成本，并解决扩展性方面的难题。

集群存储多在大型数据中心或高性能计算中心使用。

●P2P存储用P2P的方式在广域网中构建大规模分布式存储系统。

从体系结构来看，系统采用无中心结构，结点之间对等，通过互相合作来完成用户任务。

用户通过该平台自主寻找其它结点进行数据备份和存储空间交换，为用户构建了大规模存储交换的系统平台。

P2P存储用于构建更大规模的分布式存储系统，可以跨多个大型数据中心或高性能计算中心使用。

●面向对象存储是SAN和NAS的有机结合，是一种存储系统的发展趋势。

在面向对象存储中，文件系统中的用户组件部分基本与传统文件系统相同，而将文件系统中的存储组件部分下移到智能存储设备上，于是用户对于存储设备的访问接口由传统的块接口变为对象接口。

4.2典型系统

基于多种分布式文件系统的研究成果，人们对体系结构的认识不断深入，分布式文件系统在体系结构、系统规模、性能、可扩展性、可用性等方面经历了较大的变化。

下面按时间顺序介绍几个分布式文件系统的典型应用。

1985年出现的NFS受到了广泛的关注和认可，被移植到了几乎所有主流的操作系统，成为分布式文件系统事实上的标准。

NFS利用Unix系统中的虚拟文件系统（VFS-VirtualFileSystem）机制，将客户机对文件系统的请求，通过规范的文件访问协议和远程过程调用，转发到服务器端进行处理；服务器端在VFS之上，通过本地文件系统完成文件的处理，实现了全局的分布式文件系统。

Sun公司公开了NFS的实施规范，互联网工程任务组（TheInternetEngineeringTaskForce，IETF）将其列为征求意见稿（RFC-RequestforComments），这很大程度上促使NFS的很多设计实现方法成为标准，也促进了NFS的流行。

GeneralParallelFileSystem（GPFS）[13]是目前应用范围较广的一个系统，在系统设计中采用了多项当时较为先进的技术。

GPFS的磁盘数据结构可以支持大容量的文件系统和大文件，通过采用分片存储、较大的文件系统块、数据预读等方法获得了较高的数据吞吐率；采用扩展哈希（extensiblehashing）技术来支持含有大量文件和子目录的大目录，提高文件的查找和检索效率。

GPFS采用不同粒度的分布式锁解决系统中的并发访问和数据同步问题：

字节范围的锁用于用户数据的同步，动态选择元数据节点（metanode）进行元数据的集中管理；具有集中式线索的分布式锁管理整个系统中空间分配等。

GPFS采用日志技术对系统进行在线灾难恢复。

每个节点都有各自独立的日志，且单个节点失效时，系统中的其他节点可以代替失效节点