Linux查看系统cpu个数、核心书、线程数

1、查看物理cpu个数

grep ‘physical id’ /proc/cpuinfo | sort -u

2、查看核心数量

grep ‘core id’ /proc/cpuinfo | sort -u | wc -l

3、查看线程数

grep ‘processor’ /proc/cpuinfo | sort -u | wc -l

4、查看CPU型号

dmidecode -s processor-version

hive调优除了看执行计划,还要desc 表审阅表情况

今天碰到一个性能问题。hive的在执行一段增量sql的时候,跑到中间有一段join,其并行度只有3。按照hive指导,小表应该放在最前面。但是这个sql已经放在前面了,应该不会有问题。但是这个并行度只有3,我猜测是因为这个表太小了导致无法放大资源并行度。

接着我想到用mapjoin,让小表缓存在内存,从而让大表进入stream状态。而且看来执行计划确实只有majoin,驱动表为小表。可惜效果依然和之前一样。

然后我觉得是不是换成大表在前,换了之后果然并行度大大提升到100并行。而且我还在小表上用了hint的/* +mapjoin(a) */。看到执行计划为大表驱动。只有mapjoin,没有reduce阶段。

这个过程和我以前看到资料完全不对,不都是要求小表在前吗?!难以置信,我一直反复思考是不是以前错了。可惜事实就是如此。

后面在无限的测试中,突然想去desc formatted一下表。结果一看吓一跳,原来那张1.4亿的大表是一张外表,而且查看numfiles时候,值为1。。。这令我无语。为什么没人告诉查半天是个外表,而且使用sqoop抽过来的。

发现问题,立即转表。将外表转为内表parquet,在内部desc一下,发现bumfiles变为100。这下再测试问题解决,原始SQL不用改变,依然小表在前,并行450。

总结:
1、在并发度不高的时候,除了看执行计划外,一定要desc 表,看表的数据文件情况。
2、不要怀疑,执行优化,HIVE中一定是小表在最前。

impala调优

impala调优
1.表变更后,一定要做表分析。表分析可以做增量表分析的。
2.第一张最大表,第二张最小表,第三张第二大表,第四第三大表,依次往下
3.使用straight join,broadcast,shuffle强制使用执行计划。记住broadcast使用于小表,shuffle(patition join)适用于大表。

CDH 安装impala+kudu

今天在CDH5.13上安装impala+kudu,原以为是很容易的点几个按钮就可以安装好,但是最终一直卡在了impala上。。哎。

1、安装IMPALA,这个确实很简单,只需在CDH上手动点击按钮即可,没有任何难度。

2、安装kudu碰到了不少问题。

a)其实一开始没有问题的。我安装步骤是配置1个master6个tablet,启动之后没有任何问题。但是当我要追加两个master的时候,无论如何都启动不了,而且之前的master也启动不了。三个master全部down掉。页面报如下错误:

F0918 18:10:37.619729 13914 master_main.cc:77] Check failed: _s.ok() Bad status: Timed out: Unable to initialize catalog manager: Failed to initialize sys tables async: Failed to create new distributed Raft config: Unable to resolve UUID for peer member_type: VOTER last_known_addr { host: "bdp01" port: 7051 }: Getting permanent uuid from bdp01:7051 timed out after 30000 ms.: Invalid argument: Client connection negotiation failed: client connection to 10.127.60.1:7051: unable to find SASL plugin: PLAIN
一开始没有看到最后SASL错误,只看到无法连接。我还以为网络策略问题,结果网络没有任何问题。一直摸不着头脑。

后来我一直反复的重装,一直这种情况。。。

b)删干净所有wal和data目录,重启3个master和6个tablet。3个master会启动一段时间,大概一分钟时间,然后全部down掉。错误和上面的一直。


/* 由于我设置的master的wal目录、data目录和tablet的wal目录、data目录都在kudu目录下,所以正好只要删除根目录即可*/
rm -rm /src/Bigdata/data1/kudu
rm -rm /src/Bigdata/data2/kudu
rm -rm /src/Bigdata/data3/kudu
rm -rm /src/Bigdata/data4/kudu
rm -rm /src/Bigdata/data5/kudu
rm -rm /src/Bigdata/data6/kudu
/*需要在所有节点上执行 */

c)后来才注意到关键错误:
client connection to 10.127.60.1:7051: unable to find SASL plugin: PLAIN
进过搜索,发现需要安装这个插件。。。
yum install cyrus-sasl*
安装好以后,再次执行b)中的删除代码,然后冲去kudu集群,成功!

d)在解决问题的过程,有些帖子说要在gflagfile上设置–master-addresses,但是实际没有任何效果。

