李軍

關(guān)鍵詞： 輕量化大數(shù)據(jù)架構(gòu) MPP 數(shù)據(jù)庫 數(shù)據(jù)任務(wù)調(diào)度 數(shù)據(jù)接入

中圖分類號(hào)： TP392 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 1672-3791（2023）15-0062-04

1 常用大數(shù)據(jù)架構(gòu)

與傳統(tǒng)數(shù)據(jù)分析一樣，大數(shù)據(jù)信息時(shí)代首先要考慮的就是數(shù)據(jù)存儲(chǔ)問題[1]，其次是數(shù)據(jù)的計(jì)算問題。在Hadoop 生態(tài)中，包含數(shù)十種大數(shù)據(jù)存儲(chǔ)和計(jì)算相關(guān)組件，如HDFS、Yarn、Hive、HBase、Presto、Azkaban、Spark、Flink、Flume 等。在不同業(yè)務(wù)場景中，通過不同組件的組合來滿足多樣的需求。在Hadoop 生態(tài)大數(shù)據(jù)架構(gòu)中，常見的架構(gòu)有如下幾種。

1.1 離線計(jì)算架構(gòu)

應(yīng)用Hadoop（HDFS、YARN、MapReduce、Hive 等）的存儲(chǔ)和計(jì)算能力來替代傳統(tǒng)的BI 組件，實(shí)現(xiàn)大數(shù)據(jù)的ETL 批處理計(jì)算。該架構(gòu)的優(yōu)點(diǎn)是能夠處理海量的大數(shù)據(jù)，支持?jǐn)?shù)據(jù)重播和歷史統(tǒng)計(jì)，缺點(diǎn)是缺乏實(shí)時(shí)的支撐。

1.2 流式架構(gòu)

通過流式計(jì)算（Spark、Flink 等）實(shí)時(shí)對(duì)數(shù)據(jù)流進(jìn)行分析。此架構(gòu)的優(yōu)點(diǎn)是數(shù)據(jù)的實(shí)效性非常高，缺點(diǎn)是對(duì)于數(shù)據(jù)的重播和歷史統(tǒng)計(jì)無法很好的支撐。

1.3 Lamda架構(gòu)

實(shí)時(shí)和離線分別處理，最后統(tǒng)一對(duì)外提供服務(wù)，但在使用過程中，需要維護(hù)兩套代碼[2]。此架構(gòu)的優(yōu)點(diǎn)是能夠同時(shí)滿足實(shí)時(shí)計(jì)算和離線計(jì)算的需求，缺點(diǎn)是架構(gòu)復(fù)雜，開發(fā)周期長，可能出現(xiàn)實(shí)時(shí)與批量計(jì)算結(jié)果不一致等問題。

1.4 Kappa 架構(gòu)

改進(jìn)流計(jì)算系統(tǒng)來解決數(shù)據(jù)全量處理的問題，使實(shí)時(shí)計(jì)算和批處理過程使用同一套代碼。Kappa 架構(gòu)，解決了代碼維護(hù)和一致性問題，但是在kafka 里進(jìn)行各種邏輯計(jì)算，邏輯越來越復(fù)雜，有數(shù)據(jù)不一致的問題[2]。

1.5 Unifield 架構(gòu)

對(duì)Lamda 進(jìn)行了改造，將機(jī)器學(xué)習(xí)和數(shù)據(jù)處理揉為一體。該架構(gòu)的優(yōu)點(diǎn)是提供了一套數(shù)據(jù)分析和機(jī)器學(xué)習(xí)結(jié)合的架構(gòu)方案，缺點(diǎn)是實(shí)施復(fù)雜度較高。

