大数据存储 模型训练数据从哪来

大数据
面对大数据的爆炸式增长,且具有大数据量、异构型、高时效性的需求时,数据的存储不仅仅有存储容量的压力,还给系统的存储性能、数据管理乃至大数据的应用方面带来了挑战。

面对大数据的爆炸式增长,且具有大数据量、异构型、高时效性的需求时,数据的存储不仅仅有存储容量的压力,还给系统的存储性能、数据管理乃至大数据的应用方面带来了挑战。这些大量的数据结构复杂,种类繁多,如何对分布、多态、异构的大数据进行管理的问题已经不期而至,传统的数据存储方式面对大数据的猛烈增长已不能满足需求,需要开展分布式存储的研究。

大数据的存储方式

分布式系统:分布式系统可以解决大数据存储的问题,为大数据的存储提供了方式。分布式系统的定义包括两个方面:第一是关于硬件的:机器本身是独立的。第二个方面是关于软件的:对于用户来说,他们就像跟单个系统打交道。这两个方面一起阐明了分布式系统的本质,缺一不可。

NoSQL数据库:它是“Not Only SQL”的缩写,意义是:适用关系型数据库的时候就使用关系型数据库,不适用的时候也没必要非使用关系型数据库不可,可以考虑使用更加合适的数据存储方式。

云存储:云存储是伴随着云计算技术的发展而衍生出来的一种新兴的网络存储技术,它是云计算的重要组成部分,也是云计算的重要应用之一;它不仅是数据信息存储的新技术、新设备模型,也是一种服务的创新模型。

面临的挑战

1 系统问题

面对大数据的爆炸式增长,且具有大数据量、异构型、高时效性的需求时,数据的存储不仅仅有存储容量的压力,还给系统的存储性能、数据管理乃至大数据的应用方面带来了挑战。

2 管理问题

这些大量的数据结构复杂,种类繁多,如何对分布、多态、异构的大数据进行管理的问题已经不期而至,传统的数据存储方式面对大数据的猛烈增长已不能满足需求,需要开展分布式存储的研究。

3 应用问题

随着数据量的爆炸式增长,不断刺激着计算机技术的发展,如何利用大数据为人们生活所用,即是大数据的应用问题。大数据的应用在人类活动中所涉及的范围越来越大,与我们已经密不可分。

4 数据转换

数据转换是按照预先设计好的规则将抽取的数据进行转换,在转化过程中,我们需要对数据进行清洗、整理和集成,即发现数据中的错误数据并进行相应的改正,将原来不同规则的数据整理集成为统一的规则。

全量抽取发现空值并处理:发现源数据中字段空值,按照一定的规则进行加载或者替换,比如可以用“0”或者按照该字段的平均取值来替换。

规范数据格式:将不同源系统的不同数据格式统一规范。转化过程需要将这些不同的表示格式统一成为唯一的规范格式。

拆分数据:有时候需要一句业务需求对字段进行分解。比如通话主叫号码02381322854,可进行区域码和电话号码分解为主叫地区023和主叫号码81322854。

数据存储系统能力的提升主要有三个方面,一是提升系统的存储容量,二是提升系统的吞吐量,三是系统的容错性

存储容量:提升系统容量有两种方式:一种是提升单硬盘的容量,通过不断采用新的材质和新的读写技术,目前单个硬盘的容量已经进入TB时代。一种是在多硬盘的情况的下如何提升整体的存储容量。

吞吐量:对于单个硬盘,提升吞吐量的主要方法是提高硬盘转速、改进磁盘接口形式或增加读写缓存等。而要提升数据存储系统的整体吞吐量,比较典型的技术是早期的专用数据库机体系。

容错性:数据存储容错是指当系统中的部件或节点由于硬件或软件故障,导致数据、文件损坏或丢失时,系统能够自动将这些损坏或丢失的文件和数据恢复到故障发生前的状态,使系统能够维持正常运行的技术。

大数据从获取到分析的各个阶段都可能会涉及到数据集的存储,考虑到大数据有别于传统数据集,因此大数据存储技术有别于传统存储技术。大数据一般通过分布式系统、NoSQL数据库等方式(还有云数据库)进行存储。同时涉及到以下几个新理念。

集群:将多台服务器集中在一起,每台服务器(节点)实现相同的业务。

因此每台服务器并不是缺一不可,集群的目的是缓解并发压力和单点故障转移问题。

例如:新浪网微博的访问量巨大,因此可以通过群集技术,几台服务器完成同一业务。当有业务访问时,选择负载较轻的服务器完成任务。

分布式

传统的项目中,各个业务模块存在于同一系统中,导致系统过于庞大,开发维护困难,无法针对单个模块进行优化以及水平扩展。因此考虑分布式系统:

将多台服务器集中在一起,分别实现总体中的不同业务。每台服务器都缺一不可,如果某台服务器故障,则网站部分功能缺失,或导致整体无法运行。因此可大幅度的提高效率、缓解服务器的访问存储压力。

分布式与集群的关系、区别

