作者：阿里巴巴菜鳥物流團隊（棄疾，孝江，姜繼忠）
一、業務背景
菜鳥智能物流分析引擎是基於搜索架構建設的物流查詢平臺，日均處理包裹事件幾十億，承載了菜鳥物流數據的大部分處理任務。
智能物流分析引擎將基於運配網絡的各類應用場景集中到了統一的一個技術架構，以此提供強大的吞吐和計算能力。基於原架構的數據處理流程爲：Datahub實時採集數據源，包含倉、配、運和訂單等數據，實時計算Flink基於流批一體的模式對數據預處理，形成一個以訂單爲單位，包含訂單跟蹤事件的寬表，寫入存儲引擎HBase中，再供外部查詢。
在數據處理部分，隨着數據量的增加，原有的存儲系統HBase在維表全量導入中所需要的時間越來越長，這就需要耗費大量的資源，另外其單機吞吐的表現不是很好，單位成本高。在數據量較小時，成本不是需要考慮的關鍵因素，但當數據量規模變大時，成本的重要性就體現出來了。菜鳥智能物流每天需要處理大批量的數據，這也就意味着每天將會浪費大量的資源。
同時，在我們的場景中，有些表是作爲Flink維表基於PK進行PointQuery，有些表需要進行OLAP分析，而HBase並不能兩種場景都滿足。爲了OLAP分析，需要將數據同步到批處理系統中，爲了KV查詢，需要將數據同步到KVStore。不同的查詢需求就需要藉助多個系統，數據在不同系統之間的導入導出不僅會加深數據同步的負擔，也會帶來冗餘存儲，也極容易出現數據不一致的情況，並且多個系統也會給開發和運維帶來一定的成本。
基於以上背景，當前我們最需要解決的問題是降低整體的資源消耗成本，那麼就需要有一款產品既能提供存儲能力還要提供高性能的寫入能力。而在查詢場景上，若是這款產品能同時滿足KV查詢和複雜OLAP查詢將會是加分項，這樣就會解決多個系統帶來的數據孤島問題，一次性滿足所有需求。
我們在集團內對多個產品進行了調研，最終選擇了Hologres替換現有的HBase。
二、業務架構
菜鳥物流引擎需要處理大量的表和數據，全量任務快遞線和倉配線通過MaxCompute（原ODPS）表的日分區快照做驅動源，增量任務通過對應的事件流做驅動，來進行引擎數據寫入。
全量任務會根據包裹的歷史履行進度進行聚合，生成這個包裹的客觀履行和歷史屬性信息，並通過Flink Job實時同步更新到Hologres裏，提供給數據任務進行關聯。實時數據在接收到一條事件消息後，首先會去關聯這條包裹歷史履行，並會調用算法服務鏈，進行拆合單、末端網點預測、路由選擇、時效預測等，生成新的預測履行進度。新的預測履行會作爲迴流數據寫入TT（消息中間件，類似Kafka）和Hologres中，並再提供給數據任務進行關聯。
通過數據任務之間的互相協同，我們對數據關係進行了梳理，並儘量降低數據之間的依賴，最終業務處理架構如下圖所示：
- 數據驅動層 在數據驅動層中，包含幾個部分：全量任務的主表驅動、增量任務的主表驅動、業務輔表的驅動。
- 數據關聯層 數據關聯層主要包括各種Flink的SQL Operator。爲了提升全量任務和增量任務的吞吐，通過存儲和計算優化，將數據關聯儘可能的分佈到不同的數據分區上，來進行性能提升。
- 數據交互層 索引數據通過Swift Sink的方式寫入到索引構建服務中；要持久化的內部數據，通過寫入接口保存到存儲服務中。
三、業務價值
將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的時候字段名寫錯立即報錯，錯誤信息很明確，避免了潛在的錯誤風險，還能節省時間。