机器人与自动化技术如何创造新岗位？
|
4 作业负载的配置化 我们也支持配置调整作业的负载，包括数据生成器的吞吐量以及吞吐曲线、各个数据流之间的数据量比例、每个数据流的数据平均大小以及数据倾斜比例等等。具体的可以参考 Source DDL 参数。 四 实验结果 我们在阿里云的三台机器上进行了 Nexmark 针对 Flink 的基准测试。每台机器均为 ecs.i2g.2xlarge 规格，配有 Xeon 2.5 GHz CPU (8 vCores) 以及 32 GB 内存，800 GB SSD 本地磁盘。机器之间的带宽为 2 Gbps。 测试了 flink-1.11 版本，我们在这 3 台机器上部署了 Flink standalone 集群，由 1 个 JobManager，8 个 TaskManager (每个只有 1 slot)组成，都是 4 GB内存。集群默认并行度为 8。开启 checkpoint 以及 exactly once 模式，checkpoint 间隔 3 分钟。使用 RocksDB 状态后端。测试发现，对于有状态的 query，每次 checkpoint 的大小在 GB 级以上，所以有效地测试的大状态的场景。 Datagen source 保持 1000 万每秒的速率生成数据，三个数据流的数据比例分别是 Bid: 92%，Auction: 6%，Person: 2%。每个 query 都先运行 3 分钟热身，之后 3 分钟采集性能指标。
运行 nexmark/bin/run_query.sh all 后，打印测试结果如下： 批处理系统 benchmark 的 metric 通常采用总体耗时来衡量。然而流计算系统处理的数据是源源不断的，无法统计 query 耗时。因此，我们提出三个主要的 metric：吞吐、延迟、CPU。Nexmark 测试框架会自动帮我们采集 metric，并做汇总，不需要部署任何第三方的 metric 服务。 吞吐
吞吐(throughput)也常被称作 TPS，描述流计算系统每秒能处理多少条数据。由于我们有多个事件流，所有事件流都由一个数据生成器生成，为了统一观测角度，我们采用数据生成器的 TPS，而非单一事件流的 TPS。我们将一个 query 能达到的最大吞吐，作为其吞吐指标。例如，针对 Flink 引擎，我们通过 Flink REST API 暴露的 延迟 延迟(Latency)描述了从数据进入流计算系统，到它的结果被输出的时间间隔。对于窗口聚合，Yahoo Benchmark 中使用 output_system_time - window_end 作为延迟指标，这其实并没有考虑数据在窗口输出前的等待时间，这种计算结果也会极大地受到反压的影响，所以其计算结果是不准确的。一种更准确的计算方式应为 output_system_time - max(ingest_time)。然而在非窗口聚合，或双流 JOIN 中，延迟又会有不同的计算方式。 所以延迟的定义和采集在流计算系统中有很多现实存在的问题，需要根据具体 query 具体分析，这在参考文献[2]中有详细的讨论，这也是我们目前还未在 Nexmark 中实现延迟 metric 的原因。 CPU
资源使用率是很多流计算 benchmark 中忽视的一个指标。由于在真实生产环境，我们并不会限制流计算引擎所能使用的核数，从而给系统更大的弹性。所以我们引入了 CPU 使用率，作为辅助指标，即作业一共消耗了多少核。通过吞吐/cores，可以计算出平均每个核对于吞吐的贡献。对于进程的 CPU 使用率的采集，我们没有使用 JVM CPU load，而是借鉴了 YARN 中的实现，通过采样/proc/ 3 Query 与 Schema Nexmark 的业务模型基于一个真实的在线拍卖系统。所有的 query 都基于相同的三个数据流，三个数据流会有一个数据生成器生成，来控制他们之间的比例、数据偏斜、关联关系等等。这三个数据流分别是：
我们一共定义了 16 个 query，所有的 query 都使用 ANSI SQL 标准语法。基于 SQL ，我们可以更容易地扩展 query 测试集，支持更多的引擎。然而，由于 Spark 在流计算功能上的限制，大部分的 query 都无法通过 Structured Streaming 来实现。因此我们目前只支持测试 Flink SQL 引擎。 （编辑：潍坊站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
