kafka-flink性能测试规划（上）

最新推荐文章于 2024-06-20 17:33:45 发布
最新推荐文章于 2024-06-20 17:33:45 发布
阅读量793 收藏 7
点赞数 3
文章标签： kafka java linux 大数据 redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_39545874/article/details/113860527
版权

1.压测方案

1.1 压测目的

   本次性能测试在正式环境下单台服务器上Kafka处理MQ消息能力进行压力测试。测试包括对Kafka写入MQ消息和消费MQ消息进行压力测试，根据不同量级的消息处理结果，评估Kafka的处理性能是否满足项目需求(该项目期望Kafka能够处理上亿级别的MQ消息)。

1.2 测试范围及方法

1.2.1 测试范围概述

   测试使用Kafka自带的测试脚本，通过命令对Kafka发起写入MQ消息和Kafka消费MQ消息的请求。模拟不同数量级的消息队列的消息写入和消费场景，根据Kafka的处理结果，评估Kafka是否满足处理亿级以上的消息的能力。

1.2.3 测试方法

  • 测试目的：

   验证单台服务器上Kafka写入消息和消费消息的能力，根据测试结果评估当前Kafka集群模式是否满足上亿级别的消息处理能力。

  • 测试方法

   在服务器上使用Kafka自带的测试脚本，模拟1y级别的消息写入以及读取请求，查看Kafka处理不同数量级的消息数时的处理能力，包括每秒生成消息数、吞吐量、消息延迟时间。

   Kafka消息写入创建的topic命名为test_kafka_throughout，Kafka消费读取的topic也是该topic;使用命令发起消费该topic的请求，针对不同的测试指标，本次我们采用固定其他值，动态变化测量值的方式来进行，具体使用脚本为kafka自带的测试脚本，分别为kafka bin目录下的kafka-producer-perf-test.sh和kafka-consumer-perf-test.sh；通过测试来查看Kafka消费不同数量级别的消息时的处理能力。

  • 准备工作

   测试之前，我们需要先用linux命令去测试磁盘的读写速度，具体命令如下：

1.测试IO读
    hdparm -t --direct /dev/sda3
    IO读用上面的命令测试即可，不过 hdparm 这个工具需要自己安装，而且需要root用户去执行；
2.测试IO写
    sync;/usr/bin/time -p bash -c "(dd if=/dev/zero of=test.dd  bs=1M count=20000)"
测试结论：
    1.dd测试出的读速度和hdparm 是存在区别的；
    2.通过 bs 选项 设置不通的读写块大小测试(默认512字节，测试使用1M)；
    3.可以看出 dd 的测出的速度与读写块的大小有关系，还可能受到系统中有IO读写的进程的影响；
    4.hdparm的测试原理可能是和dd的测试方法存在差别；
    
整体上看，IO的实际测试速度是受到很多因素影响的，包括读写的方式(随机还是顺序，hdparm和dd测试是都是采用顺序读写)、缓存机制、测试的取样等等。
所以不太可能得到一个确定的值(相同的命令行多次测试也不一样，不过差别要小些)，以上的方法中读测试还是推荐使用hdparm。
以上的数据虽然存在偏差，但还是能大体分析出机器的IO性能。只是需要明确，这些测试值是在什么样的环境下获得的。
3.测试结果
    1.磁盘cache读7471m/s；
    2.disk读163m/s；
    3.IO写125m/s；
    4.IO读206m/s；
经过测试，我们拿到的磁盘读应该在163m/s-206m/s之间，而写速度是163m/s。后续评测我们以该磁盘测试为基准来核定。

1.3 测试环境

主 机数量资 源操作系统
MQ消息服务1硬件：32(核)-32(G)-20(T)软件:Kafka集群(Kafka_2.11-1.1.0)CentoOS

