文章目录

  • Hadoop
  • Hive
  • Zookeeper
  • zk仲裁机制
  • Spark
  • SparkStreaming
  • RDD五大特性
  • SparkStreaming背压机制
  • SparkShuffle的优化配置
  • Kafka
  • kafka数据同步/镜像工具 kafka mirror maker
  • Kafka为什么快
  • 磁盘读写
  • 页缓存pagecache+buffcache
  • mmap（内存文件映射）
  • 零拷贝（zero-copy）
  • 存储设计
  • 批量发送
  • 压缩
  • 消息写入过程
  • 消息读的过程


Hadoop

HttpFs
NFS Gateway工具可以将HDFS上面的空间映射到linux本地磁盘上，然后再进行操作。
只要在一个hdfs客户端上装上，启动NFS Gateway服务，并mount上这个NFS文件夹，其他主机即可访问（编辑文件有限制，读写没问题）。
在尝试启动 NFS Gateway 角色实例之前，请先启动该主机上的portmap或者rpcbind服务。
没有的话需要安装

yum install rpcbind -y
//安装rpcbind

Hive

hive Metastore 服务器端口 9083

Zookeeper

zk仲裁机制

zk服务器运行方式有两种

  • 独立模式(standlone)
  • 仲裁模式

zk的状态无法进行覆盖，生产环境中会有一定危险

仲裁模式集群中，具备高可用的覆写功能。如果zk信息全部同步完成后，在进行下一条数据的同步，延时会比较突出

为了规避这个问题，zk使用了法定人数的思想。在zk信息同步时，保证若干个指定的节点同步完成，就继续下一次操作，而不是等全部的节点都同步完成。

法定人数至少是3，为了正常工作，集群中至少有3台服务器是正常运行的。

Spark

SparkStreaming

RDD五大特性

A list of partitions
a function for computing each split 
a list of dependencies on other RDDs
Optionally,a partitioner for key-value RDDs
Optionally,a list of preferred locations to compute each splip
//每一个RDD都有多个分
//每一个分区都有一个computing函数来进行计算
//RDD之间存在着宽窄依赖关系
//在K-V类型的RDD上存在着分区器，分区器有两种，Range partitioner和Hash partitioner
//移动数据不如移动计算

SparkStreaming背压机制

当Spark消费数据时，batch processing time>batch interval时，也就是批次数据的处理时间比批次数据产生的时间长的时候，越来越多的数据被接收，但是数据的处理速度没有跟上，导致数据开始积压，可能进一步导致OOM异常

Spark1.5之前，使用Receiver-based数据接收器，可以通过配置spark.streaming.receiver.maxRate参数来限制每个receiver每秒最大可以接受的记录的数据。对于 Direct Approach 的数据接收，我们可以通过配置spark.streaming.kafka.maxRatePerPartition 参数来限制每次作业中每个 Kafka 分区最多读取的记录条数。

这种方法虽然可以通过限制接收速率，来适配当前的处理能力，但这种方式存在以下几个问题：

  • 我们需要事先估计好集群的处理速度以及消息数据的产生速度；
  • 这两种方式需要人工参与，修改完相关参数之后，我们需要手动重启 Spark Streaming 应用程序；
  • 如果当前集群的处理能力高于我们配置的 maxRate，而且 producer 产生的数据高于 maxRate，这会导致集群资源利用率低下，而且也会导致数据不能够及时处理。

(背压)反压机制

Spark 1.5 引入了反压（Back Pressure）机制，其通过动态收集系统的一些数据来自动地适配集群数据处理能力。

SparkShuffle的优化配置

set hive.exec.dynamic.partition=true;  
set hive.exec.dynamic.partition.mode=nonstrict;
set spark.speculation=true;
set spark.sql.shuffle.partitions=1000;
set spark.sql.adaptive.enabled=true;
set spark.sql.adaptive.shuffle.targetPostShuffleInputSize=128000000;
set spark.sql.adaptiveBroadcastJoinThreshold=10485760; 
set spark.sql.adaptive.allowAdditionalShuffle=true;
set spark.sql.adaptive.join.enabled=true;
set spark.sql.adaptive.skewedJoin.enabled=true;
set spark.sql.adaptive.minNumPostShufflePartitions=1;
set spark.sql.adaptive.maxNumPostShufflePartitions=1000;
set spark.sql.planner.skewJoin=true;
set spark.sql.planner.skewJoin.threshold=100000;
set spark.sql.cbo.enabled=true;
set spark.sql.cbo.joinReorder.card.weight=0.8;
set spark.executor.extraJavaOptions=-XX:ParallelGCThreads=4 -XX:+UseParallelGC;
set spark.sql.autoBroadcastJoinThreshold=10485760;
set spark.sql.broadcastTimeout=600s;
set spark.sql.bigdata.useExecutorBroadcast=true;
set spark.hadoopRDD.ignoreEmptySplits=true;