以上幾種大數(shù)據(jù)架構(gòu)，雖然在不同程度能夠滿足實(shí)時(shí)計(jì)算和離線計(jì)算的需求，但是其架構(gòu)都有一定的復(fù)雜性。以上述5 種架構(gòu)中最簡單的離線計(jì)算架構(gòu)為例，部署一個(gè)簡單的離線計(jì)算架構(gòu)的大數(shù)據(jù)環(huán)境至少需要部署24 個(gè)Java 組件節(jié)點(diǎn)，如圖1 所示。按照平均一個(gè)節(jié)點(diǎn)需4 G 內(nèi)存計(jì)算，則至少需要96 G 內(nèi)存。由于Hadoop 生態(tài)的大數(shù)據(jù)架構(gòu)比較耗費(fèi)資源，且架構(gòu)復(fù)雜，導(dǎo)致實(shí)施Hadoop 大數(shù)據(jù)架構(gòu)的人力、財(cái)力成本較高，很多中小型的項(xiàng)目因此棄用Hadoop 大數(shù)據(jù)技術(shù)。

2 輕量化大數(shù)據(jù)架構(gòu)特性

大部分企業(yè)應(yīng)用中的大數(shù)據(jù)容量規(guī)模在1 TB～10 PB之間。對(duì)于這些容量規(guī)模不大的大數(shù)據(jù)應(yīng)用，應(yīng)用Hadoop架構(gòu)比較耗費(fèi)資源，且在實(shí)時(shí)計(jì)算業(yè)務(wù)場景中需要較大開發(fā)工作量。因此，輕量化的大數(shù)據(jù)架構(gòu)，在中小型項(xiàng)目中有較大需求。

為滿足企業(yè)應(yīng)用中大部分的大數(shù)據(jù)需求，本文研究的輕量化大數(shù)據(jù)組件主要滿足以下特性：（1）部署的組件盡量少，組件占用資源盡量低；（2）支持可配置的數(shù)據(jù)接入；（3）支持可配置的ETL 計(jì)算；（4）支持準(zhǔn)實(shí)時(shí)計(jì)算；（5）支持秒級(jí)DWD、DWS 層數(shù)據(jù)查詢；（6）支持TB 級(jí)到10 PB 級(jí)別的數(shù)據(jù)存儲(chǔ)和計(jì)算。

3 輕量化大數(shù)據(jù)架構(gòu)實(shí)現(xiàn)方案

3.1 概述

在滿足企業(yè)大數(shù)據(jù)需求的同時(shí)，主要從部署架構(gòu)輕量化、開發(fā)架構(gòu)輕量化兩方面來設(shè)計(jì)企業(yè)級(jí)輕量化大數(shù)據(jù)架構(gòu)。其中，部署架構(gòu)輕量化是指部署的組件盡量少、占用的CPU、內(nèi)存等資源盡量低；開發(fā)架構(gòu)輕量化是指通過少量代碼開發(fā)即可實(shí)現(xiàn)企業(yè)大數(shù)據(jù)業(yè)務(wù)需求。具體實(shí)現(xiàn)方案為：首先，在核心的大數(shù)據(jù)計(jì)算和存儲(chǔ)層面，采用輕量級(jí)的MPP 數(shù)據(jù)庫（Apache Doris）替代Hadoop 技術(shù)，滿足企業(yè)級(jí)別TB 級(jí)到PB 級(jí)別數(shù)據(jù)到存儲(chǔ)及準(zhǔn)實(shí)時(shí)計(jì)算能力；其次，設(shè)計(jì)并研發(fā)任務(wù)調(diào)度和開發(fā)管理一體的輕量化組件，實(shí)現(xiàn)企業(yè)常用大數(shù)據(jù)開發(fā)管理業(yè)務(wù)。

輕量化大數(shù)據(jù)架構(gòu)最低僅需要部署9 個(gè)組件節(jié)點(diǎn)（其中包括3個(gè)C語言開發(fā)的組件、6個(gè)Java組件），按照平均一個(gè)節(jié)點(diǎn)4 G 內(nèi)存計(jì)算，則最少需要36 G 內(nèi)存，具體見圖2。對(duì)比前面所述的傳統(tǒng)簡單離線計(jì)算架構(gòu)，輕量化架構(gòu)可以減少15個(gè)組件節(jié)點(diǎn)，折合減少60 G內(nèi)存。

