Greenplum集群部署和架构优化，我总结了5000字的心得

最近对离线数仓体系进行了扩容和架构改造，也算是一波三折，出了很多小插曲，有一些改进点对我们来说也是真空地带，通过对比和模拟压测总算是得到了预期的结果，这方面尤其值得一提的是郭运凯同学的敬业，很多前置的工作，优化和应用压测的工作都是他完成的。 

整体来说，整个事情的背景是因为服务器硬件过保，刚好借着过保服务器替换的机会来做集群架构的优化和改造。 

1集群架构改造的目标

在之前也总结过目前存在的一些潜在问题，也是本次部署架构改进的目标：

1）之前 的GP segment数量设计过度 ，因为资源限制，过多考虑了功能和性能，对于集群的稳定性和资源平衡性考虑有所欠缺，在每个物理机节点上部署了10个Primary,10个Mirror，一旦1个服务器节点不可用，整个集群几乎无法支撑业务。

2）GP集群 的存储资源和性能的平衡不够 ，GP存储基于RAID-5,如果出现坏盘，磁盘重构的代价比较高，而且重构期间如果再出现坏盘，就会非常被动，而且对于离线数仓的数据质量要求较高，存储容量相对不是很大，所以在存储容量和性能的综合之上，我们选择了RAID-10。

3)集 群的异常场景的恢复需要完善， 集群在异常情况下（如服务器异常宕机，数据节点不可用，服务器后续过保实现节点滚动替换）的故障恢复场景测试不够充分，导致在一些迁移和改造中，相对底气不足，存在一些知识盲区。

4）集群版本过 低 ，功能和性能上存在改进空间。毕竟这个集群是4年前的版本，底层的PG节点的版本也比较旧了，在功能上和性能上都有一定的期望，至少能够与时俱进。

5）操作系统版本升 级 ，之前的操作系统是基于CentOS6，至少需要适配CentOS 7 。

6）集群TPCH 压测验收 ，集群在完成部署之后，需要做一次整体的TPCH压测验收，如果存在明显的问题需要不断调整配置和架构，使得达到预期的性能目标。

此外在应用层面也有一些考虑，总而言之，是希望能够解决绝大多数的痛点问题，无论是在系统层面，还是应用层面，都能上一个台阶。

2集群规划设计的选型和思考

明确了目标，就是拆分任务来规划设计了，在规划设计方面主要有如下的几个问题：

1）Greenplum的版本选择 ，目前有两个主要的版本类别，一个是开源版（Open Source distribution）和Pivotal官方版，它们的其中一个差异就是官方版需要注册，签署协议，在此基础上还有GPCC等工具可以用，而开源版本可以实现源码编译或者rpm安装，无法配置GPCC。综合来看，我们选择了 开源版本的6162 ，这其中也询问了一些行业朋友，特意选择了几个涉及稳定性bug修复的版本。

2）数据集市的技术选型 ，在数据集市的技术选型方面起初我是比较坚持基于PostgreSQL的模式，而业务侧是希望对于一些较为复杂的逻辑能够通过GP去支撑，一来二去之后，加上我咨询了一些行业朋友的意见，是可以选择基于GP的方案，于是我们就抱着试一试的方式做了压测，所以数据仓库和和数据集市会是两个不同规模体量的GP集群来支撑。

3）GP的容量规划 ，因为之前的节点设计有些过度，所以在数量上我们做了缩减，每台服务器部署12个segment节点，比如一共12台服务器，其中有10台服务器是Segment节点，每台上面部署了6个Primary,6个Mirror，另外2台部署了Master和Standby，就是即（6+6）10+2，整体的配置情况类似下面的模式。

4）部署架构方案选型 ，部署架构想起来比较容易，但是落实起来有很多的考虑细节，起初考虑GP的Master和Standby节点如果混用还是能够节省一些资源，所以设计的数据仓库和数据集市的部署架构是这样考虑的，但是从走入部署阶段之后，很快就发现这种交叉部署的模式是不可行的，或者说有一些复杂度。

除此之外，在单个GP集群的部署架构层面，还有4类方案考虑。

  方案1 ：Master,Standby和segment混合部署

  方案2 ：Master,Standby和segment独立部署，整个集群的节点数会少一些

  方案3 ：Segment独立部署，Master,Standby虚拟机部署

  方案4 ：最小化单节点集群部署（这是数据集市最保底的方案）  

这方面存在较大的发挥空间，而且总体来说这种验证磨合的成本也相对比较高，实践给我上了一课， 越是想走捷径，越是会让你走一些弯路 ，而且有些时候的优化其实我也不知道改怎么往下走，感觉已经无路可走，所以上面这4种方案其实我们都做了相关的测试和验证。

3集群架构的详细设计和实践

1）设计详细的部署架构图

在整体规划之上，我设计了如下的部署架构图，每个服务器节点有6个Primary,6个Mirror,服务器两两映射。

2）内核参数优化

按照官方文档的建议和具体的配置情况，我们对内核参数做了如下的配置：

vmswappiness=10

vmzone_reclaim_mode = 0

vmdirty_expire_centisecs = 500

vmdirty_writeback_centisecs = 100

vmdirty_background_ratio = 0 # See System Memory

vmdirty_ratio = 0

vmdirty_background_bytes = 1610612736

vmdirty_bytes = 4294967296

vmmin_free_kbytes = 3943084

vmovercommit_memory=2

kernelsem = 500 2048000 200 4096

4集群部署步骤

1）首先是配置/etc/hosts，需要把所有节点的IP和主机名都整理出来。 

2）配置用户，很常规的步骤

groupadd  gpadmin

useradd gpadmin -g gpadmin

passwd gpadmin

3）配置sysctlconf和资源配置

4）使用rpm模式安装

# yum install -y apr apr-util bzip2 krb5-devel  zip

# rpm -ivh open-source-greenplum-db-6162-rhel7-x86_64rpm

