58快狗打車基于Hologres的實時離線統一資料服務

作者簡介：陶王飛，58快狗打車資深大資料開發工程師，長期專注于實時計算和資料應用。

前言

資料的實時化是最近幾年資料行業很重要的趨勢，我們在去年底也建立起新一代的實時數倉，但是在資料應用上一直沒有取得很大的突破，我們希望實時數倉不僅僅是支撐大屏、核心實時報表、個别實時應用等簡單的場景，希望更大的發揮實時數倉的價值，更友善、更快速、更大規模的對外提供資料服務是我們一直思考的問題。

基于阿裡雲Hoogres 所建設的統一資料服務，在一定程度上幫助我們實作了這個目标。

通過這套系統整合離線和實時資料，對外提供統一的資料服務，目前已經支撐了實時報表、使用者司機實時标簽系統，push系統、運力排程、營銷活動實時監控、公司内部的客服背景系統等幾十個資料需求，實作實時使用者精細化營運。在資料易用性、傳遞周期、資料的準确性上都比以往有了很大的提升。

公司介紹

快狗打車（原58速運）是一家拉貨的短途貨運打車平台，解決比如搬家、買大家具家電、買各種大件、批發市場商家發貨等場景對貨車的需求，同時為藍領司機師傅提供一個可以接單的平台，也就是貨運版的“滴滴”，來實作幫助1000w人解決就業問題的目标。

資料服務的發展背景

原始階段

在早期，我們的資料服務常見的場景，根據每一個需求加工資料。

如果是離線需求，通過Hive加工資料，使用Sqoop将結果資料導出到業務提供的MySQL表中，供業務查詢。

如果是實時需求，開發一個實時項目将處理的資料落表或者發送MQ（Kafka或DMQ(自研元件)），提供到業務方使用。

這種從底到頂的煙囪式開發，導緻的開發成本高、邏輯分散 、資料不一緻、管理維護困難等問題，随着業務的發展，已經難以接受。

1.0階段

18年我們基于Spark Streaming 和Spark SQL所實作的實時數倉，對落地表進行分層、建設大寬表，将計算好的資料統一存放到HBase中，使用ES給HBase做索引，并仿照SQL接口設計了一個較為簡單的查詢API，對外提供統一的查詢接口。所有需要實時資料的任務都可以從這套系統擷取資料，不再根據具體需求做定制化開發。

這種方式，在一定程度上降低了開發成本，增加了資料的複用、緩解了資料不一緻問題，并且應用在多個實時程式上。但是因為計算層面Spark Streaming 狀态支援有限很難做較複雜計算、開發修改成本高。存儲和服務層面，通過接口查詢在HBase中的資料，隻能做明細查詢和簡單聚合查詢，靈活性不足，能對外提供的功能有限，同時也沒有能解決針對離線資料需求的問題，是以大部分應用主要是在部門内，為部門内提效。

2.0階段

在去年底實作的基于Blink的實時數倉，借助于Blink SQL的實時ETL能力，重新設計了實時數倉的資料模型，完善了層級劃分和主題建設，能對外提供的資料比之前多得多。

在存儲層，我們選擇類似于開源Doris的一種實時OLAP引擎，接口層面都是相容MySQL，對于一些不是太複雜的OLAP查詢，可以在秒級甚至亞秒級傳回結果。我們将一部分查詢場景簡單、資料量大、查詢QPS特别高的表輸出到HBase中，使用ES做索引。

底層存儲的割裂，隻能在資料服務層做統一。為此我們設計了一套查詢接口，無論資料存放在實時OLAP引擎、HBase、MYSQL、Maxcompute中，都可以通過接口的SQL查詢出來。但是接口層并沒有完全屏蔽底層存儲，要根據資料存儲位置不同，寫不同的查詢SQL。不同存儲之間，也不能做跨庫join，在使用上還是有很多的局限性。雖然承接了一些資料需求，但是這些局限還是限制了不能更大規模的推廣，我們希望提供給到使用者的是一個使用起來足夠簡單、豐富的資料服務。

3.0 階段

底層存儲的不一緻導緻的一系列問題一直困擾着我們 ，期望有一種引擎，具有幫助我們統一實時資料存儲的能力。

我們是在Hologres（下面稱Holo） 剛剛商業化的時候注意到Holo的，Holo提出的HSAP概念統一了服務的點查詢和實時OLAP查詢。通過一周多的測試、對Holo的系統架構有了一定了解之後，明确了預期收獲、風險點、成本等因素後，寫了一篇Holo的測試文章之後，将實時數倉的資料存儲全部遷移到Holo。