关系:分布式方便我们系统的维护和开发,但是不能解决并发问题,也无法保证我们的系统崩溃后的正常运转。集群则恰好弥补了分布式的缺陷,多个服务器处理相同的业务,这可以改善系统的并发问题,同时保证系统崩溃后的正常运转。

因此,分布式和集群技术一般同时出现,密不可分。(分布式中的每一个节点,都可以做集群)

区别:分布式是以缩短单个任务的执行时间来提升效率的,而集群则是通过提高单位时间内执行的任务数来提升效率。

【补充】例如:

如果一个任务由10个子任务组成,每个子任务单独执行需1小时,则在一台服务器上执行改任务需10小时。

  • 采用分布式方案:提供10台服务器,每台服务器只负责处理一个子任务,不考虑子任务间的依赖关系,执行完这个任务只需一个小时。(这种工作模式的一个典型代表就是Hadoop的Map/Reduce分布式计算模型)
  • 而采用集群方案:同样提供10台服务器,每台服务器都能独立处理这个任务。假设有10个任务同时到达,10个服务器将同时工作,10小时后,10个任务同时完成。整身来看,还是1小时内完成一个任务。

文件系统 & 分布式文件系统

文件系统——是一种存储和组织计算机数据的方法。

数据是以文件的形式存在,提供 Open、Read、Write、Seek、Close 等API 进行访问;

文件以树形目录进行组织,提供重命名(Rename)操作改变文件或者目录的位置。

分布式文件系统——允许文件通过网络在多台主机上分享的文件系统,可让多机器上的多用户分享文件和存储空间。

几种常见的分布式文件存储系统有GFS(Google分布式文件系统)、HDFS(Hadoop分布式文件系统)、TFS、Swift、Ceph等。

图片

 HDFS系统示意图


NoSQL(非关系型数据库)

NoSQL(Not Only SQL),意即"不仅仅是SQL"。NoSQL数据库可同时存储结构化、非结构化数据、半结构化数据。

相比于关系型数据库,非关系型数据库提出另一种理念:每一个样本(元组)根据需要可以有不同的字段,这样就不局限于固定的结构,调取数据时也更方便。可以减少一些时间和空间的开销。因此为了获取用户的不同信息,不需要像关系型数据库中,对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询,通过XQuery、SPARQL等查询语言完成查询过程。

非关系型数据库有以下几种类型:

图片

大数据集的数据量巨大,单机无法存储与处理如此规模的数据量,只能依靠大规模集群以进行存储和处理,因此系统需要具备可扩展性。

目前主流的大数据存储与计算系统往往采用横向扩展(Scale Out)的方式。因此,对于待存储处理的海量数据,需要用过数据分片将数据进行切分,并分配到各服务器中。

数据分布的两条途径:复制 & 分片

分布式NoSQL的两大特性:复制和分片。

数据分片与数据复制是紧密联系的两个概念。对于海量数据,可通过数据分片实现系统的水平扩展,通过数据复制保证数据的高可用性。

 图片

 数据分片与数据复制的关系

分片(sharding/partition)——将数据的各个部分存放在不同的服务器/节点中,每个服务器/节点负责自身数据的读取与写入操作,以此实现横向扩展。

复制(replication)——将同一份数据拷贝到多个节点。分为主从复制master-slave方式、对等式复制peer-to-peer。

  • 主从式复制:master节点用于存放权威数据,通常负责数据的更新,其余节点都叫做slave节点,复制操作就是让slave节点的数据与master节点的数据同步。适用于读请求密集的负载。 
  • 对等式复制:两个节点相互为各自的副本,也同时可以接受写入请求,丢失其中一个不影响整个数据库的访问。但同时接受写入请求,容易出现数据(写入)不一致问题,实际使用上,通常是只有一个节点接受写入请求,另一个master作为stand-by,在对方出现故障的时候自动承接写操作请求。

分片与复制可以组合,即同时采用主从复制与分片、对等复制与分片。

优缺点对比:

分片可以极大地提高读取性能,但对于要频繁写的应用,帮助不大。另外,分片对改善故障恢复能力并没有帮助,但是它减少了故障范围,只有访问这个节点的那些用户才会受影响,其余用户可以正常访问。虽然数据库缺失了一部分,但是还是其余部分还是可以正常运转。

复制除保证可用性之外,还可增加读操作的效率。即客户端可以从多个备份数据中选择物理距离较近的进行读取,这既增加了读操作的并发性又可以提高单次读的读取效率。

对于分布式数据库系统的设计过程,需遵循CAP定理:

CAP定理(布鲁尔定理)

布式数据库系统不可能同时满足以下三点,最多只能同时满足两个:

  • 一致性(Consistency)——所有节点在同一时间具有相同的数据;
  • 可用性(Availability)——保证每个请求不管成功或者失败都有响应;
  • 分区容忍(Partition tolerance)——系统中任意信息的丢失或失败不会影响系统的继续运作。

因此,当代的分布式数据存储服务,均是针对各自服务的内容、性质取舍。

而NoSQL数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类。

图片

关系型数据库的设计原则与事务管理遵循ACID规则:

ACID