5）配置两个host文件，也是为了后面进行统一部署方便，在此建议先开启gpadmin的sudo权限，可以通过gpssh处理一些较为复杂的批量操作

6）通过gpssh-exkeys来打通ssh信任关系，这里需要吐槽这个ssh互信，端口还得是22，否则处理起来很麻烦,需要修改/etc/ssh/sshd_config文件

gpssh-exkeys -f hostlist

7）较为复杂的一步是打包master的Greenplum-db-6162软件，然后分发到各个segment机器中，整个过程涉及文件打包，批量传输和配置，可以借助gpscp和gpssh，比如gpscp传输文件，如下的命令会传输到/tmp目录下

gpscp -f /usr/local/greenplum-db/conf/hostlist /tmp/greenplum-db-6162targz =:/tmp

或者说在每台服务器上面直接rpm -ivh安装也可以。

8）Master节点需要单独配置相关的目录，而Segment节点的目录可以提前规划好，比如我们把Primary和Mirror放在不同的分区。 

mkdir -p /data1/gpdata/gpdatap1

mkdir -p /data1/gpdata/gpdatap2

mkdir -p /data2/gpdata/gpdatam1

mkdir -p /data2/gpdata/gpdatam2

9）整个过程里最关键的就是gpinitsystem_config配置了，因为Segment节点的ID配置和命名，端口区间都是根据一定的规则来动态生成的，所以对于目录的配置需要额外注意。

10）部署GP集群最关键的命令是

gpinitsystem -c gpinitsystem_config -s standby_hostname

其中文件gpinitsystem_config的主要内容如下：

MASTER_HOSTNAME=xxxx

declare -a DATA_DIRECTORY=(/data1/gpdata/gpdatap1  /data1/gpdata/gpdatap2 /data1/gpdata/gpdatap3 /data1/gpdata/gpdatap4 /data1/gpdata/gpdatap5 /data1/gpdata/gpdatap6)

TRUSTED_SHELL=ssh

declare -a MIRROR_DATA_DIRECTORY=(/data2/gpdata/gpdatam1  /data2/gpdata/gpdatam2 /data2/gpdata/gpdatam3 /data2/gpdata/gpdatam4 /data2/gpdata/gpdatam5 /data2/gpdata/gpdatam6)

MACHINE_LIST_FILE=/usr/local/greenplum-db/conf/seg_hosts

整个过程大约5分钟~10分钟以内会完成，在部署过程中建议要查看后端的日志查看是否有异常，异常情况下的体验不是很好，可能会白等。

5集群部署问题梳理

集群部署中还是有很多细节的问题，太基础的就不提了，基本上就是配置，目录权限等问题，我提另外几个：

1） 资源配置问题 ，如果/etc/security/limitsconf的资源配置不足会在安装时有如下的警告：

2） 网络问题 ，集群部署完成后可以正常操作，但是在查询数据的时候会抛出错误，比如SQL是这样的，看起来很简单：select count() from customer,但是会抛出如下的错误：

这个问题的主要原因还是和防火墙配置相关，其实不光需要配置INPUT的权限，还需要配置OUTPUT的权限。 

对于数据节点可以开放略大的权限，如：

入口的配置：

-A INPUT -p all -s xxxxx    -j ACCEPT

出口的配置：

-A OUTPUT -p all -s xxxxx    -j ACCEPT

3）网络配置问题 ，这个问题比较诡异的是，报错和上面是一样的，但是在排除了防火墙配置后，select count() from customer；这样的语句是可以执行的，但是执行的等待时间较长，比如表lineitem这表比较大，过亿的数据量，,在10个物理节点时，查询响应时间是10秒，但是4个物理节点，查询响应时间是在90秒，总体删感觉说不过去。

为了排查网络问题，使用gpcheckperf等工具也做过测试，4节点和10节点的基础配置也是相同的。

gpcheckperf -f /usr/local/greenplum-db/conf/seg_hosts -r N -d /tmp

$ cat /etc/hosts

127001   localhost localhostlocaldomain localhost4 localhost4localdomain4

::1      localhost localhostlocaldomain localhost6 localhost6localdomain6

#127001    test-dbs-gp-128-230

xxxxx128238 test-dbs-gp-svr-128-238

xxxxx128239 test-dbs-gp-svr-128-239

其中127001的这个配置在segment和Master,Standby混部的情况是存在问题的，修正后就没问题了，这个关键的问题也是郭运凯同学发现的。

5集群故障恢复的测试

集群的故障测试是本次架构设计中的重点内容，所以这一块也是跃跃欲试。

整体上我们包含两个场景，服务器宕机修复后的集群恢复和服务器不可用时的恢复方式。

第一种场景相对比较简单，就是让Segment节点重新加入集群，并且在集群层面将Primary和Mirror的角色互换，而第二种场景相对时间较长一些，主要原因是需要重构数据节点，这个代价基本就就是PG层面的数据恢复了，为了整个测试和恢复能够完整模拟，我们采用了类似的恢复方式，比如宕机修复使用了服务器重启来替代，而服务器不可用则使用了清理数据目录，类似于一台新配置机器的模式。

1）服务器宕机修复后集群恢复

select from gp_segment_configuration where status!='u';

gprecoverseg  -o /recov

gprecoverseg -r

select from gp_segment_configuration where status='u'

2）服务器不可用时集群恢复

重构数据节点的过程中，总体来看网络带宽还是使用很充分的。

select from gp_segment_configuration where status='u'

select from gp_segment_configuration where status='u' and role!=preferred_role;

gprecoverseg -r

select from gp_segment_configuration where status='u' and role!=preferred_role;

经过测试，重启节点到数据修复，近50G数据耗时3分钟左右

6集群优化问题梳理

1）部署架构优化和迭代

对于优化问题，是本次测试中尤其关注，而且争议较多的部分。 

首先在做完初步选型后，数仓体系的部署相对是比较顺利的，采用的是第一套方案。