e)回忆起,在发生sasl plugin前,出现了一下问题:
Check failed: _s.ok() Bad status: Timed out: Unable to initialize catalog manager: Failed to initialize sys tables async: Failed to create new distributed Raft config: Unable to resolve UUID for peer member_type: VOTER last_known_addr { host: "bdp01" port: 7051 }: Getting permanent uuid from bdp01:7051 timed out after 30000 ms.: Network error: Client connection negotiation failed: client connection to 10.127.60.1:7051: BlockingRecv error: recv error: Connection reset by peer (error 104)
我一直以为是网络问题,可以网络是通的,telnet没有任何问题。
最后搜索到有效答案是在CDH kudu的gfileflag上设置–trusted-subnet

PS:总结下:如果你要安装kudu的多个master,一定要一开始就设置,不要最后才来追加master。否则我估计你也会碰到我这样的问题。。。

CDH 集群节点通用调优

1、增加操作系统文件句柄数

a)ulimit

编辑/etc/security/limits.conf

增加四行:

* soft nofile 65000

* hard nofile 65000

* soft nproc 65000

* hard nproc 65000

保存后重登录生效

 


PS:今天碰到几台服务器怎么修改soft nproc的值都无法生效。这里是你得检查

ls /etc/security/limits.d/ 下面20-nproc.conf中的配置是否把soft nproc的配置给覆写了,修改即可。

b)file-max

编辑/etc/sysctl.conf

增加一行:fs.file-max = 200000

然后执行指令:sysctl -p。这样无需重启即可生效

c)检查:使用ulimit -a,ulimit -Sn,ulimit -Hn检查参数是否生效。

2、降低交换比例

编辑 /etc/sysctl.conf

增加一行:vm.swappiness=10

然后执行指令:sysctl -p。这样无需重启即可生效。

(CDH以前推荐设置为0.现在推荐设置为10)

3、禁用大透明页:
transparent_hugepages=never
echo never > /sys/kernel/mm/transparent_hugepage/defrag
echo never > /sys/kernel/mm/transparent_hugepage/enabled

4、mount盘的时候需要为noatime,

参考文章:

1、http://crazyadmins.com/tune-hadoop-cluster-to-get-maximum-performance-part-1/

2、http://crazyadmins.com/tune-hadoop-cluster-to-get-maximum-performance-part-2/

HIVE JOIN 优化:启用分桶JOIN

今天做了一次优化测试,对同一个脚本的表,针对是否启用分桶JOIN做了A/B测试。发现建立分桶表后,启用分桶JOIN。整个脚本的执行速度快了整整一倍。

1、针对大数据量表中的最常用JOIN字段作为分桶键。不一定是主键,而是要去JOIN的键作为分桶键。而且要进行排序。

2、两表拥有同样的分桶键,分桶数量需要一致(没验证过,只是看到有这个说法)

/* 插入的时候一定要设置改参数,否则你必须手动指定reducer的数量*/
set hive.enforce.bucketing = true;

/* 插入的时候一定要设置改参数,否则你的插入数据将不会排序,即便你设置了sort by.而且你使用该表进行
sort merge的时候,数据将会是错误的。我就因为没有设置该参数,导致我两张大表JOIN本来有两千万结果的,
最后只有900多条结果!!
参考资料:join-optimization-in-apache-hive*/
set hive.enforce.sorting=true;

CREATE TABLE A(
item_id string,
master_id string,
policy_id string
)
CLUSTERED BY(POLICY_ID) SORTED BY (POLICY_ID) INTO 256 BUCKETS
ROW FORMAT DELIMITED FIELDS TERMINATED BY ','
STORED AS parquet
TBLPROPERTIES ("parquet.compression"="SNAPPY");

CREATE TABLE B (
POLICY_ID string,
POLICY_CODE string
)
CLUSTERED BY(POLICY_ID) SORTED BY (POLICY_ID) INTO 256 BUCKETS
row format delimited fields terminated by ‘,’
stored as parquet
TBLPROPERTIES (“parquet.compression”=”SNAPPY”);

上面两表都是大表,都按照policy_id分桶并排序,分桶数均为256.

3、Join的时候启用分桶JOIN:

set hive.auto.convert.sortmerge.join=true;
set hive.optimize.bucketmapjoin = true;
set hive.optimize.bucketmapjoin.sortedmerge = true;

SELECT *
FROM ODS_SNAPPY_BUCKET.T_CONTRACT_PRODUCT P
INNER JOIN ODS_SNAPPY_BUCKET.T_CONTRACT_MASTER M ON M.POLICY_ID = P.POLICY_ID

4、分桶JOIN和不分桶JOIN对比:
启用分桶JOIN

STAGE DEPENDENCIES:
Stage-1 is a root stage
Stage-0 depends on stages: Stage-1

