中國郵政郵科院 X DorisDB:統一OLAP平臺,大幅降低運維成本

語言: CN / TW / HK

郵政科學研究規劃院有限公司(以下簡稱“郵科院”),作為中國郵政集團有限公司的科研智庫單位,專注於戰略規劃、企業管理、工程設計、物流裝備、智慧終端、質量檢測、標準化研究等領域,在助力中國郵政戰略轉型和經營發展中發揮著重要支撐作用。

郵科院資料組負責全院大資料體系架構的建設,支撐日常BI運營分析、科研資料產品、物流資料、網點畫像等業務場景。郵科院資料組通過使用DorisDB,統一了實時和離線的分析場景,替換了ClickHouse、Presto、MySQL等系統,解決了原有多套系統帶來的運維和使用複雜性,簡化了資料ETL流程,同時大幅提升OLAP、Adhoc等場景的查詢效率。本文主要介紹郵科院資料組基於新一代極速全場景MPP資料庫DorisDB,在資料服務體系和資料應用場景中的實踐和探索。


“   作者:謝翔
   郵政科學研究規劃院有限公司寄遞研究所資料組負責人,專注於數倉建設、資料分析等領域研究。  



業務背景


隨著科研資料積累越來越大,資料規模和體量也急劇膨脹。科研的原始資料通常來源於研報抽取、日誌埋點檔案、業務資料庫、三方介面等。過去通常基於CDH/Hadoop等大資料分散式計算框架和資料整合工具,構建離線的資料倉庫,並對資料進行適當的分層、建模、加工和管理,構建各類分析主題。郵科院資料體系中沉澱了諸多研報主題資料,例如:電商流量資料,物流企業財務資料,行業報告相關的資料等。

上層資料應用對查詢的響應延遲和時效性要求高,會將資料通過資料同步工具同步到MySQL、ElasticSearch、Presto、HBase、ClickHouse等資料庫系統中,來支撐上層資料應用的查詢要求。

郵科院的大資料總體架構如下圖所示,從下到上可以分為資料接入層、資料計算層、資料服務層和資料應用層。

資料計算層使用科研工作各分析場景下產生的模型/方案/業務的明細資料,進行離線資料計算,對TB級別的明細資料進行排程、聚合、計算,在數倉裡沉澱出大量明細表、聚合表和最終的資料報表。

資料計算層生成的各類資料表,會同步到資料服務層,由資料服務層提供介面給資料應用層使用,滿足不同的資料業務需求。


業務痛點


資料服務層的願景是開放數倉能力,建立統一的資料服務出口,針對不同的資料業務分析場景(資料規模、QPS、UDF支援、運維成本等),原有架構在底層使用了不同的查詢引擎:

  • 大資料量、低QPS:使用Hive、Presto、ClickHouse等基於Hadoop生態的離線批任務計算框架和MPP資料庫來解決。

  • 小資料量、高QPS:使用MySQL、ElasticSearch、HBase、MongoDB等關係型/非關係型資料庫來解決。

使用多套查詢引擎,我們遇到如下問題和挑戰:

  • 離線/實時ETL任務過多,處理邏輯大部分為簡單聚合/去重,聚合表數量龐大,導致運營和運維上的成本增加;

  • 針對中等資料量、中等QPS的查詢場景,如何能兼顧資料規模的同時,有較友好的查詢響應延遲;

  • 大資料量下插入、更新的實時資料場景無法得到支援,例如:網點畫像、實時資料匯入、郵路路徑、研報資料彙總等。


OLAP引擎選型


針對如上的問題和挑戰,我們的目標是尋求儘可能少的OLAP引擎,利用在明細表上現場計算來解決ETL任務、數倉表過多問題,同時需要兼顧在資料規模、查詢QPS、響應耗時、查詢場景方面的權衡。

目前市面上OLAP引擎百花齊放,諸如Impala、Druid、ClickHouse、DorisDB。經過一番調研,我們最終選擇了DorisDB。DorisDB是基於MPP架構的分析型資料庫,自帶資料儲存,整合了大資料框架的優勢,支援主鍵更新、支援現代化物化檢視、支援高併發和高吞吐的即席查詢等諸多優點,天然能解決我們上述的問題。


DorisDB應用實踐


DorisDB已經投入生產環境,主要作為離線/實時資料的OLAP資料庫使用。離線資料主要儲存於HDFS中,通過DataX任務批量同步資料到DorisDB;另一部分實時資料主要儲存於Kafka中,使用DorisDB的routine load功能實時將資料從kafka寫入到DorisDB。

