智慧图书馆大数据采集

对于大数据分析来说，获取大数据是重要的基础。数据采集，又称数据获取，是处于大数据生命周期的第一个环节，它是通过RFID 射频数据、传感器数据、社交网络、移动互联网等方式获取各种类型的结构化、半结构化和非结构化的海量数据。由于可能存在成千上万的用户并发的访问和操作，因此，必须采用专门针对大数据的采集方法。

大数据采集是在确定用户目标的基础上，针对该范围内的海量数据的智能化识别、跟踪及采集的过程。实际应用中，大数据可能是部门内部的交易信息，比如联机交易数据和联机分析数据；也可能是源于各种网络和社交媒体的半结构化和非结构化数据，比如Web 文本、手机呼叫详细记录、GPS 和地理定位映射数据、通过管理文件传输协议传送的海量图像文件、评价数据等；还有源于各类传感器的海量数据，比如摄像头、可穿戴设备、智能家电、工业设备等收集的数据。面对如此复杂、海量的数据，制定适合大数据的采集策略或者方法是值得深入研究的。

传统数据采集是从传感器或其他设备自动采集信息的过程。这种方法数据来源单一，数据结构简单，且存储、管理和分析数据量也相对较小，大多采用集中式的关系型数据库或并行数据仓库即可处理。但是，在大数据时代，面对数据来源广泛、数据类型复杂以及海量数据的井喷式增长和用户不断增长需求的问题，传统的集中式数据库的弊端日益显现，基于分布式数据库的数据采集方法应运而生。

基于分布式数据库的数据采集方法相比传统数据采集方法的特点如下：

第一，具有更高的数据访问速度：分布式数据库为了保证数据的高可靠性，往往采用备份的策略实现容错，因此，客户端可以并发地从多个备份服务器同时读取，从而提高了数据访问速度。

第二，具有更强的可扩展性：分布式数据库可以通过增添存储节点来实现存储容量的线性扩展，而集中式数据库的可扩展性十分有限。

第三，更高的并发访问量：分布式数据库由于采用多台主机组成存储集群，所以相对集中式数据库，它可以提供更高的用户并发访问量。

目前，多家知名公司都已开发了采用分布式架构的大数据采集平台，比如 Apache Chukwa、Flume、Serible 以及 Apache kafka 等。

Apache Chukwa 是一个开源的用于监控大型分布式系统的数据采集平台，它是构建在Hadoop 分布式文件系统（HDFS）和 MapReduce 框架之上，并继承了Hadoop 的可伸缩性和健壮性。Apache Chukwa 还包括一个灵活、强大的工具集，用于显示、监视和分析结果，以充分利用收集到的数据。

Flume 是一种分布式、可靠和可用的服务，可以有效地采集海量日志数据。Flume 支持在日志系统中定制各类数据发送方，用于数据采集；同时，Flume 提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。Flume 最早是Cloudera 提供的日志采集系统，称为Flume OG（Original Generation）。但随着Flume 功能的扩展，Flume OG 代码工程臃肿、核心组件设计不合理、核心配置不标准等缺点暴露出来，尤其是在 Flume OG 的最后一个发行版本9.94.0 中，旧志传输不稳定的现象尤为严重。为了解决这些问题，2011年11月 22 号，Cloudera 完成了 Flume-728，对 Flume 进行了包括重构核心组件、核心配置以及代码架构等改动，重构后的版本被纳入Apache 旗下，Cloudera Flume 改名为ApacheFlume。

Seribe 是Facebook 开源的分布式数据采集平台，目前在各大互联网公司内部已经得到大量的应用。它能够从各种日志源上收集日志，存储到一个中央存储系统（可以是 NFS、分布式文件系统等）上，以便于进行集中统计分析处理。它为日志的“分布式收集，统一处理”提供了一个可扩展的、高容错的方案。

