技術文章 » ClickHouse與Elasticsearch壓測實踐

ClickHouse與Elasticsearch壓測實踐

2022-08-29 12:00:51

1 需求分析

1.1 分析壓測物件

1）什麼是ClickHouse 和Elasticsearch

ClickHouse 是一個真正的列式資料庫管理系統（DBMS)。在 ClickHouse 中，資料始終是按列儲存的，包括向量（向量或列塊）執行的過程。只要有可能，操作都是基於向量進行分派的，而不是單個的值，這被稱為«向量化查詢執行»，它有利於降低實際的資料處理開銷。

Elasticsearch是一個開源的分散式、RESTful 風格的搜尋和資料分析引擎，它的底層是開源庫Apache Lucene。 它可以被這樣準確地形容：

  • 一個分散式的實時檔案儲存，每個欄位可以被索引與搜尋
  • 一個分散式實時分析搜尋引擎
  • 能勝任上百個服務節點的擴充套件，並支援 PB 級別的結構化或者非結構化資料
2）為什麼要對他們進行壓測

眾所周知，ClickHouse在基本場景表現非常優秀，效能優於ES，但是我們實際的業務查詢中有很多是複雜的業務查詢場景，甚至是大數量的查詢，所以為了在雙十一業務峰值來到前，確保大促活動峰值業務穩定性，針對ClickHouse 和Elasticsearch在我們實際業務場景中是否擁有優秀的抗壓能力，通過這次效能壓測，探測系統中的效能瓶頸點，進行鍼對性優化，從而提升系統效能。

1.2 制定壓測目標

為什麼會選擇這個（queryOBBacklogData）介面呢？

1）從複雜度來看，介面（queryOBBacklogData）查詢了5次，程式碼如下：
/**
* 切ck-queryOBBacklogData
* @param queryBO
* @return
*/
public OutboundBacklogRespBO queryOBBacklogDataCKNew(OutboundBacklogQueryBO queryBO) {
log.info(" queryOBBacklogDataCK入參：{}", JSON.toJSONString(queryBO));
// 公共條件-卡最近十天時間
String commonStartTime = DateUtils.getTime(DateUtil.format(new Date(), DateUtil.FORMAT_DATE), DateUtils.ELEVEN_AM, 1, -10);
String commonEndTime = DateUtils.getTime(DateUtil.format(new Date(), DateUtil.FORMAT_DATE), DateUtils.ELEVEN_AM, 1, 1);
// 越庫資訊-待越庫件數&待越庫任務數
WmsObCrossDockQueryBo wmsObCrossDockQueryBo = wmsObCrossDockQueryBoBuilder(queryBO,commonStartTime, commonEndTime);
log.info("queryOBBacklogDataCK-wmsObCrossDockQueryBo: {}", JSON.toJSONString(wmsObCrossDockQueryBo));
CompletableFuture<OutboundBacklogRespBO> preCrossDockInfoCF = CompletableFuture.supplyAsync(
() -> wmsObCrossDockMapper.preCrossDockInfo(wmsObCrossDockQueryBo), executor);
// 集合任務資訊-待分配訂單
WmsObAssignOrderQueryBo wmsObAssignOrderQueryBo = wmsObAssignOrderQueryBoBuilder(queryBO, commonStartTime, commonEndTime);
log.info("queryOBBacklogDataCK-wmsObAssignOrderQueryBo: {}", JSON.toJSONString(wmsObAssignOrderQueryBo));
CompletableFuture<Integer> preAssignOrderQtyCF = CompletableFuture.supplyAsync(
() -> wmsObAssignOrderMapper.preAssignOrderInfo(wmsObAssignOrderQueryBo), executor);
// 揀貨資訊-待揀貨件數&待揀貨任務數
WmsPickTaskQueryBo wmsPickTaskQueryBo = wmsPickTaskQueryBoBuilder(queryBO, commonStartTime, commonEndTime);
log.info("queryOBBacklogDataCK-wmsPickTaskQueryBo: {}", JSON.toJSONString(wmsPickTaskQueryBo));
CompletableFuture<OutboundBacklogRespBO> prePickingInfoCF = CompletableFuture.supplyAsync(
() -> wmsPickTaskMapper.pickTaskInfo(wmsPickTaskQueryBo), executor);
// 分播資訊-待分播件數&待分播任務
WmsCheckTaskDetailQueryBo wmsCheckTaskDetailQueryBo = wmsCheckTaskDetailQueryBoBuilder(queryBO, commonStartTime, commonEndTime);
log.info("queryOBBacklogDataCK-wmsCheckTaskDetailQueryBo: {}", JSON.toJSONString(wmsCheckTaskDetailQueryBo));
CompletableFuture<OutboundBacklogRespBO> preSowInfoCF = CompletableFuture.supplyAsync(
() -> wmsCheckTaskDetailMapper.checkTaskDetailInfo(wmsCheckTaskDetailQueryBo), executor);
// 發貨資訊-待發貨件數
WmsOrderSkuQueryBo wmsOrderSkuQueryBo = wmsOrderSkuQueryBoBuilder(queryBO, commonStartTime, commonEndTime);
log.info("queryOBBacklogDataCK-wmsOrderSkuQueryBo: {}", JSON.toJSONString(wmsOrderSkuQueryBo));
CompletableFuture<Integer> preDispatchCF = CompletableFuture.supplyAsync(
() -> wmsOrderSkuMapper.preDispatchInfo(wmsOrderSkuQueryBo), executor);
return processResult(preCrossDockInfoCF, preAssignOrderQtyCF, prePickingInfoCF, preSowInfoCF, preDispatchCF);
}

　　

