站長資訊網(wǎng)郵政科學研究規(guī)劃院有限公司(以下簡稱“郵科院”)，作為中國郵政集團有限公司的科研智庫單位，專注于戰(zhàn)略規(guī)劃、企業(yè)管理、工程設計、物流裝備、智能終端、質(zhì)量檢測、標準化研究等領(lǐng)域，在助力中國郵政戰(zhàn)略轉(zhuǎn)型和經(jīng)營發(fā)展中發(fā)揮著重要支撐作用。
郵科院數(shù)據(jù)組負責全院大數(shù)據(jù)體系架構(gòu)的建設，支撐日常BI運營分析、科研數(shù)據(jù)產(chǎn)品、物流數(shù)據(jù)、網(wǎng)點畫像等業(yè)務場景。郵科院數(shù)據(jù)組通過使用DorisDB，統(tǒng)一了實時和離線的分析場景，替換了ClickHouse、Presto、MySQL等系統(tǒng)，解決了原有多套系統(tǒng)帶來的運維和使用復雜性，簡化了數(shù)據(jù)ETL流程，同時大幅提升OLAP、Adhoc等場景的查詢效率。本文主要介紹郵科院數(shù)據(jù)組基于新一代極速全場景MPP數(shù)據(jù)庫DorisDB，在數(shù)據(jù)服務體系和數(shù)據(jù)應用場景中的實踐和探索。
“作者：謝翔 郵政科學研究規(guī)劃院有限公司寄遞研究所數(shù)據(jù)組負責人，專注于數(shù)倉建設、數(shù)據(jù)分析等領(lǐng)域研究。”
一、業(yè)務背景
隨著科研數(shù)據(jù)積累越來越大，數(shù)據(jù)規(guī)模和體量也急劇膨脹。科研的原始數(shù)據(jù)通常來源于研報抽取、日志埋點文件、業(yè)務數(shù)據(jù)庫、三方接口等。過去通常基于CDH/Hadoop等大數(shù)據(jù)分布式計算框架和數(shù)據(jù)集成工具，構(gòu)建離線的數(shù)據(jù)倉庫，并對數(shù)據(jù)進行適當?shù)姆謱印⒔！⒓庸ず凸芾恚瑯?gòu)建各類分析主題。郵科院數(shù)據(jù)體系中沉淀了諸多研報主題數(shù)據(jù)，例如：電商流量數(shù)據(jù)，物流企業(yè)財務數(shù)據(jù)，行業(yè)報告相關(guān)的數(shù)據(jù)等。
上層數(shù)據(jù)應用對查詢的響應延遲和時效性要求高，會將數(shù)據(jù)通過數(shù)據(jù)同步工具同步到MySQL、ElasticSearch、Presto、HBase、ClickHouse等數(shù)據(jù)庫系統(tǒng)中，來支撐上層數(shù)據(jù)應用的查詢要求。
郵科院的大數(shù)據(jù)總體架構(gòu)如下圖所示，從下到上可以分為數(shù)據(jù)接入層、數(shù)據(jù)計算層、數(shù)據(jù)服務層和數(shù)據(jù)應用層。
數(shù)據(jù)計算層使用科研工作各分析場景下產(chǎn)生的模型/方案/業(yè)務的明細數(shù)據(jù)，進行離線數(shù)據(jù)計算，對TB級別的明細數(shù)據(jù)進行調(diào)度、聚合、計算，在數(shù)倉里沉淀出大量明細表、聚合表和最終的數(shù)據(jù)報表。
數(shù)據(jù)計算層生成的各類數(shù)據(jù)表，會同步到數(shù)據(jù)服務層，由數(shù)據(jù)服務層提供接口給數(shù)據(jù)應用層使用，滿足不同的數(shù)據(jù)業(yè)務需求。
二、業(yè)務痛點
數(shù)據(jù)服務層的愿景是開放數(shù)倉能力，建立統(tǒng)一的數(shù)據(jù)服務出口，針對不同的數(shù)據(jù)業(yè)務分析場景(數(shù)據(jù)規(guī)模、QPS、UDF支持、運維成本等)，原有架構(gòu)在底層使用了不同的查詢引擎：
·大數(shù)據(jù)量、低QPS：使用Hive、Presto、ClickHouse等基于Hadoop生態(tài)的離線批任務計算框架和MPP數(shù)據(jù)庫來解決。
·小數(shù)據(jù)量、高QPS：使用MySQL、ElasticSearch、HBase、MongoDB等關(guān)系型/非關(guān)系型數(shù)據(jù)庫來解決。
使用多套查詢引擎，我們遇到如下問題和挑戰(zhàn)：
·離線/實時ETL任務過多，處理邏輯大部分為簡單聚合/去重，聚合表數(shù)量龐大，導致運營和運維上的成本增加;
·針對中等數(shù)據(jù)量、中等QPS的查詢場景，如何能兼顧數(shù)據(jù)規(guī)模的同時，有較友好的查詢響應延遲;
·大數(shù)據(jù)量下插入、更新的實時數(shù)據(jù)場景無法得到支持，例如：網(wǎng)點畫像、實時數(shù)據(jù)導入、郵路路徑、研報數(shù)據(jù)匯總等。
三、OLAP引擎選型
針對如上的問題和挑戰(zhàn)，我們的目標是尋求盡可能少的OLAP引擎，利用在明細表上現(xiàn)場計算來解決ETL任務、數(shù)倉表過多問題，同時需要兼顧在數(shù)據(jù)規(guī)模、查詢QPS、響應耗時、查詢場景方面的權(quán)衡。
目前市面上OLAP引擎百花齊放，諸如Impala、Druid、ClickHouse、DorisDB。經(jīng)過一番調(diào)研，我們最終選擇了DorisDB。DorisDB是基于MPP架構(gòu)的分析型數(shù)據(jù)庫，自帶數(shù)據(jù)存儲，整合了大數(shù)據(jù)框架的優(yōu)勢，支持主鍵更新、支持現(xiàn)代化物化視圖、支持高并發(fā)和高吞吐的即席查詢等諸多優(yōu)點，天然能解決我們上述的問題。
四、DorisDB應用實踐
DorisDB已經(jīng)投入生產(chǎn)環(huán)境，主要作為離線/實時數(shù)據(jù)的OLAP數(shù)據(jù)庫使用。離線數(shù)據(jù)主要存儲于HDFS中，通過DataX任務批量同步數(shù)據(jù)到DorisDB;另一部分實時數(shù)據(jù)主要存儲于Kafka中，使用DorisDB的routine load功能實時將數(shù)據(jù)從kafka寫入到DorisDB。
在沒有引入DorisDB之前，我們使用的底層引擎是MySQL、Presto on HDFS和ClickHouse等系統(tǒng)，對明細表/聚合表進行查詢。這幾種方式都存在著不少問題：
·MySQL處理上億規(guī)模的數(shù)據(jù)，無論使用分庫分表、分區(qū)表、集群化部署的PolarDB方案，都會存在慢查詢、數(shù)據(jù)庫扛不住、運維困難的窘境;
·Presto on HDFS的方案更偏向于分析型數(shù)據(jù)業(yè)務，雖然能存儲海量的數(shù)據(jù)，計算能力不錯，唯一致命的在于無法滿足在線業(yè)務的高吞吐QPS，查詢比較難做到毫秒級。
·ClickHouse對Join支持較弱，通常使用大寬表建模，不夠靈活，另外運維也比較復雜。
·在引入DorisDB替換MySQL、Presto和ClickHouse后，DorisDB帶來的業(yè)務效果如下：
·支撐了在線報表查詢+數(shù)據(jù)分析業(yè)務，服務于對內(nèi)運營+對外行業(yè)分析的數(shù)據(jù)產(chǎn)品，報表業(yè)務查詢大部分耗時在毫秒級別，分析型業(yè)務查詢大部分耗時在秒級別;
·支持10億規(guī)模的明細表查詢，月、季、年等維度統(tǒng)計數(shù)據(jù)現(xiàn)場算聚合統(tǒng)計、精準去重等，查詢耗時都能控制在500ms以內(nèi);
·千萬級別的多表的Join和union查詢，經(jīng)過Colocate Join特性優(yōu)化，查詢響應在秒級。
另外，我們還將DorisDB應用到實時數(shù)據(jù)分析場景，DorisDB在實時數(shù)據(jù)分析主要有如下優(yōu)勢：
·實時寫入性能：目前DorisDB支持HTTP方式的Stream Load，可以自定義的分鐘級別微批寫入，以及Routine Load功能，可以將Kafka的數(shù)據(jù)實時同步到DorisDB中，滿足當前實時數(shù)據(jù)分析業(yè)務;
·統(tǒng)一離線和實時分析：實時數(shù)據(jù)和離線數(shù)據(jù)更好的在DorisDB中進行融合，靈活支撐應用，數(shù)據(jù)存儲策略通過DorisDB動態(tài)分區(qū)的功能進行自動管理;
·SQL Online Serving：高效的SQL即席查詢能力，能夠兼容業(yè)界標準的SQL規(guī)范，支撐業(yè)務靈活復雜的訪問，提高取數(shù)開發(fā)的效率。
五、總結(jié)和規(guī)劃
郵科院數(shù)據(jù)組引入DorisDB生產(chǎn)集群，解決了數(shù)據(jù)服務層單表億級別規(guī)模、高QPS數(shù)據(jù)場景下引擎的空白，直接開放明細表準實時查詢的能力，給各項目組上層數(shù)據(jù)業(yè)務和BI系統(tǒng)提供了更多的選擇和自由度，同時將大大減少數(shù)倉中大量ETL任務、聚合表、報表，降低了數(shù)倉ETL的運維壓力和維護成本，DorisDB綜合性價比較原有的MySQL、Presto、ClickHouse等同類產(chǎn)品提升數(shù)倍以上。
未來，郵科院在DorisDB的應用和實踐上還有不少規(guī)劃：
·除了unique和duplicate數(shù)據(jù)模型，未來會將符合的數(shù)據(jù)場景遷移至aggregation模型，并使用物化視圖，進一步降低數(shù)倉開發(fā)維護成本，降低查詢延遲;
·DorisDB on ES的功能也值得我們深挖和探索，解決原生ES集群無法支持跨索引Join的能力;
·更多數(shù)據(jù)應用層的場景接入DorisDB，例如網(wǎng)點畫像服務、郵路路徑分析等，將進一步拓展DorisDB在實時數(shù)據(jù)寫入、批量數(shù)據(jù)更新場景中的應用;
·與科研數(shù)據(jù)分析平臺、數(shù)倉平臺深度打通，完善數(shù)據(jù)整體架構(gòu)，作為數(shù)據(jù)團隊的基礎(chǔ)設施去保障穩(wěn)定性和服務;
·考慮使用多云架構(gòu)，自主可控的數(shù)倉架構(gòu)可以靈活的在多云間切換遷移，降低單一云廠商的依賴，控制成本提高可用性。
·……
最后的最后，感謝DorisDB技術(shù)團隊給予的熱情、靠譜的答疑解惑和技術(shù)支持!!!
特別提醒：本網(wǎng)信息來自于互聯(lián)網(wǎng)，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實，對本文以及其中全部或者部分內(nèi)容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關(guān)內(nèi)容。本站不承擔此類作品侵權(quán)行為的直接責任及連帶責任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益，請及時聯(lián)系我們，本站將會在24小時內(nèi)處理完畢。
