博客园_逖靖寒的世界

关于HFile的思考

2011-07-05T02:01:00Z

0.90.x版本的HBase中的文件是存储在HFile中的。

关于HFile文件的详细介绍，可以查看这篇文章：http://www.data-works.org/download/hfile.pdf

这篇文章中介绍了以下五点内容：

HFile的作用。
HFile的格式。
HFile的性能。
HFile的使用注意事项。
HFile的编程接口。

HFile中有一个很重要的参数，那就是block size。如果我们写入hfile中的某一个value的值大于block size会怎么样？

于是有如下的测试代码：

1: // create local file system 2: FileSystem fs = new RawLocalFileSystem(); 3: fs.setConf(new Configuration()); 4: 5: // block size = 1kb 6: HFile.Writer hwriter = new HFile.Writer(fs, 7: new Path("hfile"), 1, (Compression.Algorithm) null, null); 8: 9: // create key & value, the value is 8kb, larger than 1kb 10: byte[] key = "www.data-works.org".getBytes(); 11: byte[] value = new byte[8 * 1024]; 12: for (int i = 0; i < 8 * 1024; i++) { 13: value[i] = '0'; 14: } 15: 16: // add values to hfile 17: for (int i = 0; i < 10; i++) { 18: hwriter.append(key, value); 19: } 20: 21: // close hfile 22: hwriter.close();

上面的代码可以看出来，每一个value的值都是8kb，已经超过了hfile预设的1kb的block size。

实际的写入情况是如果value大于block size，那么就按照实际的情况来写。

上面的测试用例执行完毕以后，整个hile文件只有1个data block。

这个hfile的读取代码如下：

1: // create local file system 2: FileSystem fs = new RawLocalFileSystem(); 3: fs.initialize(URI.create("file:///"), new Configuration()); 4: fs.setConf(new Configuration()); 5: HFile.Reader hreader = new HFile.Reader(fs, 6: new Path("hfile"), null, false); 7: 8: // loadFileInfo 9: hreader.loadFileInfo(); 10: 11: HFileScanner hscanner = hreader.getScanner(false, false); 12: 13: // seek to the start position of the hfile. 14: hscanner.seekTo(); 15: 16: // print values. 17: int index = 1; 18: while (hscanner.next()) { 19: System.out.println("index: " + index++); 20: System.out.println("key: " + hscanner.getKeyString()); 21: System.out.println("value: " + hscanner.getValueString()); 22: } 23: 24: // close hfile. 25: hreader.close();

上面的代码将读取hfile，并将这个文件中的所有kv打印出来。

通过上面的测试可以看出：如果某一个key有非常非常多的value，那么查找这些value就无法通过索引去快速查找，而是需要通过遍历进行。

另外，JIRA上面的HBASE-3857也提出了一种新的HFile格式，HFile v2

他主要是针对现有HFile的两个主要缺陷提出来的：

暂用过多内存
启动加载时间缓慢

有兴趣的朋友可以详细了解一下。

更多关于HBase方面的文章，请参考：http://blog.data-works.org

本文链接

《Cassandra实战》CassSeller程序源代码下载

2011-06-18T03:34:00Z

下载地址：

Windows版本

http://www.data-works.org/download/casssellersrc-windows.zip

mac版本

http://www.data-works.org/download/casssellersrc.zip

本目录中
CassSeller对应的是Cassandra-0.6.x版本的代码
CassSeller-0.7对应的是Cassandra-0.7.x版本的代码

对于Cassandra-0.6.x版本，打开conf/storage-conf.xml文件，在Keyspace配置项中，新添加一个Keyspace的配置信息，内容如下：
<Keyspace Name=”CassSeller”>
<ColumnFamily Name=”Seller”
CompareWith=”UTF8Type” />
<ColumnFamily Name=”Buyer”
CompareWith=”UTF8Type” />
<ColumnFamily Name=”ProductCategory”
CompareWith=”TimeUUIDType” />
<ColumnFamily Name=”Product”
CompareWith=”UTF8Type” />
<ColumnFamily Name=”Comment”
ColumnType=”Super”
CompareWith=”TimeUUIDType”
CompareSubcolumnsWith=”UTF8Type”/>