3.2 輕量化存儲(chǔ)計(jì)算引擎

MPP（—種海量數(shù)據(jù)實(shí)時(shí)分析架構(gòu)）是通過一定的互聯(lián)網(wǎng)節(jié)點(diǎn)連接多個(gè)SMP（對(duì)稱多處理）服務(wù)器協(xié)同完成工作任務(wù)。MPP 數(shù)據(jù)庫將任務(wù)并行地分散到多個(gè)服務(wù)器和節(jié)點(diǎn)上，在每個(gè)節(jié)點(diǎn)計(jì)算完成后，將各自的結(jié)果匯總在一起從而得到最終結(jié)果[3]。ClickHouse 等列式數(shù)據(jù)庫從某種意義上來說，也是一類NoSQL 數(shù)據(jù)庫，但鑒于列式數(shù)據(jù)庫本身的獨(dú)特性，與MongoDB、Redis 等有很大不同，所以可以視為另外一種單獨(dú)的解決方案。在很多場景下，比Hadoop、Spark 技術(shù)棧具有更高的性能更小的系統(tǒng)資源開銷[4]。對(duì)于新型數(shù)倉中實(shí)時(shí)性要求高的統(tǒng)計(jì)分析業(yè)務(wù)中，使用MPP 存儲(chǔ)通常較為合理[5]。因此，在存儲(chǔ)計(jì)算層，采用輕量的MPP 數(shù)據(jù)庫替代Hadoop。目前，主流的MPP 數(shù)據(jù)庫有Apache Doris、ClickHouse、Greenplum 等。由于Apache Doris 使用更簡單、運(yùn)維更簡單、分布式更強(qiáng)、SQL 支持更好、國內(nèi)技術(shù)支持更好，因此選用Apache Doris 來搭建輕量化大數(shù)據(jù)架構(gòu)。

Apache Doris 數(shù)據(jù)庫和Hadoop 技術(shù)對(duì)比，存在以下優(yōu)勢(shì)：（1）Doris 所需部署的組件數(shù)量更低，占用CPU內(nèi)存資源更少；（2）Doris 數(shù)據(jù)庫核心的Backends 組件采用C 語言開發(fā)，運(yùn)行性能更好，占用內(nèi)存更低；（3）Doris 數(shù)據(jù)庫的結(jié)構(gòu)化數(shù)據(jù)批量寫入性能更好，支持200～300 MB/s 的結(jié)構(gòu)化數(shù)據(jù)批量寫入（在Hadoop 生態(tài)中結(jié)構(gòu)化數(shù)據(jù)的實(shí)時(shí)寫入和在線分析需要引入Hbase、Hive、Presto 等組件，部署架構(gòu)比較復(fù)雜，耗費(fèi)CPU、內(nèi)存資源也更多）；（4）Doris 數(shù)據(jù)庫原生為數(shù)據(jù)分析設(shè)計(jì)的Aggregate、Uniq、Duplicate 等模型，能很好的支撐企業(yè)應(yīng)用中的數(shù)據(jù)分析場景；（5）Doris 數(shù)據(jù)庫在大數(shù)據(jù)量、多表join、聚合查詢等場景下的性能優(yōu)于Hadoop 生態(tài)中的組件；（6）Doris 數(shù)據(jù)庫原生對(duì)Kafka 數(shù)據(jù)導(dǎo)入、Mysql 數(shù)據(jù)庫同步等支持較好，不需要部署額外組件即可實(shí)現(xiàn)常用的數(shù)據(jù)集成工作；（7）Doris 數(shù)據(jù)庫處理結(jié)構(gòu)化數(shù)據(jù)優(yōu)于Hadoop，企業(yè)應(yīng)用中大部分?jǐn)?shù)據(jù)也為結(jié)構(gòu)化數(shù)據(jù)，因此Doris 更適合企業(yè)應(yīng)用中大部分的結(jié)構(gòu)化數(shù)據(jù)需求；（8）大部分企業(yè)應(yīng)用的數(shù)據(jù)量在PB 級(jí)別以內(nèi)，Doris 數(shù)據(jù)庫能夠較好地支撐10 PB 內(nèi)的數(shù)據(jù)分析。

