两集群数据拷贝

作者: 阿甘骑士 | 来源:发表于2018-08-16 18:03 被阅读0次

业务场景：

公司有两套集群，A集群专门做数据存储，B集群专门做数据清洗和数据展现
A集群每天定时把数据同步过来B集群后，B集群负责后续清洗和供业务系统使用

集群背景

两套集群都配有各自的KDC服务器
A集群没做namenode HA，B集群是HA
集群拷贝的数据为parquet格式
A集群域为A.CN，B集群域为B.COM
数据从A到B

第一步 KDC互信 (没有配置kerberos的可以忽略)

假设是A集群拷贝数据到B集群
两边添加相同principal

#A访问B，两个REALM需要共同拥有名为 krbtgt/B.COM@A.CN的principal
#两个Keys需要保证密码，version number和加密方式一致
#在主KDC节点执行以下命令，两个集群都要
kadmin.local
addprinc –e "aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal " krbtgt/B.COM@A.CN

两边添加user和principal规则映??

受信任的领域.png

设置hadoop.security.auth_to_local参数

<property>
<name>hadoop.security.auth_to_local</name> 
<value>RULE:[1:$1@$0](^.*@A\.CN$)s/^(.*)@A\.CN$/$1/g 
RULE:[2:$1@$0](^.*@A\.CN$)s/^(.*)@A\.CN$/$1/g 
RULE:[1:$1@$0](^.*@B\.COM$)s/^(.*)@B\.COM$/$1/g 
RULE:[2:$1@$0](^.*@B\.COM$)s/^(.*)@B\.COM$/$1/g 
DEFAULT 
</value> 
</property>

在krb5.conf中配置信任关系
在两集群/etc/krb5.conf文件配置domain和realm的映射关系
A集群

[capaths]
  A.CN = {
     B.COM= .
  }

B集群

[capaths]
  B.COM = {
    A.CN = .
  }

配置realms
A集群添加以下

[realms]
B.COM = {
  kdc = node1
  admin_server = node1
  kdc = node2
}

B集群添加以下

[realms]
A.CN = {
   kdc = snn
   admin_server = snn
   default_realm = A.CN
}

两边配置domain_realm
A B集群添加以下

[domain_realm] 
.B.COM = B.COM 
B.COM = B.COM
snn = A.CN

重启kerberos
配置hdfs-site.xml，设置dfs.namenode.kerberos.principal.pattern为"*"

namenode,kerberos.principal.png
重启hdfs
测试

[root@node1 ~]# hdfs dfs -ls /
Found 7 items
drwxr-xr-x   - hdfs  supergroup          0 2018-06-29 14:23 /flume
drwx------   - hbase hbase               0 2018-08-08 11:53 /hbase
drwxr-xr-x   - hdfs  supergroup          0 2018-04-04 23:47 /lsltest
drwxr-xr-x   - sdc   sdc                 0 2018-07-12 10:18 /sdc
drwxrwxrwt   - hdfs  supergroup          0 2018-08-16 10:53 /tmp
drwxr-xr-x   - hdfs  supergroup          0 2018-08-09 11:02 /user
drwxr-xr-x   - hdfs  supergroup          0 2018-04-23 17:03 /usr
[root@node1 ~]# hdfs dfs -ls hdfs://node1:8020/
Found 3 items
drwxrwxrwx   - hdfs supergroup          0 2018-06-04 14:52 hdfs://node1:8020/data
drwxrwxrwt   - hdfs supergroup          0 2018-07-03 19:26 hdfs://node1:8020/tmp
drwxr-xr-x   - hdfs supergroup          0 2018-06-11 12:17 hdfs://node1:8020/user
[root@node1 ~]#

这样两集群算是互通了

第二步数据拷贝

数据拷贝用hadoop自带的distcp命令
执行该命令为mapreduce操作，需消耗本机yarn资源

#数据拷贝，往活动的namenode发送数据
hadoop distcp  -overwrite -i hdfs://snn:9000/dev_hive/warehouse/gtp.db/product/partition_date=20180601 webhdfs://node1:50070/user/hive/warehouse/gtp_tmp.db/product/partition_date=20180601

这时候有个问题：集群B是做了namenode高可用，而且活动节点会时不时切换，这就会导致一个问题，假如A集群写死往一个namenode写数据，那该namenode变成standby状态的时候，就会导致拷贝失败

    ERROR tools.DistCp: Exception encountered
    org.apache.hadoop.security.AccessControlException: Authentication required
    at org.apache.hadoop.hdfs.web.WebHdfsFileSystem.validateResponse(WebHdfsFileSystem.java:457)
    at org.apache.hadoop.hdfs.web.WebHdfsFileSystem.access$200(WebHdfsFileSystem.java:113)
    at org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.runWithRetry
    (WebHdfsFileSystem.java:738)
    at org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.access$100(WebHdfsFileSystem.java:582)
    at org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner$1.run(WebHdfsFileSystem.java:612)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:422)
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1724)

或者

ls: Operation category READ is not supported in state standby

