作者：阿里巴巴菜鳥物流團(tuán)隊(duì)（棄疾，孝江，姜繼忠）

一、業(yè)務(wù)背景

菜鳥智能物流分析引擎是基于搜索架構(gòu)建設(shè)的物流查詢平臺(tái)，日均處理包裹事件幾十億，承載了菜鳥物流數(shù)據(jù)的大部分處理任務(wù)。
智能物流分析引擎將基于運(yùn)配網(wǎng)絡(luò)的各類應(yīng)用場(chǎng)景集中到了統(tǒng)一的一個(gè)技術(shù)架構(gòu)，以此提供強(qiáng)大的吞吐和計(jì)算能力。基于原架構(gòu)的數(shù)據(jù)處理流程為：Datahub實(shí)時(shí)采集數(shù)據(jù)源，包含倉、配、運(yùn)和訂單等數(shù)據(jù)，實(shí)時(shí)計(jì)算Flink基于流批一體的模式對(duì)數(shù)據(jù)預(yù)處理，形成一個(gè)以訂單為單位，包含訂單跟蹤事件的寬表，寫入存儲(chǔ)引擎HBase中，再供外部查詢。

在數(shù)據(jù)處理部分，隨著數(shù)據(jù)量的增加，原有的存儲(chǔ)系統(tǒng)HBase在維表全量導(dǎo)入中所需要的時(shí)間越來越長(zhǎng)，這就需要耗費(fèi)大量的資源，另外其單機(jī)吞吐的表現(xiàn)不是很好，單位成本高。在數(shù)據(jù)量較小時(shí)，成本不是需要考慮的關(guān)鍵因素，但當(dāng)數(shù)據(jù)量規(guī)模變大時(shí)，成本的重要性就體現(xiàn)出來了。菜鳥智能物流每天需要處理大批量的數(shù)據(jù)，這也就意味著每天將會(huì)浪費(fèi)大量的資源。

同時(shí)，在我們的場(chǎng)景中，有些表是作為Flink維表基于PK進(jìn)行PointQuery，有些表需要進(jìn)行OLAP分析，而HBase并不能兩種場(chǎng)景都滿足。為了OLAP分析，需要將數(shù)據(jù)同步到批處理系統(tǒng)中，為了KV查詢，需要將數(shù)據(jù)同步到KVStore。不同的查詢需求就需要借助多個(gè)系統(tǒng)，數(shù)據(jù)在不同系統(tǒng)之間的導(dǎo)入導(dǎo)出不僅會(huì)加深數(shù)據(jù)同步的負(fù)擔(dān)，也會(huì)帶來冗余存儲(chǔ)，也極容易出現(xiàn)數(shù)據(jù)不一致的情況，并且多個(gè)系統(tǒng)也會(huì)給開發(fā)和運(yùn)維帶來一定的成本。

基于以上背景，當(dāng)前我們最需要解決的問題是降低整體的資源消耗成本，那么就需要有一款產(chǎn)品既能提供存儲(chǔ)能力還要提供高性能的寫入能力。而在查詢場(chǎng)景上，若是這款產(chǎn)品能同時(shí)滿足KV查詢和復(fù)雜OLAP查詢將會(huì)是加分項(xiàng)，這樣就會(huì)解決多個(gè)系統(tǒng)帶來的數(shù)據(jù)孤島問題，一次性滿足所有需求。

我們?cè)诩瘓F(tuán)內(nèi)對(duì)多個(gè)產(chǎn)品進(jìn)行了調(diào)研，最終選擇了Hologres替換現(xiàn)有的HBase。

二、業(yè)務(wù)架構(gòu)

菜鳥物流引擎需要處理大量的表和數(shù)據(jù)，全量任務(wù)快遞線和倉配線通過MaxCompute（原ODPS）表的日分區(qū)快照做驅(qū)動(dòng)源，增量任務(wù)通過對(duì)應(yīng)的事件流做驅(qū)動(dòng)，來進(jìn)行引擎數(shù)據(jù)寫入。
全量任務(wù)會(huì)根據(jù)包裹的歷史履行進(jìn)度進(jìn)行聚合，生成這個(gè)包裹的客觀履行和歷史屬性信息，并通過Flink Job實(shí)時(shí)同步更新到Hologres里，提供給數(shù)據(jù)任務(wù)進(jìn)行關(guān)聯(lián)。實(shí)時(shí)數(shù)據(jù)在接收到一條事件消息后，首先會(huì)去關(guān)聯(lián)這條包裹歷史履行，并會(huì)調(diào)用算法服務(wù)鏈，進(jìn)行拆合單、末端網(wǎng)點(diǎn)預(yù)測(cè)、路由選擇、時(shí)效預(yù)測(cè)等，生成新的預(yù)測(cè)履行進(jìn)度。新的預(yù)測(cè)履行會(huì)作為回流數(shù)據(jù)寫入TT（消息中間件，類似Kafka）和Hologres中，并再提供給數(shù)據(jù)任務(wù)進(jìn)行關(guān)聯(lián)。
通過數(shù)據(jù)任務(wù)之間的互相協(xié)同，我們對(duì)數(shù)據(jù)關(guān)系進(jìn)行了梳理，并盡量降低數(shù)據(jù)之間的依賴，最終業(yè)務(wù)處理架構(gòu)如下圖所示：