<ReplicaPlacementStrategy>org.apache.cassandra.locator.RackUnawareStrategy</ReplicaPlacementStrategy>

<EndPointSnitch>org.apache.cassandra.locator.EndPointSnitch</EndPointSnitch>
</Keyspace>
编辑完成后，保存并重新启动Cassandra。

对于Cassandra-0.7.x版本，CassSeller-0.7代码中已经包含了修改Cassandra Schema的逻辑，所以无需做任何修改即可执行。

更多关于《Cassandra实战》的信息请关注：
http://blog.data-works.org
如果希望交流Cassandra方面问题，可以关注：
http://bbs.data-works.org

本文链接

注意你的hosts文件--记一次HBase问题定位

2011-04-24T07:34:00Z

最近在测试HBase时遇到一个非常奇怪的问题：集群有7台机器，其中1台Master，6台RegionServer。但是Master只能控制其中1台RegionServer，而无法控制其他5台RegionServer。

打开master的日志文件，发现以下错误信息：

2011-04-22 16:37:21,242 WARN org.apache.hadoop.hbase.master.AssignmentManager: Failed assignment of -ROOT-,,0.70236052 to serverName=hp2,60020,1303461559353, load=(requests=0, regions=0, usedHeap=28, maxHeap=3979), trying to assign elsewhere instead; retry=0
org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed setting up proxy interface org.apache.hadoop.hbase.ipc.HRegionInterface to /10.131.18.3:60020 after attempts=1
    at org.apache.hadoop.hbase.ipc.HBaseRPC.waitForProxy(HBaseRPC.java:355)
    at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:965)
    at org.apache.hadoop.hbase.master.ServerManager.getServerConnection(ServerManager.java:606)
    at org.apache.hadoop.hbase.master.ServerManager.sendRegionOpen(ServerManager.java:541)
    at org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:920)
    at org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:730)
    at org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:710)
    at org.apache.hadoop.hbase.master.AssignmentManager.assignRoot(AssignmentManager.java:1189)
    at org.apache.hadoop.hbase.master.HMaster.assignRootAndMeta(HMaster.java:432)
    at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:389)
    at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:283)
Caused by: java.net.ConnectException: Connection refused
    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
    at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:574)
    at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206)
    at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:408)
    at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:328)
    at org.apache.hadoop.hbase.ipc.HBaseClient.getConnection(HBaseClient.java:883)
    at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:750)
    at org.apache.hadoop.hbase.ipc.HBaseRPC$Invoker.invoke(HBaseRPC.java:257)
    at $Proxy7.getProtocolVersion(Unknown Source)
    at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:419)
    at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:393)
    at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:444)
    at org.apache.hadoop.hbase.ipc.HBaseRPC.waitForProxy(HBaseRPC.java:349)
    ... 10 more

在这个日志中，master机器无法与IP地址为10.131.18.3的regionserver进行通信。

然后找到10.131.18.3机器，查看这台机器的regionserver日志，查看regionserver的启动信息：

