设计一个互联网级的大规模系统(On Designing and Deploying Internet-Scale Services)

前不久看到微软的James Hamilton 写的《On Designing and Deploying Internet-Scale Services》,觉得超棒,看完总想留下点什么,给自己出了个馊主意要把全文翻译成中文,花了一个晚上翻了3千字眼都花了。接下来我是真不想继续往下翻译,可是半途而废又心有不甘,突然想到我为啥要把丫翻译成中文,英文看着更顺,更准确啊,一下子把自己问住,是啊,自己突然脑残了。于是马上掉转方向,一个是只写总结要点了,另外一个是直接用英文了,哈,果然干起来顺畅了很多。

GDE Error: Error retrieving file - if necessary turn off error checking (308:Permanent Redirect)
GDE Error: Error retrieving file - if necessary turn off error checking (308:Permanent Redirect)

使用“智能”路由,无缝翻墙

伟大的长城已经到了让人忍无可忍的地步,查资料,文档的时候各种无理由connection reset。连slideshare都墙让人很火光。无奈只好翻墙,我现在用的是vpn,但是开了vpn有个问题,上国内网站也要绕一圈回来,速度很慢。理想的是由网关来翻墙,而后根据访问的目标ip来走不通的路由。公司的网关我没有办法改,下面是具体的在一台redhat linux 5 网关服务器上的安装vpn作为新网关的安装步骤。

大慨步骤很简单1. 连接上vpn 2.获取中国IP列表,根据列表设置路由表,国内IP走国内网关,剩余的IP统一VPN出去。

1.安装openvpn客户端

wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm

rpm -ivh rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm

yum install openvpn

而后到/etc/openvpn 目录下新建文件 vps.opvn

client
dev tap
proto tcp
remote xxx.xxx.xxx.xxx 443
resolv-retry infinite
nobind
mute-replay-warnings
redirect-gateway
ca /etc/openvpn/ca.crt
cert /etc/openvpn/rhel223.crt
key /etc/openvpn/rhel223.key
comp-lzo
verb 4

直接执行以下命令启动客户端

nohup openvpn /etc/openvpn/rhel223.ovpn &

执行ifconfig应该可以看到类似的显示,表明vpn顺利连接。

2.设置路由表

新建一个shell脚本,getip.sh  ,内容与下

#!/bin/sh

rm ip.txt
FILE=china-ip
wget http://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest -O $FILE
grep ‘apnic|CN|ipv4|’ $FILE | cut -f 4,5 -d’|’|sed -e ‘s/|/ /g’ | while read ip cnt
do
echo $ip:$cnt
mask=$(cat << EOF | bc | tail -1
pow=32;
define log2(x) {
if (x<=1) return (pow);
pow–;
return(log2(x/2));
}
log2($cnt)
EOF
)

echo $ip/$mask >>ip.txt
done

新建一shell脚本,addroute.sh 内容如下:

#!/bin/bash

VPS=”209.141.50.182″
#current default gw
GW=’172.16.131.254′
CNLIST=”ip.txt”

#VPS
route add -host $VPS gw $GW
#lan addr
route add -net 172.16.130.0/23 gw $GW
#change default gw
route add default dev tun0

for i in `cat $CNLIST`
do
route add -net $i gw $GW
done

而后执行两个shell,路由表就应该设置完成,执行route命令应该看到如下图的结果 

3.网络设置

编辑/etc/sysctl.conf 文件,将net.ipv4.ip_forward = 0 从0改为1

而后执行sysctl -p 命令将设置生效

而后执行以下命令允许不同网卡间转发,及做nat

iptables -A FORWARD -i eth0 -o tap0 -j ACCEPT
iptables -A FORWARD -i tap0 -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.16.130.0/23 -o tun0 -j MASQUERADE

到此变结束了。

在windows的客户端上执行以下命令,设置路由,将局域网内服务器指向原默认网关,而新默认网关指向新的有vpn的服务器,即可。

route delete 0.0.0.0
route add 172.6.0.0 mask 255.255.255.0 172.16.131.254
route add 172.16.130.0 mask 255.255.254.0 172.16.131.254
route add 0.0.0.0 mask 0.0.0.0 172.16.130.223

在windows 上执行tracert slideshare.net 和tracert baidu.com 看看效果吧。

爽爽的享受吧!!

 

留20%的时间给自己