Apche Knka 是最初由 Linkedin 公司开发，是一个分布式、支持分区的、多副本的、基于ZonKceper 协调的分布式消息系统，它的最大的特性就是可以实时地处理大数据以满足各种需求场景。

Linkedin 于2010年被纳入Apache，并更名为 Apache Kafku。除上述这些广泛应用的大数据采集平台外，还有Fluend、Logstash、Splunk Forwarder 等大数据采集平台，它们大都提供高可靠和高扩展的数据采集。大多数平台都抽象出了输入，输出和中间的缓冲架构。利用分布式的网络连接，大多数平台都能实现一定程度的扩展性和高可靠性。

随着互联网技术的飞速发展，互联网中沉淀着大量以共享和开放形式存在的，能反映用户偏好倾向、事件趋势、浏览历史、购买历史等相关数据，对于这些数据的采集也是大数据分析的重要组成部分。对于这部分大数据的采集，通常采用网络爬虫或网站公开 API 等方式从网页中抽取数据，将其存储为统一的本地数据文件。同时，它也可以支持图片、音频、视频等文件或附件的非结构数据的采集。此外，随着移动互联网的兴起，移动终端也产生了大量的个性化信息，对于这类数据的采集，各种应用 App 是获取用户移动端数据的有效方法。

很多企事业单位内部产生了大量的数据并被存储于数据中心或数据集市中。如ERP 系统产生的数据存储在ERP 数库中，在线交易平台产生的数据存储在交易数据库中。对于这类数据的采集，ETL 是整合数据的一个重要方式。

在大数据的采集过程中，主要面对的挑战是并发数高，因为同时可能会有成千上万的用户进行访问和操作。例如，“12306”售票系统和淘宝网站，它们并发的访问量的峰值达到上百万，所以需要在采集端部署大量的数据库才能支撑，并且如何在这些数据库之间进行负载均衡和分片是采集工具重点解决的问题。

大数据的价值不在于存储数据本身，而在于如何挖掘数据，只有具备足够的数据源，才可挖掘出数据背后的价值。因此，大数据采集是非常重要的基础。针对如此庞大的数据量，在数据采集过程中，主要面临的挑战和困难如下：

数据的分布性：文档数据分布在数以百万计的不同服务器上，没有预先定义的拓扑结构相连；数据的不稳定性：系统会定期或不定期地添加和删除数据；数据的无结构和冗余性：很多网络数据没有统一的结构，并存在着大量重复信息；数据的错误性：数据可能是错误的或无效的。错误来源有录入错误、语法错误、OCR 错误等；数据结构复杂：既有存储在关系数据库中的结构化数据，也有文档、系统日志、图形图像、语音、视频等非结构化数据。

过去，通常使用传统的关系型数据库 MYSQL 和 Oracle 等来存储每一笔事务数据，因此，可以利用数据库进行数据采集。在大数据时代，快速的海量数据导致传统关系型数据库的存储效果和并发访问等存在诸多问题。传统的数据采集技术已经无法满足大数据的需求，如何部署大量的采集端数据库进行分布式采集，并保证数据库之间的负载均衡是值得思考的问题。

就大数据采集而言，大型互联网企业由于自身用户规模庞大，可以把自身用户产生的交易、社交搜索等数据充分挖掘，拥有稳定安全的数据资源。对于其他大数据公司和大数据研究机构而言，大数据采集常用方法包括系统日志采集、利用 ETL工具采集以及网络爬虫等。

2.4.3.1　系统日志文件采集

系统日志文件采集是一种广泛使用的数据收集方法，日志文件是由数据源系统自动生成的记录文件，为了后续的分析，须以指定的文件格式记录活动。日志文件通常用于几乎所有的计算机系统中。例如，Web 服务器日志文件记录了 Web 服务器接受处理请求以及运行时错误等各种原始信息，以及 Web 网站的外来访问信息，包括各页面的点击数、点击率、网站用户的访问量和 Web 用户的财产记录等。