2011-04-14 18:32:05,122 INFO org.apache.hadoop.ipc.HBaseServer: IPC Server handler 10 on 60020: starting
2011-04-14 18:32:05,122 INFO org.apache.hadoop.ipc.HBaseServer: IPC Server handler 11 on 60020: starting
2011-04-14 18:32:05,122 INFO org.apache.hadoop.ipc.HBaseServer: IPC Server handler 12 on 60020: starting
2011-04-14 18:32:05,122 INFO org.apache.hadoop.ipc.HBaseServer: IPC Server handler 13 on 60020: starting
2011-04-14 18:32:05,122 INFO org.apache.hadoop.ipc.HBaseServer: IPC Server handler 14 on 60020: starting
2011-04-14 18:32:05,122 INFO org.apache.hadoop.ipc.HBaseServer: IPC Server handler 15 on 60020: starting
2011-04-14 18:32:05,122 INFO org.apache.hadoop.ipc.HBaseServer: IPC Server handler 16 on 60020: starting
2011-04-14 18:32:05,122 INFO org.apache.hadoop.ipc.HBaseServer: IPC Server handler 17 on 60020: starting
2011-04-14 18:32:05,123 INFO org.apache.hadoop.ipc.HBaseServer: IPC Server handler 18 on 60020: starting
2011-04-14 18:32:05,123 INFO org.apache.hadoop.ipc.HBaseServer: IPC Server handler 19 on 60020: starting
2011-04-14 18:32:05,123 INFO org.apache.hadoop.ipc.HBaseServer: PRI IPC Server handler 0 on 60020: starting2011-04-14 18:32:05,123 INFO org.apache.hadoop.ipc.HBaseServer: PRI IPC Server handler 1 on 60020: starting
2011-04-14 18:32:05,123 INFO org.apache.hadoop.ipc.HBaseServer: PRI IPC Server handler 2 on 60020: starting2011-04-14 18:32:05,123 INFO org.apache.hadoop.ipc.HBaseServer: PRI IPC Server handler 3 on 60020: starting
2011-04-14 18:32:05,123 INFO org.apache.hadoop.ipc.HBaseServer: PRI IPC Server handler 4 on 60020: starting2011-04-14 18:32:05,123 INFO org.apache.hadoop.ipc.HBaseServer: PRI IPC Server handler 5 on 60020: starting
2011-04-14 18:32:05,123 INFO org.apache.hadoop.ipc.HBaseServer: PRI IPC Server handler 6 on 60020: starting2011-04-14 18:32:05,124 INFO org.apache.hadoop.ipc.HBaseServer: PRI IPC Server handler 7 on 60020: starting
2011-04-14 18:32:05,124 INFO org.apache.hadoop.ipc.HBaseServer: PRI IPC Server handler 8 on 60020: starting2011-04-14 18:32:05,124 INFO org.apache.hadoop.ipc.HBaseServer: PRI IPC Server handler 9 on 60020: starting2011-04-14 18:32:05,124 INFO org.apache.hadoop.hbase.regionserver.HRegionServer: Serving as dell4,60020,1302777124101, RPC listening on /127.0.0.1:60020, sessionid=0x12f535856620004

可以看出，这台regionserver机器启动成功了，但是RPC的监听ip地址却是本机的地址（127.0.0.1）。这样的话，master机器就无法与这台regionserver正常通信了，正确的监听地址应该是10.131.18.3才对。

查看代码，RPC监听地址的代码如下：

/** @return Bind address */
public String getBindAddress() {
    final InetAddress addr = address.getAddress();
    if (addr != null) {
      return addr.getHostAddress();
    } else {
      LogFactory. getLog(HServerAddress.class).error( "Could not resolve the"
          + " DNS name of " + stringValue );
      return null;
    }
}

代码没有错，看来是机器的某些配置导致java读取本机的ip地址出现了错误。最后查看这台机器的hosts文件：

[hadoop@hp2 logs]$ vi /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               hp2 localhost.localdomain localhost
::1             localhost6.localdomain6 localhost6
10.131.18.8     dell1
10.131.18.5     dell2
10.131.18.6     dell3
10.131.18.7     dell4
10.131.18.2     hp1
10.131.18.3     hp2
10.131.18.4     hp3

问题找到了，其实是hosts文件的配置原因，接下来修改hosts文件为如下：

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               localhost.localdomain localhost
::1             localhost6.localdomain6 localhost6
10.131.18.8     dell1
10.131.18.5     dell2
10.131.18.6     dell3
10.131.18.7     dell4
10.131.18.2     hp1
10.131.18.3     hp2
10.131.18.4     hp3

再次启动整个集群，问题解决。

更多关于HBase的文章，可以参考：http://www.cnblogs.com/gpcuster/tag/HBase/

本文链接

HADOOP实践101：在Hadoop集群中添加机器和删除机器

2011-04-12T03:02:00Z

无论是在Hadoop集群中添加机器和删除机器，都无需停机，整个服务不中断。

本次操作之前，Hadoop的集群情况如下：

HDFS的机器情况如下：

MR的机器情况如下：

添加机器

在集群的Master机器中，修改$HADOOP_HOME/conf/slaves文件，在其中添加需要加入集群的新机器（hp3）的主机名：

hp3
hp2
dell1
dell2
dell3
dell4

然后在Master机器中执行如下命令：

