Categories
程式開發

從Exadata 到TiDB,中通快遞HTAP 實踐


中通快遞業務是第一個達成年百億業務量的快遞企業,在2019 年的雙十一更是完成了訂單量超過2 億的佳績。 中通科技是中通快遞旗下的互聯網物流科技平台,擁有一支千餘人規模的研發團隊,秉承著“互聯網+物流”的理念,與公司的戰略、業務緊密的銜接,為中通生態圈的業務打造全場景全鏈路的數字化平台服務。

從Exadata 到TiDB,中通快遞HTAP 實踐 1

上圖展示了快遞物流的生命週期,簡單舉個例子,大家如果在某寶上下了一個訂單,從付款結束開始,到商家打單,大家的包裹基本上就開啟了一個快遞的旅程。 簡單的介紹可以分為五個字,收發到派簽,整個物流的全鏈路中可以拆解成以下的關鍵節點,客戶下單之後快遞員的攬收,攬收網點的建包,建包之後會把快遞交到中心,至此快遞就開啟了轉運和運輸的過程,最終負責派件的末端網點會根據三段碼的解析去末端的中心把快遞拉到末端的快遞網點進行分揀,分揀之後會指派到指定的快遞員,進行派件,快遞小哥會把快遞送到客戶的手裡,客戶完成簽收,在我們看來這一票件就完成了快遞的全鏈路的生命週期。 在每個環節中會產生大量的數據,對每個環節的每一個數據我們都會進行相關的分析,包括時效的監控。

2017 年的時候,我們就已經開始關注TiDB ,那時候的關注點主要在解決一些分庫分錶的問題上,從2018 年底開始調研測試大數據,我們主要想去解決存儲和計算的問題,2019年初上線服務生產應用。 目前生產上有近58 個物理節點,同時服務OLTP 和OLAP 的業務,服務平穩。 支撐了2019 年雙十一的大促,我們的QPS 峰值在12 萬+,支持百億級的插入和更新,TiSpark 支持業務在線的分鐘級統計分析。 實時ETL 寬表建設,TiSpark 將實時和離線很好的串聯起來,在分析上互為補充。

為什麼選擇TiDB

中通為什麼會選擇TiDB 呢? 隨著業務的快速發展,我們遇到了很多技術上面的痛點,主要有以下幾個方面:

  • 業務發展快、數據量激增, 能存放在Exadata 一體機數據周期越來越短, 業務方對數據周期需求上升。

  • 分庫分錶設計滿足不了業務方分析和時效需求,統計分析依賴存儲過程,系統的擴展性和可維護性不高。

  • 業務高峰單機性能瓶頸,單點故障風險高,數據同步T+1,分析時效不夠。

  • 測試HBase、Kudu 建設實時數倉,和現有技術棧難以兼容,並且不能很好支撐業務端多維度的query。

有了痛點,接下來談一下我們的需求。 我們的需求主要有以下幾點:

  • 支持在線擴展,數據按region 分片,像HBase 一樣能分裂和遷移,最好自己支持熱點調度。

  • 強一致的分佈式事務、二級索引,這是支持原來Oracle 業務必須要有的。

  • 能高並發寫和更新,並且支持我們快速的按照業務方的需求查詢結果。

  • 技術生態與Spark 要緊密結合,支持我們用Spark 快速的做分鐘級統計分析。

  • 支持大寬表的建設,支持多維度的查詢分析。

數據庫雲服務器到TiDB

從Exadata 到TiDB,中通快遞HTAP 實踐 2

上圖是我們線上一個比較核心的系統以前的架構,大家可以看到在各個轉運環節中我們有很多的數據,有很多的消息來源。 左邊是我們對接的消息中間件,從這裡可以看到我們有很多的topic。 右邊可以分為以下幾塊,第一個是應用消費程序,我們會把這些中間件的消息消費進來,然後存到Oracle 裡面;另外我們會提供API 和應用的數據服務,對外提供服務能力。 在原來的體系架構裡面,大量的數據統計分析依賴於在Oracle 上建好多存儲過程,但隨著數據量越來越大,我們發現存儲和計算的問題越來越明顯,單純靠升級Oracle 的硬件無法從根本上解決問題,並且隨著硬件的不斷升級,成本也越來越高。 我們覺得應該從一個新的技術方案上去尋找突破,對我們的業務系統進行一個重新的架構升級。

這次技術上的升級給我們帶來了以下幾個好處:

  1. 數據存儲周期從15 天支持到45 天。
  2. 支持在線橫向擴展,隨時上下線存儲和計算節點,應用無感知。
  3. 滿足高性能的OLTP 的業務需求,性能略低於Oracle,這個無法避免,因為TiDB 是一個分佈式的數據庫。
  4. 數據庫單點壓力沒了,TP 和AP 分離。
  5. 支持更多業務維度的分析。
  6. 整體架構清晰,可維護性增強,系統擴展性增強。
  7. 硬件成本降低。

從Exadata 到TiDB,中通快遞HTAP 實踐 3

上圖是我們整個系統重構後的架構:

  • 左邊這部分還是很多消息的接入,通過Spark 實時計算把這些消息接進來,與Hive 維表在分佈式計算裡面做一些Merge 和JOIN。

  • 同時會跟離線T+1 的計算分析出來的數據、存在HBase 的數據做Merge 的計算。

  • 最終計算的結果我們會把它存到TiDB 裡面。 我們每天會定時的和TiDB 做一次同步,把TiDB 的數據同步到Hive,做一個數據備份。

  • 我們依賴於TiSpark 在TiDB 上做數據的統計分析,通常稱為匯總層,匯總層包括公共數據和業務層數據,我們也會把這些數據放在Oracle 裡面一份,包括輕度匯總和多維匯總

  • 我們還會基於TiDB 去提供明細的服務,像API 接口的服務、明細查詢和一些標籤。

