前言

? ? ? ? 數(shù)據(jù)的實時化是最近幾年數(shù)據(jù)行業(yè)很重要的趨勢，我們在去年底也建立起新一代的實時數(shù)倉，但是在數(shù)據(jù)應用上一直沒有取得很大的突破，我們希望實時數(shù)倉不僅僅是支撐大屏、核心實時報表、個別實時應用等簡單的場景，希望更大的發(fā)揮實時數(shù)倉的價值，更方便、更快速、更大規(guī)模的對外提供數(shù)據(jù)服務是我們一直思考的問題。? ? ? ? 基于阿里云Hoogres 所建設的統(tǒng)一數(shù)據(jù)服務，在一定程度上幫助我們實現(xiàn)了這個目標。? ? ? ? 通過這套系統(tǒng)整合離線和實時數(shù)據(jù)，對外提供統(tǒng)一的數(shù)據(jù)服務，目前已經(jīng)支撐了實時報表、用戶司機實時標簽系統(tǒng)，push系統(tǒng)、運力調度、營銷活動實時監(jiān)控、公司內部的客服后臺系統(tǒng)等幾十個數(shù)據(jù)需求，實現(xiàn)實時用戶精細化運營。在數(shù)據(jù)易用性、交付周期、數(shù)據(jù)的準確性上都比以往有了很大的提升。

公司介紹

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

數(shù)據(jù)服務的發(fā)展階段

原始階段

? ? ? ? ?在早期，我們的數(shù)據(jù)服務常見的場景，根據(jù)每一個需求加工數(shù)據(jù)。

? ? ? ? ?如果是離線需求，通過Hive加工數(shù)據(jù)，使用Sqoop將結果數(shù)據(jù)導出到業(yè)務提供的MySQL表中，供業(yè)務查詢。

? ? ? ? 如果是實時需求，開發(fā)一個實時項目將處理的數(shù)據(jù)落表或者發(fā)送MQ(Kafka或DMQ(自研組件))，提供到業(yè)務方使用。

? ? ? ? ?這種從底到頂?shù)臒焽枋介_發(fā)，導致的開發(fā)成本高、邏輯分散 、數(shù)據(jù)不一致、管理維護困難等問題，隨著業(yè)務的發(fā)展，已經(jīng)難以接受。

1.0階段

? ? ?? 18年我們基于Spark Streaming 和Spark SQL所實現(xiàn)的實時數(shù)倉，對落地表進行分層、建設大寬表，將計算好的數(shù)據(jù)統(tǒng)一存放到HBase中，使用ES給HBase做索引，并仿照SQL接口設計了一個較為簡單的 查詢api，對外提供統(tǒng)一的查詢接口。所有需要實時數(shù)據(jù)的任務都可以從這套系統(tǒng)獲取數(shù)據(jù)，不再根據(jù)具體需求做定制化開發(fā)。

? ? ? 這種方式，在一定程度上降低了開發(fā)成本，增加了數(shù)據(jù)的復用、緩解了數(shù)據(jù)不一致問題，并且應用在多個實時程序上。但是因為計算層面Spark Streaming 狀態(tài)支持有限很難做較復雜計算、開發(fā)修改成本高。存儲和服務層面，通過接口查詢在HBase中的數(shù)據(jù)，只能做明細查詢和簡單聚合查詢，靈活性不足，能對外提供的功能有限，同時也沒有能解決針對離線數(shù)據(jù)需求的問題，所以大部分應用主要是在部門內，為部門內提效。

2.0階段

? ? ?? 在去年底實現(xiàn)的基于Blink 的實時數(shù)倉，借助于Blink SQL的實時ETL能力，重新設計了實時數(shù)倉的數(shù)據(jù)模型，完善了層級劃分和主題建設，能對外提供的數(shù)據(jù)比之前多得多。

? ? ?? 在存儲層，我們選擇有較好實時OLAP性能的阿里云AnalyticDB MySQL(下稱ADB)，和開源Doris類似，接口層面都是兼容MySQL，對于一些不是太復雜的OLAP查詢，可以在秒級甚至亞秒級返回結果。但是由于ADB并不是太好的實時寫入性能、存儲成本昂貴以及一些內部原因，我們將一部分查詢場景簡單、數(shù)據(jù)量大、查詢QPS特別高的表輸出到HBase中，使用ES做索引。

