3.2.1 数据抽取与集成
大数据的一个重要特点就是多样性，这就意味着数据来源极其广泛，数据类型极为繁杂。这种复杂的数据环境给大数据的处理带来极大的挑战。要想处理大数据，首先必须对所需数据源的数据进行抽取和集成，从中提取出关系和实体，经过关联和聚合之后采用统一定义的结构来存储这些数据。在数据集成和提取时需要对数据进行清洗，保证数据质量及可信性。同时还要特别注意前面提及的大数据时代模式和数据的关系，大数据时代的数据往往是先有数据再有模式，且模式是在不断的动态演化之中的。
数据抽取和集成技术不是一项全新的技术，传统数据库领域已对此问题有了比较成熟的研究。随着新的数据源的涌现，数据集成方法也在不断的发展之中。从数据集成模型来看，现有的数据抽取与集成方式可以大致分为以下四种类型：基于物化或是ETL 方法的引擎(Materialization or ETL engine)、基于联邦数据库或中间件方法的引擎(Federation engine orMediator)、基于数据流方法的引擎(Stream engine)及 基于搜索引擎的方法(Search engine)。
3.2.2 数据分析
数据分析是整个大数据处理流程的核心，因为大数据的价值产生于分析过程。从异构数据源抽取和集成的数据构成了数据分析的原始数据。根据不同应用的需求可以从这些数据中选择全部或部分进行分析。传统的分析技术如数据挖掘、机器学习、统计分析等在大数据时代需要做出调整，因为这些技术在大数据时代面临着一些新的挑战，主要有：
1、数据量大并不一定意味着数据价值的增加，相反这往往意味着数据噪音的增多。因此在数据分析之前必须进行数据清洗等预处理工作，但是预处理如此大量的数据对于机器硬件以及算法都是严峻的考验。
2、大数据时代的算法需要进行调整。首先大数据的应用常常具有实时性的特点，算法的准确率不再是大数据应用的最主要指标。很多场景中算法需要在处理的实时性和准确率之间取得一个平衡，比如在线的机器学习算法(online machine learning)。其次云计算是进行大数据处理的有力工具，这就要求很多算法必须做出调整以适应云计算的框架，算法需要变得具有可扩展性。最后在选择算法处理大数据时必须谨慎，当数据量增长到一定规模以后，可以从小量数据中挖掘出有效信息的算法并一定适用于大数据。统计学中的邦弗朗尼原理(Bonferroni’s Principle)就是一个典型的例子。
3、数据结果好坏的衡量。得到分析结果并不难，但是结果好坏的衡量却是大数据时代数据分析的新挑战。大数据时代的数据量大、类型庞杂，进行分析的时候往往对整个数据的分布特点掌握的不太清楚，这会导致最后在设计衡量的方法以及指标的时候遇到诸多困难。大数据分析已被广泛应用于诸多领域，典型的有推荐系统、商业智能、决策支持等。
3.2.3 数据解释
数据分析是大数据处理的核心，但是用户往往更关心结果的展示。如果分析的结果正确但是没有采用适当的解释方法，则所得到的结果很可能让用户难以理解，极端情况下甚至会误导用户。数据解释的方法很多，比较传统的就是以文本形式输出结果或者直接在电脑终端上显示结果。这种方法在面对小数据量时是一种很好的选择。但是大数据时代的数据分析结果往往也是海量的，同时结果之间的关联关系极其复杂，采用传统的解释方法基本不可行。
可以考虑从下面两个方面提升数据解释能力。
1、引入可视化技术。可视化作为解释大量数据最有效的手段之一率先被科学与工程计算领域采用。通过对分析结果的可视化用形象的方式向用户展示结果，而且图形化的方式比文字更易理解和接受。常见的可视化技术有标签云(Tag Cloud)、历史流(history flow)、空间信息流(Spatial information flow)等。可以根据具体的应用需要选择合适的可视化技术。
2、让用户能够在一定程度上了解和参与具体的分析过程。这个既可以采用人机交互技术，利用交互式的数据分析过程来引导用户逐步的进行分析，使得用户在得到结果的同时更好的理解分析结果的由来。也可以采用数据起源技术，通过该技术可以帮助追溯整个数据分析的过程，有助于用户理解结果。
4、关键技术分析
大数据价值的完整体现需要多种技术的协同。文件系统提供最底层存储能力的支持。为了便于数据管理，需要在文件系统之上建立数据库系统。通过索引等的构建，对外提供高效的数据查询等常用功能。最终通过数据分析技术从数据库中的大数据提取出有益的知识。
4.1 云计算：大数据的基础平台与支撑技术
如果将各种大数据的应用比作一辆辆“汽车”的话，支撑起这些“汽车”运行的“高速公路”就是云计算。正是云计算技术在数据存储、管理与分析等方面的支撑，才使得大数据有用武之地。
在所有的“高速公路”中，Google 无疑是技术最为先进的一个。需求推动创新，面对海量的Web 数据， Google 于2006 年首先提出了云计算的概念。支撑Google 内部各种大数据应用的正是其自行研发的一系列云计算技术和工具。难能可贵的是Google 并未将这些技术完全封闭，而是以论文的形式逐步公开其实现。正是这些公开的论文，使得以GFS、MapReduce、Bigtable 为代表的一系列大数据处理技术被广泛了解并得到应用，同时还催生出以Hadoop为代表的一系列云计算开源工具。云计算技术很多，但是通过Google 云计算技术的介绍能够快速、完整的把握云计算技术的核心和精髓。本节以Google 的相关技术介绍为主线，详细介绍Google 以及其他众多学者和研究机构在大数据技术方面已有的一些工作。根据Google 已公开的论文及相关资料，结合大数据处理的需求，我们对Google 的技术演化进行了整理，如图4所示：
图 4 Google 技术演化图
4.1.1 文件系统
文件系统是支撑上层应用的基础。在Google 之前，尚未有哪个公司面对过如此多的海量数据。因此对于Google 而言并没有完全成熟的存储方案可以直接使用。Google 认为系统组件失败是一种常态而不是异常，基于此思想Google 自行设计开发了Google 文件系统GFS(Google File System)。GFS 是构建在大量廉价服务器之上的一个可扩展的分布式文件系统，GFS 主要针对文件较大，且读远大于写的应用场景，采用主从(Master-Slave)结构。通过数据分块、追加更新(Append-Only)等方式实现了海量数据的高效存储。随着时间推移，GFS 的架构逐渐开始无法适应需求。Google 对GFS 进行了重新的设计，该系统正式的名称为Colosuss，具体实现尚未公开，但是从ACM 对GFS 团队核心工程师的访谈可以了解其一些新的特性。其中GFS 的单点故障(指仅有一个主节点容易成为系统的瓶颈)、海量小文件的存储等问题在Colosuss 中均得到了解决。
除了Google，众多企业和学者也从不同方面对满足大数据存储需求的文件系统进行了详尽的研究。微软自行开发的Cosmos支撑着其搜索、广告等业务。HDFS和CloudStore都是模仿GFS 的开源实现。GFS 类的文件系统主要是针对较大文件设计的，而在图片存储等应用场景，文件系统主要存储海量小文件，此时GFS 等文件系统因为频繁读取元数据等原因，效率很低。针对这种情况，Facebook 推出了专门针对海量小文件的文件系统Haystack，通过多个逻辑文件共享同一个物理文件、增加缓存层、部分元数据加载到内存等方式有效的解决了Facebook 海量图片存储问题。淘宝推出了类似的文件系统TFS(Tao File System)，通过将小文件合并成大文件、文件名隐含部分元数据等方式实现了海量小文件的高效存储。FastDFS针对小文件的优化类似于TFS。
4.1.2 数据库系统
原始的数据存储在文件系统之中，但是用户习惯通过数据库系统来存取文件。因为这样会屏蔽掉底层的细节，且方便数据管理。直接采用关系模型的分布式数据库并不能适应大数据时代的数据存储，主要因为：
1)规模效应所带来的压力。大数据时代的数据量远远超过单机所能容纳的数据量，因此必须采用分布式存储的方式。这就需要系统具有很好的扩展性，但这恰恰是传统数据库的弱势之一。因为传统的数据库产品对于性能的扩展更倾向于Scale-Up(纵向扩展)的方式，而这种方式对于性能的增加速度远低于需要处理数据的增长速度，且性能提升存在上限。适应大数据的数据库系统应当具有良好的Scale-Out(横向扩展)能力，而这种性能扩展方式恰恰是传统数据库所不具备的。即便是性能最好的并行数据库产品其Scale-Out 能力也相对有限。
2)数据类型的多样化。传统的数据库比较适合结构化数据的存储，但是数据的多样性是大数据时代的显著特征之一。这也就是意味着除了结构化数据，半结构化和非结构化数据也将是大数据时代的重要数据类型组成部分。如何高效的处理多种数据类型是大数据时代数据库技术面临的重要挑战之一。
3)设计理念的冲突。关系数据库追求的是“One size fits all”的目标，希望将用户从繁杂的数据管理中解脱出来，在面对不同的问题时不需要重新考虑数据管理问题，从而可以将重心转向其他的部分。但在大数据时代不同的应用领域在数据类型、数据处理方式以及数据处理时间的要求上有极大的差异。在实际的处理中几乎不可能有一种统一的数据存储方式能够应对所有场景。比如对于海量Web 数据的处理就不可能和天文图像数据采取同样的处理方式。在这种情况下，很多公司开始尝试从“One size fits one”和“One size fits domain”的设计理念出发来研究新的数据管理方式，并产生了一系列非常有代表性的工作。
4)数据库事务特性。众所周知关系数据库中事务的正确执行必须满足ACID 特性，即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability)。对于数据强一致性的严格要求使其在很多大数据场景中无法应用。这种情况下出现了新的BASE 特性，即只要求满足Basically Available(基本可用), Soft state(柔性状态)和 Eventually consistent(最终一致)。从分布式领域著名的CAP 理论的角度来看，ACID 追求一致性C，而BASE更加关注可用性A。正是在事务处理过程中对于ACID 特性的严格要求，使得关系型数据库的可扩展性极其有限。
面对这些挑战，以Google 为代表的一批技术公司纷纷推出了自己的解决方案。Bigtable是Google 早期开发的数据库系统，它是一个多维稀疏排序表，由行和列组成，每个存储单元都有一个时间戳，形成三维结构。不同的时间对同一个数据单元的多个操作形成的数据的多个版本之间由时间戳来区分。除了Bigtable，Amazon 的Dynamo和Yahoo 的PNUTS也都是非常具有代表性的系统。Dynamo 综合使用了键/值存储、改进的分布式哈希表(DHT)、向量时钟(Vector Clock)等技术实现了一个完全的分布式、去中心化的高可用系统。PNUTS是一个分布式的数据库，在设计上使用弱一致性来达到高可用性的目标，主要的服务对象是相对较小的记录，比如在线的大量单个记录或者小范围记录集合的读和写访问。不适合存储大文件、流媒体等。Bigtable、Dynamo、PNUTS 等的成功促使人们开始对关系数据库进行反思，由此产生了一批未采用关系模型的数据库，这些方案现在被统一的称为NoSQL(NotOnly SQL)。NoSQL 并没有一个准确的定义，但一般认为NoSQL 数据库应当具有以下的特征：模式自由(schema-free)、支持简易备份(easy replication support)、简单的应用程序接口(simple API)、最终一致性(或者说支持BASE 特性，不支持ACID)、支持海量数据(Huge amountof data)。NoSQL 和关系型数据库的简单比较如表3 所示：
表3 NoSQL 数据库和关系数据库的对比
典型的NoSQL 数据库分类如表4所示：
表4 典型NoSQL 数据库
Bigtable 的模型简单，但是相较传统的关系数据库其支持的功能非常有限，不支持ACID特性。因此Google 开发了Megastore]系统，虽然其底层数据存储依赖Bigtable，但是它实现了类似RDBMS 的数据模型，同时提供数据的强一致性解决方案。Megastore 将数据进行细粒度的分区，数据更新会在机房间进行同步复制。Spanner是已知的Google 的最新的数据库系统，Google 在OSDI2012 上公开了Spanner 的实现。Spanner 是第一个可以实现全球规模扩展(Global Scale)并且支持外部一致的事务(support externally-consistent distributedtransactions)的数据库。通过GPS 和原子时钟(atomic clocks)技术，Spanner 实现了一个时间API。借助该API，数据中心之间的时间同步能够精确到10ms 以内。Spanner 类似于Bigtable，但是它具有层次性的目录结构以及细粒度的数据复制。对于数据中心之间不同操作会分别支持强一致性或弱一致性，且支持更多的自动操作。Spanner 的目标是控制一百万到一千万台服务器，最多包含大约10万亿目录和一千万亿字节的存储空间。另外在SIGMOD2012上，Google 公开了用于其广告系统的新数据库产品F1，作为一种混合型数据库F1 融合兼有Bigtable的高扩展性以及SQL数据库的可用性和功能性。该产品的底层存储正是采用Spanner，具有很多新的特性，包括全局分布式、同步跨数据中心复制、可视分片和数据移动、常规事务等。
有些比较激进的观点认为“关系数据库已死”，我们认为关系数据库和NoSQL 并不是矛盾的对立体，而是可以相互补充的、适用于不同应用场景的技术。例如实际的互联网系统往往都是ACID 和BASE 两种系统的结合。近些年来，以Spanner 为代表的若干新型数据库的出现，给数据存储带来了SQL、NoSQL 之外的新思路。这种融合了一致性和可用性的NewSQL 或许会是未来大数据存储新的发展方向。
4.1.3 索引与查询技术
数据查询是数据库最重要的应用之一。而索引则是解决数据查询问题的有效方案。就Google 自身而言，索引的构建是提供搜索服务的关键部分。Google 最早的索引系统是利用MapReduce 来更新的。根据更新频率进行层次划分，不同的层次对应不同的更新频率。每次需要批量更新索引，即使有些数据并未改变也需要处理掉。这种索引更新方式效率较低。随后Google 提出了Percolator，这是一种增量式的索引更新器，每次更新不需要替换所有的索引数据，效率大大提高。虽然不是所有的大数据应用都需要索引，但是这种增量计算的思想非常值得我们借鉴。Google 当前正在使用的索引系统为Caffeine，其具体实现尚未公布。但是可以确定Caffeine 是构建在Spanner 之上，采用Percolator 更新索引。效率相较上一代索引系统而言有大幅度提高。
关系数据库也是利用对数据构建索引的方式较好的解决了数据查询的问题。不同的索引方案使得关系数据库可以满足不同场景的要求。索引的建立以及更新都会耗费较多的时间，在面对传统数据库的小数据量时这些时间和其所带来的查询便利性相比是可以接受的，但是这些复杂的索引方案基本无法直接应用到大数据之上。表5是对一些索引方案直接应用在Facebook 上的性能估计：
表5 查询索引的案例
从上表可以看出不太可能将已有的成熟索引方案直接应用于大数据。NoSQL 数据库针对主键的查询效率一般较高，因此有关的研究集中在NoSQL 数据库的多值查询优化上。针对NoSQL 数据库上的查询优化研究主要有两种思路：
1、采用MapReduce 并行技术优化多值查询：当利用MapReduce 并行查询NoSQL 数据库时，每个MapTask 处理一部分的查询操作，通过实现多个部分之间的并行查询来提高多值查询的效率。此时每个部分的内部仍旧需要进行数据的全扫描。
2、采用索引技术优化多值查询：很多的研究工作尝试从添加多维索引的角度来加速NoSQL 数据库的查询速度。表6 列举了已有的一些解决方案的对比。
表6 采用索引加速多值查询的方案对比
ITHbase、IHbase、CCIndex和Asynchronous views是典型的采用多个一维二级索引来加速多值查询优化的实现方案。其中ITHbase 和IHbase 是两个开源的实现方案，ITHbase 主要关注于数据一致性，事务性是其重要特性。IHbase与ITHbase类似，从HBase 源码级别进行了扩展，重新定义和实现了Server、Client 端处理逻辑。CCIndex (ComplementalClustering Index)是中科院提出的另外一种索引结构，它在索引中既存储索引项，也存储记录的其他列的数据，以便在查询的时候直接在索引表中通过顺序扫描找到相应的数据，大幅度减少查询时间。该方法本质是以空间代价来换取查询效率。CCIndex 的索引更新代价比较高，会影响系统的吞吐量。索引创建以后，不能够动态增加或修改。Asynchronous views 以异步视图的方式来实现非主键的查询，提出了两种视图方案：远端视图表(Remote ViewTables: RVTs)和局部视图表(Local View Tables: LVTs)。
RT-CAN采用多维索引加速多值查询。其局部索引采用R-tree，全局索引中采用了能够支持多维查询的CAN覆盖网络。QT-Chord是另一种双层索引结构，它的局部索引采用的是改进的四叉树IMX-CIF quad-tree，全局索引采用的Chord 覆盖网络。EMINC[56]针对每个局部节点建立一个KD-tree，然后选择KD-tree 的部分节点作为全局索引。每一个局部索引节点被看成是一个多个维度组成的立方体，然后在全局索引中用R-tree 对这些立方体进行索引。A-Tree提出了另外一种方案。基本思路是：针对每一个存储节点构建R-tree，同时创建一个Bloom filter(布隆过滤器)。这样在进行点查询的时候，首先通过Bloom filter进行验证，如果查询点不在其中，则不再进行R-tree 查询，否则继续进行R-tree查询。
MD-HBase提出一种基于空间目标排序的索引方案。基于空间目标排序的索引方法的基本思想是：按照一定规则将覆盖整个研究区的范围划分为大小相等的格子，并给每一格网分配一个编号，用这些编号为空间目标生成一组具有代表意义的数字。其实质是将k 维空间的实体映射到一维空间，因此可以利用现有数据库管理系统中比较成熟的一维索引技术。UQE-Index主要针对海量物联网应用场景的时空特性，在时间维度上把数据分成当前数据和历史数据，对当前数据和历史数据进行不同粒度的索引，对当前数据，在时间段和子空间上进行索引，从而减少索引更新的次数，降低索引维护的代价，提高系统的吞吐量；对历史数据，批量地建立记录级别的索引；在建立子空间索引时，为了确保数据分布均匀，采用KD Tree进行动态划分。但是如果所有的数据都需要经过KD Tree来索引的话，也会带来较高的代价，会影响数据的插入速度，因此，可以对数据进行采样，对采样得到的数据利用KD Tree进行索引，从而得到空间上的划分方案。
就已有方案来看，针对NoSQL 数据库上的查询优化技术都并不成熟，仍有很多关键性问题亟待解决。
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：大数据管理：概念、技术与挑战（中）
相关文章