從新的架構上看,每一個關鍵的節點都支持可橫向擴展,基本上沒有單點或者單關鍵路徑上壓力的問題。

實時寬表建設

其實在2017 年的時候我們就一直在探索實時數倉的建設,我們測試過HBase 和Kudu。 在國內,小米使用Kudu 比較多,寫入性能還是不錯的,但是社區活躍度一般,使用的是Impala 作為查詢引擎,但是在我們的技術棧裡主要使用的是Presto,兼容性有待考慮,而且Hbase很難滿足我們全部業務Query 的需求。 在我們整個物流鏈路的過程中,有很多消息的接入,我們需要針對每一票件進行全鏈路路由和時效的預測,定位到每一票件轉運環節,不僅數據量大,並且對時效要求高。 有了之前的項目經驗,我們決定嘗試用TiDB+TiSpark 構建我們實時寬表建設。

實時數倉寬表建設,業務的OLTP 數據通過TiDB 實時寫入,我們構建了一個70+ 字段的寬表,後續OLAP 的業務是通過TiSpark 做分鐘級的分析,有五分鐘也有十分鐘的。 之前我們採用過DataX 和Sqoop,但數據同步的效率遠遠不如TiSpark,並且還遇到過把TiDB Server 拉掛的情況。 經過我們的測試,TiSpark 同步3 億條數據到Hive 大概需要10 分鐘,這為我們的實時數據建設與離線T+1 的整合提供了保障。 並且實時寬表的建設來源於10 多個topic,多個消息的接入很難保障消息之間的有序性, TiSpark 可以幫助我們在實時業務分析的場景中融合離線數據。

從Exadata 到TiDB,中通快遞HTAP 實踐 4

上圖是我們實時寬表建設一個大概的架構:

  • 通過Spark 把多個消息接入到集群裡面做計算,並且和Hive 維表做JOIN。

  • JOIN 之後我們會把明細數據存到TiDB,接下來通過TiSpark 來計算TiDB 中的數據並存到Hive,並通過Presto 集群對外提供分析的數據支持。

  • 另外我們會把T+1 的一些離線分析數據通過TiSpark 回刷到TiDB,並通過TiDB 對外提供業務應用支持的服務。

以上是我們目前實時寬表的建設,它支撐了我們全鏈路的時效分析,包括時效的監控,基本上能達到準實時的了解到每一票件在每一個環節是否出了問題。

運維

TiDB 有豐富的監控指標,他們使用的是比較流行的Prometheus + Grafana,監控指標已經可以滿足我們的需求。 關於數據同步,我們採用了DataX T+1 同步到Hive 做數據備份,但因為我們集群既支持線上業務,也支持開發人員來做一些數據的查詢,所以之前遇到過SQL 把DB server 拉掛的情況,針對這個問題我們做了一些監控和管控,主要有以下幾點:

  1. 監控線上特殊賬號的慢SQL,我們自動會殺掉,然後通知到運維和應用的負責人;

  2. 開發了Query 的平台,讓用戶使用Spask SQL 去查詢TiDB 的數據,並發和安全的控制;

  3. 指標額外接入了小米監控,核心的告警會電話通知到相關的值班人員,相當於做了自動化監控的值班。

遇到的問題

下面來說一下在使用TiDB 的過程我們遇到的一些問題。

首先是熱點問題,因為我們業務的一些特殊性,在特定的時間範圍內會有大量寫入、更新的需求,索引熱點在目前情況下比較突出,很多業務基於時間來查詢,需要創建時間相關的索引或者組合索引,連續時間段的寫入或更新會導致索引熱點,影響部分寫入性能。

第二點是部分問題排查比較困難,我們在線上會發現當部分的SQL 觸發了大量的Coprocessor 時,會導致KV 示例負載Load 打滿後,集群寫入性能下降,此時定位expensive SQL 需要查看日誌,或者通過Show Processlist 去排查,當DBserver 較多時,排查比較耗費時間費力,我們想的解決辦法是把這些日誌的情況全都接入到ELK。

第三個問題是內存碎片化,因為我們有大量數據的更新、插入,也有大批量的數據刪除。 我們當時用的版本是TiDB 的3.0.3 的版本,在系統穩定運行一段時間後,發現監控上的部分節點的監控數據觸底了,像Raftstore CPU,並且相關的監控指標,如SQL Duration 有緩慢上升的趨勢,一開始排查誤以為是監控的問題,後來在TiDB 工程師的協助下,最終定位為內存碎片化的問題,當時通過滾動重啟集群暫時解決問題。 在TiDB 3.0.14 的版本中,這個問題已經得到了解決,我們升級後目前未發現異常。

總結和展望

目前我們有多條業務線穩定的運行在3.0.14 的版本上, TiDB 4.0 GA 在5 月28 號發布,從2019 年我們就關注著這個版本的進度,其中很多新的特性都是我們迫切需要的,比如說像大數據量的備份、大事務、TiFlash 等。 現在我們TP 和AP 的業務在KV 節點上還不是真正的物理分離,當有大量的分析需求, 且分析的時間週期跨度大、數據量大的時候,數據過濾的性能並不高,TiSpark 的資源需求很大,KV 的節點壓力也較大,在業務高峰的時候我們發現分析會影響到部分寫入的性能,所以在4.0 的版本中我們特別關注TiFlash,TiFlash 是為分析而生的,也是我們迫切需要的。 接下來我們會專注4.0 的測試,加大實時數倉的建設。

作者介紹:

朱志友,中通快遞大數據架構師。