3.3 輕量化任務(wù)調(diào)度及開發(fā)管理組件

數(shù)據(jù)管理應(yīng)主要包含數(shù)據(jù)導(dǎo)入、數(shù)據(jù)清洗和數(shù)據(jù)治理3 個(gè)方面[6]。一體化輕量管理組件將大數(shù)據(jù)分析中常用的數(shù)據(jù)管理功能（如任務(wù)調(diào)度、庫表管理、SQL開發(fā)、Kafka 數(shù)據(jù)接入、關(guān)系數(shù)據(jù)庫接入等）整合到一起，實(shí)現(xiàn)單應(yīng)用、單進(jìn)程輕量化部署與應(yīng)用。一體化輕量管理組件的主要功能如下。

（1）任務(wù)調(diào)度。任務(wù)調(diào)度組件支持SQL 計(jì)算任務(wù)調(diào)度即可滿足大部分的企業(yè)應(yīng)用需求，且大部分企業(yè)應(yīng)用中的調(diào)度任務(wù)較少，因此調(diào)度組件的摒棄DolphinScheduler、Azkaban 等較重的架構(gòu)，開發(fā)單應(yīng)用架構(gòu)的輕量化任務(wù)調(diào)度組件。

（2）庫表管理。開發(fā)Doris 數(shù)據(jù)庫的庫/表元數(shù)據(jù)管理、數(shù)據(jù)預(yù)覽功能。

（3）SQL 開發(fā)。支撐在線的Doris sql 編輯、執(zhí)行、結(jié)果顯示等功能。

（4）Kafka 數(shù)據(jù)接入。支撐在線的Doris RoutineLoad 配置、管理、監(jiān)控等功能。

（5）關(guān)系數(shù)據(jù)庫接入。支持在線的Doris Sync Job配置、管理、監(jiān)控等功能。

3.4 總體架構(gòu)

輕量化大數(shù)據(jù)架構(gòu)支持多種類型的業(yè)務(wù)數(shù)據(jù)接入，包括mysql 業(yè)務(wù)數(shù)據(jù)庫、其他非數(shù)據(jù)庫中的業(yè)務(wù)數(shù)據(jù)。對(duì)于數(shù)據(jù)庫中的業(yè)務(wù)數(shù)據(jù)，可以借助Canal、DataX等組件實(shí)時(shí)或定時(shí)接入Doris 存儲(chǔ)；對(duì)于非數(shù)據(jù)庫中的業(yè)務(wù)數(shù)據(jù)，可以接入Kafa 中，再借助Doris Routine Load技術(shù)實(shí)時(shí)存儲(chǔ)到Doris。一體化輕量管理組件負(fù)責(zé)為開發(fā)人員提供便捷的任務(wù)調(diào)度、庫表管理、SQL 開發(fā)、數(shù)據(jù)接入等常用服務(wù)。總體架構(gòu)如圖3 所示。

4 應(yīng)用場景分析

4.1 適用場景

本文所述對(duì)輕量化大數(shù)據(jù)架構(gòu)適用于以下場景：（1）對(duì)結(jié)構(gòu)化或半結(jié)構(gòu)化的數(shù)據(jù)做大數(shù)據(jù)分析，數(shù)據(jù)量規(guī)模在1 TB 到10 PB 范圍；（2）準(zhǔn)實(shí)時(shí)計(jì)算或離線計(jì)算的業(yè)務(wù)場景；（3）結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)寫入和查詢性能要求較高的業(yè)務(wù)場景；（4）ETL 計(jì)算不是特別復(fù)雜的業(yè)務(wù)場景（即能夠通過SQL 計(jì)算，且單次數(shù)據(jù)計(jì)算規(guī)模為GB 級(jí)別）。