$HADOOP_HOME/bin/start-all.sh

这样操作完成之后，新的机器就添加到集群中来了。

HDFS集群增加了一台新的机器：

MR集群中也新增了一台机器：

删除机器

不安全的方式

由于Hadoop集群自身具备良好的容错性，可以直接关闭相应的机器，从而达到将该机器撤除的目的。但是如果一次性操作3台以上的机器，就有可能造成部分数据丢失，所以不推荐使用这种方式进行操作。

安全的方式

在集群的Master机器中，新建一个文件：$HADOOP_HOME/conf/nn-excluded-list，在这个文件中指定需要删除的机器主机名（hp3）：

hp3

然后，修改Master机器的配置文件：$HADOOP_HOME/conf/hdfs-site.xml，添加如下内容：

<property>
<name>dfs.hosts.exclude</name>
<value>conf/nn-excluded-list</value>
</property>

最后，在Master机器中执行如下命令：

$HADOOP_HOME/bin/hadoop dfsadmin -refreshNodes

这样操作完成之后，可以在HDFS集群中看到，hp3机器已经处于Decommission In Progress状态：

但是MR机器中hp3机器依旧在运行中：

我们需要等待一定的时间，等待hp3中datanode的Decommission操作完成以后，再到hp3机器中关闭所有的Hadoop进程即可。

这样就完成了整个从集群中删除机器的操作。

更多关于Hadoop的文章，可以参考：http://www.cnblogs.com/gpcuster/tag/Hadoop/

本文链接

利用Sqoop将数据从数据库导入到HDFS

2011-03-01T07:03:00Z

基本使用

如下面这个shell脚本：

#Oracle的连接字符串，其中包含了Oracle的地址，SID，和端口号
CONNECTURL=jdbc:oracle:thin:@20.135.60.21:1521:DWRAC2
#使用的用户名
ORACLENAME=kkaa
#使用的密码
ORACLEPASSWORD=kkaa123
#需要从Oracle中导入的表名
oralceTableName=tt
#需要从Oracle中导入的表中的字段名
columns=AREA_ID,TEAM_NAME
#将Oracle中的数据导入到HDFS后的存放路径
hdfsPath=apps/as/hive/$oralceTableName

#执行导入逻辑。将Oracle中的数据导入到HDFS中
sqoop import --append --connect $CONNECTURL --username $ORACLENAME --password $ORACLEPASSWORD --target-dir $hdfsPath --num-mappers 1 --table $oralceTableName --columns $columns --fields-terminated-by '\001'

执行这个脚本之后，导入程序就完成了。

接下来，用户可以自己创建外部表，将外部表的路径和HDFS中存放Oracle数据的路径对应上即可。

注意：这个程序导入到HDFS中的数据是文本格式，所以在创建Hive外部表的时候，不需要指定文件的格式为RCFile，而使用默认的TextFile即可。数据间的分隔符为'\001'。如果多次导入同一个表中的数据，数据以append的形式插入到HDFS目录中。

并行导入

假设有这样这个sqoop命令，需要将Oracle中的数据导入到HDFS中：

sqoop import --append --connect $CONNECTURL --username $ORACLENAME --password $ORACLEPASSWORD --target-dir $hdfsPath --m 1 --table $oralceTableName --columns $columns --fields-terminated-by '\001' --where "data_desc='2011-02-26'"

请注意，在这个命令中，有一个参数“-m”，代表的含义是使用多少个并行，这个参数的值是1，说明没有开启并行功能。

现在，我们可以将“-m”参数的值调大，使用并行导入的功能，如下面这个命令：

sqoop import --append --connect $CONNECTURL --username $ORACLENAME --password $ORACLEPASSWORD --target-dir $hdfsPath --m 4 --table $oralceTableName --columns $columns --fields-terminated-by '\001' --where "data_desc='2011-02-26'"

一般来说，Sqoop就会开启4个进程，同时进行数据的导入操作。

但是，如果从Oracle中导入的表没有主键，那么会出现如下的错误提示：

ERROR tool.ImportTool: Error during import: No primary key could be found for table creater_user.popt_cas_redirect_his. Please specify one with --split-by or perform a sequential import with '-m 1'.