数据集市的集群部分因为节点相对较少，所以就选用了第二套方案

实际测试的过程，因为配置问题导致TPCH的结果没有达到预期。

所以这个阶段也产生了一些疑问和怀疑，一种就是折回第一种方案，但是节点数会少很多，要不就是第三种采用虚拟机的模式部署，最保底的方案则是单节点部署，当然这是最牵强的方案。

这个阶段确实很难，而在上面提到的修复了配置之后，集群好像突然开悟了一般，性能表现不错，很快就完成了100G和1T数据量的TPCH测试。

在后续的改造中，我们也尝试了第三套方案，基于虚拟机的模式，通过测试发现，远没有我们预期的那么理想，在同样的数据节点下，Master和Standby采用物理机和虚拟机，性能差异非常大，这个是出乎我们预料的。比如同样的SQL,方案3执行需要2秒，而方案2则需要80秒，这个差异我们对比了很多指标，最后我个人理解差异还是在网卡部分。

所以经过对比后，还是选择了方案2的混合部署模式。

2）SQL性能优化的分析

此外整个过程的TPCH也为集群的性能表现提供了参考。比如方案2的混合部署模式下，有一条SQL需要18秒，但是相比同类型的集群，可能就只需要2秒钟左右，这块显然是存在问题的。 

在排除了系统配置，硬件配置的差异之后，经典的解决办法还是查看执行计划。

性能较差的SQL执行计划：

# explain analyze select count()from customer;

QUERY PLAN   

Aggregate  (cost=00043100 rows=1 width=8) (actual time=2479291624792916 rows=1 loops=1)

   ->  Gather Motion 36:1  (slice1; segments: 36)  (cost=00043100 rows=1 width=1) (actual time=325516489394 rows=150000000 loops=1)

         ->  Seq Scan on customer  (cost=00043100 rows=1 width=1) (actual time=07801267878 rows=4172607 loops=1)

Planning time: 4466 ms

   (slice0)    Executor memory: 680K bytes

   (slice1)    Executor memory: 218K bytes avg x 36 workers, 218K bytes max (seg0)

Memory used:  2457600kB

Optimizer: Pivotal Optimizer (GPORCA)

Execution time: 24832611 ms

(9 rows)

Time: 24892500 ms

性能较好的SQL执行计划：

# explain analyze select count()from customer;                            

QUERY PLAN

Aggregate  (cost=00084208 rows=1 width=8) (actual time=15193111519311 rows=1 loops=1)

   ->  Gather Motion 36:1  (slice1; segments: 36)  (cost=00084208 rows=1 width=8) (actual time=6347871519214 rows=36 loops=1)

         ->  Aggregate  (cost=00084208 rows=1 width=8) (actual time=14732961473296 rows=1 loops=1)

               ->  Seq Scan on customer  (cost=00083433 rows=4166667 width=1) (actual time=0758438319 rows=4172607 loops=1)

Planning time: 5033 ms

   (slice0)    Executor memory: 176K bytes

   (slice1)    Executor memory: 234K bytes avg x 36 workers, 234K bytes max (seg0)

Memory used:  2457600kB

Optimizer: Pivotal Optimizer (GPORCA)

Execution time: 1543611 ms

(10 rows)

Time: 1549324 ms

很明显执行计划是被误导了，而误导的因素则是基于统计信息，这个问题的修复很简单：

analyze customer;

但是深究原因，则是在压测时，先是使用了100G压测，压测完之后保留了原来的表结构，直接导入了1T的数据量，导致执行计划这块没有更新。

3）集群配置优化

此外也做了一些集群配置层面的优化，比如对缓存做了调整。 

gpconfig -c statement_mem -m 2457600 -v 2457600

gpconfig -c gp_vmem_protect_limit -m 32000 -v 32000

7集群优化数据

最后来感受下集群的性能：

1）10个物理节点，（6+6）10+2

tpch_1t=# iming on

Timing is on

tpch_1t=# select count()from customer;

   count   

-----------

150000000

(1 row)

Time: 1235801 ms

tpch_1t=# select count()from lineitem;

   count    

------------

5999989709

(1 row)

Time: 10661756 ms

2）6个物理节点，（6+6）6

# select count()from customer;

   count   

-----------

 150000000

(1 row)

Time: 1346833 ms

# select count()from lineitem;

   count    

------------

 5999989709

(1 row)

Time: 18145092 ms

3）4个物理节点，（6+6）4

# select count()from customer;

   count   

-----------

 150000000

(1 row)

Time: 1531621 ms

# select count()from lineitem;

   count    

------------

 5999989709

(1 row)

Time: 25072501 ms

4）TPCH在不通架构模式下的性能比对 ，有19个查询模型，有个别SQL逻辑过于复杂暂时忽略，也是郭运凯同学整理的列表。

在1T基准下的基准测试表现：

上世界60年代开始，美国的计算机学术界就开始了虚拟技术的萌芽。1959年克里斯托弗(Christopher Strachey)发表了一篇学术报告，名为《大型高速计算机中的时间共享》(Time Sharing in Large Fast Computers)，他在文中提出了虚拟化的基本概念，这篇文章也被认为是虚拟化技术的最早论述。

现在由于虚拟化技术在x86服务器上的迅速普及已经引发了虚拟化技术的热潮，但虚拟化技术最初只是应用在大型主机上。大型机上的虚拟分区技术最早可以追溯到上世纪六、七十年代。早在上世纪60年代，IBM公司就发明了一种操作系统虚拟机技术，允许用户在一台主机上运行多个操作系统，让用户尽可能地充分利用昂贵的大型机资源。

最早使用虚拟化技术的是IBM 7044 计算机。IBM之后，在上世纪60年代还开发了型号为Model 67的System/360主机。Model 67主机通过虚拟机监视器(Virtual Machine Monitor)虚拟所有的硬件接口。1965年IBM公司的“M44/44X”计算机项目，定义了虚拟内存管理机制，用户程序可以运行在虚拟的内存中，对于用户来说，这些虚拟内存就好像一个个“虚拟机”，为多个用户的程序提供了独立的计算环境。

