Cloudera CCA131培训考试要点

培训课程

官方文档：https://www.cloudera.com/documentation/enterprise/latest/topics/admin_rm.html

 

cloudera 管理

cloudera 分析（pig，impala，hive）

cloudera 开发

cloudera hbase

常用组件

Avro 通用的数据存储格式（行级）

Flume 采集（近似实时），日志

hadoop: 核心组件：hdfs、yarn、MR

HCatalog: hive和impala提供API

kudu: 数据存储系统，结构化，其他2个数据存储系统是：hbase 和 hdfs

Parquet：通用数据存储格式（列级）

Pig：脚本进行数据分析

sqoop: RDBMS -> Hadoop

 

HDFS: 适合批量IO，不适合做检索（原因：文件存储，没有索引的概念，只能逐行扫描）

Hbase：适合检索，但是批量效率不高

Kudu：介于两者之间

 

注意：

组件配置文件/var/run/...下

客户端配置文件/etc下

HDFS和数据本地化

1、将1GB的文件1.log被分片（split）成小文件-block

2、block的大小128M，3个副本，必须存储在三个不同的物理服务器上

 

HDFS：存放大文件，不建议小文件（维护的元数据条目会增大，即便在内存中维护，也会操作延时）

大：大于128M，实际是大于1G，性能好

 

一次性写，文件一旦被上传不能被修改，只能删除重新上传

读写粒度：block，名称是blk_ID

 

数据冗余，应用也冗余

并发-主要对block进行并发操作

 

数据本地化，数据在哪里，应用就在哪里（datanode-nodemanager）。减少网络延迟，本地处理，可大大提高效率

安装部署流程：建DB-建库-安装CM-安装CDH

CM是BS架构，Sever端建议选取独立服务器，client端需要部署Agent程序，CDH组件的安装都是通过Agent安装部署

 

安装方式：

CM - rpm包

 

CDH - 源码

      二进制

      rpm包

      parcels（官方建议）

      

远程方式管理介质，http、配置yum源

 

10.0.15.181 elephant

10.0.15.182 tiger

10.0.15.183 horse

10.0.15.184 monkey

10.0.15.185 lion

 

代理启动：

start_SOCKS5_proxy.sh

 

连接CM介质：lion:8000

连接CDH介质：lion:8050

 

start_SOCKS5_proxy.sh

 

sudo /usr/share/cmf/schema/scm_prepare_database.sh \

mysql cmserver cmserveruser password

 

hdfs访问web：

http://elephant:50070

NameNode

NameNode功能：在内存中维护元数据

元数据：文件路径

        用户、属组、权限

        1.log-> ID1,ID2,...

        ID1 -> 所在机器列表

        

SencodNameNode只能是作为Namenode的辅助，不能作为其备份。SencodNameNode主要做fsimage和edit log的合并，然后生成新的new fsimage，再回写到NameNode中的fsimage。改操作

叫检查点操作：默认一小时进行一次更新，有了SencodNameNode之后就fsimage不再为空（最近一小时的数据），不用去加载edit log（量大）；

 

元数据变更：向NameNode请求，先在NN节点的磁盘上写 log，再写mem

 

刚启动：格式化生成一个空的fsimage文件，NN加载fsimage（空）到内存（空）

运行一段时间：产生大量的edit log，重启后还是先加载空的fsimage文件到内存，再恢复edit log，可能时间很长

 

HA架构中是否有检查点工作，有，但不是SNN（该角色在HA中已经没有了），是备份的NN来做！！！

 

机器感知

防止数据丢失，额外配置，防止服务器宕机数据不丢失，机架宕机，数据也不丢失（副本放置策略）

 

NameNode的内存大小？

默认将1GB修改4GB，以后根据元数据量大增加

YARN-Spark-MR

YARN的ResourceManager：评估应用程序的资源请求

 

MR

input Split：对block文件进行键值对处理

Map的结果：是写入本地磁盘（延迟）

Map-Reduce：可能跨网络数据传输（延迟）

 

Spark优秀:

内存计算

RDD数据结构

通用

 

适合场景：流式、批量、SQL...

 

spark ——> Yarn 提交作业：

2种提交模式的区别

client：spark drive管理型Java进程跑在客户机上，调试模式，要保持客户机和集群机器通信

cluster：spark drive管理型Java进程也跑在集群中，适合生产

 

RDD：