在这种情况下，为了更好的使用Sqoop的并行导入功能，我们就需要从原理上理解Sqoop并行导入的实现机制。

如果需要并行导入的Oracle表的主键是id，并行的数量是4，那么Sqoop首先会执行如下一个查询：

select max(id) as max, select min(id) as min from table [where 如果指定了where子句];

通过这个查询，获取到需要拆分字段（id）的最大值和最小值，假设分别是1和1000。

然后，Sqoop会根据需要并行导入的数量，进行拆分查询，比如上面的这个例子，并行导入将拆分为如下4条SQL同时执行：

select * from table where 0 <= id < 250;

select * from table where 250 <= id < 500;

select * from table where 500 <= id < 750;

select * from table where 750 <= id < 1000;

注意，这个拆分的字段需要是整数。

从上面的例子可以看出，如果需要导入的表没有主键，我们应该如何手动选取一个合适的拆分字段，以及选择合适的并行数。

再举一个实际的例子来说明：

我们要从Oracle中导入creater_user.popt_cas_redirect_his。

这个表没有主键，所以我们需要手动选取一个合适的拆分字段。

首先看看这个表都有哪些字段：

然后，我假设ds_name字段是一个可以选取的拆分字段，然后执行下面的sql去验证我的想法：

select min(ds_name), max(ds_name) from creater_user.popt_cas_redirect_his where data_desc='2011-02-26'

发现结果不理想，min和max的值都是相等的。所以这个字段不合适作为拆分字段。

再测试一下另一个字段：CLIENTIP
select min(CLIENTIP), max(CLIENTIP) from creater_user.popt_cas_redirect_his where data_desc='2011-02-26'

这个结果还是不错的。所以我们使用CLIENTIP字段作为拆分字段。

所以，我们使用如下命令并行导入：

sqoop import --append --connect $CONNECTURL --username $ORACLENAME --password $ORACLEPASSWORD --target-dir $hdfsPath --m 12 --split-by CLIENTIP --table $oralceTableName --columns $columns --fields-terminated-by '\001' --where "data_desc='2011-02-26'"

这次执行这个命令，可以看到，消耗的时间为：20mins, 35sec，导入了33,222,896条数据。

另外，如果觉得这种拆分不能很好满足我们的需求，可以同时执行多个Sqoop命令，然后在where的参数后面指定拆分的规则。如：

从而达到并行导入的目的。

更多关于Hadoop的文章，可以参考：http://www.cnblogs.com/gpcuster/tag/Hadoop/

本文链接

Hadoop的本地库（Native Libraries）介绍

2011-02-17T07:41:00Z

Hadoop是使用Java语言开发的，但是有一些需求和操作并不适合使用java，所以就引入了本地库（Native Libraries）的概念，通过本地库，Hadoop可以更加高效地执行某一些操作。

目前在Hadoop中，本地库应用在文件的压缩上面：

在使用这两种压缩方式的时候，Hadoop默认会从$HADOOP_HOME/lib/native/Linux-*目录中加载本地库。

如果加载成功，输出为：

DEBUG util.NativeCodeLoader - Trying to load the custom-built native-hadoop library...
INFO util.NativeCodeLoader - Loaded the native-hadoop library

如果加载失败，输出为：

INFO util.NativeCodeLoader - Unable to load native-hadoop library for your platform... using builtin-java classes where applicable

在Hadoop的配置文件core-site.xml中可以设置是否使用本地库：

<property>
<name>hadoop.native.lib</name>
<value>true</value>
<description>Should native hadoop libraries, if present, be used.</description>
</property>

Hadoop默认的配置为启用本地库。

另外，可以在环境变量中设置使用本地库的位置：

export JAVA_LIBRARY_PATH=/path/to/hadoop-native-libs

有的时候也会发现Hadoop自带的本地库无法使用，这种情况下就需要自己去编译本地库了。在$HADOOP_HOME目录下，使用如下命令即可：

ant compile-native

编译完成后，可以在$HADOOP_HOME/build/native目录下找到相应的文件，然后指定文件的路径或者移动编译好的文件到默认目录下即可。

更多关于Hadoop的文章，可以参考：http://www.cnblogs.com/gpcuster/tag/Hadoop/