? ? ? 底層存儲的割裂，只能在數(shù)據(jù)服務層做統(tǒng)一。為此我們設計了一套查詢接口，無論數(shù)據(jù)存放在ADB、HBase、MYSQL、Maxcompute中，都可以通過接口的SQL 查詢出來。但是接口層并沒有完全屏蔽底層存儲，要根據(jù)數(shù)據(jù)存儲位置不同，寫不同的查詢SQL。不同存儲之間，也不能做跨庫join，在使用上還是有很多的局限性。雖然承接了一些數(shù)據(jù)需求，但是這些局限還是約束了不能更大規(guī)模的推廣。我們希望提供給到用戶的是一個使用起來足夠簡單、豐富的數(shù)據(jù)服務。

?

3.0 階段

? ? ? 底層存儲的不一致導致的一系列問題一直困擾著我們 ，期望有一種引擎，具有幫助我們統(tǒng)一實時數(shù)據(jù)存儲的能力。

? ? ? 我們是在Hologres(下稱Holo) 剛剛商業(yè)化的時候注意到Holo的，Holo提出的HSAP概念統(tǒng)一 針對服務的點查詢和實時OLAP查詢，在存儲上也沒有ADB翻倍厲害的情況。通過一周多的測試、對Holo的系統(tǒng)架構有了一定了解之后，明確了預期收獲、風險點、成本等因素后，寫了一篇Holo的測試文章之后，將實時數(shù)倉的數(shù)據(jù)存儲全部遷移到Holo。

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

Hologres簡介

? ? ? ? 下面是個人在使用Hologres過程中結合官網(wǎng)資料對Hologres的理解：

? ? ? ? 阿里云官網(wǎng)對Hologres 的介紹是：交互式分析(Hologres)是一款兼容PostgreSQL協(xié)議的實時交互式分析產(chǎn)品。Hologres與大數(shù)據(jù)生態(tài)無縫打通，支持對PB級數(shù)據(jù)進行高并發(fā)、低延時的分析處理。是基于阿里提出的HASP (hybrid serving and analytical processing)理念而設計的一種ROLAP系統(tǒng)。相對于HTAP(Hybrid transaction/analytical processing)來說，HASP弱化了對事務的要求，追求更強的性能和更快的響應時間。

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

? ? ?? ??

? ? ? ?HASP理念的主要目標，將以上的這些存儲統(tǒng)一成一種存儲引擎，主要分為兩種場景：點查(point query)和OLAP的查詢，Holo的點查詢實現(xiàn)很類似于HBase，使用很小的資源就可以支撐起很高的QPS，實時OLAP查詢則是基于MPP的實時交互式查詢，針對兩種場景分別使用了行存和列存兩種不同的存儲格式。

? ? ? ?在存儲上，Hologres采取云原生設計，存儲計算分離，數(shù)據(jù)存儲在阿里云分布式文件系統(tǒng)pangu中(類比開源HDFS)，方便按需單獨擴展計算或者存儲，讀寫分離的設計，以同時支持高并發(fā)讀取和高吞吐的寫入。

Holo的數(shù)據(jù)寫入也是使用LSM tree ，寫入即可見，定期刷新，但是碎片文件會分為多個級別。弱化一致性，僅支持原子寫和Read-your-writes以實現(xiàn)高吞吐和低延遲的讀取和寫入。

? ? ? ?宣傳的是寫入可以達到數(shù)億的TPS，比起ADB數(shù)萬的TPS高出了很多。我們在壓測時，沒有遇到寫入瓶頸。

? ? ? ?在查詢上，Hologres使用LBS做查詢負載均衡，查詢請求發(fā)送到Hologres FE，做查詢優(yōu)化，生成并行化的很多片段的執(zhí)行計算DAG，提交給Blackhole執(zhí)行。

? ? ? Holo設計了稱為HOS的用戶態(tài)線程調度系統(tǒng)，執(zhí)行上下文之間的切換成本幾乎忽略不計，同時可以實現(xiàn)更高的并行。Holo的調度策略中，還考慮到大型分析查詢不應阻止對低敏感的服務查詢，此處的服務查詢也就是點查詢(point query)。和Clickhouse、Doris底層一樣，Holo也是使用C++實現(xiàn)，使用native方法，以及向量化引擎等提供更好的性能。

? ? ? ? 我們在實際的使用中，還發(fā)現(xiàn)Holo的硬掃的能力很強，幾百萬級別的數(shù)據(jù)，不需要要索引就很快返回。

? ?

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

如果對Holo的實現(xiàn)感興趣，文末附有Holo發(fā)表在vldb上的論文鏈接。

場景實踐

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

• 實時數(shù)據(jù)由Blink做實時ETL，寫入Hologres。

• 使用Hologres統(tǒng)一實時數(shù)據(jù)存儲。

• 基于Hologres和離線倉庫之上，提供統(tǒng)一數(shù)據(jù)服務，對接業(yè)務層的各種報表、分析系統(tǒng)等。