IBM提出的虚拟机技术，使一批新产品涌现了出来，比如：IBM360/40，IBM360/67，以及VM/370，这些机器在当时都具有虚拟机功能，通过一种叫VMM(虚拟机监控器)的技术在物理硬件之上生成了很多可以运行独立操作系统软件的虚拟机实例。

由于虚拟化技术技术在商业应用上的优势，RISC服务器与小型机成为了虚拟化技术第二代受益者。1999年，IBM公司在AS/400上提出了上“逻辑分区(LPAR)”技术和新的高可用性集群解决方案。在POWER管理程序上运行的AS/400 LPAR令单台服务器工作起来如同12个独立的服务器。而在2002年，IBM 还更进一步，其AIX5L v52还首次包括了IBM实现的动态逻辑分区(DLPAR)。DLPAR允许在无需重启系统的情况下，将包括处理器、内存和其它组件在内的系统资源分配给独立的分区。这种在不中断运行的情况下进行资源分配的能力不仅令系统管理变得更加轻松，而且因为能够更好地使用资源而帮助降低总拥有成本。

不过，尽管惠普、Sun公司也跟随IBM在自己的RISC服务器上提供了虚拟化技术，但由于真正使用大型机和小型机的用户还是少数，加上各家产品和技术之间并不兼容，虚拟化技术仍旧不太被公众所关注。而现在，虚拟化技术的发展已经惠及到了x86架构。

此前，虚拟化技术在x86架构上进展缓慢的主要原因是x86架构本身不适合进行虚拟化，不过这个障碍已经由英特尔、AMD修改，x86处理器的指令集得到解决；还有一个原因是x86处理器的性能不足，这一原因也由于x86处理器在性能上的飞速提高得到了解决。由于x86架构的广泛普及，x86架构上的虚拟化技术也得到了比以前更大的关注。

随着x86平台上虚拟化技术的实现，首次向人们展示了虚拟化应用的广阔前景，因为x86平台可以提供便宜的、高性能和高可靠的服务器。更重要的是，一些用户已经开始配置虚拟化的生产环境，他们需要得到新的管理工具，从而随着虚拟化技术的发展而得到更大的收益。

不过，与已经有多年历史的UNIX服务器、大型主机上的虚拟化技术相比，x86服务器上的虚拟化仍旧处于早期阶段——根据英特尔的蓝图，在处理器当中集成硬件辅助虚拟化指令只是IA平台上的第一步，而在第二步则要实现I/O方面的虚拟化，直到最后实现整个IA平台的虚拟化。也就是说，目前的x86平台上，仅仅能够实现在处理器级别的虚拟化，在I/O以及其他方面的虚拟化还需要进一步的发展。不仅如此，x86架构上的虚拟化技术还无法完美实现虚拟分区之间动态迁移，而这些在UNIX平台、大型主机上早已不是问题。目前，x86架构上的虚拟化技术的最高规划是支持8路SMP系统，可以实现对单个CPU资源的配置。

自2006年以来，从处理器层面的AMD和Intel到操作系统层面的微软的加入，从数量众多的第三方软件厂商的涌现到服务器系统厂商的高调，我们看到一个趋于完整的服务器虚拟化的产业生态系统正在逐渐形成。这也使得在过去的一两年时间里，虚拟化开始成为广受关注的热点话题。整体看来，随着计算机新技术的飞速发展，虚拟化的前景和一年前相比几乎彻底改变了，新的虚拟化平台前景十分乐观。

云服务器是云计算服务的重要组成部分，是面向各类互联网用户提供综合业务能力的服务平台。平台整合了传统意义上的互联网应用三大核心要素：计算、存储、网络，面向用户提供公用化的互联网基础设施服务。

云服务器服务包括两个核心产品

面向中小企业用户与高端用户的云服务器租用服务；

面向大中型互联网用户的弹性计算平台服务。

云服务器平台的每个集群节点被部署在互联网的骨干数据中心，可独立提供计算、存储、在线备份、托管、带宽等互联网基础设施服务。集群节点由以下硬件构成：

管理服务器：采取双机热备的方式，对整个节点的所有计算服务器、共享存储、网络进行管理，同时对外提供管理整个节点的API。管理服务器上提供：

管理服务（管理节点的计算服务器，对外提供管理接口）、DHCP 服务（为计算服务器的网络启动分配管理网段的IP）、tftp 服务（为计算服务器的网络启动提供远程启动映象）、nbd 服务（为计算服务器提供网络块设备服务）。管理服务器上还会运行一个数据采集程序，他定时将各种性能数据采集下来并发送到中央的数据采集服务器上存储服务器群：存储服务器可以是ISCSI 或内置存储容量比较大的x86 服务器，通过 集群文件系统组成一个统一的存储池，为节点内的虚拟机提供逻辑磁盘存储、非结构数据存储以及整合备份服务。

计算服务器群：计算服务器是高配置的八核以上服务器，计算服务器无需安装操作系统，但必须具备网络引导功能，其上运行一个linux微内核、云计算机软件、一个与管理服务器进行通讯的Agent

交换机：按不同功能和节点性能要求配备多个三层交换机，分别负责管理网段、公网交换网段、内部交换网段、存储网段等

在现如今，随着IT互联网信息技术的飞速发展和进步。

目前大数据行业也越来越火爆，从而导致国内大数据人才也极度缺乏，下面IT培训http://wwwkmbdqncn/介绍一下关于Hadoop环境中管理大数据存储技巧。

1、分布式存储传统化集中式存储存在已有一段时间。

但大数据并非真的适合集中式存储架构。

Hadoop设计用于将计算更接近数据节点，同时采用了HDFS文件系统的大规模横向扩展功能。