这时候需要在A集群hdfs-site.xml配置B集群namenode信息

 <property>
    <name>dfs.nameservices</name>
    <value>bdap-nameservice</value>
  </property>
  <property>
    <name>dfs.client.failover.proxy.provider.bdap-nameservice</name>
    <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
  </property>
  <property>
    <name>dfs.ha.automatic-failover.enabled.bdap-nameservice</name>
    <value>true</value>
  </property>
  <property>
    <name>ha.zookeeper.quorum</name>
    <value>node1:2181,node2:2181,node1:2181</value>
  </property>
  <property>
    <name>dfs.ha.namenodes.bdap-nameservice</name>
    <value>namenode81,namenode132</value>
  </property>
  <property>
    <name>dfs.namenode.rpc-address.bdap-nameservice.namenode81</name>
    <value>node1:8020</value>
  </property>
  <property>
    <name>dfs.namenode.servicerpc-address.bdap-nameservice.namenode81</name>
    <value>node1:8022</value>
  </property>
  <property>
    <name>dfs.namenode.http-address.bdap-nameservice.namenode81</name>
    <value>node1:50070</value>
  </property>
  <property>
    <name>dfs.namenode.https-address.bdap-nameservice.namenode81</name>
    <value>node1:50470</value>
  </property>
  <property>
    <name>dfs.namenode.rpc-address.bdap-nameservice.namenode132</name>
    <value>node2:8020</value>
  </property>

集群的客户端信息可以从CDH直接下载

下载客户端.png
重启hdfs
命令从明确的一个namenode ip改为bdap-nameservice，根据上述的配置

hadoop distcp  -overwrite -i hdfs: //snn:9000/dev_hive/warehouse/gtp.db/product/partition_date=20180601 webhdfs://bdap-nameservice/user/hive/warehouse/gtp_tmp.db/product/partition_date=20180601

第三步数据修复

第二步是直接把parquet文件或者整个分区拷贝到相应的目录下，这时候还不能直接使用这些数据，需要修复表，刷新元数据
这时候可以通过ssh命令从A集群登陆B集群，通过表修复命令实现修复元数据

#ssh到B集群，执行B集群的脚本实现表修复
#自动填充密码
#!/bin/sh
#假设有以下表
a=('product' 'product' 'product')

for var in ${a[@]};
do
expect<<-END
set timeout 10000
 spawn sh /usr/deng_yb/repair.sh $var
 expect "password: "
 send "wms\n"
expect eof
exit
END
done

# 通过beeline，msck repair table命令修复表结构
#!/bin/sh
table=$1
ssh wms@node1  << eeooff
beeline -u 'jdbc:hive2://node1:10000/gtp_tmp;principal=hive/node1@B.COM' --hiveconf mapreduce.job.queuename=datacenter  -e 'msck repair table ${table};'
eeooff

这样第二步和第三步就可以在同一个调度系统按顺序完成
这时候表修复完后，通过hive是可以查到数据的，但是impala还不行
这时候要刷新impala元数据，最好再做下表分析，这样查表的时候评估的内存使用就会更加准确

#impala刷新元信息
INVALIDATE METADATA gtp_tmp.product
#表分析
COMPUTE INCREMENTAL STATS gtp_tmp.product

第四步数据清洗

第二和三步骤把把数据拷贝过来修复好后，B集群可以在基础数据上面做清洗，整理出业务系统需要的报表数据
B集群是impala清洗，为什么用impala不用hive，原因如下
1. A集群把数据清洗完，并distcp过来，做完元信息修复后，剩余给B集群做清洗的时间不多
2. yarn和impala资源对半分情况下，impala比MapReduce任务快至少20倍
大表全量的任务要分区跑，或者根据时间切分跑，否则会报以下异常

内存消耗过多.png

impala任务，类似以下

impala-shell -i node1:25003 -q  "
 INSERT OVERWRITE TABLE gtp.product_target
      select 
        id,
        item_no,
       ....
     from  gtp_tmp.product
     group by id, item_no....
          
"

B端集群清洗完后的表做刷新元数据和表分析，然后就可以给业务系统通过jdbc方式连接impala查询相应数据了
注意：所有执行脚本都统一在一个调度系统中，可以选择开源的azkaban
整体流程结构就是

A 集群数据清洗
AB端kerberos认证通过
A distcp数据 B
A ssh B 修复hive和impala表结构和元信息
B 数据清洗以及更新impala元信??

网友评论

本文标题：两集群数据拷贝

本文链接：https://www.haomeiwen.com/subject/lwbnbftx.html

延伸阅读

深度阅读

您也可以注册成为美文阅读网的作者，发表您的原创作品、分享您的心情！

两集群数据拷贝

业务场景：

集群背景

第一步 KDC互信 (没有配置kerberos的可以忽略)

第二步数据拷贝

第三步数据修复

第四步数据清洗

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

两集群数据拷贝

业务场景：

集群背景

第一步 KDC互信 (没有配置kerberos的可以忽略)

第二步 数据拷贝

第三步 数据修复

第四步 数据清洗

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

第二步数据拷贝

第三步数据修复

第四步数据清洗