本文链接

漫谈Hadoop HDFS Balancer

2011-02-16T15:50:00Z

Hadoop的HDFS集群非常容易出现机器与机器之间磁盘利用率不平衡的情况，比如集群中添加新的数据节点。当HDFS出现不平衡状况的时候，将引发很多问题，比如MR程序无法很好地利用本地计算的优势，机器之间无法达到更好的网络带宽使用率，机器磁盘无法利用等等。可见，保证HDFS中的数据平衡是非常重要的。

在Hadoop中，包含一个Balancer程序，通过运行这个程序，可以使得HDFS集群达到一个平衡的状态，使用这个程序的命令如下：

sh $HADOOP_HOME/bin/start-balancer.sh –t 10%

这个命令中-t参数后面跟的是HDFS达到平衡状态的磁盘使用率偏差值。如果机器与机器之间磁盘使用率偏差小于10%，那么我们就认为HDFS集群已经达到了平衡的状态。

Hadoop的开发人员在开发Balancer程序的时候，遵循了以下几点原则：

1. 在执行数据重分布的过程中，必须保证数据不能出现丢失，不能改变数据的备份数，不能改变每一个rack中所具备的block数量。

2. 系统管理员可以通过一条命令启动数据重分布程序或者停止数据重分布程序。

3. Block在移动的过程中，不能暂用过多的资源，如网络带宽。

4. 数据重分布程序在执行的过程中，不能影响name node的正常工作。

基于这些基本点，目前Hadoop数据重分布程序实现的逻辑流程如下图所示：

Rebalance程序作为一个独立的进程与name node进行分开执行。

1 Rebalance Server从Name Node中获取所有的Data Node情况：每一个Data Node磁盘使用情况。

2 Rebalance Server计算哪些机器需要将数据移动，哪些机器可以接受移动的数据。并且从Name Node中获取需要移动的数据分布情况。

3 Rebalance Server计算出来可以将哪一台机器的block移动到另一台机器中去。

4,5,6 需要移动block的机器将数据移动的目的机器上去，同时删除自己机器上的block数据。

7 Rebalance Server获取到本次数据移动的执行结果，并继续执行这个过程，一直没有数据可以移动或者HDFS集群以及达到了平衡的标准为止。

Hadoop现有的这种Balancer程序工作的方式在绝大多数情况中都是非常适合的。

现在我们设想这样一种情况：

1 数据是3份备份。

2 HDFS由2个rack组成。

3 2个rack中的机器磁盘配置不同，第一个rack中每一台机器的磁盘空间为1TB，第二个rack中每一台机器的磁盘空间为10TB。

4 现在大多数数据的2份备份都存储在第一个rack中。

在这样的一种情况下，HDFS级群中的数据肯定是不平衡的。现在我们运行Balancer程序，但是会发现运行结束以后，整个HDFS集群中的数据依旧不平衡：rack1中的磁盘剩余空间远远小于rack2。

这是因为Balance程序的开发原则1导致的。

简单的说，就是在执行Balancer程序的时候，不会将数据中一个rack移动到另一个rack中，所以就导致了Balancer程序永远无法平衡HDFS集群的情况。

针对于这种情况，可以采取2中方案：

1 继续使用现有的Balancer程序，但是修改rack中的机器分布。将磁盘空间小的机器分叉到不同的rack中去。

2 修改Balancer程序，允许改变每一个rack中所具备的block数量，将磁盘空间告急的rack中存放的block数量减少，或者将其移动到其他磁盘空间富余的rack中去。

更多关于Hadoop的文章，可以参考：http://www.cnblogs.com/gpcuster/tag/Hadoop/

本文链接

分布式实时统计系统--Rainbird

2011-02-06T06:26:00Z

最近Twitter开发了一款分布式实时统计系统Rainbird。

用处

Rainbird可以用于实时数据的统计：

1 统计网站中每一个页面，域名的点击次数

2 内部系统的运行监控（统计被监控服务器的运行状态）

3 记录最大值和最小值

性能要求

作为大型网站的分布式应用，需要具备以下性能：

1 极高的写入性能，可以达到100,000的WPS

2 非常高的读取性能，可以达到10,000s的RPS

