基准测试的特点_nexmark

基准测试的特点

1.可复现性

测试结果可以重现

2.能调整作业的负载（数据量、数据分布） 

数据库领域非常著名的TPC-H、TPC-DS涵盖了大量的query集合，来捕获查询引擎之间细微的差别。而且这些query集合都立于真实业务场景之上（商品零售行业），数据规模大，因此也很受一些大数据系统的青睐。

3.能调整作业的负载。即数据量、数据分布

在大数据领域，不同的数据规模对于引擎来说可能会是完全不同的事情。例如 Yahoo Benchmark 中使用的 campaign id 只有 100 个，使得状态非常小，内存都可以装的下。这样使得同步 IO 和 checkpoint 等的影响可以忽略不计。而真实的场景往往要面对大状态，面临的挑战要复杂困难的多。像 TPC-DS 的数据生成工具会提供 scalar factor 的参数来控制数据量。其次在数据分布上最好也能贴近真实世界的数据，如有数据倾斜，及调整倾斜比例。从而能全面、综合地反映业务场景和引擎之间地差异 

4.有统一的性能衡量指标和采集汇总工具

基准测试的性能指标的定义需要清晰、一致，且能适用于各种计算引擎。然而流计算的性能指标要比传统批处理的更难定义、更难采集。是流计算 benchmark 最具挑战性的一个问题，这也会在下文展开描述。

我们也研究了很多其他的流计算相关的基准测试，包括：StreamBench、HiBench、BigDataBench，但是它们都在上述几个基本面有所欠缺。基准测试的行业标杆无疑是 TPC 发布的一系列 benchmark，如 TPC-H，TPC-DS。然而这些 benchmark 是面向传统数据库、传统数仓而设计的，并不适用于今天的流计算系统。例如 benchmark 中没有考虑事件时间、数据的乱序、窗口等流计算中常见的场景。因此我们不得不考虑重新设计并开源一个流计算基准测试框架

5.三个指标

吞吐

吞吐（throughput）也常被称作 TPS，描述流计算系统每秒能处理多少条数据。由于我们有多个事件流，所有事件流都由一个数据生成器生成，为了统一观测角度，我们采用数据生成器的 TPS，而非单一事件流的 TPS。我们将一个 query 能达到的最大吞吐，作为其吞吐指标。例如，针对 Flink 引擎，我们通过 Flink REST API 暴露的 <source_operator_name>.numRecordsOutPerSecond metric 来获取当前吞吐量。 

延迟

延迟（Latency）描述了从数据进入流计算系统，到它的结果被输出的时间间隔。对于窗口聚合，Yahoo Benchmark 中使用 output_system_time - window_end 作为延迟指标，这其实并没有考虑数据在窗口输出前的等待时间，这种计算结果也会极大地受到反压的影响，所以其计算结果是不准确的。一种更准确的计算方式应为 output_system_time - max(ingest_time)。 然而在非窗口聚合，或双流 JOIN 中，延迟又会有不同的计算方式。 

所以延迟的定义和采集在流计算系统中有很多现实存在的问题，需要根据具体 query 具体分析，这也是我们目前还未在 Nexmark 中实现延迟 metric 的原因

 CPU

资源使用率是很多流计算 benchmark 中忽视的一个指标。由于在真实生产环境，我们并不会限制流计算引擎所能使用的核数，从而给系统更大的弹性。所以我们引入了 CPU 使用率，作为辅助指标，即作业一共消耗了多少核。通过 吞吐/cores，可以计算出平均每个核对于吞吐的贡献。对于进程的 CPU 使用率的采集，我们没有使用 JVM CPU load，而是借鉴了 YARN 中的实现，通过采样 /proc/<pid>/stat 并计算获得，该方式可以获得较为真实的进程 CPU 使用率。因此我们的 Nexmark 测试框架需要在测试开始前，先在每台机器上部署 CPU 采集进程。