在沒有引入DorisDB之前,我們使用的底層引擎是MySQL、Presto on HDFS和ClickHouse等系統,對明細表/聚合表進行查詢。這幾種方式都存在著不少問題:

  • MySQL處理上億規模的資料,無論使用分庫分表、分割槽表、叢集化部署的PolarDB方案,都會存在慢查詢、資料庫扛不住、運維困難的窘境;

  • Presto on HDFS的方案更偏向於分析型資料業務,雖然能儲存海量的資料,計算能力不錯,唯一致命的在於無法滿足線上業務的高吞吐QPS,查詢比較難做到毫秒級。

  • ClickHouse對Join支援較弱,通常使用大寬表建模,不夠靈活,另外運維也比較複雜。

在引入DorisDB替換MySQL、Presto和ClickHouse後,DorisDB帶來的業務效果如下:

  • 支撐了線上報表查詢+資料分析業務,服務於對內運營+對外行業分析的資料產品,報表業務查詢大部分耗時在毫秒級別,分析型業務查詢大部分耗時在秒級別;

  • 支援10億規模的明細表查詢,月、季、年等維度統計資料現場算聚合統計、精準去重等,查詢耗時都能控制在500ms以內;

  • 千萬級別的多表的Join和union查詢,經過Colocate Join特性優化,查詢響應在秒級。

另外,我們還將DorisDB應用到實時資料分析場景, DorisDB在實時資料分析主要有如下優勢:

  • 實時寫入效能:目前DorisDB支援HTTP方式的 Stream Load,可以自定義的分鐘級別微批寫入,以及Routine Load功能,可以將Kafka 的資料實時同步到DorisDB中,滿足當前實時資料分析業務;

  • 統一離線和實時分析:實時資料和離線資料更好的在DorisDB中進行融合,靈活支撐應用,資料儲存策略通過DorisDB動態分割槽的功能進行自動管理;

  • SQL Online Serving:高效的SQL即席查詢能力,能夠相容業界標準的SQL規範,支撐業務靈活複雜的訪問,提高取數開發的效率。


總結和規劃

郵科院資料組引入DorisDB生產叢集,解決了資料服務層單表億級別規模、高QPS資料場景下引擎的空白,直接開放明細表準實時查詢的能力,給各專案組上層資料業務和BI系統提供了更多的選擇和自由度,同時將大大減少數倉中大量ETL任務、聚合表、報表,降低了數倉ETL的運維壓力和維護成本,DorisDB綜合性價比較原有的MySQL、Presto、ClickHouse等同類產品提升數倍以上。

未來,郵科院在DorisDB的應用和實踐上還有不少規劃:

  • 除了unique和duplicate資料模型,未來會將符合的資料場景遷移至aggregation模型,並使用物化檢視,進一步降低數倉開發維護成本,降低查詢延遲;

  • DorisDB on ES的功能也值得我們深挖和探索,解決原生ES叢集無法支援跨索引Join的能力;

  • 更多資料應用層的場景接入DorisDB,例如網點畫像服務、郵路路徑分析等,將進一步拓展DorisDB在實時資料寫入、批量資料更新場景中的應用;

  • 與科研資料分析平臺、數倉平臺深度打通,完善資料整體架構,作為資料團隊的基礎設施去保障穩定性和服務;

  • 考慮使用多雲架構,自主可控的數倉架構可以靈活的在多雲間切換遷移,降低單一雲廠商的依賴,控制成本提高可用性。

  • ......



最後的最後,感謝DorisDB技術團隊給予的熱情、靠譜的答疑解惑和技術支援!!!另外,郵科院資料組熱烈歡迎對資料分析感興趣的同學傳送簡歷到:[email protected]

END



八千里路雲和月 | 從零到大資料專家學習路徑指南

Kafka原始碼閱讀的一些小提示

我們在學習Flink的時候,到底在學習什麼?

193篇文章暴揍Flink,這個合集你需要關注一下

Flink生產環境TOP難題與優化,阿里巴巴藏經閣YYDS

Flink CDC我吃定了耶穌也留不住他!| Flink CDC線上問題小盤點

我們在學習Spark的時候,到底在學習什麼?

在所有Spark模組中,我願稱SparkSQL為最強!

硬剛Hive | 4萬字基礎調優面試小總結

資料治理方法論和實踐小百科全書

標籤體系下的使用者畫像建設小指南

4萬字長文 | ClickHouse基礎&實踐&調優全視角解析

【面試&個人成長】2021年過半,社招和校招的經驗之談

大資料方向另一個十年開啟 |《硬剛系列》第一版完結

我寫過的關於成長/面試/職場進階的文章

當我們在學習Hive的時候在學習什麼?「硬剛Hive續集」


你好,我是王知無,一個大資料領域的硬核原創作者。

做過後端架構、資料中介軟體、資料平臺&架構、演算法工程化。

專注大資料領域實時動態&技術提升&個人成長&職場進階,歡迎關注。

本文分享自微信公眾號 - 大資料技術與架構(import_bigdata)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。