Greenplm高性能数据引擎探秘.docVIP

Greenplum高性能数据引擎探秘 2010-03-12 08:33 red7 51CTO.com 我要评论(2) 字号：T | T 高性能数据引擎也都是基于这两个方面的来最求高效：“大规模”需要的是数据吞吐能力，就是所谓的I/O；“数据处理”需要的是并行计算能力，即充分利用硬件资源对任务及进程的最大化运行。 AD： 【51CTO独家特稿】Greenplum数据引擎是为新一代数据仓库和大规模分析处理而建立的软件解决方案。其最大的特点是不需要高端的硬件支持仍然可以支撑大规模的高性能数据仓库和商业智能查询。在数据仓库、商业智能的应用上，尤其海量数据的处理方面性能极其优异。 高性能的大规模数据处理能力是DBA对数据库梦寐以求的能力之一。从字面上不难看出，“高性能的大规模数据处理能力”中，一方面是针对“大规模的数据”，另一方面就是“数据的处理”，施加于二者之上的要求是“高性能”。 所以，高性能数据引擎也都是基于这两个方面的来最求高效：“大规模”需要的是数据吞吐能力，就是所谓的I/O；“数据处理”需要的是并行计算能力，即充分利用硬件资源对任务及进程的最大化运行。 在理解提升I/O和并行计算的能力之前，我们需要深入Greenplum的核心，了解一下Greenplum的Shared Nothing架构。 Shared Nothing架构 与Oracle RAC的Shared Everything架构不同，Greenplum采用Shared Nothing架构。整个集群由很多个数据节点（Segment Host）和控制节点（Master Host）组成，其中每个数据节点上可以运行多个数据库。 简单来说，Shared Nothing是一个分布式的架构，每个节点相对独立。典型的Shared Nothing系统会集数据库、内存Cache、等存储状态的信息；而不在节点上保存状态的信息。 Shared Nothing架构简图 对于应对大规模数据处理的服务器集群设备，若将Session状态信息保存在各个数据节点上，各节点的Session复制会极大的影响性能；若采用Shared Nothing，保持每个节点的无状态性，不再使用Session来保持全局的状态，而是将Session直接放在数据库中，在数据库前再加一层如Memcached分布式Cache，这样将可极大的提高性能，当改变Session中的对象时，将同步到Cache和数据库。 基于Shared Nothing的分布式架构模式，Greenplum在高效处理I/O数据吞吐和并发计算的过程就很好理解。 高效I/O的实现 I/O瓶颈是数据库，特别是大规模数据分析处理中永恒的话题。在Greenplum中，需要存储的数据在进入进入数据库时，将首先进行数据分布的处理工作；将一个表里的数据平均分布到每个节点，并为每个表指定一个分发列（distribute Column），之后便根据Hash来分布数据。 Greenplum的高效数据载入 基于Shared Nothing的原则，Greenplum这样处理可以充分发挥每个节点处I/O的处理能力。在这一过程中，控制节点（Master Host）将不再承担计算任务，而只负责必要的逻辑控制和客户端交互。 这是Greenplum的独到之处。在多数集群的大规模数据处理系统中，都使用中心节点进行大量的控制和计算，大量的数据交换过程中将造成中心节点的负载过大；多数情况下，数据库的I/O瓶颈在这一位置（处理过程）形成病灶，进而随多核心CPU时序控制和处理响应的时段等问题开始蔓延，最终致使系统中很多节点的I/O位置病入膏肓。 在Greenplum中，控制节点只负责必要的逻辑处理和客户端交互，节点间的数据交互将直接在节点间完成，而不需要控制节点；在一定的硬件资源支持下，高效I/O不再是DBA的梦想。 并行计算能力 I/O瓶颈的解决为并行计算能力的提升创造了良好的环境。下面我们一起来看看Greenplum是如何进行高性能的并行计算的。 在硬件方面，Greenplum可以使用标准的服务器并通过服务器间的高级通信连接，将多台服务器组成一个强大的计算平台，实现快速的海量并行运算。 在系统内部，Greenplum通过自己的并行数据流引擎来实现更多计算需求的硬件资源调度。一般，多表JOIN操作是考验系统并行计算能力的经典案例。在Greenplum中，这一过程是将一个表里的数据平均分布到每个节点，并为每个表指定一个分发列，之后便根据Hash算法来分布数据。 这样，每个节点的数据通过分发列即得知。如果对distribute Column做JOIN操作，只需要通过分发列得到数据的节点位置，并对相应的节点进行计算，最后合并结果就可完成。 当然，这种几个表规模的查询还不能证明Greenplum