为获取用户在网站上的活动信息，Web 服务器主要包括以下三种日志文件格式：公用日志文件格式、扩展日志格式和 IIS 日志格式。所有三种类型的日志文件都是 ASCII 文本格式。除了文本文件外，数据库有时可能会被用来存储日志信息，从而提高海量日志存储的查询效率。还有基于数据收集的一些其他日志文件，包括金融应用中的股票指标以及网络监控和交通管理中的运行状态信息等。

对于系统日志文件采集，可以使用海量数据采集工具，如Hadoop 的Chukwa，Cloudera 的Flume，Facebook 的Serible 以及Apache kafka 等大数据采集框架。这些工具均采用分布式架构，能满足大数据的日志数据采集和传输需求。

2.4.3.2　利用ETL　工具采集

在图书馆内部，管理和服务等业务流程中产生了大量的数据并被存储于数据中心或数据集市中。这些数据虽然都是由同一图书馆的内部业务所产生，但一般是由不同的系统产生并以不同的数据结构存储在不同的数据库中。如借还系统产生的数据存储在图书馆管理数据库中，考勤的数据存储在打卡数据库中。

另一方面，在图书馆运营过程中可能会涉及其他合作图书馆的数据，这些由不同用户和图书馆内部不同部门提供的内部数据可能来自不同的途径，其数据内容、数据格式和数据质量千差万别，有时甚至会遇到数据格式不能转换或转换数据格式后丢失信息等棘手问题，严重阻碍了各部门和各应用系统中数据的流动与共享。因此，能否对数据进行有效的整合将成为是否能够对内部数据进行有效利用的关键，ETL 是整合数据的一个重要途径。

ETL 即数据抽取（extract）、转换（transform）、加载（load）的过程。ETL 是将图书馆内部的各种形式和来源的数据经过抽取、清洗转换之后进行格式化的过程。ETL 的目的是整合图书馆中分散、零乱、标准不统一的数据，以便于后续的分析、处理和运用。

图2-15　ETL体系结构

ETL 主要负责将分散的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后，进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、为数据挖掘提供决策支持的数据。为了实现这些功能，ETL 相关工具一般会进行一些功能上的扩展，如工作流、调度引擎、规则引擎、脚本支持、统计信息等。

数据抽取实际上就是数据采集，也就是从数据源中抽取数据的过程。由于在大多数场景下，数据会存放在数据库里，数据抽取也就变成了从数据库中抽取数据的过程。从数据库中抽取数据一般分为两种方式：全量抽取和增量抽取。

全量抽取就是对整个数据库的所有数据进行抽取，它将数据源库中的所有数据原封不动地从数据库中抽取出来，然后转换成 ETL 工具可以识别的格式。由于全量抽取是对整个数据库的所有数据进行抽取，不需要进行其他复杂处理，因此抽取过程比较直观、简单。但是在实际运用中，很少会用到全量抽取，主要是因为数据是实时增加的，全量抽取在每次抽取的时候将会重复抽取上次已经抽取过的历史数据，这样在产生大量冗余数据的同时也降低了抽取的效率。于是增量抽取策略被广泛关注，并得到广泛应用。

增量抽取只抽取自上次抽取以来数据库中要抽取的表中新增或修改的数据。如何捕获变化的数据是增量抽取的关键。优秀的捕获方法应该能够做到以较高的准确率获得数据库中发生变化的数据，同时还不能对业务系统造成太大的压力以免影响现有的业务。在增量数据抽取的过程中，常用的捕获变化数据的方法有：日志比对、时间戳、触发器、全表比对等。

第一，日志比对：通过分析数据库自身的日志来判断发生变化的数据。例如，常用的Oracle 数据库。Oracle 数据库具有改变数据捕获（Changed Data Capture，CDC）的特性。CDC 能够帮助用户识别从上次抽取之后发生变化的数据。利用 CDC 在对源表进行“Insert”“update”或“delete”等操作的同时就可以提取数据，并且将变化的数据保存在数据库的变化表中。这样就可以捕获发生变化的数据，然后利用数据库视图以一种可控的方式提供给目标系统。

