桔妹導讀：滴滴自成立以來，有海量的資料儲存在離線平臺，離線資料雖然儲存便宜，壓縮比高，但不適用於線上使用。為此，我們提供了一鍵式DTS平臺——FastLoad，幫助業務往線上儲存系統搬運離線資料，目前主要針對滴滴自研分散式儲存Fusion，Fusion以RocksDB為儲存引擎，服務線上叢集500+，承載業務資料1600TB+，總QPS峰值1200W+，是一個成熟穩定的分散式NoSQL/NewSQL解決方案。

0.

1. 業務背景：雄關漫道真如鐵

在沒有FastLoad以前，業務一般都會自己維護讀離線資料，寫線上儲存引擎的業務邏輯。比如，滴滴有很多重要的業務有如下的場景：前一天的訂單資料會落到離線平臺，經過一些特徵提取和分析，轉換成業務需要使用的資料。在第二天線上高峰期前，需要把這部分資料及時匯入線上，才能夠不影響業務邏輯。這些業務都需要定時更新線上資料、線上使用最新資料，下面我們對需求進行提取。

定時更新

像特徵資料，一般需要小時級別甚至天級別的更新，所以業務需要有快捷的定時更新功能。

快速更新

特徵資料還有一個特點，就是資料量特別大，以乘客特徵為例，動輒上 TB 級別資料量。這麼大的資料量透過 SDK 寫入肯定是不行的。剛開始業務方也確實是這麼玩的，直接透過 Hadoop 任務呼叫 Redis SDK，然後一條條的寫入 Fusion，一般是每天凌晨開始寫資料，等到早高峰 8 點時大量讀取。但是這種方法實踐下來，經常導致 Fusion 各類超時，在早高峰叫車已經來臨時還在寫凌晨的資料，非常影響穩定性。因此第 3 個需求是必須快速更新。

穩定性

這個是毋容置疑的。

多表隔離

有些業務有很多類特徵資料，他們有隔離儲存的需求，也有分類更新、分類查詢的需求，因此需要多表來支援邏輯到物理的隔離。

下面我們看下使用者正常寫儲存的流程，如圖展示了以RocksDB為引擎的儲存的寫入過程。

正常灌庫流程

如圖可見，從Hive寫到最終儲存的鏈路比較長，資料要經過幾次中轉才能最終落盤。我們做一個公式換算，1TB的資料，以5w的QPS寫入儲存，每個請求寫512B，需要大約12個小時，也就是半天的時間才能將資料完全寫入。要是每天更新的任務，在早高峰之前根本不能取到最新的資料，是不滿足業務場景的。

為了滿足上述提及的4點需求，我們需要轉換思維，不能拘泥於傳統的資料灌入方式。我們萌生了一個快速匯入的想法，如果將檔案直接複製到儲存中，就可以避免上圖中的1/2/3/4，直接對外開放讀。

2. 技術探討：工欲善其事必先利其器

▍Ingest SST

我們需要以檔案方式匯入到儲存引擎中，藉助了RocksDB提供的IngestFile介面，透過使用者預先建立好的SST檔案，直接載入到硬碟的LSM結構中，已達到快速匯入的目的。直接構造SST檔案並匯入的方式，繞開了上圖正常灌庫的流程，避免了寫WAL日誌、寫記憶體、刷盤等操作，同時RocksDB的Ingest能夠儘可能地將資料放在LSM結構中最底層的位置，減少L0到Ln層不斷Compact帶來的寫放大。

Ingest SST檔案

Ingest SST檔案流程為：

檢查需要匯入的SST是否合法，包括檔案之間Key值是否有重疊，檔案是否為空，ColumnFamilyID是否合法等等。
阻塞DB例項的寫入操作，對可能與Ingest檔案有重疊的MemTable進行刷盤操作。阻止RocksDB執行新的Compact任務導致LSM結構更新。
確定Ingest的檔案應該在磁碟LSM結構中的哪一層，RocksDB會盡可能地將檔案放在Key值不重疊的最底層。如上圖所示，Key值範圍為[E, F]的SST檔案將Ingest匯入到了L1層；隨後，根據當前存在的快照、LSM組織形式等設定SST檔案的元資訊。
將之前設定的阻塞標記全部刪除。