2.kafka参数

   在调试和优化使用Java开发的系统时，第一步绕不开对JVM的调优，Kafka也不例外，而JVM调优的重点则是在内存上。

   其实Kafka服务本身并不需要很大内存，其依赖的是系统提供的PageCache来满足性能上的要求，本次测试时设置30G内存的目的是支持更高的并发，高并发本身就必然会需要更多的内存来支持，同时高并发也意味着SocketBuffer等相关缓存容量会成倍增长。实际使用中，调整内存大小的准则是留给系统尽可能多的空闲内存，Broker本身则是够用就好。

   JVM上的垃圾回收器，官方文档里推荐使用最新的G1来代替CMS作为垃圾回收器。为了稳定性问题，本次我们使用jdk8以上的版本，我们本次使用G1回收器的原因如下：

  • G1是一种适用于服务器端的垃圾回收器，很好的平衡了吞吐量和响应能力；
  • 对于内存的划分方法不同，Eden, Survivor, Old区域不再固定，使用内存会更高效。G1通过对内存进行Region的划分，有效避免了内存碎片问题；
  • G1可以指定GC时可用于暂停线程的时间(不保证严格遵守)。而CMS并不提供可控选项；
  • CMS只有在FullGC之后会重新合并压缩内存，而G1把回收和合并集合在一起；
  • CMS只能使用在Old区，在清理Young时一般是配合使用ParNew，而G1可以统一两类分区的回收算法。

其使用场景如下：

  • JVM占用内存较大(At least 4G)；
  • 应用本身频繁申请、释放内存，进而产生大量内存碎片时；
  • 对于GC时间较为敏感的应用。
       首先，我们设置JVM配置为：
-Xmx6G -Xms6G -XX:MMetaspaceSize=96m -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:G1HeapRegionSize=16m -XX:MinMetaspaceFreeRatio=50 -XX:MaxMetaspaceFreeRatio=80

   后续在broker的相关参数测试完成后，保持其在最优的参数下，再来针对我们的服务器和kafka的页缓存及jvm堆内存以及策略等进行测试。

2.1 Producer相关参数

   我们在producer涉及到性能的关键因素可能会存在如下几个：

  • thread:我们测试时的单机线程数；
  • bath-size:我们所处理的数据批次大小；
  • ack:主从同步策略我们在生产消息时特别需要注意，是follower收到后返回还是只是leader收到后返回，这对于我们的吞吐量影响颇大；
  • message-size:单条消息的大小，要在producer和broker中设置一个阈值，且它的大小范围对吞吐量也有影响；
  • compression-codec:压缩方式，目前我们有不压缩，gzip，snappy，lz4四种方式;
  • partition:分区数，主要是和线程复合来测试；
  • replication:副本数；
  • througout:我们所需要的吞吐量，单位时间内处理消息的数量，可能对我们处理消息的延迟有影响；
  • linger.ms：两次发送时间间隔，满足后刷一次数据。

2.2 Consumer相关参数

  • thread：我们测试时的单机线程数；
  • fetch-size：抓取数据量；
  • partition:分区数，主要是和线程复合来测试；
  • replication:副本数；
  • througout:我们所需要的吞吐量，单位时间内处理消息的数量，可能对我们处理消息的延迟有影响；

2.3 Broker相关参数

  • num.replica.fetchers：副本抓取的相应参数，如果发生ISR频繁进出的情况或follower无法追上leader的情况则适当增加该值，==但通常不要超过CPU核数+1；==
  • num.io.threads：broker处理磁盘IO的线程数，主要进行磁盘io操作，高峰期可能有些io等待，因此配置需要大些。==建议配置线程数量为cpu核数2倍，最大不超过3倍；==
  • num.network.threads：broker处理消息的最大线程数，和我们生产消费的thread很类似主要处理网络io，读写缓冲区数据，基本没有io等待，==建议配置线程数量为cpu核数加1；==
  • log.flush.interval.messages：每当producer写入多少条消息时，刷数据到磁盘；
  • log.flush.interval.ms：每隔多长时间，刷数据到磁盘；