第二，时间戳：通过增加一个时间戳字段，在更新修改表数据的同时修改时间戳字段的值。当进行数据抽取时，通过比较系统时间与时间戳字段的值来决定抽取哪些数据。对于只对时间戳自动更新的数据库来说，在数据库表其他字段的数据发生改变时，系统将自动更新时间戳字段的值。有的数据库不支持时间戳的自动更新，这就要求业务系统在更新业务数据的同时，手工更新时间戳字段。时间戳的方式性能比较好，数据抽取相对清楚简单，但对业务系统需要增加额外的时间戳字段。另外，因为无法捕获对时间戳以前数据的“delete”和“update”操作，因此在数据准确性上受到了一定的限制。

第三，触发器：在数据源表上建立触发器。例如；可以建立“Insert”“&apos；updale”或“delele”三个触发器，每当源表中的数据发生变化时，通过相应的触发器将变化的数据写入一个临时表，抽取线程从临时表中抽取数据，临时表中抽取过的数据被标记或删除。触发器方式的优点是数据抽取的性能较高；缺点是要求业务表建立触发器，对业务系统有一定的影响。

第四，全表比对：典型的全表比对的方式是采用MD5 校验码。ETL 工具事先为要抽取的表建立一个结构类似的MD5 临时表，该临时表记录源表的主键及根据所有字段的数据计算出来的MD5 校验码。每次进行数据抽取时，对源表和MD5 临时表进行MD5 校验码的比对，从而决定源表中的数据是新增、修改还是删除，同时MD5 更新MD5 校验码。MD5 方式的优点是对源系统的倾入性较小（仅需要建立一个MD5 临时表）。与触发器和时间戳的主动通知不同，MD5 方式是被动地进行全表数据的比对，性能较差。当表中没有主键或唯一列且含有重复记录时，MD5 方式的准确性就较差。

ETL 处理的数据源除了关系数据库外，也可以是文件，如txt 文件、xml 文件等。对文件数据的抽取一般是进行全量抽取，每次抽取前可保存文件的时间戳或计算文件的MD5 校验码，下次抽取时进行比对，如果相同则可忽略本次抽取。

从数据源中抽取的数据不一定完全满足目的数据库的要求，如数据格式的不一致、数据输入错误、数据不完整等，因此有必要对抽取出来的数据进行数据转换和加工。数据的转换和加工可以在ETL 引擎中进行，也可以在数据抽取的过程中利用关系数据库的特性同时进行。(www.xing528.com)

在ETL 引擎中一般以组件化的方式实现数据转换。常用的数据转换组件有字段映射、数据过滤、数据清洗、数据替换、数据计算、数据验证、数据加解密、数据合并、数据拆分等。这些组件如同一条流水线上的一道道工序，它们是可插拔的，且可以任意组装，各组件之间通过数据总线共享数据。

将转换和加工后的数据加载到目的库中通常是ETL 过程的最后步骤。加载数据的最佳方法取决于所执行操作的类型及需要装入的数据量。

在大数据项目建设过程中，数据采集是最关键的环节。利用ETL 工具采集的数据源对象包括图书馆的自有数据。这里隐含的一个问题是，除了本馆的自有数据以外，还应该采集那些相关的外部数据。因此，实际的数据采集还涉及如下的问题：

第一，在系统初始上线前，将既有数据导入新系统中，通常是不可或缺的步骤。如果数据是在图书馆自有系统中，则需要从既有自营系统中将数据导出并输入到新系统中。

第二，在实操作中，往往还有一类既有数据，它是以历史文档的形式保存，甚至是以纸质（非电子存储）的方式存放在图书馆里。这类数据往往也是需要数据导入的范围。特别是对于非电子存储的数据，意味着首先需要数字化，然后进行数据导入。

