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?

 从DHCP服务器刷新ip地址

 

 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

http://qing.weibo.com/2294942122/88ca09aa330003zz.html

https://issues.apache.org/jira/browse/HDFS-347

思行合一,体验实现

律政俏佳人2这部多年前看过片子我已经记不清其中的情节了,但是这么多年来让我记在心中的是片尾Elle在国会的演讲里剪头发那个比喻。嫌头发剪的不好看?经常发生的情况是你就坐在那里,眼睁睁的看着发生的事,就让它发生了。生活工作中何尝不是常见此场景,抱怨不断,但是什么都没做,只是眼睁睁就看着它发生了,为什么不行动起来,做点什么呢?

多年后再读一遍全文,有更多的感受。

Elle Woods’ Speech:

      Thank you, congress madam.

      Hello everyone! My name is Elle Woods, and I’m here to speak to you today about a piece of legislation called Bruiser’s bill.

      But you know, today is supposed to be by education. So instead I wanna tell you about the education you all have given to me of the past 3 months. See one day, I came to Washington to help my dog Bruiser and someone along the way I’ve learned a really unexpective lesson. I know you were thinking, Who is this girl? And what could this simple small town girl from Barelare have to say to all of us? Well, I’ll tell you. It’s about something that bigger than me or any single active legislation, this is about a matter that should be of the highest importance to every America- My hair.

      You see there is a salon in Barbalyhouse, it’s really fancy and beautiful, but it’s impossible to get an appointment, I mean unless you join your robots so one of the girls is your friends or you can just forget it. But one day, they called me, they had an opening, so I was gonna finally to get a chance to sit in one of those secret beauty chairs, I was so excited. Then the colorist give me breathlessly brazen instead of hair-look honey, the shampoo girl, wash my hair with perm solution instead of color intensive moisture strengthen conditioning shampoo, finally the stylist give me a bob, with bangs. Suppose to say, I was just wrong, all wrong, for me, you know? First I was angry, and then I realize my anger was complete misrouted, I mean, this wasn’t the salon’s fault, I had sat there and witness this injustice, and I just let it happen. I didn’t get involved in the process. I forgot to use my voice. I forgot to believe in myself. But now I know better. I know that one honest voice can be louder than a crow, I know that if we lose our voice, or we let those who speak on our behalf compromise our voice, well then this country, this country is infer a really bad hair cut. So speak up America, speak up! Speak up for the home of the brave; speak up for the land has the free gifts with purchase, Speak up America, Speak up!

       And remember, you are beautiful!

      Thank you.

谢谢你们,国会的女士
各位好!我是ELLE WOODS,我今天来这里是讲述给大家被称为Bruiser’s bill的一条法规。
各位知道,今天的社会是通过教育实现的.所以我想给各位讲述过去3个月你们给我的教育.
一天,我来华盛顿帮助我的狗狗Bruiser和我学到的没有预料到的一课.
我知道你们一定正在想,这个女孩是谁呢?这个来自BARELARE小镇的女孩会对我们说什么呢?
好的,我来告诉大家,它是关于比我或是任何单一积极的法规大许多,这是有关对每个美国人都最为重要的一件事情.
你们知道在BARBALYHOUSE有一个沙龙,它是非常有魔力的,不过要预约到他们的服务是很难的,除非你加入到明星们的行列中或是你能够忘记它。
然而有一天,他们对我开放了,我最终能得到机会坐到这些秘密而漂亮的椅子上,我异常兴奋。
接下来理发师把我的头发弄成屏息状以及黄铜色的头发,而不是我头发真正的蜂蜜颜色。洗头的女孩用烫发洗液为我洗头发而不是用护发素,最后发型师给我剪了一头短发,像邦士一般可笑。
我猜想,我错了,完全错了,你们明白吗?首先我生气了,
然后我意识到我的气愤是被误导了,我明白了,这不是沙龙的错
我坐在那里,眼睁睁的看着发生的事,就让它发生了。
我没能身处其中,我忘了使用发言权,忘了自信。我知道一个诚实的声音要比咯咯笑更响亮,
我知道 如果我们丧失自己的声音,或是我们让那些代表我们发言的人使得我们的声音妥协,
那么这个国家,一定是糟糕的发型。所以 大声说 美国,大声点!为了勇敢的祖国,为了土地有购买礼物的自由,大声说 美国,大声说!
记住,你是最美丽的!
Thank you.

 

国产列式数据库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上面的服务吧。重启后正常了。

 2.6G的文件,5分多加载完毕。大约8MB/s。应该说还是没达到预期,文件是存储在227上面,本地节点加载速度不受网络限制,2个外部节点网络占用也才2MB多。但是这个性能不好比较,一个是我们测试机器不太好,网络也是百兆的网络。我用oracle单机sqlldr加载耗时 6m15.485s。也是通过百兆网络加载。

加载完以后到各台服务器/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的集成测试。

 

 

 

 

 

 

 

国产列式数据库GBASE 8a 集群版评测(1)