虽然，通常解决Hadoop管理自身数据低效性的方案是将Hadoop数据存储在SAN上。

但这也造成了它自身性能与规模的瓶颈。

现在，如果你把所有的数据都通过集中式SAN处理器进行处理，与Hadoop的分布式和并行化特性相悖。

你要么针对不同的数据节点管理多个SAN，要么将所有的数据节点都集中到一个SAN。

但Hadoop是一个分布式应用，就应该运行在分布式存储上，这样存储就保留了与Hadoop本身同样的灵活性，不过它也要求拥抱一个软件定义存储方案，并在商用服务器上运行，这相比瓶颈化的Hadoop自然更为高效。

2、超融合VS分布式注意，不要混淆超融合与分布式。

某些超融合方案是分布式存储，但通常这个术语意味着你的应用和存储都保存在同一计算节点上。

这是在试图解决数据本地化的问题，但它会造成太多资源争用。

这个Hadoop应用和存储平台会争用相同的内存和CPU。

Hadoop运行在专有应用层，分布式存储运行在专有存储层这样会更好。

之后，利用缓存和分层来解决数据本地化并补偿网络性能损失。

3、避免控制器瓶颈(ControllerChokePoint)实现目标的一个重要方面就是——避免通过单个点例如一个传统控制器来处理数据。

反之，要确保存储平台并行化，性能可以得到显着提升。

此外，这个方案提供了增量扩展性。

为数据湖添加功能跟往里面扔x86服务器一样简单。

一个分布式存储平台如有需要将自动添加功能并重新调整数据。

4、删重和压缩掌握大数据的关键是删重和压缩技术。

通常大数据集内会有70%到90%的数据简化。

以PB容量计，能节约数万美元的磁盘成本。

现代平台提供内联(对比后期处理)删重和压缩，大大降低了存储数据所需能力。

5、合并Hadoop发行版很多大型企业拥有多个Hadoop发行版本。

可能是开发者需要或是企业部门已经适应了不同版本。

无论如何最终往往要对这些集群的维护与运营。

一旦海量数据真正开始影响一家企业时，多个Hadoop发行版存储就会导致低效性。

我们可以通过创建一个单一，可删重和压缩的数据湖获取数据效率6、虚拟化Hadoop虚拟化已经席卷企业级市场。

很多地区超过80%的物理服务器现在是虚拟化的。

但也仍有很多企业因为性能和数据本地化问题对虚拟化Hadoop避而不谈。

7、创建弹性数据湖创建数据湖并不容易，但大数据存储可能会有需求。

我们有很多种方法来做这件事，但哪一种是正确的这个正确的架构应该是一个动态，弹性的数据湖，可以以多种格式(架构化，非结构化，半结构化)存储所有资源的数据。

更重要的是，它必须支持应用不在远程资源上而是在本地数据资源上执行。

已有设备如何利用？

服务器可以利旧，但要注意兼容性列表和稳定性。

如上介绍，超融合完全基于 x86 、ARM等架构的通用服务器构建，所以用户已有服务器是可以用来构建超融合系统。但需要注意以下几点：

1需要保证服务器以及配件都要严格符合厂商的兼容性列表要求。一般来说，服务器改造成超融合节点还需要加配 SSD、万兆网卡等配件；

2 一个集群中的硬件尽可能地保持配置统一，否则低配置节点会影响整体集群的性能

3尽管超融合的分布式存储有副本保证可靠性，但一般来说超过3年的设备不建议使用，一方面陈旧设备的使用会提升多个设备同时出现故障的概率，影响整体的稳定性；另一方面，老旧设备配件的后续采购也是一大问题。

SAN存储不能用在资源池中，但可以构建冗余的系统

由于超融合系统通过分布式存储软件和 x86 、ARM等架构的通用服务器构建了存储池，所以原有的 SAN 存储和光纤交换机都不需要整合在新系统中。在 SmartX 的客户中，部分用户会将产品用在核心生产业务中，并同时使用原有的存储构建一个冗余的系统。冗余的方式可以采用应用层面的负载均衡和冗余，也可以采用类似 Oracle Data Guard 做数据库层面的冗余（以上方式都需要增加部分服务器），从而在超融合副本等技术的保护之下，再上一层保险。既增加了业务的可靠性，又利用了原有的设备。

服务器服务器是指在网络环境下运行相应的应用软件，为网上用户提供共享信息资源和各种服务的一种高性能计算机，英文名称叫做SERVER。

服务器既然是一种高性能的计算机，它的构成肯定就与我们平常所用的电脑（PC）有很多相似之处，诸如有CPU(中央处理器)、内存、硬盘、各种总线等等，只不过它是能够提供各种共享服务（网络、Web应用、数据库、文件、打印等）以及其他方面的高性能应用,它的高性能主要体现在高速度的运算能力、长时间的可靠运行、强大的外部数据吞吐能力等方面, 是网络的中枢和信息化的核心。由于服务器是针对具体的网络应用特别制定的，因而服务器又与微机（普通PC）在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面存在很大的区别。而最大的差异就是在多用户多任务环境下的可靠性上。用PC机当作服务器的用户一定都曾经历过突然的停机、意外的网络中断、不时的丢失存储数据等事件,这都是因为PC机的设计制造从来没有保证过多用户多任务环境下的可靠性,而一旦发生严重故障,其所带来的经济损失将是难以预料的。但一台服务器所面对的是整个网络的用户，需要7X24小时不间断工作，所以它必须具有极高的稳定性，另一方面，为了实现高速以满足众多用户的需求，服务器通过采用对称多处理器（SMP）安装、插入大量的高速内存来保证工作。它的主板可以同时安装几个甚至几十、上百个CPU(服务器所用CPU也不是普通的CPU，是厂商专门为服务器开发生产的)。内存方面当然也不一样，无论在内存容量，还是性能、技术等方面都有根本的不同。另外，服务器为了保证足够的安全性，还采用了大量普通电脑没有的技术，如冗余技术、系统备份、在线诊断技术、故障预报警技术、内存纠错技术、热插拔技术和远程诊断技术等等，使绝大多数故障能够在不停机的情况下得到及时的修复，具有极强的可管理性（man ability）。