事务(transaction),具有如下四个特性:

  • A (Atomicity) 原子性——事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功,只要有一个操作失败,整个事务失败,需要回滚。
  • C (Consistency)一致性——数据库要一直处于一致的状态,事务的运行不会改变数据库原本的约束。
  • I (Isolation) 独立性——并发的事务是相互隔离的,一个事务的执行不能被其他事务干扰。
  • D (Durability) 持久性——是指一旦事务提交后,它所做的修改将会永久的保存在数据库上,即使系统崩溃也不会丢失。

基于CAP定理演化而来BASE数据库设计原则:

BASE

包括:Basically Available(基本可用)、Soft state(软状态)、Eventually consistent(最终一致性)。

针对数据库系统要求的可用性、一致性,BASE放宽要求,形成基本可用和软状态/柔性事务。而一致性是最终目的。

大模型训练的数据来源

大模型的基础是大量的数据以及算力,下面是一些典型大模型的训练数据集大小(以 GB 为单位)。

图片

大模型的训练数据源主要包含:

  1. 维基百科 维基百科是一个免费的多语言协作在线百科全书,由超过 300,000 名志愿者组成的社区编写和维护。截至 2022 年 4 月,英文版维基百科中有超过 640 万篇文章,包含超 40 亿个词[5]。一般来说,重点研究实验室会首先选取它的纯英文过滤版作为数据集。
  2. 书籍 故事型书籍由小说和非小说两大类组成,主要用于训练模型的故事讲述能力和反应能力,数据集包括 Project Gutenberg 和 Smashwords (Toronto BookCorpus/BookCorpus) 等。
  3. 杂志期刊 预印本和已发表期刊中的论文为数据集提供了坚实而严谨的基础,因为学术写作通常来说更有条理、理性和细致。这类数据集包括 ArXiv 和美国国家卫生研究院等。
  4. Reddit 链接 WebText 是一个大型数据集,它的数据是从社交媒体平台 Reddit 所有出站链接网络中爬取的,每个链接至少有三个赞,代表了流行内容的风向标,对输出优质链接和后续文本数据具有指导作用。
  5. Common Crawl
    Common Crawl 是 2008 年至今的一个网站抓取的大型数据集,数据包含原始网页、元数据和文本提取,它的文本来自不同语言、不同领域。重点研究实验室一般会首先选取它的纯英文过滤版(C4)作为数据集。
  6. 其他数据集不同于上述类别,这类数据集由 GitHub 等代码数据集、StackExchange 等对话论坛和视频字幕数据集组成。
    很多人认为,这个数据量也不大啊,也就是几百GB到TB,根本无法称之为大量数据。其实,以CC数据集为例,合计1.4PB,而GPT3用于训练的CC数据仅使用了其中的570GB。这中间是因为单次训练进行了数据的预处理,只提取了自己关心的部分。

图片

数据爬取和保存通常使用WARC、WAT和WET格式的数据存储。LLaMA的模型使用的是WET格式的数据。以Common Crawl为例,每个CC快照的文本大小约300T,而一个WET格式的快照大小约30T。
数据去重
用CCNet将这些快照进行分片(sharding),将原来的数据分成5G一个分片。然后对每个数据做预处理:如小写化所有数据、数字变成占位符等,然后计算每个段落的hash,再去重。并行处理数据,提高处理速度,降低数据量。
文本语言识别与过滤
识别语言,然后对不同语言的数据计算分数,最后根据分数确定是否保留某些语言。在pipeline中执行此操作的顺序可能会影响语言识别的质量。CCNet使用使用n-gram特征的fastText分类器。
质量过滤
CCNet中,他们建议使用维基百科在目标语言上训练一个简单的语言模型,然后计算每段的困惑度(perplexity),并使用困惑度分布的来对它们进行分段。
进一步过滤
为了确定页面的质量。如果这个页面无法被认为是可以作为维基百科引用的,说明页面本身质量可能比较差,所以可以进一步丢弃,提高数据的质量,降低训练成本。经过这么一轮操作猛如虎,剩下数据就很少了。未来数据从单一的文本自然语言走向多模态,相关的训练数据集就会更多了。

责任编辑:庞桂玉 来源: 数字化助推器
相关推荐

2020-06-23 09:55:40

Spring Boo指标Java

2016-10-10 14:05:46

存储

2012-11-08 09:32:24

2023-10-20 16:57:09

2016-02-19 17:54:42

智慧医疗大数据

2013-03-11 09:55:52

大数据中数据

2017-07-13 11:13:18

大数据数据存储

2013-08-08 10:07:43

大数据存储结构化数据

2017-03-22 20:25:31

大数据存储紫光西部数据

2018-12-21 11:01:05

存储大数据RAID

2018-03-28 17:16:09

大数据

2017-07-03 13:53:17

大数据大数据平台数据治理

2013-03-20 11:03:05

大数据

2020-07-14 10:55:28

大数据IT技术

2020-09-24 22:54:46

大数据IT技术

2018-03-20 10:37:33

存储大数据管理

2013-01-16 10:10:26

2022-09-01 23:34:18

大数据数据分析工具

2014-02-17 10:28:34

大数据
点赞
收藏

51CTO技术栈公众号