3.flink参数

4.测试过程

4.1 producer测试

4.1.1 bath-size

  • 测试脚本
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 687  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=10000   --throughput 30000
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 687  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=20000   --throughput 30000
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 687  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=40000   --throughput 30000
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 687  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=60000   --throughput 30000
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 687  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=80000   --throughput 30000
  • 测试结果
batch-sizeackmessage-sizecompression-codecpartitionreplicationthroughputMB/SMsgNum/s
100000687none333000018.0727576
200000687none333000019.6529986
400000687none333000019.6529991
600000687none333000019.6329954
800000687none333000019.6429983

  • 测试结论

   测试中通过我们增加batch-size的大小，我们可以发现在消息未压缩的前提下，20000条一批次之后吞吐稳定在30000条/s,而数据量在19.65M/s。

4.1.2 ack

  • 测试脚本
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 4096  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=20000 acks=0   --throughput 30000
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 4096  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=20000 acks=1  --throughput 30000
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 4096  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=20000 acks=-1  --throughput 30000
  • 测试结果
batch-sizeackmessage-sizecompression-codecpartitionreplicationthroughputMB/SMsgNum/s
200000(不响应)687none333000019.6930225
200001(leader响应)687none333000019.6329954
20000-1(follower响应)687none33300005.087760
  • 测试结论

   测试中通过我们使用不同的ack策略，我们可以发现在消息未压缩的前提下，不响应速度最快，其次是leader响应，而follower响应吞吐只有其25%左右，在主从同步策略上要根据数据量还有我们的数据稳定性结合来考量。

4.1.3 message-size

  • 测试脚本
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 687  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=20000 acks=-1  --throughput 30000
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 454  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=20000 acks=-1  --throughput 30000
  • 测试结果
batch-sizeackmessage-sizecompression-codecpartitionreplicationthroughputMB/SMsgNum/s
200001687none333000019.6329954
200001454none333000012.9829976
  • 测试结论

   测试中通过我们使用两种不同的消息大小，发现在消息未压缩的前提下且其他参数一致的情况下，687字节的吞吐量是要优于454字节的，目前我们的两种消息为此大小，测试中发现当消息大小为4k时效果最优，这点可以在后续实践中再去证实。

4.1.4 compression-codec

  • 测试脚本
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 687  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=20000 acks=1 compression.type=none  --throughput 30000
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 687  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=20000 acks=1 compression.type=gzip --throughput 30000
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 687  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=20000 acks=1  compression.type=snappy --throughput 30000
./kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 687  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=20000 acks=1  compression.type=lz4 --throughput 30000
  • 测试结果1
batch-sizeackmessage-sizecompression-codecpartitionreplicationthroughputMB/SMsgNum/s
200001687none333000019.6329954
200001687gzip333000012.9729961
200001687snappy333000012.9729945
200001687lz4333000012.9529919

   在batch-size为2w且并发量在3w时，可以看出来不压缩的吞吐量最好，其他的基本相差不大。

  • 测试结果2
batch-sizeackmessage-sizecompression-codecpartitionreplicationthroughputMB/SMsgNum/s
10000001687none3310000058.689455
10000001687gzip3310000039.860762
10000001687snappy3310000065.4599907
10000001687lz43310000065.4799928

   我们在后续测试中发现，在batch-size为100w且并发量在10w时，可以看出来snappy和lz4的吞吐量上升幅度明显，而gzip由于压缩的费时其吞吐最差，不压缩的在本测试中的吞吐次之。

  • 测试结果3
batch-sizeackmessage-sizecompression-codecpartitionreplicationthroughputMB/SMsgNum/s
10000001687none3320000077.69118585
10000001687gzip3320000038.2858422
10000001687snappy3320000084.08128326
10000001687lz433200000130.89199772

   我们在后续测试中发现，在batch-size为100w且并发量在20w时，lz4的吞吐量优势明显达到19w/s，snappy次之为12.8w/s，而gzip由于压缩的费时其吞吐最差基本在5.8w/s，不压缩的在本测试中的吞吐也能达到11w/s。

  • 测试结果4