1、数据丢失，就重新计算，保证数据冗余（牺牲CPU+MEM）

2、RDD初始是HDFS文件

 

Spark例子：

val file = sc.textFile("hdfs://elephant:8020/tmp/shakespeare.txt")

val counts = file.flatMap(line => line.split(" ")).map(word => (word, 1)).reduceByKey(_ + _).sortByKey()

counts.saveAsTextFile("hdfs://elephant:8020/tmp/sparkcount")

sc.stop()

sys.exit()

 

sqoop优化

1、修改map的并发度，默认为4

2、底层连接JDBC驱动换掉（专门开发）

 

集群规划

单台服务器硬盘空间不建议超过36T；

不建议RAID；

Hive-Impala

装beeline客户端就是要安装gateway服务

 

impala Deamon 分布式任务执行（注意与datanode一一对应，数据本地化计算）

impala catalog 维护元数据

impala state 查看Deamon的状态

 

impala提高性能中的参数

1、dfs.client.read.shortcircuit 设为true，提高读取性能

 

高级配置

NameNode参数调整

dfs.namemode.handler.count

NameNode可以开启的线程数，默认为30，如果集群机器规模大，可调整增大；算法：log(N)*20 个，太小会报“connection refused”

 

DataNode参数调整

dfs.datanode.max.locked.memory - 用于缓存的最大内存

 

YARN参数调整

mapreduce.job.reduce.slowstart.completedmaps - 在启动Reduce作业前，完成的Map任务的进度，默认为80%

设置原因：1、提供执行的效率；2、尽量节约Yarn资源（MR申请的容器会同时初始化，但是Reduce任务是在Map任务结束后才会执行，到时Reduce无效的占用资源-容器）

 

mapreduce.reduce.shuffle.parallelcopies - 复制（洗牌）阶段期间 reduce 运行的并行传输的默认数量，ln(nodes)*4 再取10的倍数。比如集群数为20，ln(20)*4= 11.98,

这里需要取20

   

MapReduce的推理执行speculative execution

当其中某个Mapper或Reducer任务执行的速度明显慢于平均速度，会重新在不同的节点上拉起一个相同的任务，执行结果是来源于第一个完成的，慢的会被kill掉；

开启要当心，如果其中的作业处理的数据量超大，重新拉起相同的任务会带来更多的资源消耗；默认是关闭；

mapreduce.map.speculative

mapreduce.reduce.speculative

 

HDFS的HA架构

在非HA架构中fsimage的维护操作是由SencodNameNode完成；在HA架构中SencodNameNode不存在，fsimage由JournalNode完成；

Failover Controller进行故障转移

 

NameNode（Active）向JournalNode写元数据，NameNode（standby）从JournalNode读元数据，并保持与NameNode（Active）心跳；

JournalNode主要是维护fsimage，定在对fsimage和edit log进行合并操作，默认一小时进行一次；

 

HA配置步骤：

1、设置JournalNode本地目录/opt/dfs/jn权限属组hdfs:hadoop（要么全部手动创建，要么不创建CM自动创建）

2、确保zk安装启动；

3、CM界面点击Enable High Availability

 

启动HA的影响，需要手动进行如下操作：

1、对HIVE

更新Hive的元数据：hive界面-操作-更新Hive Metadata NameNode

 

2、对Impala

执行 INVALIDATE METADATA

 

3、对Hue

对HDFS增加HttpFS角色

 

安全模块

1、sentry

2、LDAP

3、Kerberos

 

资源管理方式

一、基于Yarn的资源管理

1、静态资源池（首页-Cluster下拉菜单-静态资源池）

2、Yarn调度器（动态资源池）

 

一、cgroup，默认是关闭的，HOST - > Enable Cgroup-based Resource Management

对进程进行管控！！！可对cpu、内存、IO管理

 

• Yarn 调度器，对内存、cpu管理

三种调度器:FIFO/容量/公平

 

容量：Yahoo粒度-池（队列），由用户创建队列，应用必须提交到队列上，百分比分配。池的内部应用程序资源分配算法是FIFO

公平：facebook开发，官方建议使用，粒度还是池，每个池都是均等的。池的内部应用程序资源分配算法：两种算法，FIFO或均等平分

区别：池内部资源分配算法。

 

集群建议使用公平调度器！！！

课程使用的是公平调度器！！！

 

公平调度器特点：

