１ 引言
最近几年，数据仓库又成为数据管理研究的热点领域，主要原因是当前数据仓库系统面临的需求在数据源、需提供的数据服务和所处的硬件环境等方面发生了根本性的变化（详见１．１节），这些变化是我们必须面对的。
本文在大数据的时代背景下，对现有数据仓库系统实现方案（主要是并行数据库和ＭａｐＲｅｄｕｃｅ）进行重新审视，期望能为设计满足时代需求的数据仓库系统提供理论参考，限于篇幅，本文主要关注不同数据仓库实现方案的主体架构及其缺陷在最近几年的改进情况，依据研究立足点的不同，本文将该领域的研究归为三大类：并行数据库、ＭａｐＲｅｄｕｃｅ、并行数据库和ＭａｐＲｅｄｕｃｅ技术的混合架构，其中第三类研究又细分为：并行数据库主导型、ＭａｐＲｅｄｕｃｅ主导型、并行数据库和ＭａｐＲｅｄｕｃｅ集成型三种，文第１节分析大数据时代，数据仓库所面临的问题及挑战；第２节列出大数据时代的数据仓库平台需具备的几个重要特性；第３节到第５节就这几个特性对各类平台进行归纳分析；第６节对最新研究做一跟踪归纳；第７节介绍中国人民大学在大数据分析方面的研究工作；第８节对未来研究做出展望；第９节总结全文。
１．１ 三个变化
（１）数据量。由ＴＢ级升至ＰＢ级，并仍在持续爆炸式增长，根据ＷｉｎｔｅｒＣｏｒｐ的调查显示，最大的数据仓库中的数据量，每两年增加３倍［１］（年均增长率为１７３％），其增长速度远超摩尔定律增长速度，照此增长速度计算，２０１５年最大数据仓库中的数据量将逼近１００ＰＢ。
（２）分析需求。由常规分析转向深度分析（ＤｅｅｐＡｎａｌｙｔｉｃｓ），数据分析日益成为企业利润必不可少的支撑点，根据ＴＤＷＩ对大数据分析的报告（如图１），企业已经不满足于对现有数据的分析和监测，而是更期望能对未来趋势有更多的分析和预测，以增强企业竞争力，这些分析操作包括诸如移动平均线分析、数据关联关系分析、回归分析、市场篮分析等复杂统计分析，我们称之为深度分析，值得补充的是，本文中的大数据分析不仅仅指基于大数据上的深度分析，也包括常规分析。
图１ 分析的趋势
（３）硬件平台。由高端服务器转向由中低端硬件构成的大规模机群平台，由于数据量的迅速增加，并行数据库的规模不得不随之增大，从而导致其成本的急剧上升，出于成本的考虑，越来越多的企业将应用由高端服务器转向了由中低端硬件构成的大规模机群平台。
１.２ 两个问题
图２是一个典型的数据仓库架构，从图中我们可以看出，传统的数据仓库将整个实现划分为４个层次，数据源中的数据首先通过ＥＴＬ工具被抽取到数据仓库中进行集中存储和管理，再按照星型模型或雪花模型组织数据，然后ＯＬＡＰ工具从数据仓库中读取数据，生成数据立方体（ＭＯＬＡＰ）或者直接访问数据仓库进行数据分析（ＲＯＬＡＰ），在大数据时代，此种计算模式存在两个问题：
问题１，数据移动代价过高，在数据源层和分析层之间引入一个存储管理层，可以提升数据质量并针对查询进行优化，但也付出了较大的数据迁移代价和执行时的连接代价：数据首先通过复杂且耗时的ＥＴＬ过程存储到数据仓库中，在ＯＬＡＰ服务器中转化为星型模型或者雪花模型；执行分析时，又通过连接方式将数据从数据库中取出，这些代价在ＴＢ级时也许可以接受，但面对大数据，其执行时间至少会增长几个数量级，更为重要的是，对于大量的即席分析，这种数据移动的计算模式是不可取的。
图２ 一个典型的数据仓库架构
问题２，不能快速适应变化，传统的数据仓库假设主题是较少变化的，其应对变化的方式是对数据源到前端展现的整个流程中的每个部分进行修改，然后再重新加载数据，甚至重新计算数据，导致其适应变化的周期较长，这种模式比较适合对数据质量和查询性能要求较高、而不太计较预处理代价的场合，但在大数据时代，分析处在变化的业务环境中，这种模式将难以适应新的需求。
１．３ 一个鸿沟
在大数据时代，巨量数据与系统的数据处理能力之间将会产生一个鸿沟：一边是至少ＰＢ级的数据量，另一边是面向传统数据分析能力设计的数据仓库和各种ＢＩ工具，如果这些系统或工具发展缓慢，该鸿沟将会随着数据量的持续爆炸式增长而逐步拉大。
虽然，传统数据仓库可以采用舍弃不重要数据或者建立数据集市的方式来缓解此问题，但毕竟只是权益之策，并非系统级解决方案，而且，舍弃的数据在未来可能会重新使用，以发掘更大的价值。
２ 期望特性
本节我们列出对大数据进行分析时，数据仓库系统需具备的几个重要特性（表１所示）。
表１ 大数据分析平台需具备的特性
高度可扩展性，一个明显的事实是，数据库不能依靠一台或少数几台机器的升级（ｓｃａｌｅｕｐ纵向扩展）满足数据量的爆炸式增长，而是希望能方便地做到横向可扩展（ｓｃａｌｅｏｕｔ）来实现此目标，普遍认为ｓｈａｒｅｄｎｏｔｈｉｎｇ无共享结构（每个节点拥有私有内存和磁盘，并且通过高速网络同其它节点互连）具备较好的扩展性，分析型操作往往涉及大规模的并行扫描、多维聚集及星型连接操作，这些操作也比较适合在无共享结构的网络环境运行，Ｔｅｒａｄａｔａ即采用此结构，Ｏｒａｃｌｅ在其新产品Ｅｘａｄａｔａ中也采用了此结构。
高性能，数据量的增长并没有降低对数据库性能的要求，反而有所提高，软件系统性能的提升可以降低企业对硬件的投入成本、节省计算资源，提高系统吞吐量，巨量数据的效率优化，并行是必由之路，１ＰＢ数据在５０ＭＢ／ｓ速度下串行扫描一次，需要２３０天；而在６０００块磁盘上，并行扫描１ＰＢ数据只需要１个小时。
高度容错，大数据的容错性要求在查询执行过程中，一个参与节点失效时，不需要重做整个查询，而机群节点数的增加会带来节点失效概率的增加，在大规模机群环境下，节点的失效将不再是稀有事件（Ｇｏｏｇｌｅ报告，平均每个ＭａｐＲｅｄｕｃｅ数据处理任务就有１.２个工作节点失效），因此在大规模机群环境下，系统不能依赖于硬件来保证容错性，要更多地考虑软件级容错。
支持异构环境，建设同构系统的大规模机群难度较大，原因在于计算机硬件更新较快，一次性购置大量同构的计算机是不可取的，而且也会在未来添置异构计算资源，此外，不少企业已经积累了一些闲置的计算机资源，此种情况下，对异构环境的支持可以有效地利用这些闲置计算资源，降低硬件成本的投入，还需特别关注的是，在异构环境下，不同节点的性能是不一样的，可能出现“木桶效应”，即最慢节点的性能决定整体处理性能，因此，异构的机群需要特别关注负载均衡、任务调度等方面的设计。
较低的分析延迟，分析延迟指的是分析前的数据准备时间，在大数据时代，分析所处的业务环境是变化的，因此也要求系统能动态地适应业务分析需求，在分析需求发生变化时，减少数据准备时间，系统能尽可能快地做出反应，快速地进行数据分析。
易用且开放的接口，ＳＱＬ的优点是简单易用，但其主要用于数据的检索查询，对于大数据上的深度分析来讲，是不够的，原因在于：（１）其提供的服务方式依赖于数据移动来实现：将数据从数据库中取出，然后传递给应用程序，该实现方式在大数据时代代价过高；（２）复杂的分析功能，如Ｒ或Ｍａｔｌａｂ中的分析功能，ＳＱＬ是难以胜任的，因此，除对ＳＱＬ的支持外，系统还应能提供开放的接口，让用户自己开发需要的功能，设计该接口时，除了关注其易用性和开放性，还需要特别注意两点隐藏的要求：（１）基于接口开发的用户自定义函数，能自动在机群上并行执行；（２）分析在数据库内进行，即分析尽可能靠近数据。
较低的成本，在满足需求的前提下，某技术成本越低，其生命力就越强，需要指出的是成本是一个综合指标，不仅仅是硬件或软件的代价，还应包括日常运维成本（网络费用、电费、建筑等）和管理人员成本等，据报告，数据中心的主要成本不是硬件的购置成本，而是日常运维成本，因此，在设计系统时需要更多地关注此项内容。
向下兼容性，数据仓库发展的３０年，产生了大量面向客户业务的数据处理工具（如Ｉｎｆｏｒｍａｃｔｉｃａ、ＤａｔａＳｔａｇｅ等）、分析软件（如ＳＰＳＳ、Ｒ、Ｍａｔｌａｂ等）和前端展现工具（如水晶报表）等，这些软件是一笔宝贵的财富，已被分析人员所熟悉，是大数据时代中小规模数据分析的必要补充，因此，新的数据仓库需考虑同传统商务智能工具的兼容性，由于这些系统往往提供标准驱动程序，如ＯＤＢＣ、ＪＤＢＣ等，这项需求的实际要求是对ＳＱＬ的支持。
总之，以较低的成本投入、高效地进行数据分析，是大数据分析的基本目标。
３ 并行数据库
并行数据库起源于２０世纪８０年代，当前主流的并行数据库都同早期的Ｇａｍｍａ和Ｇｒａｃｅ等并行数据库类似，这些数据库都支持标准ＳＱＬ，并且实现了数据库界过去３０年提出的许多先进技术，其主要采用ｓｈａｒｅｄｎｏｔｈｉｎｇ结构，将关系表在节点间横向划分，并且利用优化器来对执行过程进行调度和管理，其目标是高性能和高可用性。
并行数据库的最大优势在于性能，这主要得益于数据库界近几十年的研究成果———许多先进的技术手段及算法，如索引、数据压缩、物化视图、结果缓冲、Ｉ／Ｏ共享、优化的数据连接等，但是在大数据时代，如前言所述，数据移动的实现方式将影响其性能。
并行数据库通过ＳＱＬ向外提供数据访问服务，ＳＱＬ因其简单易用的特点而被广泛使用，因此，大多ＢＩ工具都支持基于标准ＳＱＬ的数据交互方式，使得关系数据库能较好地兼容当前多数ＢＩ工具，某些数据库，如ＩＢＭＤＢ２还针对一些ＢＩ工具进行了优化，但在大数据分析面前，ＳＱＬ接口面临巨大挑战，ＳＱＬ的优势源于其对底层数据访问的封装，但封装在一定程度上影响了其开放性，而且并行数据库提供的用户自定义函数大都是基于单数据库实例设计的，从而不能在机群上并行执行，也即意味着传统的实现方式不适合大数据的处理及分析，而且，在并行数据库中实现用户自定义函数往往需要经过复杂的系统交互，甚至要熟悉数据库的内部结构及系统调用等，从而难以使用。
并行数据库在扩展性、容错性、成本、对异构环境的支持等几项上有所欠缺，这几项实际是相互影响的，我们以其最大问题———扩展性为主线展开讨论，并行数据库大多支持有限扩展，一般可扩至数百节点的规模，尚未有数千节点规模的应用案例，并行数据库扩展性有限主要因为如下几点：（１）并行数据库软件级容错能力较差，并行数据库基于高端硬件设计，并且假设查询失败属于稀有事件，因此当查询失败时，一般采取重做查询的方式，而在大规模机群环境下，查询失败将会变为一个普通事件，极端情况下，并行数据有可能出现不停重做查询的局面；（２）并行数据库对异构硬件的支持非常有限，且对于处理较慢的节点反应敏感，容易出现“木桶效应”，如第２节中所论述的，完全基于同构硬件搭建大规模机群在现实中是较难实现的，因而，对异构硬件的支持能力影响了其扩展性；（３）并行数据库若做到大规模可扩展，其代价将会较高（需基于高端硬件来保证可靠性，需购买昂贵的软件系统），从而限制了其扩展性；（４）根据ＣＡＰ理论①，在分布式系统中，数据一致性（Ｃｏｎｓｉｓｔｅｎｃｙ）、可用性（Ａｖａｉｌａｂｉｌｉｔｙ）、子网可分解性（ＮｅｔｗｏｒｋＰａｒｔｉｔｉｏｎｉｎｇ）不可同时兼得，选择其中任两项，便会损害另一项，并行数据库追求的是数据一致性和系统的可用性，从而影响了它的扩展能力。
此外，如１.２节所讨论的，基于并行数据库实现的传统数据仓库借助于外围工具（ＥＴＬ工具、ＯＬＡＰ产品、ＢＩ报表工具、统计分析软件等）来完成数据的预处理和分析展现任务，导致其数据处理及分析过程涉及大量的数据迁移和计算，分析延迟往往较高。
４MapReduce
ＭａｐＲｅｄｕｃｅ是２００４年由Ｇｏｏｇｌｅ提出的面向大数据集处理的编程模型，起初主要用作互联网数据的处理，例如文档抓取、倒排索引的建立等，但由于其简单而强大的数据处理接口和对大规模并行执行、容错及负载均衡等实现细节的隐藏，该技术一经推出便迅速在机器学习、数据挖掘、数据分析等领域得到广泛应用。
ＭａｐＲｅｄｕｃｅ将数据处理任务抽象为一系列的Ｍａｐ（映射）Ｒｅｄｕｃｅ（化简）操作对，Ｍａｐ主要完成数据的过滤操作，Ｒｅｄｕｃｅ主要完成数据的聚集操作，输入输出数据均以〈ｋｅｙ，ｖａｌｕｅ〉格式存储，用户在使用该编程模型时，只需按照自己熟悉的语言实现Ｍａｐ函数和Ｒｅｄｕｃｅ函即可，ＭａｐＲｅｄｕｃｅ框架会自动对任务进行划分以做到并行执行。
下面本文将以基于ＭａｐＲｅｄｕｃｅ的开源实现Ｈａｄｏｏｐ为主，对其主要特性进行介绍。
ＭａｐＲｅｄｕｃｅ是面向由数千台中低端计算机组成的大规模机群而设计的，其扩展能力得益于其ｓｈａｒｅｄｎｏｔｈｉｎｇ结构、各个节点间的松耦合性和较强的软件级容错能力：节点可以被任意地从机群中移除，而几乎不影响现有任务的执行，该技术被称为ＲＡＩＮ（Ｒｅｄｕｎｄａｎｔ／ＲｅｌｉａｂｌｅＡｒｒａｙｏｆＩｎｄｅｐｅｎｄｅｎｔ（ａｎｄＩｎｅｘｐｅｎｓｉｖｅ）Ｎｏｄｅｓ），ＭａｐＲｅｄｕｃｅ卓越的扩展能力已在工业界（Ｇｏｏｇｌｅ、Ｆａｃｅｂｏｏｋ、Ｂａｉｄｕ、Ｔａｏｂ等）得到了充分验证，ＭａｐＲｅｄｕｃｅ对硬件的要求较低，可以基于异构的廉价硬件来搭建机群，且免费开源，因此其构建成本低于并行数据库，但基于ＭａｐＲｅｄｕｃｅ的应用软件相对较少，许多数据分析功能需要用户自行开发，从而会导致使用成本的增加。
作为开源系统，ＭａｐＲｅｄｕｃｅ具有完全的开放性：其〈ｋｅｙ，ｖａｌｕｅ〉存储模型具有较强的表现力，可以存储任意格式的数据；Ｍａｐ和Ｒｅｄｕｃｅ两个基本的函数接口也给用户提供了足够的发挥空间，可以实现各种复杂的数据处理功能，但这种开放性也带来一个问题，就是将本来应由数据库管理系统完成的工作，诸如文件存储格式的设计、模式信息的记录、数据处理算法的实现等，转移给了程序员，从而导致程序员负担过重，程序员水平对系统处理性能起决定性作用，在某些情况下，写ＭａｐＲｅｄｕｃｅ程序的时间远大于写ＳＱＬ语句的时间，部分复杂的ＢＩ报表分析，可能仅程序的编写和调试就要耗费几天的时间。
基于ＭａｐＲｅｄｕｃｅ平台的分析，无需复杂的数据预处理和写入数据库的过程，而是可以直接基于平面文件进行分析，并且其采用的计算模式是移动计算而非移动数据，因此可以将分析延迟最小化。
在同等硬件条件下，ＭａｐＲｅｄｕｃｅ性能远低于并行数据库，这是由其最初的设计定位决定的，ＭａｐＲｅｄｕｃｅ的设计初衷是面向非结构化数据的处理，这些数据具有数据量大，处理复杂等特点，而且往往是一次性处理，为了获得较好的扩展能力和容错能力，ＭａｐＲｅｄｕｃｅ采取了基于扫描的处理模式和对中间结果步步物化的执行策略，从而导致较高的Ｉ／Ｏ代价，为了减少数据预处理时间，ＭａｐＲｅｄｕｃｅ没有使用模式、索引、物化视图等技术手段，其数据预处理仅是一次数据加载操作，但由此导致了一个问题———较高的元组解析代价。ＭａｐＲｅｄｕｃｅ环境下，每个查询都是直接从文件系统中读入原始数据文件，而非传统的从数据库中读入经处理过的文件，因此其元组解析代价远高于关系数据库，对数据分析领域来说，连接是关键操作（如传统的星型查询和雪花查询均是依赖于连接来处理查询），但ＭａｐＲｅｄｕｃｅ处理连接的性能尤其不尽如人意，原因在于ＭａｐＲｅｄｕｃｅ最初是针对单数据集设计的处理模型，而连接操作往往涉及多个数据集，在利用ＭａｐＲｅｄｕｃｅ实现连接时，最直接的方式是每个任务执行一个属性上的连接操作，然后将多个ＭａｐＲｅｄｕｃｅ任务通过物化的中间结果串接起来，这种实现方式往往涉及中间结果的读写，从而导致大量的Ｉ／Ｏ操作和网络传输。
ＭａｐＲｅｄｕｃｅ目前基本不兼容现有的ＢＩ工具，原因在于其初衷并不是要成为数据库系统，因此它并未提供ＳＱＬ接口，但已有研究致力于ＳＱＬ语句与ＭａｐＲｅｄｕｃｅ任务的转换工作（例如Ｈｉｖｅ），进而有可能实现ＭａｐＲｅｄｕｃｅ与现存ＢＩ工具的兼容。
５ 并行数据库和ＭａｐＲｅｄｕｃｅ的混合架构
基于以上分析，我们可以清楚地看出，基于并行数据库和ＭａｐＲｅｄｕｃｅ实现的数据仓库系统都不是大数据分析的理想方案，针对两者哪个更适合时代需求的问题，业界近年展开了激烈争论，当前基本达成如下共识：并行数据库和ＭａｐＲｅｄｕｃｅ是互补关系，应该相互学习，基于该观点，大量研究着手将两者结合起来，期望设计出兼具两者优点的数据分析平台，这种架构又可以分为三类：并行数据库主导型、ＭａｐＲｅｄｕｃｅ主导型、ＭａｐＲｅｄｕｃｅ和并行数据库集成型（表２对３种架构进行了对比分析）。
表２ 混合架构型解决方案对比分析
５．１ 并行数据库主导型
该种方式关注于如何利用ＭａｐＲｅｄｕｃｅ来增强并行数据库的数据处理能力，代表性系统是Ｇｒｅｅｎｐｌｕｍ（已被ＥＭＣ收购）和ＡｓｔｅｒＤａｔａ（已被Ｔｅｒａｄａｔａ收购），ＡｓｔｅｒＤａｔａ将ＳＱＬ和ＭａｐＲｅｄｕｃｅ进行结合，针对大数据分析提出了ＳＱＬ／ＭａｐＲｅｄｕｃｅ框架。
该框架允许用户使用Ｃ＋＋、ｊａｖａ、Ｐｙｔｈｏｎ等语言编写ＭａｐＲｅｄｕｃｅ函数，编写的函数可以作为一个子查询在ＳＱＬ中使用，从而同时获得ＳＱＬ的易用性和ＭａｐＲｅｄｕｃｅ的开放性，不仅如此，ＡｓｔｅｒＤａｔａ基于ＭａｐＲｅｄｕｃｅ实现了３０多个统计软件包，从而将数据分析推向数据库内进行（数据库内分析），大大提升了数据分析的性能。
Ｇｒｅｅｎｐｌｕｍ也在其数据库中引入了ＭａｐＲｅｄｕｃｅ处理功能，其执行引擎可以同时处理ＳＱＬ查询和ＭａｐＲｅｄｕｃｅ任务，这种方式在代码级整合了ＳＱＬ和ＭａｐＲｅｄｕｃｅ：ＳＱＬ可以直接使用ＭａｐＲｅｄｕｃｅ任务的输出，同时ＭａｐＲｅｄｕｃｅ任务也可以使用ＳＱＬ的查询结果作为输入。
总的来说，这些系统都集中于利用ＭａｐＲｅｄｕｃｅ来改进并行数据库的数据处理功能，其根本性问题———可扩展能力和容错能力并未改变。
５．２ＭａｐＲｅｄｕｃｅ主导型
该方向的研究主要集中于利用关系数据库的ＳＱＬ接口和对模式的支持等技术来改善ＭａｐＲｅｄｕｃｅ的易用性，代表系统是Ｈｉｖｅ、ＰｉｇＬａｔｉｎ等。
Ｈｉｖｅ是Ｆａｃｅｂｏｏｋ提出的基于Ｈａｄｏｏｐ的大型数据仓库，其目标是简化Ｈａｄｏｏｐ上的数据聚集、ａｄｈｏｃ查询及大数据集的分析等操作，以减轻程序员的负担，它借鉴关系数据库的模式管理、ＳＱＬ接口等技术，把结构化的数据文件映射为数据库表，提供类似于ＳＱＬ的描述性语言ＨｉｖｅＱＬ供程序员使用，可自动将ＨｉｖｅＱＬ语句解析成一优化的ＭａｐＲｅｄｕｃｅ任务执行序列，此外，它也支持用户自定义的ＭａｐＲｅｄｕｃｅ函数。
ＰｉｇＬａｔｉｎ是Ｙａｈｏｏ！提出的类似于Ｈｉｖｅ的大数据集分析平台，两者的区别主要在于语言接口。
Ｈｉｖｅ提供了类似ＳＱＬ的接口，ＰｉｇＬａｔｉｎ提供的是一种基于操作符的数据流式的接口，图３是ＰｉｇＬａｔｉｎ在处理查询时的一个操作实例，该查询的目的是找出“年龄在１８～２５周岁之间的用户（Ｕｓｅｒｓ）最频繁访问的５个页面（Ｐａｇｅｓ）”，从图３可以看出，Ｐｉｇ提供的操作接口类似于关系数据库的操作符（对应图中右侧部分中的每一行命令），用户查询的脚本类似于逻辑查询计划（对应图中左侧部分），因此，也可以说Ｐｉｇ利用操作符来对Ｈａｄｏｏｐ进行封装，Ｈｉｖｅ利用ＳＱＬ进行封装。
５．３ＭａｐＲｅｄｕｃｅ和并行数据库集成型
该方向的代表性研究是耶鲁大学提出的ＨａｄｏｏｐＤＢ（已于２０１１年商业化为Ｈａｄａｐｔ）Ｓｔｏｎｅｂｒａｋｅｒ等人设计的Ｖｅｒｔｉｃａ数据库和ＮＣＲ公司的Ｔｅｒａｄａｔａ数据库。
图３ ＰｉｇＬａｔｉｎ的一个查询示例（右边为实际脚本）
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：架构大数据：挑战、现状与展望(上)
相关文章