batch-sizeackmessage-sizecompression-codecpartitionreplicationthroughputMB/SMsgNum/s
10000001687none3350000061.3293596
10000001687gzip3350000035.1753686
10000001687snappy33500000105.86161582
10000001687lz433500000205.37313459

   在batch-size为100w且并发量在50w时，lz4的吞吐量优势明显达到31.3w/s，snappy次之为16.1w/s，而gzip由于压缩的费时其吞吐最差基本在5.3w/s，不压缩的在本测试中的吞吐也能达到9.3w/s。

  • 测试结果5
batch-sizeackmessage-sizecompression-codecpartitionreplicationthroughputMB/SMsgNum/s
10000001687none3360000061.5393909
10000001687gzip3360000035.4354070
10000001687snappy3360000071.04108431
10000001687lz433600000245.88375280

   在batch-size为100w且并发量在60w时，lz4的吞吐达到37.5w/s，snappy此时下降到10.8w/s，而gzip由于压缩的费时其吞吐最差基本在5.4w/s，不压缩的在本测试中的吞吐为9.4w/s。

  • 测试结果6
batch-sizeackmessage-sizecompression-codecpartitionreplicationthroughputMB/SMsgNum/s
10000001687none3370000046.9471648
10000001687gzip3370000038.2258331
10000001687snappy3370000091.34139419
10000001687lz433700000178.66272695

   在batch-size为100w且并发量在70w时，lz4的吞吐量下降到达到27.2w/s，snappy次之为13.9w/s，而gzip则继续保持在5.8w/s，不压缩则下降到7.1w/s。

  • 测试结果7

    测试单副本单分区下的各压缩的吞吐量：

batch-sizeackmessage-sizecompression-codecpartitionreplicationthroughputMB/SMsgNum/s
10000001687none1160000044.0167179
10000001687gzip1160000038.9559454
10000001687snappy1160000089.44138245
10000001687lz411600000139.19212449

   我们这次使用1个分区1个副本的主题，测试中通过我们使用不同的压缩格式，在其他参数一致的情况下，在并发和batch-size增大到60w和100w的情况下，lz4达到最好的吞吐21.2w/s，而普通不压缩的方式则维持在6.7w/s。

  • 测试结论

   本次测试对数据的存储块大小未测，但在之前的测试中发现压缩以及解压的情况也是lz4算法最优，==lz4压缩最大时可以达到30w+/s的吞吐，而不压缩为12w/s,snappy最大为16w/s,gzip最大为5.8w/s==；故后续生产消息时建议采用lz4压缩，不仅可以节省磁盘，也可以大幅度增加我们的吞吐。

4.1.5 partition

  • 测试脚本
1、创建topic
/bin/kafka-topics.sh --create --zookeeper 110.240.0.9:2181,10.240.0.10:2181,10.240.0.13:2181/kafka --topic test_kafka_perf11  --partitions 1 --replication-factor 1
/bin/kafka-topics.sh --create --zookeeper 110.240.0.9:2181,10.240.0.10:2181,10.240.0.13:2181/kafka --topic test_kafka_perf8 --partitions 2 --replication-factor 1
/bin/kafka-topics.sh --create --zookeeper 110.240.0.9:2181,10.240.0.10:2181,10.240.0.13:2181/kafka --topic test_kafka_perf16 --partitions 3 --replication-factor 1
/bin/kafka-topics.sh --create --zookeeper 110.240.0.9:2181,10.240.0.10:2181,10.240.0.13:2181/kafka1 --topic test_kafka_perf24 --partitions 4 --replication-factor 1
/bin/kafka-topics.sh --create --zookeeper 110.240.0.9:2181,10.240.0.10:2181,10.240.0.13:2181/kafka --topic test_kafka_perf32 --partitions 5 --replication-factor 1