同時基于Holo重新修改了資料服務接口，由于統一的資料存儲、更完善的資料建設、以及Holo很強的實時OLAP能力、統一的資料服務，我們的需求傳遞能力相比以往有了很大的提升。很多以往要做幾天的需求，現在隻需要配置一條SQL，效率的提升是巨大的。系統上線兩個月，接到了很多外部資料需求，目前每天請求百萬次，高峰期實時OLAP 查詢QPS上百（和OLTP的QPS不可比，可以想象1s向Hive送出100個查詢），大部分周期查詢平均耗時幾十毫秒、兩三百毫秒，很少有超過1s的。單個周期查詢最大耗時很少有超過1s。雖然從請求量上看，并不是太大，但是考慮到公司體量和我們上線的時間，這個資料還是很可觀的。目前公司新上的實時資料需求基本上都是在使用這套資料服務。

Hologres簡介

下面是個人在使用Hologres過程中結合官網資料對Hologres的了解：

阿裡雲官網對Hologres 的介紹是：互動式分析（Hologres）是一款相容PostgreSQL協定的實時互動式分析産品，與大資料生态無縫打通，支援對PB級資料進行高并發、低延時的分析處理。 是基于阿裡提出的HSAP（hybrid serving and analytical processing）理念而設計的一種ROLAP系統。相對于HTAP（Hybrid transaction/analytical processing）來說，HSAP弱化了對事務的要求，追求更強的性能和更快的響應時間。

一般來說，為了應對不同的資料使用場景，我們會将高QPS的點查請求的資料存放在kv存儲中，比如說Redis、HBase、Tair等系統中，分析型的資料存放在Druid、Clickhouse、Doris等系統中，有些場景還會使用ES、MySQL等。比如說下圖美團到店的實時數倉存儲分層圖，就是目前常見的實時數倉存儲架構。

HSAP理念的主要目标，将以上的這些存儲統一成一種存儲引擎，主要分為兩種場景：點查（point query）和OLAP的查詢，Holo的點查詢實作很類似于HBase，使用很小的資源就可以支撐起很高的QPS，實時OLAP查詢則是基于MPP的實時互動式查詢，針對兩種場景分别使用了行存和列存兩種不同的存儲格式。

在存儲上，Hologres采取雲原生設計，存儲計算分離，資料存儲在阿裡雲分布式檔案系統pangu中（類比開源HDFS），友善按需單獨擴充計算或者存儲，讀寫分離的設計，以同時支援高并發讀取和高吞吐的寫入。

Holo的資料寫入也是使用LSM tree ，寫入即可見，定期重新整理，但是碎片檔案會分為多個級别。弱化一緻性，僅支援原子寫和Read-your-writes以實作高吞吐和低延遲的讀取和寫入。

宣傳的是寫入可以達到數億的TPS，我們在壓測時，沒有遇到寫入瓶頸。

在查詢上，Hologres使用LBS做查詢負載均衡，查詢請求發送到Hologres FE，做查詢優化，生成并行化的很多片段的執行計算DAG，送出給Blackhole執行。

Holo設計了稱為HOS的使用者态線程排程系統，執行上下文之間的切換成本幾乎忽略不計，同時可以實作更高的并行。Holo的排程政策中，還考慮到大型分析查詢不應阻止對低敏感的服務查詢，此處的服務查詢也就是點查詢（point query）。和Clickhouse、Doris底層一樣，Holo也是使用C++實作，使用native方法，以及向量化引擎等提供更好的性能。

我們在實際的使用中，還發現Holo的硬掃的能力很強，幾百萬級别的資料，不需要要索引就很快傳回。

另外，Holo還提供了多種索引，可以手動添加，比如聚簇索引、分段索引、bitmap索引、字典索引等等。要注意的是，除bitmap和字典索引，其他索引都需要在建表時指定，不能修改。

如果對Holo的實作感興趣，文末附有Holo發表在vldb上的論文連結。

場景實踐

下面是58快狗打車基于Hologres的場景架構圖，主要的架構思路是：

• 實時資料由Blink做實時ETL，寫入Hologres。
• 使用Hologres統一實時資料存儲。
• 基于Hologres和離線倉庫之上，提供統一資料服務，對接業務層的各種報表、分析系統等

  

可以看到，整個架構主要有主要分為3個部分：資料服務、實時數倉和資料存儲。下面将會就這3個部分仔細講訴。

1.資料服務

主要基于Holo，我們做了一套對外提供的統一資料服務。從上面的架構圖可以看到，使用者送出的查詢請求到統一資料服務接口，經過安全校驗解析、别名映射後，送出到Holo等執行。

使用Holo為我們解決了兩個半問題：

1）Holo很大程度上降低了存儲的成本。

2）Holo解決了資料存儲不統一的問題，同時提供了高性能的實時OLAP能力。

3）Holo提供了無需搬移資料，加速查詢離線資料的功能，但是由于是以資源消耗為代價，性能會比直接查詢Holo内部表差10倍，同時有較多的限制（例如單次query命中的資料量為200G、分區限制512個等）。是以，算是解決了半個問題。