3 高度的可扩展性，包括读取和存储等等，能够扩展到100+ TB的量级

4 读取速度响应间隔短，绝大多数的读取速度应该不超过100ms

系统组件

Rainbird一款基于Zookeeper, Cassandra,Scribe, Thrift的分布式实时统计系统，这些基础组件的基本功能如下：

1 Zookeeper，Hadoop子项目中的一款分布式协调系统，用于控制分布式系统中各个组件中的一致性。

2 Cassandra，NoSQL中一款非常出色的产品，集合了Dynamo和Bigtable特性的分布式存储系统，用于存储需要进行统计的数据，统计数据，并且提供客户端进行统计数据的查询。（需要使用分布式Counter补丁CASSANDRA-1072）

3 Scribe，Facebook开源的一款分布式日志收集系统，用于在系统中将各个需要统计的数据源收集到Cassandra中。

4 Thrift，Facebook开源的一款跨语言C/S网络通信框架，开发人员基于这个框架可以轻易地开发C/S应用。

整体设计

Rainbird的设计架构图如下：

整个Rainbird系统中各个组件之间的协调和容灾处理由ZooKeeper负责，Cassandra负责整个数据的存储和统计。

Front End中部署了Scribe，收集需要统计的数据，然后将收集到数据实时地发生到Rainbird Aggregator中。

Rainbird Aggregator将缓存收集的数据（1M），并将缓存的数据进行一次预处理，然后再将数据一次性批量写入到Cassandra中。这里预处理的作用类似于MapReduce框架中的combiner的作用，在Maper端做Reduce。

Rainbird Query接受用户的查询请求，直接到Cassandra中查询已经统计好的数据返回给客户端。

页面URL统计示例

将设我们需要统计网站的页面点击的情况，那么如何使用Rainbird来进行统计呢？

在统计的过程中，本博客中一篇文章的URL为：http://www.cnblogs.com/gpcuster/tag/Cassandra/

我们可以将这个URL分拆为以下四个部分

com

cnblogs

www

http://www.cnblogs.com/gpcuster/tag/Cassandra/

然后以分拆后的这四个部分组合为以下Key：

com,cnblogs,www,http://www.cnblogs.com/gpcuster/tag/Cassandra/

com,cnblogs,www

com,cnblogs

com

最后将这些Key的数据写入Cassandra中。这样就完成了整个统计的过程。

如果需要查询页面http://www.cnblogs.com/gpcuster/tag/Cassandra/被访问了多少次，只要在Cassandra中查询Key为com,cnblogs,www,http://www.cnblogs.com/gpcuster/tag/Cassandra/的值即可。

如果需要查询页面http://www.cnblogs.com被访问了多少次，只要在Cassandra中查询Key为com,cnblogs,www的值即可。

如果要查询页面http://*cnblogs.com被访问了多少次，也可以进行类似的查询即可。

更多参考

如果希望了解更详细的信息，可以参考：http://www.slideshare.net/kevinweil/rainbird-realtime-analytics-at-twitter-strata-2011

另外，想了解更多关于Cassandra的信息，可以参考：http://www.cnblogs.com/gpcuster/tag/Cassandra/

想了解更多关于ZooKeeper的信息，可以参考：http://www.cnblogs.com/gpcuster/tag/ZooKeeper/

本文链接

Hadoop中的CRC数据校验文件

2011-01-26T05:11:00Z

Hadoop系统为了保证数据的一致性，会对文件生成相应的校验文件，并在读写的时候进行校验，确保数据的准确性。

比如我们遇到的这个Case：

执行的命令：

hadoop jar dw-hadoop-2010_7_23.jar jobDriver -files tb_steps_url_path_dim.txt multisteps_output 2011-01-25

出错日志的提示：

org.apache.hadoop.fs.ChecksumException: Checksum error: file:tb_steps_url_path_dim.txt at 0

at org.apache.hadoop.fs.FSInputChecker.verifySum(FSInputChecker.java:277)

at org.apache.hadoop.fs.FSInputChecker.readChecksumChunk(FSInputChecker.java:241)

at org.apache.hadoop.fs.FSInputChecker.read1(FSInputChecker.java:189)