Kafka

kafka数据同步/镜像工具 kafka mirror maker

MirrorMaker为kafka的镜像工具，如果没有这个需求就可以不启动这个服务。
可以使用kafkamaker来进行kafka之间的数据迁移/发送

Kafka为什么快


kafka 如何保证消息不重复_spark

磁盘读写

磁盘读写过程

  • 先进行寻址（找到对应的柱面，磁头要瞄准相应的磁道）
  • 旋转（等待扇区从磁头地下旋转经过）
  • 数据传输（从内存和磁盘中进行实际传输）

kafka读取数据是采用的是顺序读写的方式，省去了磁盘寻址的时间，比随机读写要快约1000倍

页缓存pagecache+buffcache

pagecache（以page为单位，进行缓存文件内容）

缓存在pagecache中的文件数据能够更快的被用户读取

同时，带有buffer的写入操作，数据写入到page cache中就立即返回，不需要等待持久化到磁盘中，提高了上层应用读写文件的整体性能。cached这列的数值表示的是当前的页缓存（page cache）的占用量，page cache文件的页数据，页是逻辑上的概念，因此page cache是与文件系统同级的

好处是：避免了brock的内存开销，避免了GC问题，应用程序重启数据不会丢失。操作系统层面的缓存利用率会更高，服务重启不会消失，避免了缓存重建的过程

buffer cache：磁盘等设备缓冲

buffers列 表示当前的块缓存（buffer cache）占用量，buffer cache用于缓存块设备（如磁盘）的块数据。块是物理上的概念，因此buffer cache是与块设备驱动程序同级的。

mmap（内存文件映射）

把物理磁盘文件和page cache进行映射，可以向读写硬盘一样读写内存

零拷贝（zero-copy）

操作系统非零拷贝过程：

  • 从磁盘copy到page cache
  • 从page cache copy到用户缓存区中
  • 从用户缓存区中copy到socket缓存中
  • socket缓存中copy到网卡接口中

零拷贝的过程：

  • 磁盘文件copy到page cache中
  • 从page cachecopy到网卡接口中

存储设计

topic分为了多个partition

partition存储时分成了多个sgement

sgement中存储了.index和.log文件

sgement只允许追加的形式

offset支持连续的预读和批量写

批量发送

为了减少网络io的开销，kafka支持batch.size和linger.ms

batch.szie:消息条数达到个数就立刻发送

linger.ms:消息不够，但是超过一定时间就发送

压缩

节省网络io

如果每个消息都压缩，但是压缩率相对很低，所以Kafka使用了批量压缩，即将多个消息一起压缩而不是单个消息压缩

Kafka允许使用递归的消息集合，批量的消息可以通过压缩的形式传输并且在日志中也可以保持压缩格式，直到被消费者解压缩

Kafka支持多种压缩协议，包括Gzip和Snappy压缩协议

消息写入过程

kafka 如何保证消息不重复_kafka_02


producer需要从用户空间到网卡(zero-copy)

生产者发送批量压缩的数据到broker，broker通过MappedByteBuffer的map()函数映射其地址到你的虚拟内存地址。

接着就可以对这个MappedByteBuffer执行写入操作了，写入的时候他会直接进入PageCache中，然后过一段时间之后，由os的线程异步刷入磁盘中，可以看上面的示意图。

上图中似乎只有一次数据拷贝的过程，他就是从PageCache里拷贝到磁盘文件里而已！这个就是你使用mmap技术之后，相比于传统磁盘IO的一个性能优化

消息读的过程

读取数据会先判断消息是否在page cache存在，存在就可以直接从page cache消费数据，所以消费实时数据会很快。

但是消费历史数据，就得将之前的历史数据和邻近的数据块，加载到page cache中。

这里加载邻近的数据就是一个预读的过程，是一个优化的过程