留20%的时间给自己,很多人从是从Google那个听说了这个规则。我们这就找老大呼吁说我们要想Google一样,上班要少上一个小时,恐怕是有点痴人说梦了。上班时间的规定也许我们无力改变,但是下班时间必须由自己来安排。可是我平时回家以后要么陪伴家人,或者继续加班做工作上的事情,却忘记了自己发展的需要,新的机会时来临时,错失机会,遇到问题后。我不想再听到自己说:“我太忙,忙的没时间学习/思考/总结/运动了。”专注是一件好事,但是过于专注就让人视线狭窄,当人固步自封。磨刀不误砍柴工的故事大家都听过,下面的一个小故事也是讲述的同样的道理:

一只野猪在大树旁勤奋地磨獠牙。狐狸看到了,好奇地问它:“既没有猎人来追赶,也没有任何危险,为什么要这样用心地磨牙?”野猪答道:“你想想看,一旦危险来临就没时间磨牙了。现在磨好了利牙,等到要用的时候就不会慌张了。”这里讲的也是未雨绸缪的道理。如果平时不勤奋地“磨刀”,等机会来临,却发现自己能力不够、基础不实,亡羊补牢,那就为时已晚。

所以,请留下20%的时间给自己!

当然道理都说的很容易,我试图从昨晚开始就留点时间给自己看书及学习,女儿9点睡觉后,连上VPN只想看看hadoop集群的跑数情况,却不知不觉陷了进去,回过神来已经11点多了。改变旧有的习惯的确不容易,但是要对自己说,不要忘记我自己,自己真正的需要。

大数据异构环境数据同步工具DataX 与Sqoop 之比较

从接触DataX起就有一个疑问,它和Sqoop到底有什么区别,昨天部署好了DataX和Sqoop,就可以对两者进行更深入的了解了。

两者从原理上看有点相似,都是解决异构环境的数据交换问题,都支持oracle,mysql,hdfs,hive的互相交换,对于不同数据库的支持都是插件式的,对于新增的数据源类型,只要新开发一个插件就好了,

但是只细看两者的架构图,很快就会发现明显的不同

DataX架构图

  • Job: 一道数据同步作业
  • Splitter: 作业切分模块,将一个大任务与分解成多个可以并发的小任务.
  • Sub-job: 数据同步作业切分后的小任务
  • Reader(Loader): 数据读入模块,负责运行切分后的小任务,将数据从源头装载入DataX
  • Storage: Reader和Writer通过Storage交换数据
  • Writer(Dumper): 数据写出模块,负责将数据从DataX导入至目的数据地

Sqoop架构图

DataX 直接在运行DataX的机器上进行数据的抽取及加载。
而Sqoop充分里面了map-reduce的计算框架。Sqoop根据输入条件,生成一个map-reduce的作业,在Hadoop的框架中运行。
从理论上讲,用map-reduce框架同时在多个节点上进行import应该会比从单节点上运行多个并行导入效率高。而实际的测试中也是如此,测试一个Oracle to hdfs的作业,DataX上只能看到运行DataX上的机器的数据库连接,而Sqoop运行时,4台task-tracker全部产生一个数据库连接。调起的Sqoop作业的机器也会产生一个数据库连接,应为需要读取数据表的一些元数据信息,数据量等,做分区。
Sqoop现在作为Apache的顶级项目,如果要我从DataX和Sqoop中间选择的话,我想我还是会选择Sqoop。而且Sqoop还有很多第三方的插件。早上使用了Quest开发的OraOop插件,确实像quest说的一样,速度有着大幅的提升,Quest在数据库方面的经验,确实比旁人深厚。
  • Transfer highly clustered data more than five times faster than with Sqoop alone
  • Avoid scalability issues that can occur with Sqoop when data has no primary key or is not stored in primary key order
  • Reduce CPU by up to 80 percent and IO time by up to 95 percent
  • Prevent disruption to concurrently running Oracle workload
  • Get free use of Data Transporter for Hive, a Java command-line utility that allows you to execute a Hive query and insert the results into an Oracle table
在我的测试环境上,一台只有700m内存的,IO低下的oracle数据库,百兆的网络,使用Quest的Sqoop插件在4个并行度的情况下,导出到HDFS速度有5MB/s ,这已经让我很满意了。相比使用原生Sqoop的2.8MB/s快了将近一倍,sqoop又比DataX的760KB/s快了两倍。
另外一点Sqoop采用命令行的方式调用,比如容易与我们的现有的调度监控方案相结合,DataX采用xml 配置文件的方式,在开发运维上还是有点不方便。
附图1.Sqoop with Quest oracle connector