可以看到，整個架構主要有主要分為3個部分：數(shù)據(jù)服務、實時數(shù)倉和數(shù)據(jù)存儲。下面將會就這3個部分仔細講訴。

1.數(shù)據(jù)服務

? ? ? 主要基于Holo，我們做了一套對外提供的統(tǒng)一數(shù)據(jù)服務。從上面的架構圖可以看到，用戶提交的查詢請求到統(tǒng)一數(shù)據(jù)服務接口，經(jīng)過安全校驗解析、別名映射后，提交到Holo等執(zhí)行。

? ? ? 使用Holo為我們解決了兩個半問題。第一，相對于ADB，Holo很大程度上降低了存儲的成本。第二，Holo解決了數(shù)據(jù)存儲不統(tǒng)一的問題，同時提供了高性能的實時OLAP能力。第三：Holo提供了無需搬移數(shù)據(jù)，加速查詢離線數(shù)據(jù)的功能，但是由于是以資源消耗為代價，性能會比直接查詢Holo內部表差10倍，同時有較多的限制。所以，算是解決了半個問題。

? ? ? 然后，我們在數(shù)據(jù)服務接口做了更進一步的統(tǒng)一，數(shù)據(jù)服務接口以Holo為主，同時兼容一些歷史上存放在MySQL中的任務。對于特別復雜，同時對響應時長不敏感的查詢，也可以使用數(shù)據(jù)服務接口直接查詢離線數(shù)據(jù)。所以，我們希望數(shù)據(jù)服務接口是作為整個數(shù)據(jù)部門統(tǒng)一的數(shù)據(jù)服務，統(tǒng)一對外的所有數(shù)據(jù)接口。

? ? ? ? Blink任務修改后，可能會導致之前的狀態(tài)不可用，狀態(tài)清空，直接修改上線落表數(shù)據(jù)正確性會有影響。同時Holo大部分索引需要在建表時指定，如果一開始表設計不合理， 或者之前的表設計不再滿足現(xiàn)有需求。這時候物理表如果被寫入很多任務中，是很難修改的。所以我們設計了別名映射的mapping系統(tǒng)，mapping中會指定物理表，庫名、連接等信息，用戶只需要知道別名就可以使用，無需關心具體位置，同時別名是相對固定的。Blink修改任務時，可以新建任務寫到新建表，待補齊數(shù)據(jù)，借助推送系統(tǒng)，一鍵切換，立即生效，所有的查詢馬上切換到新物理表，線上業(yè)務無感知，類似于一個主備切換的過程。另外如果一旦發(fā)生較大改動，也可以在我們這邊控制。

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

2.實時數(shù)倉

? ? 實時數(shù)倉原始數(shù)據(jù)源來自日志數(shù)據(jù)和MySQL binlog訂閱，我們開發(fā)了數(shù)據(jù)訂閱平臺，通過平臺配置，將數(shù)據(jù)統(tǒng)一發(fā)送到Kafka中，使用Blink SQL做實時ETL。

? ? ? 在建模上，參考了離線的已有的數(shù)據(jù)模型，但是又不完全一樣，主要體現(xiàn)在分層和表字段設計，這是因為離線、實時數(shù)據(jù)的本身的屬性不同。離線每天拉取一次，一次性計算，跑一次，當天都可以一直使用，同時離線計算能力強，所以可以建設高內聚低耦合復雜的數(shù)據(jù)模型 ，使用邏輯下沉、復雜模型、完善分層和更完整維度抽象等方式，來更好的保障數(shù)據(jù)一致性和數(shù)據(jù)易用性。對外提供的也是聚合數(shù)據(jù)為主，明細為輔。

? ? ? 但是實時任務是24小時運行，更高的層級抽象意味著使用起來不靈活、鏈路長穩(wěn)定性差、維護代價大、時效性差等。

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

? ? ? 更重要的是，借助于Holo很好的實時OLAP性能，很多任務可以實時OLAP 現(xiàn)算，而不用針對具體任務加工具體的應用層數(shù)據(jù)，使用實時Join也不用做大寬表。這對效率的提升是巨大的。以前，很多實時需求需要專門寫實時加工任務，而且如果需求修改，修改實時任務的代價也是很大的，整個開發(fā)周期好幾天，現(xiàn)在可能使用統(tǒng)一數(shù)據(jù)服務接口，基于我們體系的數(shù)據(jù)建設，可能幾分鐘就可以交付了。目前實時OLAP是數(shù)據(jù)領域發(fā)展得比較快的一個模塊，很多公司依賴于開源Doris、Clickhouse等來實現(xiàn)，但是從完成度來講，Holo算是做得比較好的，不過是商業(yè)閉源軟件。

