菜鳥+Hologres=智能物流

做者：阿里巴巴菜鳥物流團隊（棄疾，孝江，姜繼忠）

1、業務背景

菜鳥智能物流分析引擎是基於搜索架構建設的物流查詢平臺，日均處理包裹事件幾十億，承載了菜鳥物流數據的大部分處理任務。

智能物流分析引擎將基於運配網絡的各種應用場景集中到了統一的一個技術架構，以此提供強大的吞吐和計算能力。基於原架構的數據處理流程爲：Datahub實時採集數據源，包含倉、配、運和訂單等數據，實時計算Flink基於流批一體的模式對數據預處理，造成一個以訂單爲單位，包含訂單跟蹤事件的寬表，寫入存儲引擎HBase中，再供外部查詢。

在數據處理部分，隨着數據量的增長，原有的存儲系統HBase在維表全量導入中所須要的時間愈來愈長，這就須要耗費大量的資源，另外其單機吞吐的表現不是很好，單位成本高。在數據量較小時，成本不是須要考慮的關鍵因素，但當數據量規模變大時，成本的重要性就體現出來了。菜鳥智能物流天天須要處理大批量的數據，這也就意味着天天將會浪費大量的資源。

同時，在咱們的場景中，有些表是做爲Flink維表基於PK進行PointQuery，有些表須要進行OLAP分析，而HBase並不能兩種場景都知足。爲了OLAP分析，須要將數據同步到批處理系統中，爲了KV查詢，須要將數據同步到KVStore。不一樣的查詢需求就須要藉助多個系統，數據在不一樣系統之間的導入導出不只會加深數據同步的負擔，也會帶來冗餘存儲，也極容易出現數據不一致的狀況，而且多個系統也會給開發和運維帶來必定的成本。

基於以上背景，當前咱們最須要解決的問題是下降總體的資源消耗成本，那麼就須要有一款產品既能提供存儲能力還要提供高性能的寫入能力。而在查詢場景上，如果這款產品能同時知足KV查詢和複雜OLAP查詢將會是加分項，這樣就會解決多個系統帶來的數據孤島問題，一次性知足全部需求。
咱們在集團內對多個產品進行了調研，最終選擇了Hologres替換現有的HBase。

2、業務架構

菜鳥物流引擎須要處理大量的表和數據，全量任務快遞線和倉配線經過MaxCompute（原ODPS）表的日分區快照作驅動源，增量任務經過對應的事件流作驅動，來進行引擎數據寫入。

全量任務會根據包裹的歷史履行進度進行聚合，生成這個包裹的客觀履行和歷史屬性信息，並經過Flink Job實時同步更新到Hologres裏，提供給數據任務進行關聯。實時數據在接收到一條事件消息後，首先會去關聯這條包裹歷史履行，並會調用算法服務鏈，進行拆合單、末端網點預測、路由選擇、時效預測等，生成新的預測履行進度。新的預測履行會做爲迴流數據寫入TT（消息中間件，相似Kafka）和Hologres中，並再提供給數據任務進行關聯。

經過數據任務之間的互相協同，咱們對數據關係進行了梳理，並儘可能下降數據之間的依賴，最終業務處理架構以下圖所示：

• 數據驅動層 在數據驅動層中，包含幾個部分：全量任務的主表驅動、增量任務的主表驅動、業務輔表的驅動。
• 數據關聯層 數據關聯層主要包括各類Flink的SQL Operator。爲了提高全量任務和增量任務的吞吐，經過存儲和計算優化，將數據關聯儘量的分佈到不一樣的數據分區上，來進行性能提高。
• 數據交互層 索引數據經過Swift Sink的方式寫入到索引構建服務中；要持久化的內部數據，經過寫入接口保存到存儲服務中。

3、業務價值

將HBase替換成Hologres以後，給業務帶來的價值主要有如下幾個方面：

1.總體硬件資源成本降低60%+
對比HBase，相同配置的Hologres有着更強的寫入性能，可以提供更好的吞吐量，也就是說咱們能夠用更少的資源來知足現有數據規模的處理需求。在實際業務應用中，總體硬件資源成本降低60%+，解決了咱們最棘手的問題。

2.更快的全鏈路處理速度（2億記錄端到端3分鐘）
全量數據處理所需的時間是很是重要的指標，設想某一天新發布的數據處理代碼有bug，新產出的數據不可用，即便修復了代碼，還得繼續解決已經存在的錯誤數據，此時就要跑一次全量，用正常的數據覆蓋錯誤的數據。全量任務的運行時間決定了故障的持續時間，全量運行的速度越快，故障才能越快解決。
在物流分析引擎的全量中，咱們須要先經過全部維表的數據，確保維表自身的數據是正確的，這是一個很是耗時的操做。以其中一張表爲例，2億多的數據量，使用Hologres同步只須要3分鐘左右，這也意味着能夠更快的執行完畢全量數據，以便咱們可以更從容應對突發狀況。

3.一個系統，滿KV和OLAP兩個場景，沒有數據冗餘
Hologres在存儲上支持行存和列存兩種存儲模式。列存適合海量數據的交互式分析，而行存適合基於Primary Key的整行讀取。這就意味着咱們能夠將全部的數據存儲在Hologres中，須要PointQuery就選擇行存模式，須要複雜OLAP分析就選擇列存模式，知足了OLAP和KV查詢，無需在藉助其餘系統，既保證了數據存儲的惟一性，也避免了各類系統之間的導入導出和複雜運維。

4.大維表實時SQL查詢
之前若是想查一下維表中的數據，因爲是KV接口，並非很方便。Hologres兼容PostgreSQL生態，能夠直接使用psql客戶端訪問，經過標準的PostgreSQL語法查詢表中的數據，支持各類過濾條件，可以很方便的實時檢查數據是否是有問題。

5.強Schema原有的維表存儲是一個弱Schema的存儲服務，在Flink任務中，即便訪問不存在的字段也不會報錯，只是獲取到的字段值爲空。代碼裏不當心寫錯了字段名，一是很難馬上發現，一般要等到數據產出時候才能發現，甚至只能等用戶發現，另外排查起來也很麻煩，無法直接定位。使用Hologres的時候字段名寫錯當即報錯，錯誤信息很明確，避免了潛在的錯誤風險，還能節省時間。