本文作者：趙銳，滴滴 |高級(jí)工程師，從事分布式存儲(chǔ)NoSQL/NewSQL的相關(guān)研發(fā)，參與從零開始構(gòu)建滴滴分布式存儲(chǔ)Fusion，有PB級(jí)別存儲(chǔ)、千萬(wàn)QPS的存儲(chǔ)經(jīng)驗(yàn)。

?

---

?

0.

目錄

1. 業(yè)務(wù)背景：雄關(guān)漫道真如鐵

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

• Ingest SST

• Map/Reduce產(chǎn)出全局有序文件

3. 系統(tǒng)架構(gòu)：千磨萬(wàn)擊還堅(jiān)勁

4. 總結(jié)展望：直掛云帆濟(jì)滄海

• 基于FastLoad的數(shù)據(jù)傳輸給業(yè)務(wù)帶來的收益

• 發(fā)展規(guī)劃

?

?

FastLoad致力于離線數(shù)據(jù)在線化，服務(wù)業(yè)務(wù)300+，單日運(yùn)行次數(shù)1000+，在線搬運(yùn)30TB+的數(shù)據(jù)，提供數(shù)百億次高效查詢，服務(wù)穩(wěn)定性達(dá)到99.99%。

?

?

?

1.

業(yè)務(wù)背景：雄關(guān)漫道真如鐵

在沒有FastLoad以前，業(yè)務(wù)一般都會(huì)自己維護(hù)讀離線數(shù)據(jù)，寫在線存儲(chǔ)引擎的業(yè)務(wù)邏輯。比如，滴滴有很多重要的業(yè)務(wù)有如下的場(chǎng)景：前一天的訂單數(shù)據(jù)會(huì)落到離線平臺(tái)，經(jīng)過一些特征提取和分析，轉(zhuǎn)換成業(yè)務(wù)需要使用的數(shù)據(jù)。在第二天線上高峰期前，需要把這部分?jǐn)?shù)據(jù)及時(shí)導(dǎo)入線上，才能夠不影響業(yè)務(wù)邏輯。這些業(yè)務(wù)都需要定時(shí)更新在線數(shù)據(jù)、線上使用最新數(shù)據(jù)，下面我們對(duì)需求進(jìn)行提取。

?

定時(shí)更新

像特征數(shù)據(jù)，一般需要小時(shí)級(jí)別甚至天級(jí)別的更新，所以業(yè)務(wù)需要有快捷的定時(shí)更新功能。

快速更新

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

穩(wěn)定性

這個(gè)是毋容置疑的。

多表隔離

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

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

?

正常灌庫(kù)流程

?

如圖可見，從Hive寫到最終存儲(chǔ)的鏈路比較長(zhǎng)，數(shù)據(jù)要經(jīng)過幾次中轉(zhuǎn)才能最終落盤。我們做一個(gè)公式換算，1TB的數(shù)據(jù)，以5w的QPS寫入存儲(chǔ)，每個(gè)請(qǐng)求寫512B，需要大約12個(gè)小時(shí)，也就是半天的時(shí)間才能將數(shù)據(jù)完全寫入。要是每天更新的任務(wù)，在早高峰之前根本不能取到最新的數(shù)據(jù)，是不滿足業(yè)務(wù)場(chǎng)景的。

?

為了滿足上述提及的4點(diǎn)需求，我們需要轉(zhuǎn)換思維，不能拘泥于傳統(tǒng)的數(shù)據(jù)灌入方式。我們萌生了一個(gè)快速導(dǎo)入的想法，如果將文件直接拷貝到存儲(chǔ)中，就可以避免上圖中的1/2/3/4，直接對(duì)外開放讀。

?

?

2.

技術(shù)探討：工欲善其事必先利其器

▍Ingest SST

?

我們需要以文件方式導(dǎo)入到存儲(chǔ)引擎中，借助了RocksDB提供的IngestFile接口，通過用戶預(yù)先創(chuàng)建好的SST文件，直接加載到硬盤的LSM結(jié)構(gòu)中，已達(dá)到快速導(dǎo)入的目的。直接構(gòu)造SST文件并導(dǎo)入的方式，繞開了上圖正常灌庫(kù)的流程，避免了寫WAL日志、寫內(nèi)存、刷盤等操作，同時(shí)RocksDB的Ingest能夠盡可能地將數(shù)據(jù)放在LSM結(jié)構(gòu)中最底層的位置，減少L0到Ln層不斷Compact帶來的寫放大。

Ingest SST文件

?

Ingest SST文件流程為：

?

• 檢查需要導(dǎo)入的SST是否合法，包括文件之間Key值是否有重疊，文件是否為空，ColumnFamilyID是否合法等等。

• 阻塞DB實(shí)例的寫入操作，對(duì)可能與Ingest文件有重疊的MemTable進(jìn)行刷盤操作。阻止RocksDB執(zhí)行新的Compact任務(wù)導(dǎo)致LSM結(jié)構(gòu)更新。