4.2 不適用場景

本文所述對(duì)輕量化大數(shù)據(jù)組件在以下場景中不太適用：（1）實(shí)時(shí)性要求比較高的復(fù)雜業(yè)務(wù)場景；（2）數(shù)據(jù)量超過10 PB 以上等業(yè)務(wù)場景；（3）非結(jié)構(gòu)化數(shù)據(jù)分析的業(yè)務(wù)場景；（4）ELT 計(jì)算數(shù)量很大的業(yè)務(wù)場景。

4.3 應(yīng)用場景擴(kuò)展

應(yīng)用此輕量化大數(shù)據(jù)架構(gòu)，能夠滿足企業(yè)大部分大數(shù)據(jù)存儲(chǔ)、計(jì)算需求。對(duì)一些特殊等需求，可以在此架構(gòu)基礎(chǔ)上擴(kuò)展。

（1）對(duì)于實(shí)時(shí)性要求高的復(fù)雜業(yè)務(wù)場景，如秒級(jí)別帶滑動(dòng)窗口的大數(shù)據(jù)實(shí)時(shí)計(jì)算，需要額外引入flink 等實(shí)時(shí)計(jì)算組件。

（2）對(duì)于總數(shù)據(jù)量10 PB 以上或單次ETL 計(jì)算數(shù)據(jù)量很大業(yè)務(wù)場景，需要引入Hadoop 的HDFS 和Hive等組件。

（3）對(duì)于人工智能場景，需要額外引入TensorFlow等AI 計(jì)算組件。

4.4 最佳實(shí)踐

（1）如果原始數(shù)據(jù)比較大，可以在數(shù)據(jù)架構(gòu)設(shè)計(jì)中刪除或縮減原始數(shù)據(jù)的存儲(chǔ)，Doris 中僅存儲(chǔ)計(jì)算結(jié)果數(shù)據(jù)，避免存儲(chǔ)規(guī)模過大。

（2）對(duì)于單次ETL 數(shù)據(jù)量較大的場景，可以把大量數(shù)據(jù)的計(jì)算拆分成多個(gè)中小規(guī)模數(shù)據(jù)量的計(jì)算，來實(shí)現(xiàn)計(jì)算大數(shù)據(jù)量的需求。

（3）對(duì)于任務(wù)量較多的ETL 離線計(jì)算，盡量把不同批次的計(jì)算任務(wù)拆分到不同時(shí)間段執(zhí)行。避免同一時(shí)間段執(zhí)行段任務(wù)太多，導(dǎo)致Doris 內(nèi)存溢出。

5 結(jié)語

在企業(yè)應(yīng)用中，大部分是結(jié)構(gòu)化或半結(jié)構(gòu)化的數(shù)據(jù)做分析，數(shù)據(jù)規(guī)?；径荚?0 PB 范圍內(nèi)，因此實(shí)施輕量化的大數(shù)據(jù)組件能滿足企業(yè)大部分的準(zhǔn)實(shí)時(shí)和離線計(jì)算業(yè)務(wù)場景。如果企業(yè)數(shù)據(jù)規(guī)模在10 PB 范圍內(nèi)，實(shí)施輕量化大數(shù)據(jù)架構(gòu)能幫忙企業(yè)減少40%～60%的系統(tǒng)資源，同時(shí)基于一體化輕量組件和Doris 易用的Routine Load、Sync job 等功能，幫助企業(yè)快速實(shí)現(xiàn)大數(shù)據(jù)業(yè)務(wù)的開發(fā)，減少企業(yè)人力、財(cái)力成本。