科技行業(yè)：Apache Doris在任子行的應(yīng)用實踐

孔繁藝高級研發(fā)工程師01背景介紹02架構(gòu)演進03企業(yè)實踐04總結(jié)規(guī)劃01背景介紹1-1公司介紹任子行網(wǎng)絡(luò)技術(shù)股份有限公司成立于2000年5月，2012年4月，在深圳證券交易所創(chuàng)業(yè)板正式掛牌上市，是國內(nèi)網(wǎng)絡(luò)安全行業(yè)領(lǐng)軍企業(yè)，致力于成為國內(nèi)領(lǐng)先的“網(wǎng)絡(luò)空間數(shù)據(jù)治理專家”。業(yè)務(wù)涵蓋網(wǎng)絡(luò)安全、公共安全、信息安全、運營商網(wǎng)絡(luò)資源安全、終端安全、5G數(shù)據(jù)安全、工業(yè)互聯(lián)網(wǎng)安全等眾多領(lǐng)域，是國家重大活動網(wǎng)絡(luò)安全服務(wù)支撐單位，也為“一帶一路”海外友好國家政府提供網(wǎng)絡(luò)安全解決方案。1-2早期業(yè)務(wù)架構(gòu)數(shù)據(jù)采集KafkaAlgoServerSparkStreammingHBaseElasticsearch輿情應(yīng)用APP數(shù)據(jù)采集KafkaAlgoServerSparkStreammingHBaseElasticsearch輿情應(yīng)用APP1-3背景介紹無法二次分析數(shù)據(jù)孤島數(shù)據(jù)比較分散，在地域和存儲引擎層面上來看都是一個個分散的數(shù)據(jù)孤島，數(shù)據(jù)無法共享及統(tǒng)一處理。無法二次分析數(shù)據(jù)孤島數(shù)據(jù)比較分散，在地域和存儲引擎層面上來看都是一個個分散的數(shù)據(jù)孤島，數(shù)據(jù)無法共享及統(tǒng)一處理。業(yè)務(wù)系統(tǒng)架構(gòu)扁平，基于ETL的明細數(shù)據(jù)，不會保留原始數(shù)據(jù)。離線分析難度大執(zhí)行導(dǎo)數(shù)分析任務(wù)時，需要直接在業(yè)務(wù)系統(tǒng)中執(zhí)行，對于大數(shù)據(jù)量的任務(wù)，嚴(yán)重影響ES集群的穩(wěn)定性。02架構(gòu)演進2-1架構(gòu)演進：技術(shù)選型思考HadHadoop生態(tài)Elasticsearch?存在寫入瓶頸，吞吐能力達不到預(yù)期；?對服務(wù)器的CPU，內(nèi)存及磁盤的要求都比較高；?倒排索引導(dǎo)致存儲成本較高，達不到降本增效的效果；?聚合計算場景能力一般，會出現(xiàn)聚合不準(zhǔn)確的情況；?分析需要具備DSL能力，復(fù)雜場景SQL模式支持有?傳統(tǒng)數(shù)倉架構(gòu)實時性得不到很好的保證。?架構(gòu)復(fù)雜度比較高，數(shù)據(jù)鏈路長。?缺乏湖生態(tài)的技術(shù)儲備，預(yù)研周期較長。2-1架構(gòu)演進：技術(shù)選型思考場景查詢并發(fā)高低存儲成本低低計算能力高高維護成本低高社區(qū)活躍高中易用性高中2-1架構(gòu)演進：技術(shù)選型思考需求場景數(shù)據(jù)分層處理，ALLINONE高吞吐，支持實時離線導(dǎo)入導(dǎo)出一站式分析，統(tǒng)一數(shù)據(jù)出口即席分析查詢能力出色的計算能力，支持多維分析高易用性及簡易架構(gòu)1、支持Duplicate明細模型，Unique主鍵數(shù)據(jù)模型，Aggregate聚合數(shù)據(jù)模型，滿足數(shù)倉大部分業(yè)務(wù)場景；2、列式存儲，數(shù)據(jù)擁有較高的壓縮比，ODS層存儲成本更低；1、支持RoutineLoad、BrokerLoad和StreamLoad等多種內(nèi)置的導(dǎo)數(shù)方式；2、支持Flink、Spark、Datax、Kafka等源；3、支持HDFS、S3、本地文件讀取與寫入；1、出色的聯(lián)邦分析能力，支持大部分主流數(shù)據(jù)湖、數(shù)據(jù)庫的連接訪問；1、支持高并發(fā)，Unique表在高并發(fā)點查場景下可達數(shù)萬QPS；2、不僅支持主鍵點查，在條件與范圍查詢場景下表現(xiàn)同樣出色；1、支持向量計算，聚合查詢低延遲；2、支持大部分Upsert操作，行更新，列更新，可滿足用戶信息，標(biāo)簽畫像更新等場景；3、大表Join支持度較好；1、采用MySQL，支持標(biāo)準(zhǔn)SQL協(xié)議，使用成本低；2、只有FE與BE兩個進程，不需要引入外部組件；3、DorisManage、X2Doris等豐富的周邊工具；4、社區(qū)活躍，社區(qū)支持度高，文檔非常詳細；2-2架構(gòu)演進：數(shù)倉架構(gòu)數(shù)據(jù)應(yīng)用數(shù)據(jù)倉庫數(shù)據(jù)源MySQLFileElasticsearchOpenAPIODSADS即席查詢標(biāo)簽畫像采集數(shù)據(jù)調(diào)度引擎/計算引擎關(guān)聯(lián)分析DolphinSchedulerApacheFlink數(shù)據(jù)攝入數(shù)據(jù)應(yīng)用數(shù)據(jù)倉庫數(shù)據(jù)源MySQLFileElasticsearchOpenAPIODSADS即席查詢標(biāo)簽畫像采集數(shù)據(jù)調(diào)度引擎/計算引擎關(guān)聯(lián)分析DolphinSchedulerApacheFlinkDataXDataXJarJarCatalogCatalogFlinkFlinkCDCKafkaKafka2-3架構(gòu)演進：存儲規(guī)模245TB1.5TB245TB1.5TB總數(shù)據(jù)規(guī)?？倲?shù)據(jù)量單日新增數(shù)據(jù)峰值總數(shù)據(jù)規(guī)模總數(shù)據(jù)量單日新增數(shù)據(jù)峰值03企業(yè)實踐3-1企業(yè)實踐：數(shù)據(jù)建模ODS貼源層ODS貼源層ADS應(yīng)用層DWS匯總層每天有幾千萬上億的半結(jié)構(gòu)化數(shù)據(jù)需要攝入，Json深度及字段數(shù)量都不可控，因此ODS層我們選用了基礎(chǔ)的DuplicateKey模型，快速穩(wěn)定的完成原始數(shù)據(jù)存儲；AggredateKey模型和UniqueKey模型之間進行選擇。簡單的去重和更新使用UniqueKey模型，指標(biāo)語句和復(fù)雜數(shù)據(jù)合并使用AggredateKey模型；ADS層作為對外直接使用的應(yīng)用層數(shù)據(jù)，我們主要沿用DuplicateKey模型和UniqueKey模型。點查和實時更新使用UniqueKey模型，周期全量計算結(jié)果表使用DuplicateKey模型；3-2企業(yè)實踐：寫入吞吐問題調(diào)整分區(qū)策略前調(diào)整分區(qū)策略后調(diào)整分區(qū)策略前CREATETABLE`ods_xxx_post`(`post_id`VARCHAR(64)NOTNULLCOMMENT'帖子ID',`user_id`VARCHAR(64)NOTNULLCOMMENT'用戶ID',`create_date`DATENOTNULLCOMMENT'發(fā)布日期',`full_data`TEXTNULLCOMMENT'原始JSON',`insert_date`DATENULLCOMMENT'入庫日期')DUPLICATEKEY(`post_id`,`user_id`,`create_date`,`task_id`)PARTITIONBYRANGE(`create_date`)DISTRIBUTEDBYHASH(`post_id`)BUCKETS16PROPERTIES("dynamic_partition.enable"="true","dynamic_partition.time_unit"="MONTH",...);CREATETABLE`ods_xxx_post`(`post_id`VARCHAR(64)NOTNULLCOMMENT'帖子ID',`user_id`VARCHAR(64)NOTNULLCOMMENT'用戶ID',`insert_date`DATENULLCOMMENT'入庫日期',`create_date`DATENOTNULLCOMMENT'發(fā)布日期',`full_data`TEXTNULLCOMMENT'原始JSON',)DUPLICATEKEY(`post_id`,`user_id`,`insert_date`,`task_id`)PARTITIONBYRANGE(`insert_date`)DISTRIBUTEDBYHASH(`post_id`)BUCKETS16PROPERTIES("dynamic_partition.enable"="true","dynamic_partition.time_unit"="MONTH",...);建表分區(qū)策略改為按照“處理時間”進行按月分區(qū)后，寫入吞吐直線上升，compactioncore維持在100+左右，CPU負載水平也回落到正常負載，解決了寫入吞吐低以及版本堆積導(dǎo)致的頻繁寫入失敗問題。3-3企業(yè)實踐：數(shù)據(jù)更新問題社交用戶數(shù)據(jù)場景中，數(shù)據(jù)渠道較多，每種渠道的字段內(nèi)容的穩(wěn)定性不一，沒有明顯特征。假設(shè)用戶數(shù)據(jù)有A，B，C，D，E五個道也會有不確定因素存在，因此DWS層的用戶數(shù)據(jù)去重與合并是一大重要挑戰(zhàn)。ODS層ADSODS層ADS層AggredateAggredate3-4企業(yè)實踐：離線遷移HBasetoDoris15億的賬號數(shù)據(jù)，128個分區(qū)，8個分區(qū)作為一批，DataX串行化執(zhí)行，同步至Doris總耗時為6小時；ElasticsearchtoDorisElasticsearch索引映射的_meta部分添加特定的Doris結(jié)構(gòu)注釋，使用REFRESH命令手動刷新元數(shù)據(jù)；外部離線數(shù)據(jù)Kafka消息隊列RoutineLoadKafka消息隊列HDFSMinIO(S3)文件系統(tǒng)HDFSMinIO(S3)文件系統(tǒng)ElasticsearshMySQL...外部數(shù)據(jù)庫INSERTElasticsearshMySQL...外部數(shù)據(jù)庫04總結(jié)規(guī)劃4-1總結(jié)規(guī)劃：降本增效數(shù)據(jù)類型數(shù)據(jù)量存儲成本降低率社交帖文2224769027（22.2億）1.393TB5.98TB76.7%社交帖文139541279（1.3億）408.582GB1.2TB66.0%社交用戶157091118（15億）52.039GB183.9GB71.5%社交關(guān)系642762889（6.4億）204.488GB529.3GB61.3%經(jīng)過多種類型數(shù)據(jù)的對比，存儲成本能節(jié)省61%-76%之間。特別社交帖文數(shù)據(jù)場景下，Elasticsearch需要使用5.98TB磁盤內(nèi)存，而在ApacheDoris只需要1.393TB，在保持高吞吐和實時性能的前提下，同等規(guī)模的數(shù)據(jù)，存儲成本大幅度降低。4-2總結(jié)規(guī)劃：高效導(dǎo)數(shù)原有平臺架構(gòu)導(dǎo)數(shù)流程（1Day）項目A項目BElasticserach項目NElasticserachElasticserachHBaseHBaseHBase基于Apache原有平臺架構(gòu)導(dǎo)數(shù)流程（1Day）項目A項目BElasticserach項目NElasticserachElasticserachHBaseHBaseHBase基于ApacheDoris的架構(gòu)改造導(dǎo)數(shù)流程（0.5Day）Doris內(nèi)部表DorisCatalogSELECTINSERTSELECTINSERTINTO匯聚集中處理FlinkConnectorKafkaKafkaKafkaKafka4-3總結(jié)規(guī)劃：統(tǒng)一分析平臺即席查詢能夠在數(shù)十億級表中實時查看數(shù)據(jù)明細，通過關(guān)鍵詞、時間、實體等緯度進行篩選。基于SQL輕松完成BI報表、數(shù)據(jù)大屏的開發(fā)與輸出。自助API只需要基于SQL定義輸入輸出，在線API測試這2步即可生成API。4-4總結(jié)規(guī)劃：高效計算原有社交關(guān)系計算（2Hour）基于ApacheDoris的流程改造（10Min原有社交關(guān)系計算（2Hour）ApacheDoris轉(zhuǎn)評贊明細表①ApacheDoris轉(zhuǎn)評贊明細表①①Elasticsearch③② ElasticsearchElasticsearch社交關(guān)系結(jié)果數(shù)據(jù)ApacheDoris社交關(guān)系結(jié)果數(shù)據(jù)②Apache