第三，ETL 是在数据库层进行数据交换的一个工具。这意味着，需要对数据源的数据字典、数据组织与表结构有清晰的了解，否则极易出现数据获取不完整的情况。

第四，传统意义上，ETL 的流程是先抽取（从原始数据库中提取出数据）、再转换（转换成目标数据库的格式）、最后加载（将转换好的数据导入目标数据库）。在大数据场景下，出于对数据加载效率的考虑，一般将顺序更改为 ELT，即先抽取、再加载、最后转换，这样做的好处在于先将原始数据库的数据最大范围地导入当前数据库中。

第五，ETL 只是众多数据交换方式中的一种，非常适合于大批量的数据导入导出的场景（比如系统上线伊始）。事实上，还有一种利用 API 接口方式进行数据交换，即由原系统提供类似功能、新开发系统按照接口标准进行数据采集和交换。在实际应用中，API 接口方式非常适合于本馆与外馆进行数据交换的场合，这种数据交换往往是建立在一定的数据共享的基础上，双方达成数据交换的意向，数据源出于对数据库访向安全的控制，往往不会倾向于在数据库层进行 ETL，而 API 接口方式则是一种非常好的补充。

实际上，任何一个新开发的大数据系统平台，本身都应该兼具的一个隐含功能——即将本系统的数据以服务的形式提供给第三方。也就是说，在进行新系统研发的过程中，系统设计者应该有意识地设计与实现面向第三方数据访问的 API 接口方式，允许第三方获得当前系统的数据。

2.4.3.3　互联网数据采集

随着互联网、物联网、云计算等技术的迅速发展，现代信息社会步入了大数据时代。网络自媒体和社交网络等新型行业的兴起及飞速地发展，在极大地改变人们的生活、交流方式的同时，也产生了大量的网络数据，如浏览数据、博文图片信息、地理位置信息等。2015年，全国两会期间，李克强总理在政府工作报告中提出了“互联网+”战略，这不仅加快互联网与传统行业的融合，同时也进一步丰富了大数据的来源。互联网数据已经成为大数据的一个重要来源。

互联网大数据通常是指“人、机、物”三元世界在网络空间中彼此之间相互交互与融合所产生的大数据。互联网大数据不仅数据量级大，而且具有一些其他数据源所不具备的特性。

第一，多源异构性：互联网大数据通常由不同的用户、不同的网站所产生，数据形式也呈现出复杂的非结构化形式，如语音、视频、图片、文本等。

第二，交互性：不同于测量和传感器获取的大规模科学数据（如气象数据、卫星遥感等数据），微博、微信、Facebook、Twilter 等社交网络的兴起导致大量互联网数据具有很强的交互性。

第三，时效性：在互联网和移动互联网平台上，每时每刻都有大量的新数据发布，互联网大数据内容不断发生变化，使得信息传播具有时序相关性。

第四，社会性：网络用户不仅可以根据需要发布信息，也可以根据自己的喜好回复或转发。互联网大数据直接反映了社会状态。

第五，突发性：有些信息在传播过程中会在短时间内引起大量新的网络数据的产生，并使相关的网络用户形成网络群体，体现出网络大数据及网络群体的突发特性。

第六，高噪声：互联网大数据来自于众多不同的网络用户，具有很高的噪声和不确定性。

总之，互联网大数据多以非结构化的形式存储在互联网中，包括 Web 网页、电子邮件，文本文档和实时社交媒体数据。互联网大数据蕴藏着巨大的价值，将其应用到图书馆管理中可以有效地帮助图书馆管理者通过信息做出比较准确的判断，以便采取适当的行动。例如，通过对读者的借阅记录进行分析，挖掘用户的阅读偏好、推荐读者新书；在社交网络领域，分析读者的博文信息和转发信息，挖掘读者的行为偏好，从而为读者提供目标文献资源等。互联网大数据本身具有的特点决定了其本身隐藏的与众不同的价值，对互联网大数据进行有效的收集以及充分挖掘将成为许多行业扩展业务的新兴突破点。