这段时间在研究大数据,对列式数据库也有一些了解,老大发了邮件说了一个国产的列式数据库GBASE,号称比oracle快10-20倍。说实话,操作系统,数据库,这样的核心技术我不认为国内有这样的实力能完全国产化自主研发,有也是基于开源技术的重新包装,有了源代码就真能掌握其中原理?而开源技术的闭源实现生命力不会持久,例如国产的linux,国产的ophone,国产office,哪个最后也没有推广开,这方面不崇洋不行。虽说有疑虑,搞技术还是要数据说话,空谈无用。

前两周GBASE销售到公司对GBASE做了交流,先对技术特点作了介绍,并讲解了一些和oracle,Greenplum,Teradata,Sybase IQ的对比测试案例,因为主题大致也和我的目前工作相关,所以老大指定我来负责公司内部的GBASE学习。GBASE看起来听起来都不错。但是做技术的都知道,没有one thing for all的解决方案,所有的解决方案都是只有在特定场景,特定规模下才是最优的。有点很好,更要知道其局限性,才能在后续项目选型中使用。

 

先简单按交流上的内容介绍下GBASE 8a

真正的列存储RDBMS体系架构。 数据加载高效:装载数据速度大于1TB/小时。

可扩展性:单个集群可达到128个节点,PB级的数据库。

压缩优势:轻量级数据压缩,数据不膨胀,启动高级压缩可以达到1:10以上的综合压缩比,压缩状态下查询性能不下降。

并发优势:读写没有互斥,MVCC的支持,边入库边查询,并发用户大于2000。 支持海量数据存储、查询。 数据分布的灵活性:基于策略的数据加载模式。

集群架构优势:偏平架构,无SPOF,无master瓶颈,高扩展性。

集群调度优势:网络带宽需求小。

并行优势:充分利用现代多核CPU资源。

易用性:不用特殊索引,调优,物化视图等。

可靠性:支持全量,增量备份/恢复。

易于维护:支持集群在线扩展。

高可用:支持数据冗余,自动故障探测和管理,自动fail over,自动同步。

高效率:智能索引对统计分析的高效率。

安全,监控能力:支持用户权限管理,提供图形化管理诊断工具。

  1. GBASE是一个列式数据库,列式数据库的优缺点我就不在说了

列式数据库的压缩会比较好做,尤其是一些唯一值比较少的,可以通过系统内部生成的代码表进行对照替换,尽管原来列中可能是一些较长的字符,通过自动代码对照,可以变成类似0,1这样的简单存储.

但是列式数据库有个普遍的问题是,只有在读取,或者更新的列数和总列数占比较低的时候才有性能优势,如果操作的列数接近于总列数,性能很可能会低于行式数据库,在后面的提问时间我也有问道这个问题,gbase这个性能的拐点大约在总列数的70%左右。就会下降到大约与oracle一致。而目前的ETL工具基本根据主键全字段更新,这个就严重影响性能。这个我下篇会做个具体的评测。

2.另外一个比较有特色的地方就是所谓的智能索引

这个图有点不太好理解,实质就是存储的时候数据每64k形成一个data cell(dc) ,这个有点像oracle的data block,然后对这个dc的常见的一些统计信息例如(max,min,count,sum,avg,null)等在加载的时候就计算好,存储下来。有了这个重要的数据,在一些简单的max,min,count,sum,avg,null操作的时候就只需要读取实现计算好的索引数据,同时还有一个很重要的作用是在读取数据的时候根据每个dc的max和min值筛选dc,可以大大减少全表扫描的IO

 

这个只能索引的ideal不错,但是后来我查资料的时候看到mysql infobright的这几张图,仔细看着是不是很眼熟??只不过这边是data pack。Gbase其实是基于mysql的,这个下篇也会具体提到。

3.集群版设计

GBASE有所谓的safegroup ,每个safegroup内至少有2台机,不能多于3台,这样就实现的所谓数据多副本存储,听着有点像那个hadoop里面的3副本存储策略。细看了这个以后其实和hadoop的多副本存储策略完全不是一回事,首先safegroup内是主备关系,只有一个节点能对外服务,浪费了机器资源,而hadoop的3个数据副本都可以直接对外提供服务。hadoop在遇到故障的时候,会自动新增副本,以将副本数保持在3份。safegroup在遇到故障的就只能靠那最多3个节点的命运了,自求多福了。

文中提到的在线扩容倒是问题不大,在线缩容这个我有点疑问,文档中说safegroup在删除的时候上面的数据全部被删除,如果是复制表问题还不大,分布式的表就有点悲催了吧,原来存在上面的数据怎么办?这个在后续的具体评测中会测试这一点。

文中的网络用的是infiniband,当时有些疑问,infiniband相对高端,而我们一般测试环境,或者生产环境也就是千兆以太网,后来问下infiniband也不是必须的,我个人觉得ppt上使用infiniband宣传的意义更大于实用。

第一部分到此结束,第二部分将介绍安装配置及使用部分,第三部分则是具体性能评测。