ＨａｄｏｏｐＤＢ的核心思想是利用Ｈａｄｏｏｐ作为调度层和网络沟通层，关系数据库作为执行引擎，尽可能地将查询压入数据库层处理，目标是想借助Ｈａｄｏｏｐ框架来获得较好的容错性和对异构环境的支持；通过将查询尽可能推入数据库中执行来获得关系数据库的性能优势，ＨａｄｏｏｐＤＢ的思想是深远的，但目前尚无应用案例，原因在于：
（１）其数据预处理代价过高：数据需要进行两次分解和一次数据库加载操作后才能使用；
（２）将查询推向数据库层只是少数情况，大多数情况下，查询仍由Ｈｉｖｅ完成，因为数据仓库查询往往涉及多表连接，由于连接的复杂性，难以做到在保持连接数据局部性的前提下将参某种模式划分；
（３）维护代价过高，不仅要维护Ｈａｄｏｏｐ系统，还要维护每个数据库节点；
（４）目前尚不支持数据的动态划分，需要手工方式将数据一次性划分好，总的来说，ＨａｄｏｏｐＤＢ在某些情况下，可以同时实现关系数据库的高性能特性和ＭａｐＲｅｄｕｃｅ的扩展性、容错性，但同时也丧失了关系数据库和ＭａｐＲｅｄｕｃｅ的某些优点，比如ＭａｐＲｅｄｕｃｅ较低的预处理代价和维护代价、关系数据库的动态数据重分布等。
Ｖｅｒｔｉｃａ采用的是共存策略：根据Ｈａｄｏｏｐ和Ｖｅｒｔｉｃａ各自的处理优势，对数据处理任务进行划分，比如Ｈａｄｏｏｐ负责非结构化数据的处理，Ｖｅｒｔｉｃａ负责结构化数据的处理；Ｈａｄｏｏｐ负责耗时的批量复杂处理，Ｖｅｒｔｉｃａ负责高性能的交互式查询等，从而将两者结合起来，Ｖｅｒｔｉｃａ实际采用的是两套系统，同时支持在ＭａｐＲｅｄｕｃｅ任务中直接访问Ｖｅｒｔｉｃａ数据库中的数据，由于结构化数据仍在Ｖｅｒｔｉｃａ中处理，在处理结构化大数据上的查询分析时，仍面临扩展性问题；如果将查询推向Ｈａｄｏｏｐ进行，又将面临性能问题，因此，Ｖｅｒｔｉｃａ的扩展性问题和Ｈａｄｏｏｐ的性能问题在该系统中共存。
与前两者相比，Ｔｅｒａｄａｔａ的集成相对简单，Ｔｅｒａｄａｔａ采用了存储层的整合：ＭａｐＲｅｄｕｃｅ任务可以从Ｔｅｒａｄａｔａ数据库中读取数据，Ｔｅｒａｄａｔａ数据库也可以从Ｈａｄｏｏｐ分布式文件系统上读取数据，同样，Ｔｅｒａｄａｔａ和Ｈａｄｏｏｐ各自的根本性问题都未解决。
６ 研究现状
对并行数据库来讲，其最大问题在于有限的扩展能力和待改进的软件级容错能力；ＭａｐＲｅｄｕｃｅ的最大问题在于性能，尤其是连接操作的性能；混合式架构的关键是，如何能尽可能多地把工作推向合适的执行引擎（并行数据库或ＭａｐＲｅｄｕｃｅ），本节对近年来在这些问题上的研究做一分析和归纳。
６．１ 并行数据库扩展性和容错性研究
华盛顿大学在文献［２３］中提出了可以生成具备容错能力的并行执行计划优化器，该优化器可以依靠输入的并行执行计划、各个操作符的容错策略及查询失败的期望值等，输出一个具备容错能力的并行执行计划，在该计划中，每个操作符都可以采取不同的容错策略，在失败时仅重新执行其子操作符（在某节点上运行的操作符）的任务来避免整个查询的重新执行。
ＭＩＴ于２０１０年设计的Ｏｓｐｒｅｙ系统基于维表在各个节点全复制、事实表横向切分并冗余备份的数据分布策略，将一星型查询划分为众多独立子查询，每个子查询在执行失败时都可以在其备份节点上重新执行，而不用重做整个查询，使得数据仓库查询获得类似ＭａｐＲｅｄｕｃｅ的容错能力，数据仓库扩展性方面的研究较少，中国人民大学的ＬｉｎｅａｒＤＢ原型属于这方面的研究，详细参见７．１节。
６．２ＭａｐＲｅｄｕｃｅ性能优化研究
ＭａｐＲｅｄｕｃｅ的性能优化研究集中于对关系数据库的先进技术和特性的移植上。
Ｆａｃｅｂｏｏｋ和俄亥俄州立大学合作，将关系数据库的混合式存储模型应用于Ｈａｄｏｏｐ平台，提出了ＲＣＦｉｌｅ存储格式。与之不同，文献［２６］将列存储技术引入Ｈａｄｏｏｐ平台，Ｈａｄｏｏｐ＋＋系统运用了传统数据库的索引技术，并通过分区数据并置（ＣｏＰａｒｔｉｔｉｏｎ）的方式来提升性能，文献［２８２９］基于ＭａｐＲｅｄｕｃｅ实现了以流水线方式在各个操作符间传递数据，从而缩短了任务执行时间；在线聚集（ｏｎｌｉｎｅａｇｇｒｅｇａｔｉｏｎ）的操作模式使得用户可以在查询执行过程中看到部分较早返回的结果，两者的不同之处在于前者仍基于ｓｏｒｔｍｅｒｇｅ方式来实现流水线，只是将排序等操作推向了ｒｅｄｕｃｅｒ，部分情况下仍会出现流水线停顿的情况；而后者利用ｈａｓｈ方式来分布数据，能实现更好的并行流水线操作，文献［３０］提出了ＭＲＳｈａｒｅ架构，对批量查询进行转换，将可共享扫描、共享Ｍａｐ输出结果等的一组任务合并为一个，以提升性能，新加坡国立大学对影响Ｈａｄｏｏｐ性能的因素做了深入分析，并提出了５项有效的优化技术，使得Ｈａｄｏｏｐ的性能提升了近３倍，逼近关系数据库的性能。
近年的研究热点是基于ＭａｐＲｅｄｕｃｅ的连接操作的性能优化，文献［３１］对ＭａｐＲｅｄｕｃｅ平台的两表连接算法做了总结，提出了Ｍａｐ端连接、Ｒｅｄｕｃｅ端连接及广播式连接等算法，文献［３２］对ＭａｐＲｅｄｕｃｅ框架进行了扩展，在Ｒｅｄｕｃｅ步骤后添加了一Ｍｅｒｇｅ步骤来完成连接操作，提出的ＭａｐＲｅｄｕｃｅＭｅｒｇｅ框架可以同时处理两个异构数据源的数据，对于多表连接，当前主流的研究集中于仅通过一个任务来完成连接操作，文献提出了一对多复制的方法，在Ｍａｐ阶段结束后，为保证连接操作的局部性，元组会被复制到多个节点，但在节点数和数据量增大的情况下，会带来Ｉ／Ｏ量及网络传输量的巨大增长，Ｌｌａｍａ通过预排序和按连接属性划分数据的方式来降低星型连接的代价，但要付出可观的预处理代价和空间代价，不同于以上等值连接优化，文献［３６］提出了针对任意连接条件的优化模型，以上连接方式都是先执行连接，然后在连接后的数据上执行聚集操作，而中国人民大学的Ｄｕｍｂｏ系统却采用了另一种更适应于ＭａｐＲｅｄｕｃｅ平台的思路：先执行过滤聚集操作，再基于聚集的数据执行连接，详细参考７．２节。
６．３ＨａｄｏｏｐＤＢ的改进
ＨａｄｏｏｐＤＢ于２０１１年针对其架构提出了两种连接优化技术和两种聚集优化技术。
两种连接优化的核心思想都是尽可能地将数据的处理推入数据库层执行，第１种优化方式是根据表与表之间的连接关系，通过数据预分解，使参与连接的数据尽可能分布在同一数据库内（参照分解法），从而实现将连接操作下压进数据库内执行，该算法的缺点是应用场景有限，只适用于链式连接，第２种连接方式是针对广播式连接而设计的，在执行连接前，先在数据库内为每张参与连接的维表建立一张临时表，使得连接操作尽可能在数据库内执行，该算法的缺点是较多的网络传输和磁盘Ｉ／Ｏ操作。
两种聚集优化技术分别是连接后聚集和连接前聚集，前者是执行完Ｒｅｄｕｃｅ端连接后，直接对符合条件的记录执行聚集操作；后者是将所有数据先在数据库层执行聚集操作，然后基于聚集数据执行连接操作，并将不符合条件的聚集数据做减法操作，该方式适用的条件有限，主要用于参与连接和聚集的列的基数相乘后小于表记录数的情况。
总的来看，ＨａｄｏｏｐＤＢ的优化技术大都局限性较强，对于复杂的连接操作（如环形连接等）仍不能下推至数据库层执行，并未从根本上解决其性能问题。
７ ＭａｐＲｅｄｕｃｅ和关系数据库技术的融合
综上所述，当前研究大都集中于功能或特性的移植，即从一个平台学习新的技术，到另一平台重新实现和集成，未涉及执行核心，因此也没有从根本上解决大数据分析问题，鉴于此，中国人民大学高性能数据库实验室的研究小组采取了另一种思路：从数据的组织和查询的执行两个核心层次入手，融合关系数据库和ＭａｐＲｅｄｕｃｅ两种技术，设计高性能的可扩展的抽象数据仓库查询处理框架，该框架在支持高度可扩展的同时，又具有关系数据库的性能，我们团队尝试过两个研究方向：
（１）借鉴ＭａｐＲｅｄｕｃｅ的思想，使ＯＬＡＰ查询的处理能像ＭａｐＲｅｄｕｃｅ一样高度可扩展（ＬｉｎｅａｒＤＢ原型）；
（２）利用关系数据库的技术，使ＭａｐＲｅｄｕｃｅ在处理ＯＬＡＰ查询时，逼近关系数据库的性能（Ｄｕｍｂｏ原型）。
７．１ ＬｉｎｅａｒＤＢ
ＬｉｎｅａｒＤＢ①原型系统没有直接采用基于连接的星型模型（雪花模型），而是对其进行了改造，设计了扩展性更好的、基于扫描的无连接雪花模型ＪＦＳＳ（ＪｏｉｎＦｒｅｅＳｎｏｗｆｌａｋｅＳｃｈｅｍａ），该模型的设计借鉴了泛关系模型的思想，采用层次编码技术［４０］将维表层次信息压缩进事实表，使得事实表可以独立执行维表上的谓词判断、聚集等操作，从而使连接的数据在大规模机群上实现局部性，消除了连接操作，图４是一个星型模型和无连接雪花模型的对应示意图。
在执行层次上，ＬｉｎｅａｒＤＢ吸取了ＭａｐＲｅｄｕｃｅ处理模式的设计思想，将数据仓库查询的处理抽象为Ｔｒａｎｓｆｏｒｍ、Ｒｅｄｕｃｅ、Ｍｅｒｇｅ３个操作（ＴＲＭ执行模型）：
（１）Ｔｒａｎｓｆｏｒｍ，主节点对查询进行预处理，将查询中作用于维表的操作（主要是谓词判断，ｇｒｏｕｐｂｙ聚集操作等）转换为事实表上的操作；
（２）Ｒｅｄｕｃｅ，每个数据节点并行地扫描、聚集本地数据，然后将处理结果返回给主节点；
（３）Ｍｅｒｇｅ，主节点对各个数据节点返回的结果进行合并，并执行后续的过滤、排序等操作，基于ＴＲＭ执行模型，查询可以划分为众多独立的子任务在大规模机群上并行执行，执行过程中，任何失败子任务都可以在其备份节点重新执行，从而获得较好的容错能力。ＬｉｎｅａｒＤＢ的执行代价主要取决于对事实表的Ｒｅｄｕｃｅ（主要是扫描）操作，因此，ＬｉｎｅａｒＤＢ可以获得近乎线性的大规模可扩展能力。
实验表明，其性能比ＨａｄｏｏｐＤＢ至少高出一个数量级。
ＬｉｎｅａｒＤＢ的扩展能力、容错能力和高性能在于其巧妙地结合了关系数据库技术（层次编码技术、泛关系模式）和ＭａｐＲｅｄｕｃｅ处理模式的设计思想，由此，可以看出，结合方式的不同可以导致系统能力的巨大差异。
７.２Ｄｕｍｂｏ
Ｄｕｍｂｏ的核心思想是根据ＭａｐＲｅｄｕｃｅ的“过滤－＞聚集”的处理模式，对ＯＬＡＰ查询的处理进行改造，使其适应于ＭａｐＲｅｄｕｃｅ框架，Ｄｕｍｂｏ采用了类似于ＬｉｎｅａｒＤＢ的数据组织模式———利用层次编码技术将维表信息压缩进事实表，区别在于Ｄｕｍｂｏ采用了更加有效的编码方式，并针对Ｈａｄｏｏｐ分布式文件系统的特点对数据的存储进行了优化。
在执行层次上，Ｄｕｍｂｏ对ＭａｐＲｅｄｕｃｅ框架进行了扩展，设计了新的ＯＬＡＰ查询处理框架———ＴＭＲＰ（Ｔｒａｎｓｆｏｒｍ－＞Ｍａｐ－＞Ｒｅｄｕｃｅ－＞Ｐｏｓｔｐｒｏｃｅｓｓ）处理框架（如图５所示），在该框架中，主节点首先对查询进行转换，生成一个ＭａｐＲｅｄｕｃｅ任务来执行查询，该任务在Ｍａｐ阶段以流水线方式扫描、聚集本地数据，并只将本地的聚集数据传至Ｒｅｄｕｃｅ阶段，来进行数据的合并及聚集、排序等操作，在Ｐｏｓｔｐｒｏｃｅｓｓ阶段，主节点在数据节点上传的聚集数据之上执行连接操作，实验表明，Ｄｕｍｂｏ性能远超Ｈａｄｏｏｐ和ＨａｄｏｏｐＤＢ。
由此我们可以看出，复杂的ＯＬＡＰ查询在ＭａｐＲｅｄｕｃｅ框架下也可以获得接近甚至超越关系数据库的性能，其关键在于如何有效地结合关系数据库和ＭａｐＲｅｄｕｃｅ两种技术，仅仅停留于表层的移植和集成是难以从根本上解决大数据分析问题的，我们在文献［４１］的研究中也展示了如何基于这种新的数据组织方式来实现复杂分析操作———百分位数的高效计算问题。
ＬｉｎｅａｒＤＢ和Ｄｕｍｂｏ虽然基本可以达到预期的设计目标，但两者都需要对数据进行预处理，其预处理代价是普通加载时间的７倍左右，因此其应对变化的能力还较弱，这是我们未来的工作内容之一。
图４ 对比：一个典型星型模型与其对应的无连接雪花模型
８ 研究展望
当前３个方向的研究都不能完美地解决大数据分析问题，也就意味着每个方向都有极具挑战性的工作等待着我们。
对并行数据库来说，其扩展性近年虽有较大改善（如Ｇｒｅｅｎｐｌｕｍ和ＡｓｔｅｒＤａｔａ都是面向ＰＢ级数据规模设计开发的），但距离大数据的分析需求仍有较大差距，因此，如何改善并行数据库的扩展能力是一项非常有挑战的工作，该项研究将同时涉及数据一致性协议、容错性、性能等数据库领域的诸多方面。
图５ Ｄｕｍｂｏ架构（深灰色部分是新增模块，剩余部分是Ｈａｄｏｏｐ自带模块）
混合式架构方案可以复用已有成果，开发量较小，但只是简单的功能集成似乎并不能有效解决大数据的分析问题，因此该方向还需要更加深入的研究工作，比如从数据模型及查询处理模式上进行研究，使两者能较自然地结合起来，这将是一项非常有意义的工作，中国人民大学的Ｄｕｍｂｏ系统即是在深层结合方向上努力的一个例子。
相比于前两者，ＭａｐＲｅｄｕｃｅ的性能优化进展迅速，其性能正逐步逼近关系数据库，该方向的研究又分为两个方向：理论界侧重于利用关系数据库技术及理论改善ＭａｐＲｅｄｕｃｅ的性能；工业界侧重于基于ＭａｐＲｅｄｕｃｅ平台开发高效的应用软件，针对数据仓库领域，我们认为如下几个研究方向比较重要，且目前研究还较少涉及：
（１）多维数据的预计算，ＭａｐＲｅｄｕｃｅ更多针对的是一次性分析操作，大数据上的分析操作虽然难以预测，但传统的分析，如基于报表和多维数据的分析仍占多数，因此，ＭａｐＲｅｄｕｃｅ平台也可以利用预计算等手段加快数据分析的速度，基于存储空间的考虑（可以想象，在爆炸数据之上计算数据立方体需要付出昂贵的存储空间代价），ＭＯＬＡＰ是不可取的，混合式ＯＬＡＰ（ＨＯＬＡＰ）应该是ＭａｐＲｅｄｕｃｅ平台的优选ＯＬＡＰ实现方案，具体研究如：①基于ＭａｐＲｅｄｕｃｅ框架的高效Ｃｕｂｅ计算算法；②物化视图的选择问题，即物化哪些数据；③不同分析操作的物化手段（比如预测分析操作的物化）及如何基于物化的数据进行复杂分析操作（如数据访问路径的选择问题）。
（２）各种分析操作的并行化实现，大数据分析需要高效的复杂统计分析功能的支持，ＩＢＭ将开源统计分析软件Ｒ集成进Ｈａｄｏｏｐ平台，增强了Ｈａｄｏｏｐ的统计分析功能，但更具挑战性的问题是，如何基于ＭａｐＲｅｄｕｃｅ框架设计可并行化的、高效的分析算法，尤其需要强调的是，鉴于移动数据的巨大代价，这些算法应基于移动计算的方式来实现。
（３）查询共享，ＭａｐＲｅｄｕｃｅ采用步步物化的处理方式，导致其Ｉ／Ｏ代价及网络传输代价较高，一种有效的降低该代价的方式是在多个查询间共享物化的中间结果，甚至原始数据，以分摊代价并避免重复计算，因此如何在多查询间共享中间结果将是一项非常有实际应用价值的研究。
（４）用户接口，如何较好地实现数据分析的展示和操作，尤其是复杂分析操作的直观展示。
（５）Ｈａｄｏｏｐ可靠性研究，当前Ｈａｄｏｏｐ采用主从结构，由此决定了主节点一旦失效，将会出现整个系统失效的局面，因此，如何在不影响Ｈａｄｏｏｐ现有实现的前提下，提高主节点的可靠性，将是一项切实的研究。
（６）数据压缩，ＭａｐＲｅｄｕｃｅ的执行模型决定了其性能取决于Ｉ／Ｏ和网络传输代价，文献［１１］在比较并行数据库和ＭａｐＲｅｄｕｃｅ基于压缩数据的性能时，发现压缩技术并没有改善Ｈａｄｏｏｐ的性能①，但实际情况是，压缩不仅可以节省空间，节省Ｉ／Ｏ及网络带宽，还可以利用当前ＣＰＵ的多核并行计算能力，平衡Ｉ／Ｏ和ＣＰＵ的处理能力，从而提高性能，比如并行数据库利用数据压缩后，性能往往可以大幅提升，此后，文献［２５、２６］的研究成功地利用压缩技术提升了Ｈａｄｏｏｐ的性能，但这些研究都基于各自的存储模型，而非Ｈａｄｏｏｐ的默认存储模式（行存模型），因此，ＭａｐＲｅｄｕｃｅ上的压缩是一个尚待研究的重要问题。
（７）多维索引研究，如何基于ＭａｐＲｅｄｕｃｅ框架实现多维索引，加快多维数据的检索速度。
当然，仍有许多其它研究工作，比如基于Ｈａｄｏｏｐ的实时数据分析、弹性研究、数据一致性研究等，都是非常有挑战和意义的研究，限于篇幅我们不再赘述。
９ 总结
本文对大数据分析的主流实现平台（并行数据库、ＭａｐＲｅｄｕｃｅ及两者的混合架构）进行了评价、归纳与对比分析，介绍了中国人民大学在大数据分析方面的研究，并对当前的研究进行了归纳，从文中可以看出，每种分析平台都不是完美的，在大数据面前，都有很长的路要走，大数据分析迫使我们反思传统的数据仓库架构，虚心地研究ＭａｐＲｅｄｕｃｅ等新生平台，以站在更高的层次来思考问题，从而找到适应时代需求的数据仓库架构。
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：架构大数据：挑战、现状与展望(下)
相关文章