2）介面（queryOBBacklogData），總共查詢了5個表，如下：
wms.wms_ob_cross_dock
wms.wms_ob_assign_order
wms.wms_picking_task.
wms.wms_check_task_detail
wms.wms_order_sku

 

3）查詢的資料量，如下：
select
(ifnull(sum(m.shouldBeCrossedDockQty),
0) -
ifnull(sum(m.satisfiedCrossedDockQty),
0)) as preCrossStockSkuQty,
count(m.docId) as preCrossStockTaskQty
from
wms.wms_ob_cross_dock m final
prewhere
m.createTime >= '2021-12-03 11:00:00'
and m.createTime <= '2021-12-14 11:00:00'
and m.warehouseNo = '279_1'
and m.orderType = '10'
and tenantCode = 'TC90230202'
where
m.deleted = 0
and m.deliveryDestination = '2'
and m.shipmentOrderDeleted = 0
and m.status = 0

 

從上面SQL截圖可以看出，查詢待越庫件數&待越庫任務數，共讀了720817行資料

select count(distinct m.orderNo) as preAssignedOrderQty
from wms.wms_ob_assign_order m final
prewhere
m.createTime >= '2021-12-03 11:00:00'
and m.createTime <= '2021-12-14 11:00:00'
and m.warehouseNo = '361_0'
and tenantCode = 'TC90230202'
where m.taskassignStatus = 0
and m.deliveryDestination = 2
and m.stopProductionFlag = 0
and m.deleted = 0
and m.orderType = 10

 

從上面SQL截圖可以看出，查詢集合任務資訊-待分配訂單，共讀了153118行資料

select minus(toInt32(ifnull(sum(m.locateQty), toDecimal64(0, 4))),
toInt32(ifnull(sum(m.pickedQty), toDecimal64(0, 4)))) as prePickingSkuQty,
count(distinct m.taskNo) as prePickingTaskQty
from wms.wms_picking_task m final
prewhere
m.shipmentOrderCreateTime >= '2021-12-03 11:00:00'
and m.shipmentOrderCreateTime <= '2021-12-14 11:00:00'
and m.warehouseNo = '286_1'
and tenantCode = 'TC90230202'
where m.pickingTaskDeleted = 0
and m.deliveryDestination = 2
and m.pickLocalDetailDeleted = 0
and m.shipmentOrderDeleted = 0
and m.orderType = 10
and (m.operateStatus = 0 or m.operateStatus = 1)

 

從上面SQL截圖可以看出，查詢揀貨資訊-待揀貨件數&待揀貨任務數，共讀了2673536行資料

select minus(toInt32(ifnull(sum(m.locateQty), toDecimal64(0, 4))),
toInt32(ifnull(sum(m.pickedQty), toDecimal64(0, 4)))) as prePickingSkuQty,
count(distinct m.taskNo) as prePickingTaskQty
from wms.wms_picking_task m final
prewhere
m.shipmentOrderCreateTime >= '2021-12-03 11:00:00'
and m.shipmentOrderCreateTime <= '2021-12-14 11:00:00'
and m.warehouseNo = '279_1'
and tenantCode = 'TC90230202'
where m.pickingTaskDeleted = 0
and m.deliveryDestination = 2
and m.pickLocalDetailDeleted = 0
and m.shipmentOrderDeleted = 0
and m.orderType = 10
and (m.operateStatus = 0 or m.operateStatus = 1)

 

從上面SQL截圖可以看出，查詢分播資訊-待分播件數&待分播任務，共讀了1448149行資料

select ifnull(sum(m.unTrackQty), 0) as unTrackQty
from wms.wms_order_sku m final
prewhere
m.shipmentOrderCreateTime >= '2021-12-03 11:00:00'
and m.shipmentOrderCreateTime <= '2021-12-14 11:00:00'
and m.warehouseNo = '280_1'
and m.orderType = '10'
and m.deliveryDestination = '2'
and tenantCode = 'TC90230202'
where m.shipmentOrderDeleted <> '1'
and m.ckDeliveryTaskDeleted <> '1'
and m.ckDeliveryTaskDetailDeleted <> '1'
and m.ckDeliveryTaskStatus in ('1','0','2')

 

從上面SQL截圖可以看出，查詢發貨資訊-待發貨件數，共讀了99591行資料

2 測試環境準備

為了儘可能發揮效能壓測作用，效能壓測環境應當儘可能同線上環境一致，所以我們使用了和線上一樣的環境

3 採集工具準備