2、生产数据
/bin/kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 10240  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=80000 acks=1  compression.type=lz4 --throughput 29000
3、初步结论
分区数越多，单线程消费者吞吐率越小。随着更多的broker线程和磁盘开始扫描不同的分区，吞吐量开始显著增加。但是，一旦使用了所有broker线程和磁盘，添加额外的分区没有任何效果。
  • 测试结果
batch-sizeackmessage-sizecompression-codecpartitionreplicationthroughputMB/SMsgNum/s
10000001687lz411600000130.9199792
10000001687lz421600000141216211
10000001687lz431600000199.6304645
10000001687lz441600000253.87387491
10000001687lz451600000153233830
  • 测试结论

   在我们的broker线程小于partiton数时，随着线程增多，吞吐上升，而在两者对等时，达到最优，后续基本稳定，但是由于网络和磁盘的问题可能会有一些起伏。

4.1.6 replication

  • 测试脚本
1、创建topic

/bin/kafka-topics.sh--create --zookeeper 110.240.0.9:2181,10.240.0.10:2181,10.240.0.13:2181/kafka --topic test_kafka_rep2 --partitions 1 --replication-factor 1
/bin/kafka-topics.sh--create --zookeeper 110.240.0.9:2181,10.240.0.10:2181,10.240.0.13:2181/kafka --topic test_kafka_rep3 --partitions 1 --replication-factor 2
/bin/kafka-topics.sh--create --zookeeper 110.240.0.9:2181,10.240.0.10:2181,10.240.0.13:2181/kafka --topic test_kafka_rep24 --partitions 1 --replication-factor 3

2、生成数据
/bin/kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 687  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=1000000 acks=1  compression.type=lz4 --throughput 500000
3、初步结论
备份数越多，吞吐率越低。
  • 测试结果
batch-sizeackmessage-sizecompression-codecpartitionreplicationthroughputMB/SMsgNum/s
60000014096lz411600000138.75211779
60000014096lz412600000104.18159008
60000014096lz41360000069.20105618
  • 测试结论

   Replication是我们对不同partition所做的副本，它的大小会在ISR中显示，为了保证数据的安全性，ISR中掉出的版本应该保持在1，所以此处我们从replica为2开始测试。在ack不同时，其数量的多少会对性能造成线性的影响，数量过少会影响数据的可用性，太多则会白白浪费存储资源，一般建议在2~4为宜，我们设置为3个，既能保障数据的高可用，又避免了浪费过多的存储资源。

4.1.7 throughout/IO

  • 测试脚本：
/bin/kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 10240  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=1000000 acks=1  compression.type=lz4 --throughput 10000
/bin/kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 10240  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=1000000 acks=1  compression.type=lz4 --throughput 30000
/bin/kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 10240  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=1000000 acks=1  compression.type=lz4 --throughput 50000
/bin/kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 10240  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=1000000 acks=1  compression.type=lz4 --throughput 70000
/bin/kafka-producer-perf-test.sh  --topic test_kafka_perf1 --num-records 100000000 --record-size 10240  --producer-props   bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092  batch.size=1000000 acks=1  compression.type=lz4 --throughput 100000
  • 测试结果
batch-sizeackmessage-sizecompression-codecpartitionreplicationthroughputMB/SMsgNum/s
10000001687lz41110000065.4699907
10000001687lz411200000130199900
10000001687lz411300000139.77213337
10000001687lz411400000145.33221818
10000001687lz411500000154.38235626
10000001687lz411600000141215517

  • 测试结论

   在主题是一个分区和一个副本时，我们看到在并发50w以下时，随着并发数增大，吞吐上升，但是在50w以后时，可以看出并发增大反而吞吐降低了，这是因为IO的限制，在高并发的情况下，产生了阻塞而导致。