然後，我們在資料服務接口做了更進一步的統一，資料服務接口以Holo為主，同時相容一些曆史上存放在MySQL中的任務。對于特别複雜，同時對響應時長不敏感的查詢，也可以使用資料服務接口直接查詢離線資料。是以，我們希望資料服務接口是作為整個資料部門統一的資料服務，統一對外的所有資料接口。

Blink任務修改後，可能會導緻之前的狀态不可用，狀态清空，直接修改上線落表資料正确性會有影響。同時Holo大部分索引需要在建表時指定，如果一開始表設計不合理， 或者之前的表設計不再滿足現有需求。這時候實體表如果被寫入很多任務中，是很難修改的。是以我們設計了别名映射的mapping系統，mapping中會指定實體表，庫名、連接配接等資訊，使用者隻需要知道别名就可以使用，無需關心具體位置，同時别名是相對固定的。Blink修改任務時，可以建立任務寫到建立表，待補齊資料，借助推送系統，一鍵切換，立即生效，所有的查詢馬上切換到新實體表，線上業務無感覺，類似于一個主備切換的過程。另外如果一旦發生較大改動，也可以在我們這邊控制。

服務保障方面，通過監控每次的查詢，建立查詢異常報警機制，監控整體服務的穩定性，對于不合理查詢可以及時提供修改意見，保障整體服務持續穩定和高效。

2.實時數倉

實時數倉原始資料源來自日志資料和MySQL binlog訂閱，我們開發了資料訂閱平台，通過平台配置，将資料統一發送到Kafka中，使用Blink SQL做實時ETL，資料的輸出主要有兩種，表（Holo）和MQ（Kafka）。

在模組化上，參考了離線的已有的資料模型，但是又不完全一樣，主要展現在分層和表字段設計，這是因為離線、實時資料的本身的屬性不同。離線每天拉取一次，一次性計算，跑一次，當天都可以一直使用，同時離線計算能力強，是以可以建設高内聚低耦合複雜的資料模型 ，使用邏輯下沉、複雜模型、完善分層和更完整次元抽象等方式，來更好的保障資料一緻性和資料易用性。對外提供的也是聚合資料為主，明細為輔。

但是實時任務是24小時運作，更高的層級抽象意味着使用起來不靈活、鍊路長穩定性差、維護代價大、時效性差等。

是以，相較于離線，實時的層級更輕。很多公司在實時數倉會有較多的次元退化，我們基于Holo較好的join 性能，在一定程度上減少次元退化的設計，提高了靈活性和開發效率。

更重要的是，借助于Holo很好的實時OLAP性能，很多任務可以實時OLAP 現算，而不用針對具體任務加工具體的應用層資料，使用實時Join也不用做大寬表，這對效率的提升是巨大的。以前，很多實時需求需要專門寫實時加工任務，而且如果需求修改，修改實時任務的代價也是很大的，整個開發周期好幾天，現在可能使用統一資料服務接口，基于我們體系的資料建設，可能幾分鐘就可以傳遞了。

當然，也并不能過度的依賴于實時OLAP，在我們的最終實踐上，為了更高的效率和一定的資料一緻性。我們預處理了部分比較固化的計算在聚合層，對外提供的資料，優先使用固化的聚合層，對于比較靈活的查詢和不好固化的統計，使用明細層，總體來說，以明細為主，需求傳遞效率有較大提升。    

可能在很多公司，實時數倉更多應用在實時報表等營運實時監控等場景，對于風控等場景，會有獨立的資料流程。我們認為實時數倉的優勢在于，資料建設完整、開發效率高、對聚合類資料有不可替代的優勢，雖然有資料處理鍊路長的劣勢，但是如果僅僅是用在實時報表有一點浪費。 是以，我們在拓展實時資料應用時，一直是有所節制，場景主要限制在一些内部需求或者靈敏度不是特别高的業務場景，比如說我們準備做的，将取消訂單等相關的資訊、使用者統計資料推送到客服系統等需求。對于個别像反作弊之類的線上業務，也會限制隻提供低層的Kafka基礎資料來確定穩定性。

3.資料存儲

Lambda架構不僅會導緻了計算的備援，也導緻了存儲的備援。而Kappa架構在目前的技術下，過于理想化。行業内還很少聽到有完全的Kappa架構落地的案例，目前主要是以Lambda為主，個别地方會做調整優化的方式。

計算的備援其實比較難以解決，雖然這幾年實時計算技術發展迅速，但是實時計算還遠遠不能完全替代掉離線程度，實時任務修改的複雜度也遠遠高于離線任務。Flink的流批一體的方案，使用一套代碼同時運作離線和實時計算的方案，目前也是在初期發展中，雖然沒有用過，但是能想到應該有很多困難的地方。

