如何實現數據處理性能提升？為你揭曉背后功臣
加入技術交流群
Arm 架構在服務器領域發展勢頭看漲。目前已有許多頭部云服務提供商和服務器制造商推出了基于 Arm Neoverse 平臺的服務器產品。Arm 架構的服務器通常具備低功耗的特性，能帶來更優異的能效比。在此前的文章中，針對搭載基于 Armv9 架構的倚天 710 芯片的 ECS 倚天實例，Arm 技術專家已在 深度學習推理任務 、 Redis 性能驗證 等方面進行了測試和比較分析。此次我們將聚焦數據處理領域，通過兩個實際案例，來探討不同云實例上 Apache Flink 和 Elasticsearch 的性能差異。
本文引用地址：http://www.j9360.com/article/202409/463223.htm案例一
針對 Apache Flink 的性能測試
在基于 Arm 架構的倚天實例上
部署 Apache Flink
性能提升最高可達 83% ！
Apache Flink 是用于對有界和無界數據流進行有狀態計算的框架。其核心是使用 Java 和 Scala 編寫的分布式流式數據流引擎。該測試同樣比較了 g8y 和 g7 之間的性能差異。
測試環境
測試使用了三個工作節點和一個主節點來運行 Flink 集群，并使用數據流基準測試工具 Nexmark 進行基準測試。為確保測試的公正性，g8y 和 g7 云實例的 CPU核心數量和內存大小、操作系統以及 Flink 軟件版本與配置均相同。
在進行基準測試時，總共有 21 個查詢測試連續運行。硬件和軟件配置如下所示：
測試結果
從測試結果可以看出：
對于吞吐量較高的查詢測試，g8y 的性能表現明顯優于 g7。具體來說，g8y 在 q13 指標上比 g7 高了 83%，在 q14 指標上高了 76%。
對于吞吐量較低的查詢測試（包含一些測試誤差），g8y 的吞吐量水平與 g7 相當。
在多數查詢測試中，g8y 的性能表現相較 g7 高出 30% 以上，同時在部分查詢測試中，g8y 的性能表現相較 g7 高出 70% 以上；在一個查詢測試中，g8y 的性能高出 83%。
圖：RPS：每秒記錄數
案例二
在云實例上部署 Elasticsearch
在基于 Arm 架構的倚天實例上
部署 Elasticsearch
性能提升高達 36% ！
Elasticsearch 是功能強大的開源、分布式搜索和分析引擎，以其速度、可擴展性和靈活性而聞名。該引擎用途非常廣泛，包括全文搜索、日志記錄和日志分析、實時分析等，在云環境中也十分普及。http_logs track 是 Elasticsearch Rally 基準測試工具中所使用的標準數據集和工作負載。它可以仿真典型網站服務器日志數據，非常適合在涉及日志數據提取和分析的場景中評估 Elasticsearch 性能。
此次測試是在 g8y 和 g7 兩種不同類型的阿里云 ECS 實例上運行了 Elasticsearch http_logs track 測試用例，并比較了兩者的差異。其中，g8y 搭載基于 Neoverse N2 的倚天 710 處理器；而 g7 則搭載第三代英特爾至強可擴展處理器。
測試環境
測試使用三個 xlarge 實例來運行 Elasticsearch 服務器，使用一個 4xlarge 實例運行 esrally 基準測試。g8y 和 g7 云實例的虛擬 CPU (vCPU) 數量和內存大小、操作系統以及 Elasticsearch/esrally 軟件版本與配置均相同。
硬件信息：
軟件版本和設置：
基準測試 esrally 設置：
測試結果
我們進行了約十次測試，以盡可能減少測試誤差。最終呈現的數據是多次測試結果的平均值。測試結果表明：
在最小值、平均值、中位數和最大值指標上，g8y 索引-追加 (index-append) 吞吐量比 g7 高出 36% 以上。
在 p50 和 p90 級別，g8y 的服務時間比 g7 縮短了約 30%，而 p99 至 p100 服務時間與 g7 相似。
當 hourly_agg 以相同的 0.20 ops/s 吞吐量運行時，g8y 的 p50、p90、p99 和 p100 服務時間比 g7 縮短 27% 以上。
總體而言，在 Elasticsearch 基準測試 esrally 的 http_logs track 測試用例中，g8y 的表現優于 g7。
<上下滑動，查看更多>
圖：Index-append 吞吐量提升
圖：Index-append 服務時間提升
圖：Hourly_agg 服務時間提升
評論