对互联网大数据的收集，通常是通过网络爬虫技术进行的。网络爬虫也叫网页蜘蛛，是一种“自动化浏览网络”的程序，或者说是一种网络机器人。通俗地说，网络爬虫从指定的链接入口，按照某种策略从互联网中自动获取有用信息。

目前，网络爬虫广泛应用于互联网搜索引擎或其他类似网站中，以获取或更新这些网站的网页内容和检索方式。它们可以自动采集能够访问到的所有页面内容，以供搜索引擎做进一步处理（分拣、整理、索引下载到的页面），使得用户能更快地检索到需要的信息。

从网络爬虫的定义可知，网络爬虫开始于一张被称作种子的统一资源地址列表（也称URL 池或UBL 队列），将其作为抓取的链接入口。当网络爬虫访问这些网页时，识别出页面上所有的所需网页链接，并将它们加入“待爬队列”中。此后从“待爬队列”中取出网页链接按照一套策略循环访问，这样一直循环，直到“待爬队列”为空时爬虫程序停止运行。

一个通用的爬虫框架流程，由种子 URL 队列、待抓取 URL 队列、已抓取 URL 队列、下载网页库等构成。首先指定入口 URL，将其加入种子 URL 队列中；然后将种子 URL 加入待抓取URL 队列中、并从待抓取 URL 队列依次读取 URL，从互联网中下载URL 所链接的网页；接着将网页的 UHRL 保存到已抓取 URL 队列中，将网页信息保存到下载网页库中，从网页中抽取出需要抓取的新 URL并加入待抓取 URL 队列中；最后重复这个过程、直到待抓取 URL 队列为空。

按照系统结构和实现技术，互联网爬虫可以分为通用网络爬虫、聚焦网络爬虫、增量式网络爬虫和分布式网络爬虫。

通用网络爬虫又称全网爬虫，搜索引擎背后的数据采集工作大多是由通用爬虫来做的。这种爬虫追求大的爬行覆盖范围，对于在网页中提取到的超链接会“照单全收”，能够爬取到尽可能多的网站，获取到各式各样的信息。这类网络爬虫的爬行范围和数量巨大，对于爬行速度和存储空间要求较高，对于爬行页面的顺序要求相对较低，同时由于待刷新的页面太多，通常采用并行工作方式，但需要较长时间才能刷新一次页面。虽然存在一定缺陷，通用网络爬虫适用于为搜索引擎搜索广泛的主题，有较强的应用价值。为提高工作效率，通用网络爬虫会采取一定的爬行策略。常用的爬行策略有：深度优先策略、广度优先策略。

聚焦网络爬虫，又称主题网络爬虫，是指选择性地爬行那些与预先定义好的主题相关页面的网络爬虫。和通用网络爬虫相比，聚焦爬虫只需要爬行与主题相关的页面，极大地节省了硬件和网络资源，保存的页面也由于数量少而更新快，还可以很好地满足一些特定人群对特定领域信息的需求。聚焦网络爬虫和通用网络爬虫相比，增加了链接评价模块以及内容评价模块。聚焦爬虫爬行策略实现的关键是评价页面内容和链接的重要性，不同的方法计算出的重要性不同，由此导致链接的访问顺序也不同，常用算法包括基于内容评价的爬行策略、基于链接结构评价的爬行策略、基于增强学习的爬行策略以及基于语境图的爬行策略等算法。

增量式网络爬虫，增量式网络爬虫是指对已下载网页采取增量式更新，并只爬行新产生的或者已经发生变化网页的爬虫，它能够在一定程度上保证所爬行的页面是尽可能新的页面。与周期性爬行以及刷新页面的网络爬虫相比，增量式爬虫只会在需要的时候爬行新产生或发生更新的页面，并不重新下载没有发生变化的页面，可有效减少数据下载量。虽然可及时更新已爬行的网页，减小时间和空间上的耗费，但是增加了爬行算法的复杂度和实现难度。增量式爬虫的目标是保持本地页面集中存储的页面为最新页面以及提高集中页面的质量。增量式爬虫的网页排序策略包括广度优先策略、PageRank 优先策略等。

