【干貨】滴滴海量離線數據的在線化 — FastLoad

  0. 目錄

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

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

   。Ingest SST

   。Map/Reduce產出全局有序文件

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

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

   ?；贔astLoad的數據傳輸給業務帶來的收益

   。發展規劃

  FastLoad致力于離線數據在線化，服務業務300+，單日運行次數1000+，在線搬運30TB+的數據，提供數百億次高效查詢，服務穩定性達到99.99%。

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

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

  定時更新

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

  快速更新

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

  穩定性

  這個是毋容置疑的。

  多表隔離

  有些業務有很多類特征數據，他們有隔離存儲的需求，也有分類更新、分類查找的需求，因此需要多表來支持邏輯到物理的隔離。

  正常灌庫流程

  從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場景提供了無限的可能。