STAGE PLANS:
Stage: Stage-1
Spark
DagName: root_20180906100101_0347c866-b18a-4712-a246-67df14874ca3:2
Vertices:
Map 1
Map Operator Tree:
TableScan
alias: m
Statistics: Num rows: 240809092 Data size: 44308872928 Basic stats: COMPLETE Column stats: NONE
Filter Operator
predicate: policy_id is not null (type: boolean)
Statistics: Num rows: 120404546 Data size: 22154436464 Basic stats: COMPLETE Column stats: NONE
Sorted Merge Bucket Map Join Operator
condition map:
Inner Join 0 to 1
keys:
0 policy_id (type: string)
1 policy_id (type: string)
outputColumnNames: _col2, _col204
Statistics: Num rows: 207420605 Data size: 41691541764 Basic stats: COMPLETE Column stats: NONE
Select Operator
expressions: _col2 (type: string), _col204 (type: string)
outputColumnNames: _col0, _col1
Statistics: Num rows: 207420605 Data size: 41691541764 Basic stats: COMPLETE Column stats: NONE
File Output Operator
compressed: false
Statistics: Num rows: 207420605 Data size: 41691541764 Basic stats: COMPLETE Column stats: NONE
table:
input format: org.apache.hadoop.mapred.TextInputFormat
output format: org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat
serde: org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe

Stage: Stage-0
Fetch Operator
limit: -1
Processor Tree:
ListSink

Time taken: 0.149 seconds, Fetched: 43 row(s)

不启用分桶JOIN

STAGE DEPENDENCIES:
Stage-1 is a root stage
Stage-0 depends on stages: Stage-1

STAGE PLANS:
Stage: Stage-1
Spark
Edges:
Reducer 2 <- Map 1 (PARTITION-LEVEL SORT, 897), Map 3 (PARTITION-LEVEL SORT, 897)
DagName: root_20180906100101_1801dd0e-2e5c-463c-ac58-f054f223a6fc:3
Vertices:
Map 1
Map Operator Tree:
TableScan
alias: p
Statistics: Num rows: 377128372 Data size: 75802802772 Basic stats: COMPLETE Column stats: NONE
Filter Operator
predicate: policy_id is not null (type: boolean)
Statistics: Num rows: 188564186 Data size: 37901401386 Basic stats: COMPLETE Column stats: NONE
Reduce Output Operator
key expressions: policy_id (type: string)
sort order: +
Map-reduce partition columns: policy_id (type: string)
Statistics: Num rows: 188564186 Data size: 37901401386 Basic stats: COMPLETE Column stats: NONE
Map 3
Map Operator Tree:
TableScan
alias: m
Statistics: Num rows: 242227352 Data size: 44569832768 Basic stats: COMPLETE Column stats: NONE
Filter Operator
predicate: policy_id is not null (type: boolean)
Statistics: Num rows: 121113676 Data size: 22284916384 Basic stats: COMPLETE Column stats: NONE
Reduce Output Operator
key expressions: policy_id (type: string)
sort order: +
Map-reduce partition columns: policy_id (type: string)
Statistics: Num rows: 121113676 Data size: 22284916384 Basic stats: COMPLETE Column stats: NONE
Reducer 2
Reduce Operator Tree:
Join Operator
condition map:
Inner Join 0 to 1
keys:
0 policy_id (type: string)
1 policy_id (type: string)
outputColumnNames: _col2, _col204
Statistics: Num rows: 207420609 Data size: 41691542428 Basic stats: COMPLETE Column stats: NONE
Select Operator
expressions: _col2 (type: string), _col204 (type: string)
outputColumnNames: _col0, _col1
Statistics: Num rows: 207420609 Data size: 41691542428 Basic stats: COMPLETE Column stats: NONE
File Output Operator
compressed: false
Statistics: Num rows: 207420609 Data size: 41691542428 Basic stats: COMPLETE Column stats: NONE
table:
input format: org.apache.hadoop.mapred.TextInputFormat
output format: org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat
serde: org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe

Stage: Stage-0
Fetch Operator
limit: -1
Processor Tree:
ListSink

Time taken: 0.092 seconds, Fetched: 65 row(s)

可以从执行计划中看到。启用分桶JOIN后,没有reduce阶段。这是一个质的飞跃。

Bucketized tables do not support INSERT INTO

今天碰到了一个错误:

FAILED: SemanticException [Error 10122]: Bucketized tables do not support INSERT INTO: Table: ecif_customer_relation_mapping

根据异常信息,我第一反应是不能使用INSERT INTO语句到一个分桶表中,但是我另外一个脚本又是没问题的。。

结果是因为我的SQL是INSERT INTO TABLE ** SELECT * FROM ….

分通表不能直接从子查询中插入。只能先将子查询固化成表后,再从改表中插入到分桶表中。

网卡情况检测

在Centos7中检测网卡情况,比如是万兆网还是千兆网,以及服务器之间的传输速度可以采用如下的方式进行检测。

1、检测网卡的传输速度

先使用ifconfig查看网卡名字。

然后使用/sbin/ethtool 网卡名,查看传输速度。

speed可以看出网卡的传输速度,这里可以看出是万兆网卡;duplex需要为full,代表启用全双工模式。

2、检测服务器间传输速度

选择两台服务器,一台作为server,一台作为client。

启动服务器:

启动客户端,即开始测试带宽:

使用的指令iperf -c ip地址 -f m(显示结果为MB) -d(双向测试)

结果中4代表从服务器到客户端的吞吐量,5代表客户端到服务器端吞吐量。