这篇文章给大家分享的是有关如何使用YCSB进行HBase性能测试的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。
创新互联公司服务项目包括五大连池网站建设、五大连池网站制作、五大连池网页制作以及五大连池网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，五大连池网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到五大连池省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！
在集群上运行任何性能基准测试工具时，关键的决定始终是应该使用什么数据集大小进行性能测试，并且在这里我们演示了为什么在运行HBase性能时选择“合适的”数据集大小非常重要在您的集群上进行测试。
HBase集群配置和数据集的大小可能会改变同一集群上工作负载的性能和测试结果。您应该根据要了解的有关集群性能的信息来选择此数据集大小。为了表明在可用内存缓存和一个有配合从底层存储我们跑读取工作组之间的差异2 YCSB工作负载与同CDP私有云基础7.2.2运营数据库集群上选择适当的数据集大小的测试。我们使用的数据集大小为40GB与1TB，下面比较了不同YCSB工作负载的吞吐量，在图表中，柱形越高，吞吐量越好。
注意：吞吐量=每秒操作
当应用程序尝试从HBase集群中读取数据时，处理请求的区域服务器会首先检查所需的结果是否在其块缓存中已经存在于其进程本地的数据块中。如果存在数据块，则可以直接从缓存中服务客户请求，这算作缓存命中。但是，如果该块当前不在区域服务器进程本地，则将其计为缓存未命中，必须从HDFS存储中的HFile中读取该块。然后，根据缓存利用率，该块将被保存在缓存中以供将来请求。
如预期并在摘要图中所示，与从hdfs存储中的HFiles访问数据的工作负载运行相比，大多数数据集适合高速缓存的工作负载的延迟较低，吞吐量更高。
为了选择工作负载数据集大小来很好地满足我们的测试目标，重要的是检查RegionServer堆，L1和L2缓存，OS缓冲区缓存的大小，然后设置适当的数据集大小。在YCSB工作负载运行完成之后，可以检查一个很好的参数，作为验证事情是否按预期运行的一种方式，即从缓存中提供了多少数据（缓存命中）以及从hdfs存储中访问了多少数据。区域服务器缓存命中次数与总读取请求的比率就是缓存命中率。
您可以从L1缓存命中率“ l1CacheHitRatio”配置中找到此信息。如果在集群中同时设置了L1和L2缓存，则L1缓存服务于索引块，L2缓存服务于数据块，并且您可以记录L1“ l1CacheHitRatio”和L2“ l2CacheHitRatio”配置以供参考。
本博文的其余部分将详细介绍测试设置，选择数据集大小，然后使用这些数据集大小运行YCSB。
用于此测试的HBase集群配置
使用的集群：6个节点集群（1个主节点+ 5个区域服务器）
说明：Dell PowerEdge R430、20c / 40t Xenon e5-2630 v4 @ 2.2Ghz，128GB Ram，4-2TB磁盘
安全性：未配置（无Kerberos）
CDP版本：CDP私有云Base 7.2.2具有1个主服务器+ 5个区域服务器的6节点HBase集群
JDK使用jdk1.8_232
HBase Region服务器配置了32GB堆
HBase主站已配置有4GB堆
具有LruBlockCache的L1高速缓存用于12.3 GB高速缓存大小
集群中的L1缓存总数为61 GB（12.3 * 5 = 61GB）
集群上未配置L2堆外缓存
在我们的HBase集群中，我们在分配给L1块缓存的5个区域服务器中总共配置了61GB（12.3GB * 5）。对于完全适合缓存的数据集，我们选择了大小为40GB的数据集。
对于第二种情况，我们希望数据比可用缓存大得多。为了选择合适的数据集大小，我们查看了集群中已配置的HBase块缓存和OS缓冲区缓存。在给定的HBase集群中，跨RegionServer聚合时，配置的L1块缓存为61G。服务器节点每个服务器总共有128G RAM，OS可以使用非专用于服务器进程的任何内存来有效地缓存基础HDFS块并提高整体吞吐量。在我们的测试配置中，每个区域服务器节点上都有大约96G OS缓存可用于此目的（忽略DataNode或OS进程使用的内存来简化操作）。在5个区域服务器上进行汇总，我们有大约500G的缓冲区（96G * 5个区域服务器）潜力。因此，我们选择了1TB的数据集大小，
将目标数据大小转换为YCSB参数在YCSB中，默认情况下一行为1KB，因此，根据加载到YCSB“用户表”中的行数，您可以轻松估算YCSB“用户表”表数据大小。因此，如果您上载100万行，则已将1,000,000 * 1KB = 1GB的数据上载到YCSB“用户表”中。
我们两个测试使用的数据集大小为：
40 GB数据和4000万行
1 TB数据和10亿行
测试方法
在6节点集群上安装了CDP私有云基础7.2.2，并生成了4000万行的工作负载数据（总数据集大小=> 40 GB），并运行了YCSB工作负载。加载后，在开始工作负载测试之前，我们等待所有压缩操作完成。在HBase上运行的YCSB工作负载是
工作负载A：50％读取和50％更新
工作负载C：100％读取
工作负载F：50％读取和50％更新/读取-修改-写入比率：50/50
仅自定义更新工作负载：100％更新
每个YCSB工作负载（A，C，F和UpdateOnly）各自运行15分钟，并且重复完整的运行5次，两次运行之间没有重新启动，以测量YCSB吞吐量*。显示的结果是5次运行中最后3次运行的平均值。为了避免第一轮和第二轮的损失，忽略了前两次测试。
一旦完成40GB的运行，我们就丢弃了可使用的用户，并重新生成了10亿行，以创建1TB的数据集大小，并在同一集群上以相同的方法重新运行了测试。
试验结果
YCSB结果为40GB
在40GB的情况下，数据可以完全容纳在集群上的61GB L1缓存中。在测试期间，在集群中观察到的L1缓存命中率接近99％。
提示： 对于较小的数据集，数据可以放入缓存中，我们还可以使用“加载时缓存”选项，并使用表选项PREFETCH_BLOCKS_ON_OPEN预热缓存以获取100％的缓存命中率
每个YCSB工作负载每5次运行15分钟，并取最后3次运行的平均值，以避免第一次运行损失。
下表显示了在区域服务器上40G L1缓存命中率达到99％时看到的结果：
运作方式 | 数字行动 | 通量 | 平均延迟 | 95延迟 | 99等待时间 |
（每秒操作数） | （多发性硬化症） | （多发性硬化症） | （多发性硬化症） | ||
工作负载C | 148558364 | 165063 | 0.24 | 0.30 | 0.48 |
仅更新 | 56727908 | 63030 | 0.63 | 0.78 | 1.57 |
工作负载A | 35745710 | 79439 | 0.40 | 0.54 | 0.66 |
工作负载F | 24823285 | 55157 | 0.58 | 0.70 | 0.96 |
在1TB的情况下，数据无法放入集群上的61GB L1高速缓存或500GB OS缓冲区高速缓存中。在测试期间观察到的集群中L1缓存命中率为82-84％。
我们每5次将每个工作负载运行15分钟，并取最近3次运行的平均值，以避免第一次运行损失。
下表显示了在区域服务器上1TB L1缓存命中率达到82-84％时看到的结果：
运作方式 | 数字行动 | 通量 | 平均延迟 | 95延迟 | 99等待时间 |
（每秒操作数） | （多发性硬化症） | （多发性硬化症） | （多发性硬化症） | ||
工作负载C | 2727037 | 3030 | 13.19 | 55.50 | 110.85 |
仅更新 | 56345498 | 62605 | 0.64 | 0.78 | 1.58 |
工作负载A | 3085135 | 6855 | 10.88 | 48.34 | 97.70 |
工作负载F | 3333982 | 3704 | 10.45 | 47.78 | 98.62 |
*吞吐率（ops / sec）=每秒操作数
分析
比较上面两个不同数据集大小的测试结果，我们可以看到当从具有预热缓存的40G数据集中更快地访问数据而不是从hdfs快速访问数据时，相同的工作负载吞吐量如何从每秒3K操作变化到每秒165K操作。存储。
下面的图表显示了吞吐量，并比较了使用2个不同大小的数据集运行时不同工作负载的吞吐量如何变化。在图表中，条形越高，吞吐量越好。
注意：吞吐量=每秒操作
如图所示，在40G情况下，读取数据如Workload A，Workload C和Workload F的YCSB工作负载具有更好的吞吐量，在40G情况下，数据容易放入缓存，而在1TB数据大小的情况下，必须使用HFile数据。从HDFS访问
从缓存命中率来看，40G数据集的缓存命中率接近99％，而1TB数据集的缓存命中率约为85％，因此在1TB情况下，有15％的数据是从hdfs存储中访问的。
在这两种情况下，我们运行的YCSB自定义仅更新工作负载都具有相同的吞吐量，因为它仅进行更新而没有读取。
在HBase性能期间，我们密切关注第95和第99个百分位延迟。平均延迟只是总吞吐量除以总时间，但是第95个百分位数和第99个百分位数显示了影响总工作负载吞吐量的实际异常值。在1TB的情况下，第95和第99个百分位的高延迟异常值会导致吞吐量下降，而在40GB的情况下，第99个百分位的低延迟缓存命中会导致总吞吐量增加。
下图显示了平均延迟，第95个百分位延迟和第99个百分位延迟的延迟比较，以及在使用不同大小的数据集运行时，不同工作负载的延迟差异。
在上面的图表中，很难看到代表40GB数据集延迟的条形图，因为它们与从HDFS访问数据的1TB数据集所观察到的延迟相比非常低。
我们使用等待时间值的对数绘制了等待时间图，以显示下表中的差异
如上所示，在40GB的情况下，缓存命中率接近99％，并且大多数工作负载数据在缓存中可用，因此延迟要低得多。与1TB数据集相比，由于必须从HDFS存储访问HFile数据，因此缓存命中率约为85％。
在40G情况下，从预热的缓存返回99％数据的Workload C的平均延迟和99延迟约为2 – 4 ms。在1TB情况下，相同Workload C的第99个百分位数延迟对于Workload C（只读工作负载）约为100ms。
这表明从堆上块高速缓存命中的高速缓存在大约2 ms内返回读取，并且高速缓存未命中以及从HDFS获取记录可能需要大约100 ms的时间。
建议
在运行YCSB基准测试时，数据集的大小会对性能结果产生重大影响，因此适当调整测试的大小非常重要。同时，查看缓存命中率以及最小延迟与第99个延迟之间的延迟差异，将有助于您找到与从集群中的基础存储访问数据相比的缓存命中的延迟。
要检查区域服务器上工作负载的缓存命中率，可以使用以下命令
curl http://
您还可以按照以下步骤从HBase Web UI中查看缓存命中率：
在HBase Web UI中，单击区域服务器
在“块高速缓存”部分下，选择L1（如果配置了L2，则选择L2）以查看高速缓存命中率。
屏幕快照显示了来自L1块缓存的缓存命中率，如下所示：
这是指向上面显示的HBase屏幕快照和块缓存的更多信息的链接https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html
感谢各位的阅读！关于“如何使用YCSB进行HBase性能测试”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！