Hadoop 现在几乎已经成为业界在大数据上事实的标准，越来越多的企业开始采用hadoop进行数据的存储及处理。既然涉及数据处理，一个不可不提的术语就是“作业” or “job”，大量的作业必然要引入作业管理及调度，hadoop也不能例外。
传统企业中的调度工具，不管像是简单crontab，或者企业级的如control-M，很容易注意到，他们都主要考虑的是将作业分配到集群中的某一台，或者其中某几台上面运行。但是像hadoop 这种大规模分布式计算的集群，考虑都不足。通常Hadoop整个集群是作为一个整体对外服务，考虑的是集群整体资源利用的最大化，HDFS的多副本策略使得集群某一单独节点运行是否正常不再重要，hadoop的一个重要理念是移动计算而不是数据，所以hadoop会尽量在数据存储的节点进行运算，而传统调度工具需要支持这些特点就需要进行大量的改造，本文只讨论传统调度工具如何与hadoop内置调度器更好结合。作业监控部分则不在本文讨论范围内。
hadoop 的内置调度机制
在 2008 年以前，集成在 JobTracker 中的原有调度算法仅有 FIFO。在 FIFO 调度中，JobTracker 从工作队列中拉取作业，最老的作业最先。当hadoop最初出现的时候，主要是设计用来进行大型的批处理例如网页索引，日志挖掘，用户将任务提交至队列，而后集群按照提交的先后顺序执行即可，FIFO也足够用了。然后，当越来越多的数据放在hadoop集群后，另一个问题出现了，人们开始希望在多个用户间共享集群。而此时Hadoop 只支持与 JobTracker 逻辑混合在一起的单一调度器。
于是2008年5月18日有人提交了一个Improvement的issue 。HADOOP-3412 (Refactor the scheduler out of the JobTracker )，调度器从jobtracker的代码中分离出来，调度器变成可插入式的，在JobTracker中加载和调用，用户可以在配置文件mapred-site.xml中的mapred.jobtracker.taskScheduler属性中指定自己的调度器。
当前Hadoop自带的调度器随着hadoop版本的不同会略有区别，但是最常见的三种调度器，分别是FIFO（默认调度器），Capacity Scheduler （容量调度器）和FairScheduler（公平调度器）以下逐一介绍其算法及其适用场景：
1. FIFO
1.1 简介
FIFO(First In First Out)算法。所有用户的作业都被提交到一个队列中，然后由JobTracker按照作业提交时间的先后顺序选择将被执行的作业。 在hadoop的后期版本中,增加了优先级处理功能,可以通过设置mapred.job.priority属性 或者在JobClient 调用 setJobPriority() 方法来进行优先级设置(优先级可以设置为 VERY_HIGH, HIGH, NORMAL, LOW, VERY_LOW), Job scheduler在选择下一运行作业时,会选择一个最高优先级的作业，而后再根据提交时间排序,但是由于FIFO调度器不支持抢占，所以一个高优先级作业仍然可能被一个长期运行的低优先级作业所阻塞。FIFO不考虑各种作业资源需求的不同。
FIFO 是hadoop的默认调度器。
1.2 与传统调度工具的集成
FIFO方式适用于单系统，单用户的hadoop集群，作业提交给hadoop集群时一般需要传递的参数只有优先级
调度平台改造部分：
1）增加作业类型：map-reduce，hive，sqoop 。使得作业的命令行可以在调度平台中配置产生。
2）将作业的优先级转换成为hadoop标准（VERY_HIGH, HIGH, NORMAL, LOW, VERY_LOW), 并在想hadoop集群提交作业时同时设置作业优先级。
优先级设置的方法有以下两种
#1：作业源码中调用API JobConf.setJobPriority(JobPriority.NORMAL)
#2：在执行的时候在命令行中添加以下参数 -D mapred.job.priority=HIGH
实际调度中通常会由调度平台动态生成命令行的方式进行。
2.Capacity Scheduler
2.1 简介
CapacityScheduler 是Yahoo开发并捐献的，容量调度器是设计目标是让hadoop应用程序真正成为一个共享的，多租户的集群，并且使得集群的吞吐量和利用率最大化。说的有点绕口，咱们细说下容量调度器的来龙去脉。
传统上企业中每个系统都会有自己的私有服务器用来保证自己的系统在高峰情况，或者接近高峰情况下也能达到预设的SLA，而这样基本上都会导致很差的资源平均利用率，并且企业内众多的独立集群也带来更大的管理成本。
在企业内共享大规模的hadoop集群使得我们可以更加高效，低成本的使用计算资源，但是人们总是担心使用共享集群的话，如果其他系统占用了大量资源的话将会使得他们自己的应用在需要的时候无法获取足够的资源以致应用无法达到预定的SLA.
而容量调度器正是设计用来共享一个大规模的集群，并给予每个系统性能保证。中心思想是各系统按照自己计算的需要，共同投资一个hadoop集群，集群中的可用资源在各系统中分享。这样的集群有个附加的好处是单个系统可以利用别的系统的闲置计算资源进行计算，使得资源的利用更加弹性及高效。
而在各系统间共享集群就必须使系统对多租户( multi-tenancy)设计有很强的支持，因为必须给予每个系统性能保证。并且要确保集群在遇到一个异常的应用/用户/数据集等也不受影响。CapacityScheduler提供一系列严格的限制来确保一个应用/用户/队列不能消耗不恰当的集群资源，同时CapacityScheduler还限制了一个单一的用户/队列可以初始化/等待的应用程序数量来确保集群的公平使用和稳定性。
利用闲置资源有个问题，大部分的系统是一个大的项目群，里面有众多的子系统，他们希望闲置资源优先用于满足同一项目群内子系统的需求，如仍有剩余再共享给其他系统使用，[MAPREDUCE-824]提出了层次队列（hierarchical queues ）的概念，资源优先在子队列*享，如还有剩余再共享给其他队列。此功能在0.21.0版本中实现。
2.2 特性
以下是Apache Hadoop 2.0.2-alpha官方文档中的特性说明，很官方，很权威。
层次队列-层次队列的支持可以确保资源在一个系统的子队列*享，而后才允许其他队列使用空闲资源，使得资源分配更加可控及可预测。
性能保证-各个队列只分配了集群的一小部分性能，这样只有部分容量供队列进行处置。所有提交进同一个队列的应用程序都可以访问队列所分配的容量，管理员可以给每一个队列配置软性的限制或者硬性限制。
安全-每个队列都有严格的访问控制列表（ACLs） ，可以控制那个用户可以提交进入哪个队列，同时也有安全机制来保证用户不能查看 and/or 修改其他用户的程序，同样也支持按队列/按系统的管理角色。
弹性-空闲的资源可以分配给其他超过其处理容量的队列。如果将来某一个时刻先前空闲的队列再次需要这些资源，在这些资源所分配到的任务完成后，空闲资源会被重新分配给先前空闲的队列（不支持抢占）这样保证了资源以一种可预期，弹性的方式分配给队列。这个还能同时防止人为的资源孤岛，提高了集群的使用率。
多租户-提供了多种的限制来保证一个单应用/用户/队列独占队列或者集群，避免集群不堪重负。
易维护- 1）配置可动态加载，队列的定义及属性可以在运行时改变，可以将对晕乎的影响降到最低，同时也提供控制台接口可以让用户或者管理员查看当前系统中各个队列的资源分配情况，管理员可以在运行时增加队列，但是注意不能在运行时删除。2），清空队列，管理员可以在运行时停止一个队列，队列处于停止状态时已经在队列中的作业会继续完成，但是不能往里再新增作业
基于资源的调度 – 支持一些资源密集的作业，作业可以指定一个高于默认值的资源需求量，进而可以满足作业的不同的资源需求，当前，资源内存仅支持内存
上面的看起来有的复杂，还需要了解的几个很重要的特性是：
支持多用户多队列，支持多系统多用户共享集群
单个队列是FIFO调度方式，队列内可以开启优先级控制功能（优先级控制默认是关闭状态）。
支持资源共享，队列内资源有剩余时，可共享给其他缺资源的队列。
当某个tasktracker上出现空闲slot时，调度器的调度策略是，先选择资源利用率（numSlotsOccupied/capacity）低的队列，然后在队列中考虑FIFO和优先级进行作业选择，选择的时候会判断做业所在的用户资源未超限，以及有足够内存满足作业的内存需求。
计算能力调度器调度job时会考虑作业的内存限制，为了满足某些特殊job的特殊内存需求，可能会为该job分配多个slot；例如一个slot是1G内存，一个需要2G内存的程序就会被分配2个slot。fifo及公平调度器不具备此功能。
2.3 配置实例
2.4 与传统调度工具的集成
增加作业类型及优先级的需求同章节1.2，此外还需要进行队列配置
1）在调度平台上新增hadoop队列配置，配置好队列，及队列的资源限制后，可以使用调度工具指定作业在某一队列中运行。
map-reduce作业：可以在作业代码中设置代码属于的队列 conf.setQueueName(“queue1″);
或者在执行的时候在命令行中添加以下参数 -D mapred.job.queue.name=queue1
hive:在执行hive任务时，设置hive属于的队列,例如queue1:
set mapred.job.queue.name=queue1;
2）设置作业的内存资源量
通过设置一下两个属性，可以设置每个task所需要的内存量，如有必要，调度器会为每个task可以申请多个slot以获取根多内存，但最大值不超过mapred.cluster.max.map.memory.mb及mapred.cluster.max.map.memory.mb ，可以将值设置为-1以禁用此功能。
mapred.job.reduce.memory.mb
mapred.job.map.memory.mb
请注意：tasktracker需要先设置
mapred.tasktracker.vmem.reserved,
mapred.task.default.maxvmem，
mapred.task.default.maxvmem，以启用内存监控功能。
3.Fair Scheduler
3.1 简介
公平调度器是由facebook贡献的，适合于多用户共享集群的环境的调度器.
公平调度器在设计时有以下4个主要目标：
1）即使在与大作业共享集群的时候也能迅速的完成小作业。不像Hadoop默认的FIFO调度器，公平调度器可以在大作业运行时让小作业的执行也能取得执行进展，同时又不会使大作业处于资源“饥饿”状态。
2）在一个共享集群里，可以同时运行一些实验性的作业同时对集群中的生产作业提供可靠的SLA。
3）便于管理及配置，程序在遇到一些异常情况的时候也能做出合适的处理，用户也仅在他们需要一些高级功能的时候才需要进行配置。
4）支持在运行时进行重配置，而不需要重启集群。
公平调度器按资源池（pool）来组织作业，并把资源公平的分到这些资源池里。默认情况下，每一个用户拥有一个独立的资源池，以使每个用户都能获得一份等同的集群资源而不管他们提交了多少作业。按用户的 Unix 群组或作业配置（jobconf）属性来设置作业的资源池也是可以的。在每一个资源池内，会使用公平共享（fair sharing）的方法在运行作业之间共享容量（capacity）。用户也可以给予资源池相应的权重，以不按比例的方式共享集群。
除了提供公平共享方法外，公平调度器允许赋给资源池保证（guaranteed）最小共享资源，这个用在确保特定用户、群组或生产应用程序总能获取到足够的资源时是很有用的。当一个资源池包含作业时，它至少能获取到它的最小共享资源，但是当资源池不完全需要它所拥有的保证共享资源时，额外的部分会在其它资源池间进行切分。
3.2 特性
公平调度器的主要特性如下：
支持多用户多队列
资源公平共享（公平共享量由优先级决定）
保证最小共享量
支持时间片抢占
限制作业并发量，以防止中间数据塞满磁盘
3.2.1 Pools
公平调度器将作业分为‘pools’，而后在pool间公平的共享资源，每个pool内可以使用FIFO或者公平共享（fair sharing）的方式进行调度。作业在哪个pool由一个Jobconf 属性决定，“pool name property”默认取mapreduce.job.user.name，所以是每个用户一个pool，但是也可以取其他属性，例如group.name,这样就可以每个unix 组一个group。
一个通常使用的方法是把pool名称设为一个未使用的属性名，例如pool.name，而后将此值默认设为mapreduce.job.user.name，这样既可以让每个用户一个pool，也可以通过直接设置pool.name 将作业制定到一个特殊的pool。以下是一个mapred-site.xml中进行配置的简单示例：
<property>
<name>mapred.fairscheduler.poolnameproperty</name>
<value>pool.name</value>
</property>
<property>
<name>pool.name</name>
<value>${mapreduce.job.user.name}</value>
</property>
3.2.2 最小份额
通常情况下，活动的pool（内有作业的）会在集群中平分map和reduce的slots，但是也可以对指定的pool设置一个最小的map和reduce的slot的份额。这样pool在活动时就会给予指定的slot数量，即便公平份额是小于指定的份额。这样设置以后在非生产作业与生产作业共享hadoop集群的时候对保证生产作业的SLA非常有用。最小份额的设置有以下3个影响
1）pool的公平份额会大于等于其设置的最小份额，slot会冲其他pool的份额中取缺额以达到pool预设份额，有个例外是如果每个活动pool的最小份额加起来大于集群中全部slot的数量，如果遇到这种情况，每个pool中的份额都会成比例的缩小。
2）少于其最小份额的pool会在slot有空闲时最先获得slot。
3）可以给pool设置一个抢占超时（preemption timeout）属性，如果获得的slot不足最小份额，允许其杀死其他作业的task来获得slot，带抢占的最小份额实际使用起来有点像SLA。
请注意，如果一个pool不是活动的，其最小份额并不会被预留，slot会分配给其他pools。
3.2.3 抢占
就像上一小节说到的那样，调度器会将一个pool中作业的task杀死一边满足另一个pool的最小份额，我们把这样的动作成为抢占，准确的说这个称为最小份额抢占（min share preemption），因为还有一个类型的抢占称为公平份额抢占（fair share preemption），如果pool间slot份额未公平共享，也自动会将作业的task杀死以公平分配slot。公平份额的抢占远比最小份额抢占保守，因为未获得公平份额的作业通产是一些非生产的作业，可以容忍一定程度的不公平，公平份额抢占只有在一个pool只获得低于一半的公平份额，并且达到一个预设的抢占超时后才会发生，这个超时通常会设置的比较高（例如10分钟）
两种抢占调度器都会从过度调度的pools中杀死最近启动的一个task，以使抢占导致的资源浪费降到最低。
3.2.4 运行作业限制
公平调度器可以限制每个pool，每个用户可以并行运行的作业。这样就可以有效限制集群上产生的中间文件，作业根据提交时间和优先级运行，如果提交的作业超过限制则会等到正在运行的作业完成后再调起。
3.2.5 作业优先级
在pool内，无论pool内的调度模式是FIFO还是公平共享（fair sharing）都可以使用优先级来控制作业调度。
1）在FIFO的pools中，作业使用hadoop的默认调度器FIFO,首先根据优先级，而后根据提交时间排序决定下一调起作业。
2）在公平共享的pools中，作业优先级被用来设置作业的权重以控制作业所得到的slot份额，普通优先级的权重是1.0，每个优先级级别间权重为上一级别的两倍。例如一个高优先级的权重为2.0，这样他就得到普通优先级两倍的slot份额。
3.2.6 pool 权重
pool可以赋予权重以使集群中的资源不公平的共享。例如一个权重设为2.0的pool得到一个设为1.0的pool的两倍的份额。
3.2.7 延迟调度
公平调度器包含一个延迟调度的算法以提高数据的本地性。hadoop的一个重要理念是移动计算而非移动数据，计算尽量在存储数据的节点上运行，但是公平调度的算法是总是将slot分配给份额比较少的pool中的第一个作业，这就引起作业的数据本地性很差，需要通过网络将数据传输到本地。 1）如果队列头的作业是一个小作业，那么在集群的一个心跳期间接受到的数据就是作业所需的本地数据的几率会很低，从而如果我们总是将slot分配给队列头作业的话，小作业的本地性就会很差。
2）公平调度器有个很强的趋势是给作业分配刚刚完成task的slot，因为当一个task完成，作业就低于其公平份额，
延迟调度算法可以暂时的牺牲公平性来提高数据的本地性，如果队列头的任务无法在tasktracker中进行一个本地任务，他会发出心跳，并且跳过，这样其他的运行作业就会根据pool份额和pool内的调度规则来寻找一个可以运行本地task的作业，但是如果队列头的作业等待的了足够长的时间，他就会允许在数据同一机架的服务器上调去，如果再有足够长的时间，就会允许在不同机架上调起。这个延迟的时间被称为本地延迟（locality delays），通常只延迟几秒就已经足够答复提供数据的本地性。本地延迟在mapred-site.xml中设置，可以设置为0表示禁用。默认值设为1.5倍心跳时间。
3.2.8 管理
公平调度器包含一个web界面可以显示活动pools，作业和其公平公平份额，将作业在pool间移动或者改变作业的优先级。同时，作业的配置文件在被改变时会自动重新加载以便在运行状态下自动重配置。
3.2.9 调度算法
公平分享的一个简单的实现方式就是，无论何时一个slot空闲下来，就将其分配到运行task数最少的那个pool，这样就保证了各个pool间获得相等的slots，除非pool的需求少于其公平份额，那多余的slots就会在其他pool间平分。一下两个特性让公平调度器的算法更加复杂
1） Pool权重意味着某些pool会获得根多的slots，例如一个权重为2的pool获得的slots就会比一个权重为1多两倍，这个通过把调度算法改为将slot分配到runningTasks/Weight 最小的pool来实现。
2）最小份额意味着少于其最小份额的pool会最先得到slots，当我们把pools排序来选择下一个调度的pool时候，我们将少于其最小份额的pool放在大于其最小份额的pool前面，而那些小于其最小份额的pool通过其少于最小份额的比例进行排序。
公平调度器采用一个层次的调度来分配tasks，首选根据如上策略选择一个pool来分配task，而后pool内通过fifo或者fair sharing 来进行作业的内部调度。
3.2.10 fair share 计算
最后再说一下pool的公平共享量的计算方法。公平共享量是基于最小共享量和共享资源量计算得到的，它反映的是某个pool经过资源共享（某些pool的资源用不了，会自动共享给其他pool）之后，一共可以获取的资源总量，一般会大于等于最小共享量。
如果每个pool没有配置最小共享量，且提交了无限量的作业，则让每个pool的slotsAssigned / weight值相同即可。（其中slotsAssgined表示分配给该pool的slot数，weight表示pool的权重）。
而有了最小共享量minShare和pool中的需求量demand（该pool中所有作业尚需的slot总数）后，计算公平共享量fairShare需注意以下两种情况：
（1） 某些pool中的最小共享量可能用不完
（2） 给配给某些pool的资源量小于其最小共享量
考虑到以上两种情况，调度器设计了基于比率R的公平资源分配方法（设集群中资源总量为totalSlots）：
[1] 如果一个pool的demand<R*weight，则该pool的fairShare=demand
[2] 如果一个pool的minShare>weight，则该pool的fairShare=minShare
[3] 除此之外，所有pool的fairShare=R*weight
[4] 所有pool的的fairShare之和应为totalSlots
通过以上算法计算出的公平共享量即为“公平调度器”的“公平”含义之所在，应尽量保证每个pool获取的资源量为fairshare，如果一定时间期限内达不到，则抢占资源。
r的算法详见下图：
3.3 与传统调度工具的集成
集成上与2.4节类似，调度服务器通过使用不同的操作系统用户调起作业进入合适的pool。
参考资料
——————————————————————————————————
【1】 Hadoop 中的调度
【2】Refactor the scheduler out of the JobTracker
【4】Hadoop MapReduce Next Generation – Capacity Scheduler
【5】（MAPREDUCE-824）Support a hierarchy of queues in the capacity scheduler
LoadRunner结果分析
本文为技术部朱晖同学做LR压力测试时的原创文章。
针对吞吐率和TPS的关系，这个在结果分析中如何使用，就个人经验和朋友讨论后，提出如下建议指导，欢迎同僚指正。
相关定义
- 响应时间=网络响应时间+应用程序响应时间
- 响应时间=(N1+N2+N3+N4)+(A1+A2+A3)
- TPS：Trasaction per second也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息来估计得分。客户机使用加权协函数平均方法来计算客户机的得分，测试软件就是利用客户机的这些信息使用加权协函数平均方法来计算服务器端的整体TPS得分。一般来说系统的TPS取决于系统事务最低处理能力的模块的TPS，经验值10-100
- HPS:Hit per second也就是点击数/秒，指的是一秒钟的时间内用户对WEB页面的链接、提交按钮等点击的总和。一般与TPS成正比关系，是衡量B/S系统的一个主要指标
- Throughput/s:吞吐率，指的是每秒系统处理的客户的请求的数量，也可以理解为单位时间内客户接收到的服务的反馈量
- 吞吐率：测试过程中每秒从服务器返回的字节数。
从定义上来看，如果TPS很小，但是吞吐率比较大，说明服务器的返回的页面文件(字节数)是比较大的，此时根据页面细分图，如果存在页面问题，考虑页面压缩。
还应根据A1—A3，N1—N3实际考虑。
如果A1或者A3比较大，说明webserver处理可能存在问题，如果A2比较大，则说明DBserver处理存在问题，建议sql优化。
当增大系统的压力(或增加并发用户数)时，吞吐率和TPS的变化曲线呈大体一致，则系统基本稳定。
若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，同时TPS也趋于平坦，查看系统资源使用，如果资源使用率比较低，说明服务器硬件资源不存在问题，查看网络流量，估计网络带宽存在问题。
同理若点击率/TPS曲线出现变化缓慢或者平坦, 点击率(用户每秒发出的请求数)如果在压力增加时，趋于平坦，很可能是服务器响应时间增加，观察服务器资源使用情况，确定是否是服务器问题。
TPS是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息来估计得分。客户机使用加权协函数平均方法来计算客户机的得分，测试软件就是利用客户机的这些信息使用加权协函数平均方法来计算服务器端的整体TPS得分。
一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。依据经验，应用系统的处理能力一般要求在10-100左右。不同应用系统的TPS有着十分大的差别，一般需要通过性能测试进行准确估算。
经验分析：
1、当增大系统的压力(或增加并发用户数)时，吞吐率和TPS的变化曲线呈正比变化，则系统基本稳定
2、若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，同时TPS也趋于平坦，查看系统资源使用，如果资源使用率比较高，则说明服务器硬件资源存在问题，需要拓展硬件或者优化应用。反之，则说明服务器硬件资源不存在问题，查看网络流量，估计网络带宽存在问题。
3、点击率/TPS曲线出现变化缓慢或者平坦,很可能是服务器响应时间增加，观察服务器资源使用情况，确定是否是服务器问题或者应用问题
windows 7 下手工增加路由时ROUTE METRIC值异常问题
公司里面采用DHCP进行IP地址分配，但是我想将默认路由指向自己的vpn服务器，这样便可无缝*，但是有时候出现问题，因为DHCP设置的IP租用时间是6个小时，在手工设置路由后，6个小时后ip会自动刷新，这样就会出现两个默认网关，DHCP的默认网关的metric值可能会大于手工指定的metric值。
下图是DHCP后得到的路由表
手工设置新路由，指定metric值为5
C:\Users\dean>route delete 0.0.0.0
OK!C:\Users\dean>route add 0.0.0.0 mask 0.0.0.0 172.16.130.223 metric 5
OK!
显示新路由表，metric是25？
ipconfig /renew
使用netsh看看metric设置，总metic指等于interface metric +gateway metric，这个和xp有区别。
netsh interface ip show address
interface的metric可以在ipv4的高级选项中手工设定。
Hadoop 各商业发行版之比较
Hadoop的发行版除了社区的Apache hadoop外，cloudera，hortonworks，mapR，EMC，IBM，INTEL，华为等等都提供了自己的商业版本。商业版主要是提供了专业的技术支持，这对一些大型企业尤其重要。每个发行版都有自己的一些特点，本文就各发行版做简单介绍。
2008 年成立的 Cloudera 是最早将 Hadoop 商用的公司，为合作伙伴提供 Hadoop 的商用解决方案，主要是包括支持，咨询服务，培训。2009年hadoop的创始人 Doug Cutting也任职于 Cloudera 公司。Cloudera产品主要为CDH，Cloudera Manager，Cloudera Support。CDH是Cloudera的hadoop发行版，完全开源，比Apache hadoop在兼容性，安全性，稳定性上有增强。Cloudera Manager是集群的软件分发及管理监控平台，可以在几个小时内部署好一个hadoop集群，并对集群的节点及服务进行实时监控。Cloudera Support即是对hadoop的技术支持。cloudera的标价为每年每个节点4000美元。
2011年成立的Hortonworks是雅虎与硅谷风投公司Benchmark Capital合资组建的公司。公司成立之初吸纳了大约25名至30名专门研究Hadoop的雅虎工程师，上述工程师均在2005年开始协助雅虎开发Hadoop，这些工程师贡献了hadoop 80%的代码。。雅虎工程副总裁、雅虎Hadoop开发团队负责人Eric Baldeschwieler出任Hortonworks的首席执行官。Hortonworks 的主打产品是Hortonworks Data Platform (HDP)，也同样是100%开源的产品，HDP除了常见的项目外还包含了Ambari，一款开源的安装和管理系统。HCatalog，一个元数据管理系统。
HDP的Datasheet中描述的版本特点是
集成和测试封装 – HDP包括稳定版本的Apache Hadoop的所有关键组件，集成和测试封装。
安装方便– HDP包括一个现代化的，直观的用户界面的安装和配置工具。
管理和监控服务 – HDP包括直观的仪表板，为监测集群和建立警示。
数据集成服务 – HDP包括Talend大数据平台，领先的开源整合工具，轻松连接Hadoop集群，而无需编写Hadoop代码的数据系统集成工具。
元数据服务 – HDP包括的Apache HCatalog，从而简化了Hadoop的应用程序之间和Hadoop和其他数据系统之间的数据共享。
高可用性– HDP与成熟的高可用性解决方案的无缝集成。
定价以集群为基础，每10个节点每年为12500美元。
cloudera和hortonworks均是在不断的提交代码完善Apache hadoop，而2009年成立的MapR公司在Hadoop领域显得有点特立独行，它提供了一款独特的发行版 。Hadoop在性能（在当前Hadoop的设计中，所有的meta data操作都要通过集中式的Namenode来进行，Namenode有可能是性能的瓶颈；M/R 应用程序需要通过DataNode来访问HDFS, 这就涉及到格外的进程切换和网络传输开销），可靠性与扩展性（namenode，jobtracker单点问题），企业级应用上的弱点（比如完全可读写的文件系统，snapshot，mirror等等）各大厂商均知，MapR则认为，Hadoop的这些缺陷来自于其架构设计本身，小修小补不能解决问题。他们选择了一条艰难得多的路： 用新架构重写HDFS，同时在API级别，和目前的Hadoop 发行版保持兼容。这家2009年成立的创业公司，在蛰伏了两年之后，终于一鸣惊人，大放异彩。他们成功的“构建一个HDFS的私有替代品，这个替代品比当前的开源版本*倍，自带快照功能，而且支持无Namenode单点故障（SPOF），并且在API上和兼容，所以可以考虑将其作为替代方案。” mapR版本不再需要单独的namenode机器，元数据分散在集群中，也类似数据默认存储三份。也不再需要用NAS来协助namenode做元数据备份，提供了机器使用率。还有个重要的特点的可以使用nfs直接访问hdfs，提供了与旧有应用的兼容性。镜像功能也很适合做数据备份，而且支持跨数据中心的镜像，快照功能对于数据的恢复作用明显。据报道mapR标价也为每年每个节点4000美元。
mapR有免费和商业两个版本，免费版本在功能上有所缩减。
EMC的Greenplum HD是基于mapR版本二次开发改造而成，特点同mapR。
IBM在去年5月推出了InfoSphere BigInsights软件。该软件包括Apache Hadoop发行版、面向MapReduce编程的Pig编程语言、针对IBM的DB2数据库的连接件以及IBM BigSheets，后者是一种基于浏览器的、使用电子表格隐喻（spreadsheet-metaphor）的界面，用于探究和分析Hadoop里面的数据。IBM在平台管理，安全认证，作业调度算法，与DB2及netezza的集成上做了增强。从IBM中国开发中心信息管理总经理朱辉下面这句话就可以看出IBM对于biginsights的定位：BigInsights并没有替代OLAP（Online Analytical Processing）或OLTP（Online Transaction Processing）应用程序，但它可以整合其中，用于“过滤大量原始数据并合并结果，将结果以结构化数据的形式保存在DBMS或数据仓库中”。
传统的硬件厂商，华为，Intel也提供hadoop的版本
Intel 的商业版本，主要是强调其能提供全面的软硬件解决方案设计，针对硬件具有更好的性能优化，以及提供集群管理工具和安装工具简化了 Hadoop 的安装和配置，能够提供项目规划到实施各阶段专业的咨询服务，实际中采购Intel版本貌似动力不足。
华为在硬件上具有天然的优势，在网络，虚拟化，PC机等都有很强的硬件实力。华为的hadoop版本基于自研的Hadoop HA平台，构建NameNode、JobTracker、HiveServer的HA功能，进程故障后系统自动Failover，无需人工干预，这个也是对hadoop的小修补，远不如mapR解决的彻底。华为在hadoop社区中的Contributor和committer也是国内最多的，算是国内技术实力较强的公司。
———————————————————————————————————
各发行版大事记
mapR
2011-05-25 ：宣布与EMC合作，EMC GREENPLUM HD 提供hadoop基础版本。
2012-01-18：宣布与rainstor合作，
2012-03-05：宣布与informatica合作
2012-06-13:宣布成为Amazon Elastic MapReduce的计算选项
2012-06-28：成为Google App Engine的计算引擎
HortonWorks
2011-10-12：微软宣布将于从雅虎分拆出来的Hortonworks合作开发，在Apache Hadoop上实现搭建Windows Server以及Windows Azure平台。Hortonworks作为微软的战略合作伙伴将会借助自己在此领域的专长帮助最大化将Hadoop集成到微软的产品之中。
2011-11-02：Hortonworks，Apache Hadoop项目的一个主要贡献者，将分发Informatica HParser Community Edition。为Hadoop推出Informatica HParser。作为业界首个针对Hadoop环境的数据解析转换解决方案，Informatica HParser利用MapReduce框架的并行性以有效地在Hadoop中把非结构化复杂数据变成一个结构化或半结构化的格式。
2011-03-03 在今年3月初的Strate大会上，开源数据集成软件厂商Talend宣布与Hortonworks达成协议，将合作把Talend开源数据集成工具带入Apache
2012-03-12 ：TeraData就在周二宣布将与Hortonworks合作，并为客户提*品和服务。
2012-06-17：Hortonworks宣布将与VMware合作并推出一套运行于HDP高可靠性模式的工具。VMware的vSphere可监测Hadoop的NameNode和JobTracker服务。如果服务出现错误时，vSphere可重定向操作实时备份服务，以保持集群的运行。
Cloudera：
2011年8月5日 – 戴尔宣布与Cloudera新的合作伙伴关系
2011年10月20日 – SGI和Cloudera联合宣布，他们的公司已经签署协议，为SGI分发Cloudera的软件预装在SGI Hadoop集群中。
2012-01-26：今年1月发布的甲骨文大数据机（Oracle Big Data Appliance）将甲骨文-Sun分布式计算平台与Cloudera的Apache Hadoop发行版、Cloudera管理器管理控制台、R分析软件的开源发行版以及甲骨文NoSQL数据库结合起来。甲骨文还包括连接件，因而让数据能够在大数据机与甲骨文Exadata或传统的甲骨文数据库部署环境之间来回传送。
2012-04-26：IBM宣布将Cloudera作为Hadoop商用版本的首选大数据平台。
———————————————————————————————————————-
除了mapR以外的发行版。基本都是在Apache hadoop上做了略微改进，只有mapR与Apache hadoop有较大区别，以下表格是一些功能上的区别，EMC Greenplum HD 是基于mapR所以功能同mapR。
http://www.slideshare.net/mcsrivas/design-scale-and-performance-of-maprs-distribution-for-hadoop
http://qing.weibo.com/2294942122/88ca09aa330003wz.html
http://qing.weibo.com/2294942122/88ca09aa330003x6.html
http://qing.weibo.com/2294942122/88ca09aa330003zv.html
国产列式数据库GBASE 8a 集群版评测(2)
上一篇介绍了GBASE 8a 的技术特点，本篇主要介绍其安装及使用。
首先这个安装需求就有点蛋疼，
同一网段？大规模的集群系统还真是没见过有这种要求的，同一网段应该还是出于进行机器间广播通信的考虑？但是要求同一网段就事实上限制了集群的规模，对集群的扩展和维护造成麻烦。
同样的操作系统？？这个和集群有何关系？应该是要求集群上各台机器应用程序版本一致吧。如果安装包和操作系统版本相关，应提示用户根据系统版本选择不同的安装包，更妥当的是安装程序根据操作系统版本自动选择。
各台机器的root密码一致，这个更晕，如果是使用动态密码等的肿么办，业界上也只是要求各个用户配好机器间信任，做好无密码互访即可，貌似是出于方便用户的考虑，提供root密码就可以自动安装，但是实际部署中还是会遇到问题。
要求各节点关闭防火墙？？与其这样不如公布需要开放的端口，关闭防火墙是对企业安全策略的彻底挑战，如此设计其实也体现了对数据安全问题的不重视。
要求节点上不存在gbase用户？？程序还绑定用户名，不允许自定义安装用户？？程序里面写死了？但是其实在后面的安装步骤中，gbase的用户又是可配置的，文档又出现不一致。
上面这些问题看着都不大，但是魔鬼总在细节中，这些细节就体现了产品的开发风格，而且现在总写文档是低级的事情，都是让初级人员写，但是注意细节也是实力的体现。
安装很简单，设置好配置文件，我打算安装在3台机器上。
[root@RHELDN1 gcinstall]# cat demo.options
authkey_file_name = authkey.demo
gcluster_dba_group = gbase
gcluster_dba_user = gbase
gcluster_dba_user_password = gbase
hosts = 172.16.130.227,172.16.130.223,172.16.130.231
mcast_addr = 226.94.1.99
mcast_port = 5479
root_password = root123
source = 172.16.130.227
skip_network_test = true
然后执行 ./gcinstall.py –silent=demo.options 就开始安装了。过程很简单，等着就好。
安装完后发现配置系统内核参数的/etc/sysctl.conf 被整个替换了，我原先的内核参数配置全没了，这个真是有点狂汗。重要的系统内核参数必须让用户来修改，用户的是生产系统，而且很可能是与其他服务共用的服务器。如果内核参数不满足需求可以提示用户修改，整个文件用安装包中的无声无息覆盖的做法这个就有点过度了。而且文档中或者安装过程中没有任何的说明或者警告，要不是我看见了，就要等到其他应用莫名报错才知道了。
节点安装完毕后，下一步是建立safegroup，因为安全组之内的服务器为主备，所以我打算3个节点，分成3个安全组。这样比较能发挥出性能的优势。
gcadmin addsg –nodes 172.16.130.227 –names node1
gcadmin addsg –nodes 172.16.130.231 –names node2
gcadmin addsg –nodes 172.16.130.223 –names node3
ok，3个节点，3个safegourp，服务一切正常，现在可以开始使用数据库啦。
使用gbase用户，执行一下命令就可以登录到数据库
/opt/gcluster/server/bin/gbase -ugbase -pgbase20110531 -h127.0.0.1 -P5258
文档中特地注明，用户名固定为gbase，密码固定为gbase20110531，在安装的时候不让人设置用户名和密码就算了，居然连密码都不让改，头一次见。翻遍文档也没看见改密码说明，这是赤裸裸的数据不设防啊。数据安全如何保证？？
界面看着很眼熟？没错，这就是mysql的界面，只是mysql替换成gbase了，再看看下面两张图，熟悉mysql的同志一看就明白哈。
言归正传，不管gbase与mysql渊源如何，还是回到我们测试上，下一步是建立用户自己的database pocdb，并建立一张分布表，先熟悉下操作。
gbase> create database pocdb;
Query OK, 0 rows affected (Elapsed: 00:00:00.18)
gbase> use pocdb;
Query OK, 0 rows affected (Elapsed: 00:00:00.01)
gbase> CREATE TABLE hive_test (id int, name varchar(200)) DISTRIBUTED BY(‘id’);
Query OK, 0 rows affected (Elapsed: 00:00:00.16)
gbase> exit
Bye
下面准备利用自带的工具进行文本入库，按照文档要去建立了配置文件
[test_t]
disp_server=172.16.130.227:6666
file_list=/home/gbase/part-m-00000
format=0
node_list=node1,node2,node3
disp_type=1
hash=CRC32
hash_column=0
db_user=gbase
db_name=demodb
table_name=hive_test
delimiter=’\001′
socket=/tmp/gbase_8a_5050.sock
extra_loader_args=–parallel=3
我最近在做hadoop测试的时候生成了一个文本，刚好拿来做测试，字段的分隔符是hive的默认分隔符\001 也就是ctrl+A那个符号。在加载前需要先启动分发服务器
./dispserver –log-file=/root/gb8a/dispatch_server.log –port=6666
这个又有个蛋疼的地方，端口不可修改。。。软件的一切设置都需要配置化，这个不是很基本的要求么？动不动就写死的做法是在不可取。
[gbase@RHELDN1 ~]$ ./dispcli t.tpl
[2012-09-26 14:33:36] ERROR: “disp_type” is NOT a valid argument! (/home/gbase/dispserver/dispcli/dispcli_app.cpp:114)
刚一执行就报错，我很确信我没写错，我是copy过来的。。
#分发类型：0 为复制；1 为分布
disp_type=1 #
这个有点囧，既然报不认识自家参数，那我就注释掉这个好了。注释后继续执行。。
[gbase@RHELDN1 ~]$ ./dispcli t.tpl
Start mission [test_t] in dispatch mode…
[172.16.130.223] [START TIME: 1970-01-01 7:0:0] [100.00%] [RATE: 0.00/s] [ERROR] [BAD REC: 0] [ETA: 0 sec] [ELAPSED: 15609 days 6 hours 38 min 6 secs]
[172.16.130.227] [START TIME: 1970-01-01 7:0:0] [100.00%] [RATE: 0.00/s] [ERROR] [BAD REC: 0] [ETA: 0 sec] [ELAPSED: 15609 days 6 hours 38 min 6 secs]base/disp
[172.16.130.231] [START TIME: 1970-01-01 7:0:0] [100.00%] [RATE: 0.00/s] [ERROR] [BAD REC: 0] [ETA: 0 sec] [ELAPSED: 15609 days 6 hours 38 min 6 secs]
[gbase@RHELDN1 ~]$ echo $?
0
两G多的文件，不到5秒钟就完了，而且这个提示，看看开始时间，和耗时。。。瀑布汗啊，中间闪过一个提示说出错了，需要看gbloader的日志，日志在哪？？？路径也没提示，而且程序退出的时候连那个出错提示都没了？屏幕上的那日期是怎么回事，而且程序报错了程序的返回码还是0？这让作业调度程序情何以堪。去数据库看了看，果然，文件没有加载进去。
哪报错了，为什么，完全没头绪，当前文件下是空的，没有任何日志文件，/var/log下面也没有，后来在/tmp下找到一个日志文件dispcli.log，
2012-09-26 14:38:02 INFO: DONE (/home/gbase/dispserver/dispcli/loader_agent.cpp:252) 2012-09-26 14:38:03 Sending 37 : get_progress dispatch_id=8 vfile_id=0 (/home/gbase/dispserver/dispcli/disp_server_agent.cpp:556)
2012-09-26 14:38:03 Received 4 : +OK (/home/gbase/dispserver/dispcli/disp_server_agent.cpp:603)
2012-09-26 14:38:04 Sending 37 : get_progress dispatch_id=8 vfile_id=0 (/home/gbase/dispserver/dispcli/disp_server_agent.cpp:556)
2012-09-26 14:38:04 Received 4 : +OK (/home/gbase/dispserver/dispcli/disp_server_agent.cpp:603) 2012-09-26 14:38:04 We read from 172.16.130.227 [STDERR]: (/home/gbase/dispserver/dispcli/loader_agent.cpp:347)
2012-09-26 14:38:04 Parameter error. Delimiter input error. (/home/gbase/dispserver/dispcli/loader_agent.cpp:348)
我截取了日志文件中的一段，这个日志应该是给开发人员调试看的，完全不像一个产品面向用户的日志。里面都是一些对终端用户毫无价值的东西。终于从其中的（Parameter error. Delimiter input error. ）看出点门道，应该是分隔符的问题，估计是不支持ctrl+a这种特殊字符转义。把文本改成逗号分隔，修改配置文件后重新开始。
[gbase@RHELDN1 ~]$ ./dispcli t.tpl
Start mission [test_t] in dispatch mode…
[172.16.130.223] [START TIME: 2012-09-26 14:52:34] [N/A] [RATE: 1.83M/s] [LOADING] [BAD REC: 0] [ETA: N/A] [ELAPSED: 45 secs]
[172.16.130.227] [START TIME: 2012-09-26 14:52:34] [N/A] [RATE: 4.13M/s] [LOADING] [BAD REC: 0] [ETA: N/A] [ELAPSED: 45 secs]
[172.16.130.231] [START TIME: 2012-09-26 14:52:34] [N/A] [RATE: 2.34M/s] [LOADING] [BAD REC: 0] [ETA: N/A] [ELAPSED: 45 secs]
[gbase@RHELDN1 ~]$ ./dispcli t.tpl
[2012-09-26 14:53:50] ERROR: Can’t start load while anchor offline. (/home/gbase/dispserver/dispcli/dispcli_app.cpp:341)
开始加载以后我发现拷过来的数据文件不完整，ctrl+c中断，而后继续执行，然后发现运行不了了，出错的错误完全看不懂。。。。日志不光是给开发人员看的，一个运维友好的日志会同时写出问题可能的原因和简要处理方法。尝试重启dispatch server ，还是不行。用gcadmin看看服务器状态，有点晕，怎么宕机了一台
我在node1上按了下ctrl+c把node3的服务搞挂了？去223上面找日志看看。没找到原因，corosync的进程没了，日志里面没有任何记录。不琢磨了，先手工重启223上面的服务吧。重启后正常了。
加载完以后到各台服务器/opt/gnode/userdata/gbase/pocdb/sys_tablespace/hive_test_n[1-3]的目录下看。
每台机上大约780MB的数据，3台机加起来就有2.3G，相对与我2.6G的文件大小，压缩比不算高，oracle未压缩的表存储用了2.4G，两者相差不大，几乎相当于没压缩？？
再用greenplum试试，greenplum只有两个节点，对比下有点不太公平。greenplum也使用列式存储并开启压缩。
gpfdist -d /home/gpadmin -p 8081 >> gpfdist.log 2>&1 &
CREATE EXTERNAL TABLE ext_hive_test ( id int, name varchar ) LOCATION (‘gpfdist://172.16.130.226:8081/*.txt’) FORMAT ‘TEXT’ (DELIMITER ‘,’) ;
CREATE TABLE hive_test (id int, name varchar )with (appendonly=true,orientation=row,compresstype=quicklz,COMPRESSLEVEL=1) DISTRIBUTED BY (id);
insert into hive_test select * from ext_hive_test;
耗时6分42秒数据加载完成。
做了下简单的测试，hive_test 是124,113,600行的数据,执行dc已经预先计算好（count,sum,avg,isnull,max,min)的操作时非常快。都在零点几秒就能返回结果。这个就不和oracle比了，绝对秒杀oracle。
尝试一下group by的性能
gbase> create table hive_t1 as select id,count(id) cnt from hive_test group by id;
ERROR 1707 (HY000): GCluster DML&DDL proxy error: gcluster DML error: EXECUTE FAILED [127.0.0.1:5258], I/O operation on ./pocdb/metadata/hive_t1.GED/table.des failed with error – No space left on device File name ./pocdb/metadata/hive_t1.GED/table.des
报错了，磁盘空间满，上面写着是127.0.0.1 也就是本机，可是df查看以后本机磁盘空间完全没问题，只好每台机找过去，原来是223那台机满了，错误提示里面写出具体主机名这个应该不难吧？？这要是机器多了，真要每台机器找过去？？清理完空间，继续。。
gbase> drop table hive_t1; Query OK, 0 rows affected (Elapsed: 00:00:00.26)
gbase> create table hive_t1 as select id,count(id) cnt from hive_test group by id; ERROR 1707 (HY000): GCluster DML&DDL proxy error: gcluster DML error: EXECUTE FAILED [127.0.0.1:5258], NODE(HOST(172.16.130.223:5050), USER(root), DB(pocdb)):[GNODE(172.16.130.223:5050) execute error: Can't execute the given command because you have active locked tables or an active transaction]
又是错误。。退出gbase客户端，重新登录就又好了。
gbase> create table hive_t1 as select id,count(id) cnt from hive_test group by id;
Query OK, 124113600 rows affected (Elapsed: 00:01:54.84)
奇怪的是我在oracle上执行同样操作只花了57秒？？当然我这个只是熟悉操作的例子，有点特例，数据只有两个字段，但是我只用了其中一个字段，按理gbase读取的数据量只有oracle的一半，两台机配置其实是大致相同的。测试的想起来，直接和oracle比有点不公平，gbase上数据是压缩的，而我oracle上没压缩，于是我启用的oracle上的表压缩。发现表只占了1.7G的空间？？上文提到了GBASE是占了2.3G，是gbase的压缩没生效？？还是3个节点上的780MB其实就是完整数据了？不需要乘以3 。那就可以理解，但是如果单节点上的就是完整副本的话，每个节点上的表的数据文件大小应该是完全一致的，可是实际上并不是。所以我只能理解为gbase的压缩根本就没生效。
将oracle表压缩后，oacle重新执行上文中的group by语句只花了44秒。相对于未压缩前有了13秒的提升，由于瓶颈一般还是在I/O上面。而压缩后数据从2.4G下降到1.7G。oracle的表现很正常。
greenplum 花了6分37秒，这有点让我没想到。当然还是不排除是机器或者配置未经调整的原因，虽然这三个数据库都是默认参数未调整。
对sql的操作的熟悉先简单到这里，具体复杂的案例评测放在下一篇。
GBASE系统介绍中提到safegroup的有个很重要的功能是failover，这也是任何系统必备的功能了。而我目前每个safegroup只有一台机，很明显没办法做这个测试了，上文中也提到，任意一台服务宕机会立刻导致集群不可用。所以打算在新增一台机器，加入到其中一个safegroup中，这样停掉safegroup中的一台机集群应该还是正常服务。
翻手册的时候又郁闷了，只有新增，或者删除整个safegroup，没有往已有的safegroup中新增或者删除节点的命令。删除整个safegroup，再重新创建？手册上又说删除后数据有丢失，重新创建也不一定能找回，那分布表的数据怎么在safegroup删除前转移？手册中无解。。。这个应该是实际运维中的合理需求吧？难道要手工改集群配置文件？？这其实是研发项目的普遍问题，考虑问题的时候理想化，对实际运维考虑不足。
鉴于管理员手册中对此无解，我只好尝试删除掉一个safegroup，而后使用两个node进行重建，数据丢失也不管了，反正我只是在测试，大不了重新加载。
因为没机器，只是临时新建一台虚拟机，做HA的测试，测试完后恢复到每个safegroup单节点运行。
gcadmin removesg sg03
gcadmin addsg –nodes 172.16.130.223,172.16.130.226 –names node3,node4
再用gcadmin看看服务一切正常。不错，没有了恼人的错误，是个良好的开始，
gbase> SELECT count(id) FROM pocdb.hive_test;
+———–+
| count(id) |
+———–+
| 82725725 |
+———–+
1 row in set (Elapsed: 00:00:00.10)
糟糕，数据果然少三分之一，这个验证了两个事情，一是数据确实按照id均匀分布在3个safegroup了，二是重建safegroup的方法是不行地。没关系。咱什么场面没见过，哥重新加载。。重新加载的时候莫名报错，看看gcadmin的状态，有问题，223的datastate变成2了，2是什么意思？不知道。文档中说要执行gcadmin sync 命令进行数据同步，为什么不同步了？不知道。反正就按照文档上同步吧。
执行gcadmin sync 172.16.130.223 进行数据同步，好，继续加载。。还是报错，
说到gcadmin sync 这个命令，要多说一句，在sync的有个步骤是将safegroup上的数据文件用scp 复制到另外一台上，这如果文件上百GB以后，还是很耗时间的，再说有必要全量复制么？其中还有个步骤是将集群状态设为readonly，这个可以理解，使用scp的话不这么来数据无法保持一致，这又对集群可用性造成了影响，所以sync这个功能还是设计的不够优秀。作为生产运维管理员，你敢随便sync么？
[root@rhel231 /]# cat ./home/gbase/hive_test_n2.gbl_report
2012-09-26 22:52:12.926 Reading from the input file error: Resource temporarily unavailable
2012-09-26 22:52:12.948 Error: kill by signal.
2012-09-26 22:52:12.968 Loader error exit: Operation cannot be accomplished in current state
2012-09-26 22:52:12.968 rollback done…
这个报错是啥意思？增加了网络超时时间，还是不管用，我drop掉表，重建试试，如果还不行，我只好重建数据库了。结果重建表以后直接Segmentation fault 了。只好使出大招，重建数据库。
gbase> drop database pocdb;
ERROR 1707 (HY000): GCluster DML&DDL proxy error: gcluster database error: Cluster at risk, more than 2 safegroup the node number is equal to 1,EXECUTE FAILED [172.16.130.227:5258], gcluster database error: EXECUTE FAILED [127.0.0.1:5050], Unknown table ‘hive_test_n1′
gbase> show databases;
+——————–+
| Database |
+——————–+
| information_schema |
| gbase |
| gctmpdb |
| pocdb |
+——————–+
4 rows in set (Elapsed: 00:00:00.00)
gbase> drop database pocdb;
ERROR 1707 (HY000): GCluster DML&DDL proxy error: gcluster database error: Cluster at risk, more than 2 safegroup the node number is equal to 1,EXECUTE FAILED [172.16.130.223:5258], gcluster database error: EXECUTE FAILED [127.0.0.1:5050], Can’t drop database ‘pocdb’; database doesn’t exist
好了。熟悉的错误又来了，也懒得drop database了，直接创建个新的吧。结果新的还是报错，伤不起的测试。。。
注意到日志里面提示
2012-09-26 23:04:17.663 Reading from the input file error: Resource temporarily unavailable
根据经验应该是虚拟机的资源不够所致，我只是测试HA，于是减少了测试数据量，head 一万行出来加载入库。果然就成功了。但是count一下却有九千多万行，应该是之前加载报错的时候没有回滚所致，这个问题在生产上很可能就导致数据重复加载，处理起来就麻烦了。
而后我停掉safegroup3中的一台机223，却登录不上数据库了。
gbase> use pocdb2;
ERROR 1707 (HY000): GCluster DML&DDL proxy error: Can’t connect to GBase server on ’172.16.130.223′ (115) gbase>
我启动223，关掉226，却又执行sql成功了？？是223作为safegroup的主服务器？所以关掉226没关系，但是不能关223？单独启动223的时候执行sql正常，而后启动226，手工做数据同步，再次关掉223，再次出现同上错误，无法连接数据库。但是已经连接上的绘画还是可以执行一些select操作，但是无法进行ddl，
gbase> create table pocdb2.t3 as select id,count(id) cnt from pocdb2.hive_test group by id;
ERROR 1708 (HY000): gcluster command error: Current operation is denied when the cluster is locked.
gcadmin命令显示集群状态为LOCKED
所以我觉得safegroup的failover还是不够完善，没有起到应有的作用。
本章节告一段落，对数据库的安装配置有了简单认识，下一篇将按照我们日常中实际应用编写测试案列分别在gbase，oracle，greenplum上运行，而后进行TPC-H 以及和datastage的集成测试。