at org.apache.hadoop.fs.FSInputChecker.read(FSInputChecker.java:158)

at java.io.DataInputStream.read(DataInputStream.java:83)

at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:49)

at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:87)

at org.apache.hadoop.fs.FileUtil.copy(FileUtil.java:209)

at org.apache.hadoop.fs.FileUtil.copy(FileUtil.java:142)

at org.apache.hadoop.mapred.JobClient.copyRemoteFiles(JobClient.java:565)

at org.apache.hadoop.mapred.JobClient.configureCommandLineOptions(JobClient.java:627)

at org.apache.hadoop.mapred.JobClient.submitJobInternal(JobClient.java:802)

at org.apache.hadoop.mapred.JobClient.submitJob(JobClient.java:771)

at org.apache.hadoop.mapred.JobClient.runJob(JobClient.java:1290)

at jobDriver.run(jobDriver.java:85)

at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)

at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:79)

at jobDriver.main(jobDriver.java:124)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

错误原因：

启动任务的命令中包含一个参数“-files tb_steps_url_path_dim.txt”

Hadoop客户端需要将机器本地磁盘中的tb_steps_url_path_dim.txt文件上传到DFS中。

在上传的过程中，Hadoop将通过FSInputChecker判断需要上传的文件是否存在进行校验的crc文件，即.tb_steps_url_path_dim.txt.crc，如果存在crc文件，将会对其内容一致性进行校验，如果校验失败，则停止上传该文件。最终导致整个MR任务无法执行。

crc文件来源

DFS命令：hadoop fs -getmerge srcDir destFile

这类命令在执行的时候，会将srcDir目录下的所有文件合并成一个文件，保存在destFile中，同时会在本地磁盘生成一个. destFile.crc的校验文件。

DFS命令：hadoop fs -get -crc src dest

这类命令在执行的时候，会将src文件，保存在dest中，同时会在本地磁盘生成一个. dest.crc的校验文件。

如何避免

在使用hadoop fs -getmerge srcDir destFile命令时，本地磁盘一定会（没有参数可以关闭）生成相应的.crc文件。

所以如果需要修改getmerge获取的文件的内容，再次上传到DFS时，可以采取以下2种策略进行规避：

1. 删除.crc文件

2. 将getmerge获取的文件修改后重新命名，如使用mv操作，再次上传到DFS中。

更多关于Hadoop的文章，可以参考：http://www.cnblogs.com/gpcuster/tag/Hadoop/

本文链接

Cassandra就要迎来1.0版本啦

2011-01-13T02:05:00Z

前一段时间，Cassandra0.7已经正式发布啦。

接下来，Cassandra1.0即将发布。邮件列表的内容如下：

Way back in Nov 09, we did a users survey and asked what features
people wanted to see. Here was my summary of the responses:
http://www.mail-archive.com/cassandra-user@incubator.apache.org/msg01446.html

Looking at that, we've done essentially all of them. I think we can
make a strong case that our next release should be 1.0; it's
production ready, it's reasonably feature-complete, it's documented,
and we know what our upgrade path story is.

The list--

Load balancing: basics done;
https://issues.apache.org/jira/browse/CASSANDRA-1427 is open to
improve it

Decommission: done

Map/reduce support: done

ColumnFamily / Keyspace definitions w/o restart: done

Design documentation: started at
http://wiki.apache.org/cassandra/ArchitectureInternals

Insert multiple rows at once: done

Remove_slice_range / remove_key_range: turned out to be a *lot* harder
than it looks at first. Postponed indefinitely.

Secondary indexing: done

Caching: done (with some enhancements possible such as
https://issues.apache.org/jira/browse/CASSANDRA-1969 and
https://issues.apache.org/jira/browse/CASSANDRA-1956)

Bulk delete (truncate): done

I would add,

User documentation: done (http://www.riptano.com/docs)

Large row support: done

Improved replication strategies and more sophisticated ConsistencyLevels: done

Efficient bootstrap/streaming: done

Flow control: done

Network-level compatibility between releases: scheduled
(https://issues.apache.org/jira/browse/CASSANDRA-1015)

更多关于Cassandra的文章：http://www.cnblogs.com/gpcuster/tag/Cassandra/

本文链接