通常，从所采用的CPU（中央处理器）来看，我们把服务器主要分为两类构架：

一部分是IA（Intel Architecture，Intel架构）架构服务器，又称CISC（Complex Instruction Set Computer复杂指令集）架构服务器，即通常我们所讲的PC服务器，它是基于PC机体系结构，使用Intel或与其兼容的处理器芯片的服务器，如联想的万全系列服务器，HP公司的Netserver系列服务器等。这类以"小、巧、稳"为特点的IA架构服务器凭借可靠的性能、低廉的价格，得到了更为广泛的应用，在互联网和局域网内更多的完成文件服务、打印服务、通讯服务、WEB服务、电子邮件服务、数据库服务、应用服务等主要应用，一般应用在中小公司机构或大企业的分支机构。目前在IA架构的服务器中全部采用Intel(英特尔)公司生产的CPU，从Intel生产CPU的历史来看，可以划分成两大系列：早期的80x86系列及现在的Pentium系列。早期的80x86系列可以包括：8088、8086、80286、80386、80486。自80486之后，Intel对自己的产品进行了重新命名，并进行注册，因此80486以后的产品形成了Pentium（奔腾）系列的CPU。Pentium系列的CPU目前包括：Pentium、Pentium MMX、Pentium Pro、PII、PII Xeon（至强）、PIII、PIII Xeon、P4 Xeon、Celeron2（赛扬）等。

另一部分是比IA服务器性能更高的服务器，即RISC（Reduced Instruction Set Computing精简指令集）架构服务器，这种RISC型号的CPU一般来讲在我们日常使用的电脑中是根本看不到的，它完全采用了与普通CPU不同的结构。使用RISC芯片并且主要采用UNIX操作系统的服务器，如Sun公司的SPARC、HP（惠普）公司的PA－RISC、DEC公司的Alpha芯片、SGI公司的MIPS等等。这类服务器通常价格都很昂贵，一般应用在证券、银行、邮电、保险等大公司大企业，作为网络的中枢神经，提供高性能的数据等各种服务。

目前，服务器的市场竞争非常激烈，国外有IBM、HP（惠普）、DELL（戴尔）、SUN等著名厂商，国内有联想、浪潮、曙光等一线厂商都提供不同级别的服务器产品，满足不同的用户的需求。 1按应用层次划分为入门级服务器、工作组级服务器、部门级服务器和企业级服务器四类。

入门级服务器

入门级服务器通常只使用一块CPU，并根据需要配置相应的内存（如256MB）和大容量IDE硬盘，必要时也会采用IDE RAID（一种磁盘阵列技术，主要目的是保证数据的可靠性和可恢复性）进行数据保护。入门级服务器主要是针对基于Windows NT，NetWare等网络操作系统的用户，可以满足办公室型的中小型网络用户的文件共享、打印服务、数据处理、Internet接入及简单数据库应用的需求，也可以在小范围内完成诸如E-mail、 Proxy 、DNS等服务。

工作组级服务器

工作组级服务器一般支持1至2个PⅢ处理器或单颗P4（奔腾4）处理器，可支持大容量的ECC（一种内存技术，多用于服务器内存）内存，功能全面。可管理性强、且易于维护，具备了小型服务器所必备的各种特性，如采用SCSI（一种总线接口技术）总线的I/O（输入/输出）系统，SMP对称多处理器结构、可选装RAID、热插拔硬盘、热插拔电源等，具有高可用性特性。适用于为中小企业提供Web、Mail等服务，也能够用于学校等教育部门的数字校园网、多媒体教室的建设等。

部门级服务器

部门级服务器通常可以支持2至4个PⅢ Xeon（至强）处理器，具有较高的可靠性、可用性、可扩展性和可管理性。首先，集成了大量的监测及管理电路，具有全面的服务器管理能力，可监测如温度、电压、风扇、机箱等状态参数。此外，结合服务器管理软件，可以使管理人员及时了解服务器的工作状况。同时，大多数部门级服务器具有优良的系统扩展性，当用户在业务量迅速增大时能够及时在线升级系统，可保护用户的投资。目前，部门级服务器是企业网络中分散的各基层数据采集单位与最高层数据中心保持顺利连通的必要环节。适合中型企业（如金融、邮电等行业）作为数据中心、Web站点等应用。

企业级服务器

企业级服务器属于高档服务器，普遍可支持4至8个PIII Xeon（至强）或P4 Xeon（至强）处理器，拥有独立的双PCI通道和内存扩展板设计，具有高内存带宽，大容量热插拔硬盘和热插拔电源，具有超强的数据处理能力。这类产品具有高度的容错能力、优异的扩展性能和系统性能、极长的系统连续运行时间，能在很大程度上保护用户的投资。可作为大型企业级网络的数据库服务器。

目前，企业级服务器主要适用于需要处理大量数据、高处理速度和对可靠性要求极高的大型企业和重要行业（如金融、证券、交通、邮电、通信等行业），可用于提供ERP（企业资源配置）、电子商务、OA（办公自动化）等服务。如Dell的PowerEdge 4600服务器，标准配置为24GHz Intel Xeon处理器，最大支持12GB的内存。此外，采用了Server Works GC-HE芯片组，支持2至4路Xeon处理器。集成了RAID控制器并配备了128MB缓存，可以为用户提供0、1、5、10四个级别的RAID，最大可以支持10个热插拔硬盘并提供730GB的磁盘存储空间。

由于是面向企业级应用，所在在可维护性以及冗余性能上有其独到的地方，例如配备了7个PCI-X插槽（其中6个支持热插拔），而且不需任何工具即可对冗余风扇、电源以及PCI-X进行安装和更换。