? ? ? 當然，也并不能過度的依賴于實時OLAP，在我們的最終實踐上，為了更高的效率和一定的數(shù)據(jù)一致性。我們預處理了部分比較固化的計算在聚合層，對外提供的數(shù)據(jù)，優(yōu)先使用固化的聚合層，對于比較靈活的查詢和不好固化的統(tǒng)計，使用明細層，總體來說，以明細為主，需求交付效率有較大提升。? ?

3.數(shù)據(jù)存儲

? ? ? Lambda架構不僅會導致了計算的冗余，也導致了存儲的冗余。而Kappa架構在目前的技術下，過于理想化。行業(yè)內還很少聽到有完全的Kappa架構落地的案例，目前主要是以Lambda為主，個別地方會做調整優(yōu)化的方式。

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

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

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

? ? ? 在實際使用中，我們測試對2億數(shù)據(jù)的點查大約在2s左右，官方給到的數(shù)據(jù)是，相比于內部表，外部表性能會差10倍，可以滿足一些對時效要求不高、查詢頻率不高的數(shù)據(jù)需求，在高時效性的任務這種性能表現(xiàn)可能不能滿足需求。

? ? ? 具體到我們的實踐上，對于一部分需要離線數(shù)據(jù)、對時效性要求不是特別高同時離線查詢分鐘級的響應時長不能滿足、查詢頻率不高的需求，我們會以外部表的形式對外提供，語法還是和Holo內表相同的語法，對于需要一部分離線數(shù)據(jù)、同時時效性要求很高、查詢頻率很高的查詢場景，我們選擇將一部分離線數(shù)據(jù)導入到Holo中，有時會和實時對應任務放在同一個表中，對外提供服務，這種做法事實上造成數(shù)據(jù)冗余，是一種妥協(xié)。

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

Hologres存在的一些問題

? ? ?Holo作為新生事物，基于新型的架構設計，提供了非常強大的性能。我們在測試和使用的過程中，也發(fā)現(xiàn)了一些不足之處。

• 目前Holo升級配置和版本需要停服，停服幾分鐘的時間，后續(xù)版本會解決，這個影響很大，要有預備。

• Holo gis 功能目前不支持索引，在大量數(shù)據(jù)下效率較低，我們測試2億數(shù)據(jù)下地理距離查詢大約幾秒鐘。目前索引功能開發(fā)中。

• Holo支持分區(qū)子表，有點類似于Hive的分區(qū)表，比較適合增量數(shù)據(jù)，在數(shù)據(jù)刪除和查詢上有一定的優(yōu)勢。但是目前每個分區(qū)子表必須手動提前建表，手動刪除。

• 資源隔離，在我們調研測試中，就發(fā)現(xiàn)Holo存在大查詢影響小查詢的響應時長問題，在后來的實測中，發(fā)現(xiàn)即使是大查詢沒有完全跑滿資源的情況，也會影響到小查詢的響應時長。這個問題在測試調研時就和Holo溝通過，我們的期望是有一個硬資源隔離，類似于yarn的資源隊列的形式，也已經(jīng)得到明顯答復后面會解決這個問題。由于我們很早就意識到這個問題，所以從一開始就做了很多措施來控制，目前還好。

• 在測試使用過程中，還發(fā)現(xiàn)一些小bug ，作為新產(chǎn)品，我們在享受便利的同時，也肯定會有一些不足的地方。

未來規(guī)劃

? ? ? ?Holo幫助我們實現(xiàn)在實時數(shù)據(jù)數(shù)據(jù)存儲方面，只使用一套存儲，在一定程度上緩解了數(shù)據(jù)不一致的問題，算是前進了一大步。但是更遠期來說，我們希望在未來可以徹底解決數(shù)據(jù)一致的問題，真正的讓一份數(shù)據(jù)只存儲在一個地方。

具體到眼前，我們的主要精力在系統(tǒng)的穩(wěn)定性、規(guī)范化沉淀、工具提效、并通過需求來完善我們的數(shù)據(jù)服務體系，更好的易用性、更強的穩(wěn)定性、更快的交付周期，會更多的在內部的建設上。

參考

Alibaba Hologres: A Cloud-Native Service ?for Hybrid ?Serving/Analytical Processing：http://www.vldb.org/pvldb/vol13/p3272-jiang.pdf

總結

以上是生活随笔為你收集整理的怎样不停请求接口实现实时刷新_快狗打车实时数仓和基于Hologres的数据服务建设...的全部內容，希望文章能夠幫你解決所遇到的問題。

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