使用sqoop1导出mysql数据到hbase中

失败的方式：安装配置cdh5.03版sqoop2-1.99.3导入数据
1.下载sqoop2：http://www.cloudera.com/content/support/en/downloads/cdh/cdh-5-0-3.html
2.无法启动配置server/conf下catalina.properties文件，把所有hadoop的共享jar包配置到sqoop环境变量中，可以参考官方文档搞定。
3.启动并使用client链接server，发现不能使用，参考如下配置还是不能正确配置成功，所以决定安装sqoop1，导入数据。

安装配置cdh5.03版sqoop-1.4.4导入数据

mysql表导入到hdfs中：

./sqoop import --driver com.mysql.jdbc.Driver --connect "jdbc:mysql://[IP地址]:3306/[数据库]?autoReconnect=true"--table CMSCHANNEL --username root --password root --target-dir /hbase/testfile

mysql表导入到HBase中：

./sqoop import --driver com.mysql.jdbc.Driver --connect "jdbc:mysql://[IP地址]:3306/[数据库]?autoReconnect=true"--table CMSCHANNEL --username root --password root --hbase-table testcms --column-family name --hbase-row-key CHANNELID --hbase-create-table

hbase常用命令：
查看当先HBase中具有哪些表

list

查看表的构造

describe 'test'

搜索所有表数据：

hbase(main):012:0> scan 'CMSCHANNEL'hbase(main):004:0> describe 'CMSCHANNEL'

hbase一些总结：
-ROOT- && .META. Table
HBase中有两张特殊的Table，-ROOT-和.META.

Ø  .META.：记录了用户表的Region信息，.META.可以有多个regoin

Ø  -ROOT-：记录了.META.表的Region信息，-ROOT-只有一个region

Ø  Zookeeper中记录了-ROOT-表的location

hbase的慢响应现在一般归纳为四类原因：网络原因、gc问题、命中率以及client的反序列化问题。我们现在对它们做了一些解决方案(后面会有介绍)，以更好地对慢响应有控制力。

Facebook之前曾经透露过Facebook的hbase架构，可以说是非常不错的。如他们将message服务的hbase集群按用户分为数个集群，每个集群100台服务器，拥有一台namenode以及分为５个机架，
每个机架上一台zookeeper。可以说对于大数据量的服务这是一种优良的架构。对于淘宝来说，由于数据量远没有那么大，应用也没有那么核心，因此我们采用公用hdfs以及zookeeper集群的架构。
每个hdfs集群尽量不超过100台规模（这是为了尽量限制namenode单点问题）。在其上架设数个hbase集群，每个集群一个master以及一个backupmaster。公用hdfs的好处是可以尽量减少compact的影响，
以及均摊掉硬盘的成本，因为总有集群对磁盘空间要求高，也总有集群对磁盘空间要求低，混合在一起用从成本上是比较合算的。zookeeper集群公用，每个hbase集群在zk上分属不同的根节点。
通过zk的权限机制来保证hbase集群的相互独立。zk的公用原因则仅仅是为了运维方便。

2.1.3.5. dfs.datanode.max.xcievers
一个 Hadoop HDFS Datanode 有一个同时处理文件的上限. 这个参数叫 xcievers (Hadoop的作者把这个单词拼错了). 在你加载之前，先确认下你有没有配置这个文件conffs-site.xml里面的xceivers参数，至少要有4096:

      <property>        <name>dfs.datanode.max.xcievers</name>        <value>4096<alue>      </property>

4.2.3.1. Shell 切换成debug 模式
你可以将shell切换成debug模式。这样可以看到更多的信息。 -- 例如可以看到命令异常的stack trace:

4.2.3.2. DEBUG log level
想要在shell中看到 DEBUG 级别的 logging ，可以在启动的时候加上 -d 参数.

$ ./bin/hbase shell -d

hbase的慢响应现在一般归纳为四类原因：网络原因、gc问题、命中率以及client的反序列化问题。

用diff 命令来展示 hbase-env.sh 文件相比默认变化的部分

hbase.regionserver.info.port
HBase RegionServer web 界面绑定的端口 设置为 -1 意味这你不想与运行 RegionServer 界面.

默认: 60030

我们之所以把这个值调的很高，是因为我们不想一天到晚在论坛里回答新手的问题。
“为什么我在执行一个大规模数据导入的时候Region Server死掉啦”，通常这样的问题是因为长时间的GC操作引起的，
他们的JVM没有调优。我们是这样想的，如果一个人对Hbase不很熟悉，不能期望他知道所有，
打击他的自信心。等到他逐渐熟悉了，他就可以自己调这个参数了。

4.2.3.2. DEBUG log level
想要在shell中看到 DEBUG 级别的 logging ，可以在启动的时候加上 -d 参数.

$ ./bin/hbase shell -d

Region的大小是一个棘手的问题，需要考量如下几个因素。

Regions是可用性和分布式的最基本单位

HBase通过将region切分在许多机器上实现分布式。也就是说，你如果有16GB的数据，只分了2个region， 你却有20台机器，有18台就浪费了。

region数目太多就会造成性能下降，现在比以前好多了。但是对于同样大小的数据，700个region比3000个要好。

region数目太少就会妨碍可扩展性，降低并行能力。有的时候导致压力不够分散。这就是为什么，你向一个10节点的Hbase集群导入200MB的数据，大部分的节点是idle的。

RegionServer中1个region和10个region索引需要的内存量没有太多的差别。

最好是使用默认的配置，可以把热的表配小一点(或者受到split热点的region把压力分散到集群中)。如果你的cell的大小比较大(100KB或更大)，就可以把region的大小调到1GB。

在Hbase集群上运行 hbck
$ ./bin/hbase hbck
这个命令的输出是 OK 或者 INCONSISTENCY. 如果你的集群汇报inconsistencies，加上-details 看更多的详细信息。如果inconsistencies，多运行hbck 几次，因为inconsistencies可能是暂时的。
 (集群正在启动或者region正在split)。加上-fix可以修复inconsistency(这是一个实验性的功能)

我们之所以把这个值调的很高，是因为我们不想一天到晚在论坛里回答新手的问题。“为什么我在执行一个大规模数据导入的时候Region Server死掉啦”，通常这样的问题是因为长时间的GC操作引起的
，他们的JVM没有调优。我们是这样想的，如果一个人对HBase不很熟悉，不能期望他知道所有，打击他的自信心。等到他逐渐熟悉了，他就可以自己调这个参数了。

参考文章：

          http://blog.csdn.net/myproudcodelife/article/details/27546563

           http://blog.csdn.net/liuxingjiaofu/article/details/6946747
          https://code.google.com/p/hbasedoc-cn/
          http://search-hadoop.com/
          http://hbase.apache.org/bulk-loads.html