總的來說，Ingest匯入是RocksDB的一個很關鍵的功能特性，適合使用者資料的大批次寫入。上述描述了一個將新檔案Ingest到已存在的DB例項中的流程，可以看出是比較重的操作，除了會導致停寫停Compact，還會導致MemTable強制刷盤。所以對於每天更新的任務，我們完全可以每天往新的DB例項裡導檔案，這樣就能避免很多的阻塞。

▍Map/Reduce產出全域性有序檔案

從上述的Ingest檔案可以看出，匯入檔案的堵塞需要付出比較大的代價，堵塞線上寫和增大系統Compact。我們可以透過往新DB例項中導檔案避免堵塞寫，透過保證SST全域性有序避免系統Compact。從Hive到SST這一步，我們依賴了大資料引擎進行Map/Reduce，將原始資料作為輸入，按照使用者提交的拼接Key的方式，啟動Map/Reduce任務直接構造最終DB需要的SST檔案。

3. 系統架構：千磨萬擊還堅勁

經過上面的背景和技術細節，我們最終完成了如下圖的系統架構。

一鍵式DTS平臺——FastLoad系統架構

整個系統分為以下幾個模組：

控制檯服務：對外提供控制檯表單和OpenAPI方式接入，提供建立任務、Schema轉換規則等服務。
大資料排程模組：依賴Hadoop的計算資源，將Hive資料匯出為我們需要的中間檔案，在經過Map/Reduce的構建，生成全域性有序的SST檔案。
檔案下載模組：根據分散式儲存的路由表，將SST檔案下載到不同的儲存節點。
檔案匯入和DB切換：依賴上文提及的Ingest SST的方式，將檔案一次性匯入DB例項。為了避免上述提及的堵塞，我們提供往新DB例項導資料的選項，這樣就可以避免因線上寫而導致的堵塞，空資料也可以避免Compact。假如選擇了新DB匯入的選項，最後還會有一次DB新舊例項的切換，相當於一次連結對映。

4. 總結展望：直掛雲帆濟滄海

▍基於FastLoad的資料傳輸給業務帶來的收益

大大縮短業務導資料耗時，1TB資料平均匯入時間為1小時；

線上服務業務300+，每天執行次數1000+，每天導資料量30TB+；

服務穩定性達到99.99%，上線執行2年無任何重大事故；
高頻運維操作一鍵自助完成，90% 的問題，5 分鐘完成定位；

▍發展規劃

架構最佳化，整體架構目前依賴Hadoop，可以考慮遷移到Spark，提升執行效率；

管控最佳化，提供更細緻更全面的FastLoad監控和報表；

多產品應用，目前FastLoad主要針對NoSQL和NewSQL兩種場景，同比可以應用在ES、MQ等場景；
新場景支援，離線資料的實時讀取不僅對OLTP場景提供了更好的支援，也為接下來大熱的HTAP場景提供了無限的可能。

本文作者


趙銳
滴滴 | 高階工程師

從事分散式儲存NoSQL/NewSQL的相關研發，參與從零開始構建滴滴分散式儲存Fusion，有PB級別儲存、千萬QPS的儲存經驗。

滴滴海量離線資料的線上化 — FastLoad

0.

目錄

1.

業務背景：雄關漫道真如鐵

2.

技術探討：工欲善其事必先利其器

▍Ingest SST

▍Map/Reduce產出全域性有序檔案

3.

系統架構：千磨萬擊還堅勁

4.

總結展望：直掛雲帆濟滄海

▍基於FastLoad的資料傳輸給業務帶來的收益

▍發展規劃

相關文章