2按服务器按用途划分为通用型服务器和专用型服务器两类。

通用型服务器

通用型服务器是没有为某种特殊服务专门设计的、可以提供各种服务功能的服务器，当前大多数服务器是通用型服务器。这类服务器因为不是专为某一功能而设计，所以在设计时就要兼顾多方面的应用需要，服务器的结构就相对较为复杂，而且要求性能较高，当然在价格上也就更贵些。

专用型服务器

专用型（或称“功能型”）服务器是专门为某一种或某几种功能专门设计的服务器。在某些方面与通用型服务器不同。如光盘镜像服务器主要是用来存放光盘镜像文件的，在服务器性能上也就需要具有相应的功能与之相适应。光盘镜像服务器需要配备大容量、高速的硬盘以及光盘镜像软件。FTP服务器主要用于在网上（包括Intranet和Internet）进行文件传输，这就要求服务器在硬盘稳定性、存取速度、I/O（输入/输出）带宽方面具有明显优势。而E－mail服务器则主要是要求服务器配置高速宽带上网工具，硬盘容量要大等。这些功能型的服务器的性能要求比较低，因为它只需要满足某些需要的功能应用即可，所以结构比较简单，采用单CPU结构即可；在稳定性、扩展性等方面要求不高，价格也便宜许多，相当于2台左右的高性能计算机价格。HP的一款Web服务器HP access server，它采用的是PIII113Gbit/s左右的CPU，内存标准配置也只有128MB/256MB，与一台性能较好的普通计算机差不多，但在某些方它还是具有PC机无可替代的优势。

4按服务器的机箱结构来划分，可以把服务器划分为“台式服务器”、“机架式服务器”、“机柜式服务器”和“刀片式服务器”四类。

台式服务器

台式服务器也称为“塔式服务器”。有的台式服务器采用大小与普通立式计算机大致相当的机箱，有的采用大容量的机箱，像个硕大的柜子。低档服务器由于功能较弱，整个服务器的内部结构比较简单，所以机箱不大，都采用台式机箱结构。这里所介绍的台式不是平时普通计算机中的台式，立式机箱也属于台式机范围，目前这类服务器在整个服务器市场中占有相当大的份额。

对于信息服务企业（如ISP/ICP/ISV/IDC）而言，选择服务器时首先要考虑服务器的体积、功耗、发热量等物理参数，因为信息服务企业通常使用大型专用机房统一部署和管理大量的服务器资源，机房通常设有严密的保安措施、良好的冷却系统、多重备份的供电系统，其机房的造价相当昂贵。如何在有限的空间内部署更多的服务器直接关系到企业的服务成本，通常选用机械尺寸符合19英寸工业标准的机架式服务器。机架式服务器也有多种规格，例如1U（445cm高）、2U、4U、6U、8U等。通常1U的机架式服务器最节省空间，但性能和可扩展性较差，适合一些业务相对固定的使用领域。4U以上的产品性能较高，可扩展性好，一般支持4个以上的高性能处理器和大量的标准热插拔部件。管理也十分方便，厂商通常提供人相应的管理和监控工具，适合大访问量的关键应用，但体积较大，空间利用率不高。

机柜式服务器

在一些高档企业服务器中由于内部结构复杂，内部设备较多，有的还具有许多不同的设备单元或几个服务器都放在一个机柜中，这种服务器就是机柜式服务器。

刀片式服务器

刀片式服务器是一种HAHD（High Availability High Density，高可用高密度）的低成本服务器平台，是专门为特殊应用行业和高密度计算机环境设计的，其中每一块“刀片”实际上就是一块系统母板，类似于一个个独立的服务器。在这种模式下，每一个母板运行自己的系统，服务于指定的不同用户群，相互之间没有关联。不过可以使用系统软件将这些母板集合成一个服务器集群。在集群模式下，所有的母板可以连接起来提供高速的网络环境，可以共享资源，为相同的用户群服务。当前市场上的刀片式服务器有两大类：一类主要为电信行业设计，接口标准和尺寸规格符合PICMG（PCI Industrial Computer Manufacturer's Group）1x或2x，未来还将推出符合PICMG 3x 的产品，采用相同标准的不同厂商的刀片和机柜在理论上可以互相兼容；另一类为通用计算设计，接口上可能采用了上述标准或厂商标准，但尺寸规格是厂商自定，注重性能价格比，目前属于这一类的产品居多。刀片式服务器目前最适合群集计算和IxP提供互联网服务。

RAID是英文Redundant Array of Independent Disks的缩写，翻译成中文意思是“独立磁盘冗余阵列”，有时也简称磁盘阵列（Disk Array）。

简单的说，RAID是一种把多块独立的硬盘（物理硬盘）按不同的方式组合起来形成一个硬盘组（逻辑硬盘），从而提供比单个硬盘更高的存储性能和提供数据备份技术。组成磁盘阵列的不同方式成为RAID级别（RAID Levels）。数据备份的功能是在用户数据一旦发生损坏后，利用备份信息可以使损坏数据得以恢复，从而保障了用户数据的安全性。在用户看起来，组成的磁盘组就像是一个硬盘，用户可以对它进行分区，格式化等等。总之，对磁盘阵列的操作与单个硬盘一模一样。不同的是，磁盘阵列的存储速度要比单个硬盘高很多，而且可以提供自动数据备份。

RAID技术的两大特点：一是速度、二是安全，由于这两项优点，RAID技术早期被应用于高级服务器中的SCSI接口的硬盘系统中，随着近年计算机技术的发展，PC机的CPU的速度已进入GHz 时代。IDE接口的硬盘也不甘落后，相继推出了ATA66和ATA100硬盘。这就使得RAID技术被应用于中低档甚至个人PC机上成为可能。RAID通常是由在硬盘阵列塔中的RAID控制器或电脑中的RAID卡来实现的。