監控工具
  1. http://origin.jd.com/ ：監控JVM，方法級別監控（提供秒級支援）
  2. http://console.jex.jd.com/ ：提供異常堆疊監控，火焰圖監控、執行緒堆疊分析
  3. http://x.devops.jdcloud.com/ ：支援檢視clickhouse/Elasticsearch資料庫服務每個節點的cpu使用率
  4. http://dashboard.fireeye.jdl.cn/ ：監測應用伺服器cpu使用率、記憶體使用率

4 壓測執行及結果分析

4.1 編寫壓測指令碼工具

Forcebot（http://forcebot.jd.com） 是專門為開發人員、測試人員提供的效能測試平臺，通過編寫指令碼、設定監控、設定場景、啟動任務、實時監控、紀錄檔定位、匯出報告一系列操作流程來完成效能測試，靈活的指令碼設定滿足同步、非同步、集合點等多種發壓模式。

幫助檔案（http://doc.jd.com/forcebot/helper/）

4.2 設計壓測資料

4.2.1 前期壓測中名詞解釋
  • DBCP：資料庫連線池，是 apache 上的一個Java連線池專案。DBCP通過連線池預先同資料庫建立一些連線放在記憶體中(即連線池中)，應用程式需要建立資料庫連線時直接到從接池中申請一個連線使用，用完後由連線池回收該連線，從而達到連線複用，減少資源消耗的目的。
  • maxTotal：是連線池中總連線的最大數量，預設值8
  • max_thread：clickhouse中底層設定，處理SQL請求時使用的最大執行緒數。預設值是clickhouse伺服器的核心數量。
  • coordinating：協調節點數，主要作用於請求轉發，請求響應處理等輕量級操作
  • 資料節點：主要是儲存索引資料的節點，主要對檔案進行增刪改查操作，聚合操作等。資料節點對cpu，記憶體，io要求較高， 在優化的時候需要監控資料節點的狀態，當資源不夠的時候，需要在叢集中新增新的節點
4.2.2 壓測資料

clickhouse資料服務：32C128G6節點2副本
應用伺服器：4核8G2
maxTotal=16

注：每次壓測前，一定要觀察每個資料節點的cpu使用率

注：從上面壓測過程中，序號6-12可以看出，並行使用者數在增加，但tps沒有幅度變化，檢查發現bigdata dbcp資料庫連結池最大執行緒數未設定，預設最大執行緒數是8，並行使用者數增加至8以後，clickhouse cpu穩定在40%~50%之間不再增加，應用伺服器CPU穩定在25%左右。

之後我們調整maxTotal=50，通過調整max_thread不同的值，資料庫節點CPU使用率保持在50%左右，來檢視相應的監測資料指標：應用服務CPU使用率、TPS、TP99、並行使用者數。

clickhouse資料節點，CPU使用率：

Elasticsearch資料服務：32C128G6節點2副本
應用伺服器：4核8G2
Elasticsearch同樣保持資料庫服務CPU使用率達到（50%左右），再監控資料指標tps、tp99
調整指標如下：coordinating協調節點數、 資料節點、poolSize

指標1：coordinating=2，資料節點=4，poolSize=400

注：在壓測的過程中發現，coordinating節點的cpu使用率達到51.69%，負載均衡的作用受限，所以協調節點需擴容2個節點

指標2：coordinating=4，資料節點=5，poolSize=800

注：在壓測的過程中，發現CPU使用率（資料庫）ES資料節點在40%左右的時候，一直上不去，檢視紀錄檔發現activeCount已經達到797，需要增加poolSize值

指標3：coordinating=4，資料節點=5，poolSize=1200

注：壓測過程中，發現coordinating協調節點還是需要擴容，不能支援現在資料節點cpu使用率達到50%
Elasticsearch資料節點及協調節點，CPU使用率：

我們在壓測的過程中發現一些之前在開發過程中沒發現的問題，首先bdcp數bigdata應用伺服器，使用的執行緒池最大執行緒數為8時，成為瓶頸，使用者數增加至8以後， clickhouse的cpu穩定在40%~50%之間不在增加，應用伺服器CPU穩定在25%左右，其次warehouse叢集協調節點設定低，協調節點CPU使用率高，最後是clickhouse-jdbc JavaCC解析sql效率低。

4.3 結果分析

4.3.1 測試結論

1）clickhouse對並行有一定的支援，並不是不支援高並行，可以通過調整max_thread提高並行

  • max_thread=32時，支援最大TPS 是37，相應TP99是122
  • max_thread=2時，支援最大TPS 是66，相應TP99是155
  • max_thread=1時，支援最大TPS 是86，相應TP99是206

2）在並行方面Elasticsearch比clickhouse支援的更好，但是相應的響應速度慢很多

  • Elasticsearch：對應的TPS是192，TP99是3050
  • clickhouse：對應的TPS 是86，TP99是206

綜合考量，我們認為clickhouse足以支撐我們的業務訴求

4.3.2 優化建議
  1. 對ES協調節點進行擴容
  2. bigdata應用執行緒池最大執行緒數調高至200
  3. bigdata應用 dbcp執行緒池maxTotal設定成50
  4. 讀取組態檔工具類增加記憶體快取

作者：潘雪豔