文章目录
一代大数据的处理方案
- linux 常见的shell编程
chmod 777 xx.sh
service iptables start|stop|restart|status
chkconfig 服务名 on|off
ps -aux|grepkill -9 ps -aux |grep 进程名字|awk '{print $1}'
用户变量:~/.bashrc|.bash_profile 系统变量 /etc/profile source 配置文件
编译安装./configure && make|make install
touch/mkdir/rm/cp/mv/vi
scp -R|r(递归拷贝) 文件名 用户名@主机地址:路径
ssh 用户名@目标主机 ssh免密码认证:ssh -keygen -t rsa
ssh -copy -id目标主机
网卡略
工具 winscp SecureCRT Xshell X-term nodepad++
- HDFS的分布式文件存储 块存储、元数据
为什么在第一次启动Hdfs 的时候需要namenode格式化?
因为hdfs是基于块存储 namenode必须去保存整个文件系统的元数据(块信息),这些信息时持久化在fsimage中的。Hdfs在启动的时候Namenode会尝试去加载fsimage文件,恢复上一次关机状态(恢复你元数据),当第一次构建Hdfs的时候因为系统中没有元数据,所以需要第一次启动的时候需要格式化,就是为了构建fsimage
阐述一下Namenode的启动过程,并解释SecondaryNameNode的作用?
当启动HDFS的时候,系统会首先启动Namenode,Namenode服务会去加载本地的fsimage元数据 edits操作日志文件,并且将这俩个文件在内存中进行合并,合并完成后会更新一个新的edits文件,同时刷新fsimage(Namenode处于安全模式 不接受写请求),需要注意该过程仅仅是在Namenode启动过程中执行一次,一旦Namenode进入状态,Namenode就不在更新fsimage,只是更新内存中的数据,同时在edits记录内存修改日志,这就导致HDFS长期出于工作过程中产生庞大的eidts文件,如果不加干预,下一次启动Namenode的时候会花费大量的时候去合并edits和fsimage文件导致启动缓慢,为了解决单机中的Namenode启动缓慢,一般会开启SecondaryNamenode辅助Namenode完成eidts和fsimage的合并。
NameNode死了SecondaryNameNode不替代,后宫不参政
HDFS常规服务解释
NameNode
:存储元数据-单机内存、管理所有的Datanode,负责Block的create、Delete、replication指令发放
DataNode
:存储块信息、响应client端的读写块请求、执行来自Namenode的命令,向Namenode汇报自身状态
SecondaryNameNode
:辅助Namenode完成eidts和fsimage文件的合并
HDFS HA
journalnode
:负责同步namenode中的操作日志信息,并且整理fsimage,替代了SecondaryNamenode
DFSZKFailoverController|zkfc
:监测Namenode的健康状况,起到哨兵
的作用,一旦AcitveNamenode宕机,standby Namenode会切换
Rack Aware
:机架意识,通过配置机架,可以帮助NameNode|ResourceManager 更好的管理DataNode|NodeManger(大规模的集群)
注意:目前为止HA只支持俩个NameNode节点间的相互备份,存储的容量仍然是单机,如果需要构建超大规模的HDFS集群,目前可以考虑Federation(联邦) 就是对NameNode再做分区了。
- MapReduce
-
job的任务计算流程11步骤
详情见我博客 https://blog.csdn.net/zax_java/article/details/96903282 -
job封装的
6大步骤
写一个mapper extends Mapper 写一个reducer extends Reducer
- 构建job
- 设置输入输出格式 job.setInputFormatClass(TextInputFormat.class)
- 设置数据的读入和写出的路径(
写出路径必须不存在 由程序创建
)- 设置mapper和reducer逻辑
- 对shuffle格式的k-v说明 对output的输出格式说明(这里还可以设置分区数 combiner reduce个数等) job.setMapOutputKeyClass(Text.class) job.setOutputKeyClass(Text.class)
- job提交
如何书写Mapper和Reducer
mapper端的输入k-v由输入格式inputformat决定 输出k-v k必须实现序列化(要溢写) 实现comparable接口 v必须实现writable
Reducer端输入的 k-v必须和map端的输出保持一致,输出端的k-v由输出格式决定(outputformat 中的record writer)
任务的发布形式
- 打jar包 再jobsubmitter中添加 job.setJarByClass(XXX.class)
hadoop jar xxx.jar 全类名
job.setMapOutputKeyClass(Text.class) job.setOutputKeyClass(Text.class)job.setMapOutputKeyClass(Text.class) job.setOutputKeyClass(Text.class)- 跨平台提交(引入配置文件 addSource)
- 本地运行
- 任务提交的源码剖析
job.watforComplate
submit
JobSubmitter(DFSClient,YarnRunner)
submitJobInternal
checkSpecs(job); //检查输出目录是否存在
//tmp/hadoop-yarn/staging/root/.staging
Path jobStagingArea = JobSubmissionFiles.getStagingDir(cluster, conf);
JobID jobId = this.submitClient.getNewJobID();//获取任务Job_ID
Path submitJobDir = new Path(jobStagingArea, jobId.toString());//构建资源提交目录
this.copyAndConfigureFiles(job, submitJobDir);//拷贝代码片段
int maps = this.writeSplits(job, submitJobDir);//上传切片信息
this.writeConf(conf, submitJobFile);//生成job.xml
this.submitClient.submitJob(jobId, submitJobDir.toString(), job.getCredentials());//任务提交
4. InputFormat和OutputFormat的源码剖析
TextInputFormat
切面大小应该是0~140.8(128*1.1) split和你的快block的大小并不相等 所以MapReduce不擅长处理小文件,小文件过多 切面过多 你的进程就多 yarnchild多 就多占用一个G
TableInputFormat
根据你这张表中的region 未来就有多少个输入分片
Hdoop提供了小文件的解决方案
TextCombineInputFormat
前提是你小文件的格式必须是一致的
- Shuffle源码剖析(分析、排序、序列化、combiner、map端压缩)
注意:combiner 虽好但不通用 输入和输出格式必须一致 例如除法不能用combiner
但是压缩可以通用
- Hbase
- Hbase列存储特点 优势
磁盘利用率100%-支持稀疏 有就存 没有不存
可以大幅度提升io的利用率 把相似的数据归入一个列 独立的索引
- Hbase和Hdfs的本质区别
都没关系,是俩种不同的东西
Hbase能达到什么级别?
数十亿行百万列数千版本=TB/PB 亚秒|毫秒 延迟 对海量数据的随机读写
目前还没有任何一个开源数据库可以达到这个延迟
- Hmaster和Hregionserver、zookeeper关系
*宏观架构
Hregionserver内部架构(Block Cache、Region、WAL)
Region的内部结构(store、Memstore、StoreFile、compact)Region的分裂策略
RowKey设计
尽可能的把查询条件写在rowkey中
格式必须固定 不允许使用uuid这样查询效率太低了
MapReduce On Hbase*
- Hive-ETL工具 Sqoop
- Hive和数据库的区别
- Hive SQL的执行 HQL->MapReduce Hive的运行原理
Hive中的表分类:
- 管理表
- 外部表
- 分区表
- Zookeeper 分布式协调服务
- zookeeper中常见的特性-持久性节点(数据永久保存)、临时节点(回话关闭丢失 临时节点不允许创建子节点)、临时序列节点(分布式锁 临时 有序)、持久序列节点 节点监测(watch)
- 基于Zookeeper分布式锁的开发 CuratorFrameWorker (连接zookeeper client的jar包)
详情见curator 分布式锁的博客
curator 连接zookeeper的client工具
curator.apache.org
锁定虚拟机间的线程
分布式锁就是一个临时序列节点 ReadWriteLock 写写互斥 读写互斥 读读并行
redis分布式锁和zookeeper分布式锁的区别?
redis的锁是无序的
除了这些锁 数据库还有行级锁
select 语句中的for updata 悲观锁和乐观锁
悲观锁
:所有的操作都加锁 效率低下
乐观锁
:在修改这条数据的时候先拿他的时间戳 我修改数据的时候如果我拿的时间戳和以前的不一致 说明有人改了 我们就放弃这次更新
分布式锁
跨虚拟机锁定线程
- Kafka
- 消息队列(架构、offset、序列化、组消费策略、事务(幂等性))
幂等:多次操作最终影响等价于一次操作。
什么时候用到幂等:当生产者没有接受到指定书目的acks,生产者会根据用户配置retries次数重发数据,这样有可能导致数据的重复写入,为了解决这个问题开启幂等。
- Kafka Streaming的流处理(架构、特点、窗口)
特点:topology是在分区内部执行 不存在任务间的shuffle,shuffle是通过将数据写回kafka内部的reparationtopic中,过滤一遍达到shuffle的目的
kafka分区的状态独立管理 通过kafka分区的Compact机制 将状态存储在changelog中
KTable:表示分区的装态,底层使用changelog实现
KStream:普通的topic
- Storm 实时流处理
- 并行度分析
Task实际是Spout和Blot的实例。默认情况下一个线程只运行一个Task(一个线程中只有一个Spout或者Bolt)
是不是worker越多越好? storm博客中有
- 可靠性分析(Acker、Tuple Tree)At Least Once机制
18. 状态管理
对比kafka storm spark状态的管理
流计算过程中的背压 storm中设置最大的处理kafka的数量 spark Streaming中设置微批的大小
-
Trident (常规算子)
-
Trident Exaxctly Once(事务,非透明化的事务) State管理
state的状态的管理 Exactly once
trident 分为事务和非透明化的事务
相同
之处在于保证状态更新的严格有序
不同
之处在于非透明化事务 事务id不变的前提之下 同一个批次的tuple可以不同
- Storm-2.0 Stream API
窗口的分类 滑动 滚动 session window
processor time | event time (
water maker
)
strom 2.0之后对象可以自动序列化 在此之前想要处理对象 需要注册
storm中的3046 和kafka集成之后如果kafka中没有数据启不了
2.0的API 在19年6月份发布 对at least once语义做了一次升级
例如流计算对用户画像的统计什么的较为方便
- Flume 1.7.0 分布式日志采集
- 常规组件 source(Avro可以和logback集成) (spoolDir采集静态文本目录)(taildirSource动态采集) channel(memory、file、jdbc) sink(Avro HDFS Kafka)、拦截器(时间戳、正则过滤、正则抽取)、通道选择器(复制、分流)、SinkProcessor负责分组(负载均衡、failover)
- 和log4j、logback整合
github上有开源的logback项目 - 日志分流的设计