相對而言，存儲的一緻性能做的事情更多。不考慮實際，理想情況下，離線和實時的資料都存儲在一個存儲引擎中，同時能跑批任務，也具有對外提供資料服務的能力。

Holo在這個方向上往前走了一步，除了解決了實時數倉存儲統一的問題，還提供了離線外表的功能，可以将離線表作為Holo的外部表，借助于Holo比較強大的硬掃能力，來加快離線資料的查詢，使用一套系統就能同時查詢離線和實時的資料。上面也講過，這種硬掃是以大量的磁盤IO和CPU資源為代價的，是以會有較多的限制，比如說為了更好的性能，對于外表的分區數量和MaxCompute資料量有一定的限制。這種做法可以了解為一種冷資料的處理，官方給的字眼是 ”離線加速“。

在實際使用中，我們測試對2億資料的點查大約在2s左右，官方給到的資料是，相比于内部表，外部表性能會差10倍，可以滿足一些對時效要求不高、查詢頻率不高的資料需求，在高時效性的任務這種性能表現可能不能滿足需求，可以通過導入内表來解決。

具體到我們的實踐上，對于一部分需要離線資料、對時效性要求不是特别高同時離線查詢分鐘級的響應時長不能滿足、查詢頻率不高的需求，我們會以外部表的形式對外提供，文法還是和Holo内表相同的文法，對于需要一部分離線資料、同時時效性要求很高、查詢頻率很高的查詢場景，我們選擇将一部分離線資料導入到Holo中，有時會和實時對應任務放在同一個表中，對外提供服務，這種做法事實上造成資料備援，是一種妥協。

總的來說，Holo 并沒有完全解決實時和離線統一存儲的問題，但是往前做了一些探索性的工作。目前，Holo和離線Maxcompute開發團隊已經融合，期待下一步看到更多的融合。

業務價值

總結來講，從業務開始接觸Hologres并上線，在實戰場景中帶來的主要優勢有以下幾點：

1.統一了實時存儲，解決了實時資料孤島等問題

2.加速離線資料查詢，簡單查詢可以數秒傳回，但還是會有一些使用限制，需要根據實際使用場景來做調整。

3.資料模型的變化，一定程度上減少了以往實時過多的次元備援，幫助我們建設更低耦合的實時數倉

4.加速了需求的傳遞，不需要做資料開發的需求，甚至隻需要十幾分鐘就能傳遞任務，大大的提升了效率。傳遞的提升，我們可以将資料更大範圍的推廣。

同時，Holo作為新生事物，基于新型的架構設計，提供了非常強大的性能。我們在測試和使用的過程中，也發現了一些不足之處，也希望這些不足或者建議能幫助快速發展

1）目前Holo更新配置和版本需要停服，需要停服幾分鐘的時間，需要提前有準備，後續版本會解決。

2）Holo gis 功能目前不支援索引，在大量資料下效率較低，我們測試2億資料下地理距離查詢大約幾秒鐘。目前索引功能開發中。

3）Holo支援分區子表，有點類似于Hive的分區表，比較适合增量資料，在資料删除和查詢上有一定的優勢。但是目前每個分區子表必須手動提前建表，手動删除，目前的解決辦法是通過排程任務來自動建表，期待Holo團隊能夠實作這個功能

4）資源隔離，在我們調研測試中，就發現高吞吐查詢會影響到對延時要求高的小查詢，在後來的實測中，發現即使是大查詢沒有完全跑滿資源的情況，也會影響到小查詢的響應時長。這個問題很早就和Holo溝通過，算是一個比較普遍的問題，開源引擎也會遇到，有些公司會使用獨立叢集對不同查詢做實體隔離。Holo也已經明确給答複後面會徹底解決這個問題。由于我們很早就意識到這個問題，是以從一開始的整體設計就有預防和控制，目前還好。

5）在測試使用過程中，還發現一些小bug ，作為新産品，我們在享受便利的同時，也肯定會有一些不足的地方，我們也願意同Holo一起成長。

未來規劃

Holo幫助我們實作在實時資料資料存儲方面，隻使用一套存儲，在一定程度上緩解了資料不一緻的問題，算是前進了一大步。但是更遠期來說，我們希望在未來可以徹底解決資料一緻的問題，真正的讓一份資料隻存儲在一個地方。

具體到眼前，我們的主要精力在系統的穩定性、規範化沉澱、工具提效、并通過需求來完善我們的資料服務體系，更好的易用性、更強的穩定性、更快的傳遞周期，會更多的在内部的建設上。

參考

Alibaba Hologres: A Cloud-Native Service  for Hybrid Serving/Analytical Processing：

http://www.vldb.org/pvldb/vol13/p3272-jiang.pdf