RAID技术经过不断的发展，现在已拥有了从 RAID 0 到 6 七种基本的RAID 级别。另外，还有一些基本RAID级别的组合形式，如RAID 10（RAID 0与RAID 1的组合），RAID 50（RAID 0与RAID 5的组合）等。不同RAID 级别代表着不同的存储性能、数据安全性和存储成本。但我们最为常用的是下面的几种RAID形式。

(1) RAID 0

RAID 0又称为Stripe（条带化）或Striping，它代表了所有RAID级别中最高的存储性能。RAID 0提高存储性能的原理是把连续的数据分散到多个磁盘上存取，这样，系统有数据请求就可以被多个磁盘并行的执行，每个磁盘执行属于它自己的那部分数据请求。这种数据上的并行操作可以充分利用总线的带宽，显著提高磁盘整体存取性能。

如图所示：系统向三个磁盘组成的逻辑硬盘（RADI 0 磁盘组）发出的I/O数据请求被转化为3项操作，其中的每一项操作都对应于一块物理硬盘。我们从图中可以清楚的看到通过建立RAID 0，原先顺序的数据请求被分散到所有的三块硬盘中同时执行。从理论上讲，三块硬盘的并行操作使同一时间内磁盘读写速度提升了3倍。 但由于总线带宽等多种因素的影响，实际的提升速率肯定会低于理论值，但是，大量数据并行传输与串行传输比较，提速效果显著显然毋庸置疑。

RAID 0的缺点是不提供数据冗余，因此一旦用户数据损坏，损坏的数据将无法得到恢复。

RAID 0具有的特点，使其特别适用于对性能要求较高，而对数据安全不太在乎的领域，如图形工作站等。对于个人用户，RAID 0也是提高硬盘存储性能的绝佳选择。

(2) RAID 1

RAID 1又称为Mirror或Mirroring（镜像），它的宗旨是最大限度的保证用户数据的可用性和可修复性。 RAID 1的操作方式是把用户写入硬盘的数据百分之百地自动复制到另外一个硬盘上。

当读取数据时，系统先从RAID 0的源盘读取数据，如果读取数据成功，则系统不去管备份盘上的数据；如果读取源盘数据失败，则系统自动转而读取备份盘上的数据，不会造成用户工作任务的中断。当然，我们应当及时地更换损坏的硬盘并利用备份数据重新建立Mirror，避免备份盘在发生损坏时，造成不可挽回的数据损失。

由于对存储的数据进行百分之百的备份，在所有RAID级别中，RAID 1提供最高的数据安全保障。同样，由于数据的百分之百备份，备份数据占了总存储空间的一半，因而Mirror(镜像)的磁盘空间利用率低，存储成本高。

Mirror虽不能提高存储性能，但由于其具有的高数据安全性，使其尤其适用于存放重要数据，如服务器和数据库存储等领域

(3) RAID 0+1

正如其名字一样RAID 0+1是RAID 0和RAID 1的组合形式，也称为RAID 10。

以四个磁盘组成的RAID 0+1为例，其数据存储方式如图所示：RAID 0+1是存储性能和数据安全兼顾的方案。它在提供与RAID 1一样的数据安全保障的同时，也提供了与RAID 0近似的存储性能。

由于RAID 0+1也通过数据的100%备份功能提供数据安全保障，因此RAID 0+1的磁盘空间利用率与RAID 1相同，存储成本高。

RAID 0+1的特点使其特别适用于既有大量数据需要存取，同时又对数据安全性要求严格的领域，如银行、金融、商业超市、仓储库房、各种档案管理等

(4) RAID 3

RAID 3是把数据分成多个“块”，按照一定的容错算法，存放在N+1个硬盘上，实际数据占用的有效空间为N个硬盘的空间总和，而第N+1个硬盘上存储的数据是校验容错信息，当这N+1个硬盘中的其中一个硬盘出现故障时，从其它N个硬盘中的数据也可以恢复原始数据，这样，仅使用这N个硬盘也可以带伤继续工作（如采集和回放素材），当更换一个新硬盘后，系统可以重新恢复完整的校验容错信息。由于在一个硬盘阵列中，多于一个硬盘同时出现故障率的几率很小，所以一般情况下，使用RAID3，安全性是可以得到保障的。与RAID0相比，RAID3在读写速度方面相对较慢。使用的容错算法和分块大小决定RAID使用的应用场合，在通常情况下，RAID3比较适合大文件类型且安全性要求较高的应用，如视频编辑、硬盘播出机、大型数据库等

(5) RAID 5

RAID 5 是一种存储性能、数据安全和存储成本兼顾的存储解决方案。 以四个硬盘组成的RAID 5为例，其数据存储方式如图4所示：图中，P0为D0，D1和D2的奇偶校验信息，其它以此类推。由图中可以看出，RAID 5不对存储的数据进行备份，而是把数据和相对应的奇偶校验信息存储到组成RAID5的各个磁盘上，并且奇偶校验信息和相对应的数据分别存储于不同的磁盘上。当RAID5的一个磁盘数据发生损坏后，利用剩下的数据和相应的奇偶校验信息去恢复被损坏的数据。

RAID 5可以理解为是RAID 0和RAID 1的折衷方案。RAID 5可以为系统提供数据安全保障，但保障程度要比Mirror低而磁盘空间利用率要比Mirror高。RAID 5具有和RAID 0相近似的数据读取速度，只是多了一个奇偶校验信息，写入数据的速度比对单个磁盘进行写入操作稍慢。同时由于多个数据对应一个奇偶校验信息，RAID 5的磁盘空间利用率要比RAID 1高，存储成本相对较低

RAID级别的选择有三个主要因素：可用性（数据冗余）、性能和成本。如果不要求可用性，选择RAID0以获得最佳性能。如果可用性和性能是重要的而成本不是一个主要因素，则根据硬盘数量选择RAID 1。如果可用性、成本和性能都同样重要，则根据一般的数据传输和硬盘的数量选择RAID3、RAID5