分布式网络爬虫，根据上述介绍，对于不同的网络爬虫方法，由于网页数量的增加以及网页中数据更新会直接影响到网络爬虫的计算复杂度和网络数据抓取效率。因此，在大数据应用场景下，使用分布式计算技术，将网络数据抓取并行化，已经成为一个必然的趋势。所谓分布式网络数据抓取，就是通过多个单机爬虫系统的有效协作和配合，实现互联网大数据的数据抓取。显然，分布式网络数据抓取至少涉及网络爬虫本身和分布式计算相关技术。总之，大数据时代互联网数据的采集是进行大数据分析和处理的前提，采集到的数据类型和质量对后续大数据的价值至关重要。网络大数据通常采用网络爬虫采集，因此开发网络爬虫来采集网络大数据显得尤为重要。目前已经有很多开源的网络爬虫技术，如 Nutch、Serapy、JSpider 等。

数据预处理是大数据处理中的重要一环，要使数据处理能挖掘出丰富的知识，就必须为它提供干净、准确、简洁的数据。然而实际应用系统中采集到的原始数据是“脏”的，不完全的、冗余的和模糊的，很少能直接满足数据分析中数据挖掘算法的要求。在海量数据中无意义的成分也很多，严重影响了算法的执行效率，其中的噪声干扰还会造成无效的归纳。因此，数据预处理已经成为大数据处理中的关键问题。

采集到的原始数据通常存在的问题如下：

第一，杂乱性：原始数据是从各个实际应用系统中获取的（多种数据库、多种文件系统），由于各应用系统的数据缺乏统一标准和定义，数据结构也有较大的差异，因此各系统间的数据存在较大的不一致性，往往不能直接拿来使用。

第二，重复性：对于同一个客观事物在数据库中存在两个或两个以上完全相同的物理描述。由于应用系统实际使用中存在的一些问题，几乎所有应用系统中都存在数据的重复和信息的冗余现象。

第三，不完整性：由于实际系统设计时存在的缺陷以及一些使用过程中人为因素所造成的影响，数据记录中可能会出现数据属性的值丢失或不确定的情况，还可能缺少必需的数据而造成数据不完整。实际使用的系统中，存在大量的模糊信息，有些数据设置还具有一定的随机性质。

2.4.3.4　数据预处理

一个完整的大数据处理系统必须包含数据预处理。它以发现任务作为目标，以领域知识作为指导，用全新的“业务模型”来组织原始数据，摈弃一些与目标不相关的属性，为大数据提供干净、准确、有针对性的数据，从而减少数据处理量，提高处理效率，提高知识发现的起点和知识的准确度。常用的数据预处理技术包括数据清理、数据集成、数据变化、数据规约等。数据清理主要是达到数据格式标准化、异常数据清理、数据错误纠正、重复数据的清除等目标。数据集成是将多个数据源中的数据结合起来并统一存储，建立数据仓库。数据变换是通过平滑聚集、数据概化、规范化等方式，将数据转换成适用于数据挖掘的形式。数据规约是指在对挖掘任务和数据本身内容理解的基础上，寻找依赖于发现目标数据的应用特征，以缩减数据规模，从而在尽可能保持数据原貌的前提下，最大限度地精简数据量。

除了上述数据预处理方法外，数据也会通过其他操作进行处理，例如，针对高维数据进行降维或特征选择和特征提取等。

事实上，基于不同数据集的考虑，建立一个统一的数据预处理过程和技术、使其适用于所有类型的数据集是不太可能的。因此，需要综合考虑数据的特征、数据分析的要求以及数据集的其他因素，然后选择合适的数据预处理策略。