• 確定Ingest的文件應(yīng)該在磁盤LSM結(jié)構(gòu)中的哪一層，RocksDB會(huì)盡可能地將文件放在Key值不重疊的最底層。如上圖所示，Key值范圍為[E, F]的SST文件將Ingest導(dǎo)入到了L1層；隨后，根據(jù)當(dāng)前存在的快照、LSM組織形式等設(shè)置SST文件的元信息。

• 將之前設(shè)置的阻塞標(biāo)記全部刪除。

  ?

總的來說，Ingest導(dǎo)入是RocksDB的一個(gè)很關(guān)鍵的功能特性，適合用戶數(shù)據(jù)的大批量寫入。上述描述了一個(gè)將新文件Ingest到已存在的DB實(shí)例中的流程，可以看出是比較重的操作，除了會(huì)導(dǎo)致停寫停Compact，還會(huì)導(dǎo)致MemTable強(qiáng)制刷盤。所以對(duì)于每天更新的任務(wù)，我們完全可以每天往新的DB實(shí)例里導(dǎo)文件，這樣就能避免很多的阻塞。

?

▍Map/Reduce產(chǎn)出全局有序文件

?

從上述的Ingest文件可以看出，導(dǎo)入文件的堵塞需要付出比較大的代價(jià)，堵塞在線寫和增大系統(tǒng)Compact。我們可以通過往新DB實(shí)例中導(dǎo)文件避免堵塞寫，通過保證SST全局有序避免系統(tǒng)Compact。從Hive到SST這一步，我們依賴了大數(shù)據(jù)引擎進(jìn)行Map/Reduce，將原始數(shù)據(jù)作為輸入，按照用戶提交的拼接Key的方式，啟動(dòng)Map/Reduce任務(wù)直接構(gòu)造最終DB需要的SST文件。

?

?

3.

系統(tǒng)架構(gòu)：千磨萬(wàn)擊還堅(jiān)勁

經(jīng)過上面的背景和技術(shù)細(xì)節(jié)，我們最終完成了如下圖的系統(tǒng)架構(gòu)。

?

一鍵式DTS平臺(tái)——FastLoad系統(tǒng)架構(gòu)

?

整個(gè)系統(tǒng)分為以下幾個(gè)模塊：

• 控制臺(tái)服務(wù)：對(duì)外提供控制臺(tái)表單和OpenAPI方式接入，提供創(chuàng)建任務(wù)、Schema轉(zhuǎn)換規(guī)則等服務(wù)。

• 大數(shù)據(jù)調(diào)度模塊：依賴Hadoop的計(jì)算資源，將Hive數(shù)據(jù)導(dǎo)出為我們需要的中間文件，在經(jīng)過Map/Reduce的構(gòu)建，生成全局有序的SST文件。

• 文件下載模塊：根據(jù)分布式存儲(chǔ)的路由表，將SST文件下載到不同的存儲(chǔ)節(jié)點(diǎn)。

• 文件導(dǎo)入和DB切換：依賴上文提及的Ingest SST的方式，將文件一次性導(dǎo)入DB實(shí)例。為了避免上述提及的堵塞，我們提供往新DB實(shí)例導(dǎo)數(shù)據(jù)的選項(xiàng)，這樣就可以避免因線上寫而導(dǎo)致的堵塞，空數(shù)據(jù)也可以避免Compact。假如選擇了新DB導(dǎo)入的選項(xiàng)，最后還會(huì)有一次DB新舊實(shí)例的切換，相當(dāng)于一次鏈接映射。

  ?

4.

總結(jié)展望：直掛云帆濟(jì)滄海

▍基于FastLoad的數(shù)據(jù)傳輸給業(yè)務(wù)帶來的收益

?

• 大大縮短業(yè)務(wù)導(dǎo)數(shù)據(jù)耗時(shí)，1TB數(shù)據(jù)平均導(dǎo)入時(shí)間為1小時(shí)；

• 線上服務(wù)業(yè)務(wù)300+，每天運(yùn)行次數(shù)1000+，每天導(dǎo)數(shù)據(jù)量30TB+；

• 服務(wù)穩(wěn)定性達(dá)到99.99%，上線運(yùn)行2年無(wú)任何重大事故；

• 高頻運(yùn)維操作一鍵自助完成，90% 的問題，5 分鐘完成定位；

?

▍發(fā)展規(guī)劃

?

• 架構(gòu)優(yōu)化，整體架構(gòu)目前依賴Hadoop，可以考慮遷移到Spark，提升運(yùn)行效率；

• 管控優(yōu)化，提供更細(xì)致更全面的FastLoad監(jiān)控和報(bào)表；

• 多產(chǎn)品應(yīng)用，目前FastLoad主要針對(duì)NoSQL和NewSQL兩種場(chǎng)景，同比可以應(yīng)用在ES、MQ等場(chǎng)景；

• 新場(chǎng)景支持，離線數(shù)據(jù)的實(shí)時(shí)讀取不僅對(duì)OLTP場(chǎng)景提供了更好的支持，也為接下來大熱的HTAP場(chǎng)景提供了無(wú)限的可能。

總結(jié)

以上是生活随笔為你收集整理的滴滴海量离线数据的在线化 — FastLoad的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。