1、pool默认有一个根池root，池是可以级联的（嵌套结构）。

2、池是不绑定资源；

3、池的均等是发生在同一层级的；

4、是yarn上面的管控资源；

5、资源均等

 

 

公平调度器抢占模式

举例：资源为30G，2个池（队列）Alice和Bob

Alice有任务，而Bob无任务运行，30G资源全部分配给Alice，当Alice中的任务运行一段时间之后，此时Bob中有任务提交，那么Yarn如何给Bob分配资源？

 

默认抢占是关闭的，只有等Alice中的任务运行完成释放资源，之后才会分配给Bob；如果抢占开启，会从Alice中抢占资源给Bob使用，会将Alice中部分的已经运行的任务kill。

 

yarn.scheduler.fair.preemption是disable

2种抢占模式：

最小抢占

公平抢占

 

公平调度器的配置变更不需要重启，因为每10s就会读取配置文件fair-scheduler.xml。

 

资源参数的配置参考Traning材料。

 

 

二、Impala查询的资源管理

Admission control

 

维护

HDFS

fsck：只能检测，⽆法修复（3copy all failure ⽆法恢复）

safe mode : 只能读不能写，即元数据不会变，可以⽤来做备份

wait 状态：⽤于脚本，检测是否处于safemode，是即夯住，恢复后脚本继续执⾏

 

备份元数据的操作

1、进入安全模式

2、检查点操作（就是将edit log与fsimage合并生成新的fsimage文件：元数据刷新）

3、进行namenode的机器上面的/opt/dfs/nn/current/fsimage_*文件

 

rebalance操作：手动操作

建议在集群闲置的时候操作

 

删除节点2种操作：

1. 退役操作
2. 删除操作

 

CDH升级

CM版本要求⼤于CDH

详见每个版本升级细节须知

 

 

练习

1. 集群自动恢复副本功能

上传1G左右的数据到hdfs上，查看block分布情况

 

可以看出block在节点上的分布情况，现将109集群的DataNode角色手动停止，查看DataNode的情况，发现109的Last Contact还在17:00点钟。

 

 

[root@bd129106 home]#  sudo -u hdfs hdfs fsck /

Connecting to namenode via http://bd129107:50070/fsck?ugi=hdfs&path=%2F

FSCK started by hdfs (auth:SIMPLE) from /192.168.129.106 for path / at Fri Feb 23 17:05:16 CST 2018

..........................................................................Status: HEALTHY

 Total size:    1982841822 B (Total open files size: 332 B)

 Total dirs:    1941

 Total files:   724

 Total symlinks:                0 (Files currently being written: 5)

 Total blocks (validated):      732 (avg. block size 2708800 B) (Total open file blocks (not validated): 4)

 Minimally replicated blocks:   732 (100.0 %)

 Over-replicated blocks:        0 (0.0 %)

 Under-replicated blocks:       0 (0.0 %)

 Mis-replicated blocks:         0 (0.0 %)

 Default replication factor:    3

 Average block replication:     3.0

 Corrupt blocks:                0

 Missing replicas:              0 (0.0 %)

 Number of data-nodes:          3

 Number of racks:               1

FSCK ended at Fri Feb 23 17:05:17 CST 2018 in 457 milliseconds

 

 

The filesystem under path '/' is HEALTHY

 

 

等到10分钟之后再次查看，109已经处于dead

到HDFS文件浏览界面查看副本数仍然为3，

 

查看datanode的报告命令

[root@bd129106 home]# sudo -u hdfs hdfs dfsadmin -report

 

 

1. HDFS快照

免费版没有文件浏览器

a）启用快照

b）拍摄快照

c）删除数据：切换eda用户，hdfs dfs -rm -r weblog

hdfs dfs -ls /user/eda

 

[eda@bd129106 home]$ hdfs dfs -ls /user/eda/.snapshot/snap1

Found 1 items

drwxr-xr-x   - eda eda          0 2018-02-24 10:15 /user/eda/.snapshot/snap1/weblog

 

hdfs dfs -tail .snapshot/snap1/weblog/test_center

 

d）恢复数据

[eda@bd129106 home]$ hdfs dfs -cp .snapshot/snap1/weblog/test_center weblog

 

e）验证

[eda@bd129106 home]$ hdfs dfs -ls /user/eda/weblog

-rw-r--r--   3 eda eda 1396874072 2018-02-24 11:25 /user/eda/weblog