林夕_Yume
关注
  • 3
    点赞
  • 踩
  • 7
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
flink kafka进 kafka出 测试代码(含数据和命令)
yy的博客
11-27 318
package TableTest import org.apache.flink.runtime.io.network.buffer.Buffer.DataType import org.apache.flink.streaming.api._ import org.apache.flink.streaming.api.scala._ import org.apache.flink.table.api._ import org.apache.flink.table.api.bridge.scala._.
Flink实时大数据处理性能测试
禅与计算机程序设计艺术
01-18 1122
1.背景介绍 Flink是一个开源的流处理框架，用于实时大数据处理。它可以处理大量数据，提供低延迟和高吞吐量。Flink的性能测试是一项重要的任务，可以帮助我们了解其在实际应用中的表现。在本文中，我们将讨论Flink实时大数据处理性能测试的背景、核心概念、算法原理、代码实例、未来发展趋势和挑战。 1.1 Flink的发展历程 Flink起源于2010年，由德国技术大学(TU Berlin)的...
【Flink 核心篇】Apache Flink 1.16 版本特性
书山有路，学海无涯。记录成长，追逐梦想
04-22 1279
Apache Flink 持续保持高速发展，是 Apache 最活跃的社区之一。Flink 1.16 共有 240 多个 Contributor 热情参与，共完成了 19 个 FLIP 和 1100 多个 issue，给社区带来非常多振奋人心的功能。
kafka-flink性能测试规划（中）
weixin_39545874的博客
07-30 286
4.2 consumer测试 4.2.1 thread 测试脚本 ./kafka-consumer-perf-test.sh --zookeeper 110.240.0.9:2181,10.240.0.10:2181,10.240.0.13:2181/kafka --topic test_kafka_perf1 --fetch-size 1048576 --messages 100000 ...
kafka-flink性能测试规划（下）
weixin_39545874的博客
07-30 644
4.3 broker测试    涉及的参数众多，诸如以下： default.replication.factor num.replica.fetchers auto.create.topics.enable min.insync.replicas unclean.leader.election.enable broker.rack log.flush.interval.messages log....
flink消费kafka数据
eyeofeagle的博客
03-25 6328
maven配置 <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-scala_2.11</artifactId> <version>1.7.2</version> </dependency> ...
flink 性能压测
wppwpp1的专栏
06-07 3803
1、维表关联性能，最高吞吐，可以通过并行度和kafka的吞吐测出相关性能,如下图压测性能，200并发，tps正常在5w左右。 2、之前kafka吞吐最高能达到90MB/s的输入，所以压测要达到两倍的性能，也就是200mb 3、以下是同样的并行度，通过设置任务延迟，消费五个小时的数据, 来实现相关性能压测，200并发，最高吞吐tps能达到30w左右 4、kafka的压测性能如下，写入稳定在250mb左右，达到要求： ...
超详细性能测试思维导图
03-10
性能测试是软件质量保证的重要环节，它主要关注的是系统在特定负载下的运行表现，包括响应时间、吞吐量（TPS）、并发用户数等关键指标。对于初学者来说，掌握性能测试的基本概念和流程至关重要。 首先，性能测试...
kafka、storm、flink、apex、spark五种流式大数据系统调研报告
06-21
本文主要调研了Apache Kafka...2）利用了kafka自带的测试脚本进行了kafka性能测试；3）通过Hibench进行了Flink、Storm和Spark Streaming的比较测试；4）进行了Apex的简单测试；5）对以上流式大数据系统进行了总结分析。
flink环境搭建.pdf
01-18
Kafka 是一个高性能的消息队列系统，Flink 需要 Kafka 来处理数据。按照以下步骤进行安装： 1. 下载 Kafka：从 Kafka 官方网站下载 Kafka 安装包。 2. 安装 Kafka：传输安装包到 /usr/local/software 目录下，解...
StreamingBench:支持Flink和Spark的流媒体基准测试
05-26
流基准测试旨在测量流处理系统（如flink和spark）的性能。 模拟了三个用例（用户访问会话分析，实时广告评估和购物记录分析）。 原始数据将生成并存储在Kafka中。 流映射到流表中，并且对这些表进行查询。 建造 ...
kafka教程
03-04
总共12课，高清未加密课程。 课程环境 linux + java 软件准备 kafka_2.11-0.10.0.1 && kafka_2.11-0.8.2.1 课程基础 Java或者Scala编程基础 熟悉基本Linux操作 最好熟悉一种及以上其它分布式...第12课 Kafka性能测试
flink状态与kafka消费参数
sunlang的博客
06-05 1069
当没有使用状态的时候，如第一次部署 我们设置了 consumer.setStartFromTimestamp(DateUtil.getMillsFromString(startTime)); 那么这个参数就会起作用 当我们任务从ck状态恢复的时候，这个参数就失去了作用 如下图 任务从ck恢复，时间设置为2021-06-05 但是并没有从凌晨消费，而是从下午3点 ...
HiBench+kafka+flink 流测试命令及步骤
Yannick Jiang 的专栏
11-05 399
测试机运行原理分析如下： Hadoop1 [flink] Internal IP enp5s0f1: 192.168.1.1 External IP enp9s0f0: 10.18.182.102 BMC : 10.18.182.109 Hadoop2 [kafka] Internal IP enp5s0f1: 192.168.1.2 External IP enp9s0f0: 10....
Kafka性能压测
紫蝶侠的博客
04-01 305
Flink-Kafka性能压测全记录 2.1 Producer相关参数    我们在producer涉及到性能的关键因素可能会存在如下几个： thread:我们测试时的单机线程数； bath-size:我们所处理的数据批次大小； ack:主从同步策略我们在生产消息时特别需要注意，是follower收到后返回还是只是leader收到后返回，这对于我们的吞吐量影响颇大； message-size:单条消息的大小，要在producer和broker中设置一个阈值，且它的大小范围对吞吐量也有影响； compress
Flink入门(十四)大job的StateBackend压力测试
baifanwudi的专栏
06-19 1619
最近有这样需求，两个topic消息interval-join。 其中一个topic是，展示列表的详细信息（曝光），大约20分钟，有100G大小（主要从服务端发送）； 另外一个topic是，用户操作列表（点击、下单），由前端发送，数据很少，大约10分钟几十M，action表示操作， itemId表示方案的唯一标识符，itme表示操作时间，unionId表示用户唯一标识符。 {"action":"cl...
hibench 压测flink_使用 Hibench 对 Spark 进行基准测试
weixin_31809171的博客
01-14 845
概述Hibench 是 Intel 开源的大数据基准测试工具，可以评估不同大数据框架的速度，吞吐量和系统资源利用率。包括 Sort, WordCount, TeraSort, Sleep, SQL, PageRank, Nutch indexing, Bayes, Kmeans, NWeight 和 enhanced DFSIO等，还支持流任务的基准测试，例如 Spark Streaming, F...
flink造压测数据到hbase
yy的博客
09-10 596
flink hbase mockdata mock数据 造数据 压测
14-Kafka-Day03
最新发布
qq_43819048的博客
06-20 730
可以理解为分配的结果带有“粘性的”。即在执行一次新的分配之前， 考虑上一次分配的结果，尽量少的调整分配的变动，可以节省大量的开销。粘性分区是 Kafka 从 0.11.x 版本开始引入这种分配策略，首先会尽量均衡的放置分区 到消费者上面，在出现同一消费者组内消费者出现问题的时候，会尽量保持原有分配的分区不变化。
Flink Connector 的架构解析及最佳开发实践.pdf
03-21
- 在测试方面，开发者需要确保充分覆盖Flink Connector的功能，包括正确处理各种边界条件、异常情况以及性能优化。 Flink Connector 的设计与开发实践对于理解和使用Apache Flink处理实时流处理和批处理任务至关...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值