• 數(shù)據(jù)驅(qū)動(dòng)層?在數(shù)據(jù)驅(qū)動(dòng)層中，包含幾個(gè)部分：全量任務(wù)的主表驅(qū)動(dòng)、增量任務(wù)的主表驅(qū)動(dòng)、業(yè)務(wù)輔表的驅(qū)動(dòng)。
• 數(shù)據(jù)關(guān)聯(lián)層?數(shù)據(jù)關(guān)聯(lián)層主要包括各種Flink的SQL Operator。為了提升全量任務(wù)和增量任務(wù)的吞吐，通過存儲(chǔ)和計(jì)算優(yōu)化，將數(shù)據(jù)關(guān)聯(lián)盡可能的分布到不同的數(shù)據(jù)分區(qū)上，來進(jìn)行性能提升。
• 數(shù)據(jù)交互層?索引數(shù)據(jù)通過Swift Sink的方式寫入到索引構(gòu)建服務(wù)中；要持久化的內(nèi)部數(shù)據(jù)，通過寫入接口保存到存儲(chǔ)服務(wù)中。

?

三、業(yè)務(wù)價(jià)值

將HBase替換成Hologres之后，給業(yè)務(wù)帶來的價(jià)值主要有以下幾個(gè)方面：

1.整體硬件資源成本下降60%+
對(duì)比HBase，相同配置的Hologres有著更強(qiáng)的寫入性能，能夠提供更好的吞吐量，也就是說我們可以用更少的資源來滿足現(xiàn)有數(shù)據(jù)規(guī)模的處理需求。在實(shí)際業(yè)務(wù)應(yīng)用中，整體硬件資源成本下降60%+，解決了我們最棘手的問題。

2.更快的全鏈路處理速度（2億記錄端到端3分鐘）
全量數(shù)據(jù)處理所需的時(shí)間是非常重要的指標(biāo)，設(shè)想某一天新發(fā)布的數(shù)據(jù)處理代碼有bug，新產(chǎn)出的數(shù)據(jù)不可用，即使修復(fù)了代碼，還得繼續(xù)解決已經(jīng)存在的錯(cuò)誤數(shù)據(jù)，此時(shí)就要跑一次全量，用正常的數(shù)據(jù)覆蓋錯(cuò)誤的數(shù)據(jù)。全量任務(wù)的運(yùn)行時(shí)間決定了故障的持續(xù)時(shí)間，全量運(yùn)行的速度越快，故障才能越快解決。
在物流分析引擎的全量中，我們需要先通過所有維表的數(shù)據(jù)，確保維表自身的數(shù)據(jù)是正確的，這是一個(gè)非常耗時(shí)的操作。以其中一張表為例，2億多的數(shù)據(jù)量，使用Hologres同步只需要3分鐘左右，這也意味著可以更快的執(zhí)行完畢全量數(shù)據(jù)，以便我們能夠更從容應(yīng)對(duì)突發(fā)情況。

3.一個(gè)系統(tǒng)，滿KV和OLAP兩個(gè)場(chǎng)景，沒有數(shù)據(jù)冗余
Hologres在存儲(chǔ)上支持行存和列存兩種存儲(chǔ)模式。列存適合海量數(shù)據(jù)的交互式分析，而行存適合基于Primary Key的整行讀取。這就意味著我們可以將所有的數(shù)據(jù)存儲(chǔ)在Hologres中，需要PointQuery就選擇行存模式，需要復(fù)雜OLAP分析就選擇列存模式，滿足了OLAP和KV查詢，無需再借助其他系統(tǒng)，既保證了數(shù)據(jù)存儲(chǔ)的唯一性，也避免了各種系統(tǒng)之間的導(dǎo)入導(dǎo)出和復(fù)雜運(yùn)維。

4.大維表實(shí)時(shí)SQL查詢
以前如果想查一下維表中的數(shù)據(jù)，由于是KV接口，并不是很方便。Hologres兼容PostgreSQL生態(tài)，可以直接使用psql客戶端訪問，通過標(biāo)準(zhǔn)的PostgreSQL語法查詢表中的數(shù)據(jù)，支持各種過濾條件，能夠很方便的實(shí)時(shí)檢查數(shù)據(jù)是不是有問題。

5.強(qiáng)Schema
原有的維表存儲(chǔ)是一個(gè)弱Schema的存儲(chǔ)服務(wù)，在Flink任務(wù)中，即使訪問不存在的字段也不會(huì)報(bào)錯(cuò)，只是獲取到的字段值為空。代碼里不小心寫錯(cuò)了字段名，一是很難立刻發(fā)現(xiàn)，通常要等到數(shù)據(jù)產(chǎn)出時(shí)候才能發(fā)現(xiàn)，甚至只能等用戶發(fā)現(xiàn)，另外排查起來也很麻煩，沒法直接定位。使用Hologres的時(shí)候字段名寫錯(cuò)立即報(bào)錯(cuò)，錯(cuò)誤信息很明確，避免了潛在的錯(cuò)誤風(fēng)險(xiǎn)，還能節(jié)省時(shí)間。

?

?

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的菜鸟+Hologres=智能物流的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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