譯者 | 李睿

審校 | 重樓

開(kāi)發(fā)人員追求數(shù)據(jù)驅(qū)動(dòng)的管理，他們的目標(biāo)是在數(shù)據(jù)平臺(tái)開(kāi)發(fā)中滿足四個(gè)需求：監(jiān)控和警報(bào)、查詢和分析、儀表板和數(shù)據(jù)建模。出于這些目的，他們基于Greenplum和CDH構(gòu)建了數(shù)據(jù)處理架構(gòu)。其中最重要的部分是風(fēng)險(xiǎn)數(shù)據(jù)集市。

風(fēng)險(xiǎn)數(shù)據(jù)集市：Apache Hive

以下介紹風(fēng)險(xiǎn)數(shù)據(jù)集市是如何按照數(shù)據(jù)流工作的：

（1）業(yè)務(wù)數(shù)據(jù)被導(dǎo)入Greenplum進(jìn)行實(shí)時(shí)分析以生成商業(yè)智能（BI）報(bào)告。這些數(shù)據(jù)的一部分也會(huì)進(jìn)入Apache Hive進(jìn)行查詢和建模分析。

（2）風(fēng)險(xiǎn)控制變量在Elasticsearch中通過(guò)消息隊(duì)列實(shí)時(shí)更新，同時(shí)Elasticsearch也將數(shù)據(jù)攝取到Hive中進(jìn)行分析。

（3）將風(fēng)險(xiǎn)管理決策數(shù)據(jù)從MongoDB傳遞給Hive進(jìn)行風(fēng)控分析和建模。

這是風(fēng)險(xiǎn)數(shù)據(jù)集市的三個(gè)數(shù)據(jù)源。

整個(gè)架構(gòu)是用CDH 6.0構(gòu)建的，其中的工作流程可分為實(shí)時(shí)數(shù)據(jù)流和離線風(fēng)險(xiǎn)分析。

• 實(shí)時(shí)數(shù)據(jù)流：來(lái)自Apache Kafka的實(shí)時(shí)數(shù)據(jù)將被Apache Flink清理，然后寫入Elasticsearch。Elasticsearch會(huì)匯總接收到的部分?jǐn)?shù)據(jù)，并將其發(fā)送給風(fēng)險(xiǎn)管理作為參考。
• 線下風(fēng)險(xiǎn)分析：基于CDH解決方案，利用Sqoop對(duì)其進(jìn)行線下數(shù)據(jù)攝取。然后將這些數(shù)據(jù)與來(lái)自MongoDB的第三方數(shù)據(jù)放在一起。然后，經(jīng)過(guò)數(shù)據(jù)清洗之后，將所有這些數(shù)據(jù)輸入Hive中進(jìn)行日常的批量處理和數(shù)據(jù)查詢。

簡(jiǎn)要概述一下，這些組件支持?jǐn)?shù)據(jù)處理平臺(tái)的四個(gè)功能：

如上圖所見(jiàn)，Apache Hive是這個(gè)架構(gòu)的核心。但在實(shí)踐中，Apache Hive執(zhí)行分析需要幾分鐘，因此下一步是提高查詢速度。

是什么拖慢了查詢速度?

外部表中的巨大數(shù)據(jù)量

基于Hive的數(shù)據(jù)集市現(xiàn)在承載著超過(guò)300TB的數(shù)據(jù)。大約有2萬(wàn)個(gè)表和500萬(wàn)個(gè)字段。將它們?nèi)糠旁谕獠勘碇惺蔷S護(hù)密集型的。此外，數(shù)據(jù)攝取可能是一個(gè)令人頭疼的問(wèn)題。

更大的平面表

由于風(fēng)險(xiǎn)管理中規(guī)則引擎的復(fù)雜性，企業(yè)在變量的推導(dǎo)上投入了大量的資金。在某些維度上，有數(shù)千個(gè)甚至更多的變量。因此，Hive中一些常用的平面表有超過(guò)3000個(gè)字段。因此，可以想象這些查詢是多么耗時(shí)。

不穩(wěn)定的接口

日常離線批處理產(chǎn)生的結(jié)果將定期發(fā)送到Elasticsearch集群 (這些更新中的數(shù)據(jù)量很大，接口調(diào)用可能會(huì)過(guò)期) 。這一過(guò)程可能導(dǎo)致高I/O并引入垃圾收集器抖動(dòng)，從而進(jìn)一步導(dǎo)致接口服務(wù)不穩(wěn)定。

此外，由于風(fēng)控分析師和建模工程師使用Hive和Spark，不斷擴(kuò)展的數(shù)據(jù)架構(gòu)也拖累了查詢性能。

統(tǒng)一查詢網(wǎng)關(guān)

在此需要一個(gè)統(tǒng)一的網(wǎng)關(guān)來(lái)管理異構(gòu)數(shù)據(jù)源。這就是為什么介紹Apache Doris的原因。

但這不會(huì)讓事情變得更復(fù)雜嗎?事實(shí)上并沒(méi)有。

可以將各種數(shù)據(jù)源連接到Apache Doris，并簡(jiǎn)單地對(duì)其進(jìn)行查詢。這是由Apache Doris的多目錄特性實(shí)現(xiàn)的：它可以與各種數(shù)據(jù)源接口，包括像Apache Hive、Apache Iceberg和Apache Hudi這樣的數(shù)據(jù)湖，以及像MySQL、Elasticsearch和Greenplum這樣的數(shù)據(jù)庫(kù)。這恰好涵蓋了工具箱。

在Apache Doris中創(chuàng)建Elasticsearch Catalog和Hive Catalog。這些目錄映射到Elasticsearch和Hive中的外部數(shù)據(jù)，因此可以使用Apache Doris作為統(tǒng)一網(wǎng)關(guān)跨這些數(shù)據(jù)源執(zhí)行查詢。此外，使用Spark-Doris- connector來(lái)實(shí)現(xiàn)Spark和Doris之間的數(shù)據(jù)通信。所以基本上，用Apache Doris代替Apache Hive作為數(shù)據(jù)架構(gòu)的中心樞紐。

這對(duì)數(shù)據(jù)處理效率有何影響?

• 監(jiān)控和警報(bào)：這是關(guān)于對(duì)實(shí)時(shí)數(shù)據(jù)的查詢。使用Apache Doris中的Elasticsearch Catalog訪問(wèn)Elasticsearch集群中的實(shí)時(shí)數(shù)據(jù)。然后直接在Apache Doris中執(zhí)行查詢。它能夠在幾秒鐘內(nèi)返回結(jié)果，而不是使用Hive時(shí)的幾分鐘級(jí)別的響應(yīng)時(shí)間。
• 查詢和分析：在Hive中有20,000個(gè)表，所以將它們?nèi)坑成涞紿ive中的外部表是沒(méi)有意義的。這需要花費(fèi)一大筆維護(hù)費(fèi)用。與其相反，利用Apache Doris 1.2的Multi Catalog特性。它支持目錄級(jí)別的數(shù)據(jù)映射，因此可以簡(jiǎn)單地在Doris中創(chuàng)建一個(gè)Hive Catalog。然后再進(jìn)行查詢。這將查詢操作從Hive的日常批量處理工作量中分離出來(lái)，從而減少資源沖突。
• 儀表板：使用Tableau和Doris提供儀表板服務(wù)。這將查詢響應(yīng)時(shí)間縮短到幾秒和幾毫秒，而在“Tableau + Hive”時(shí)則需要幾分鐘。
• 建模：使用Spark和Doris進(jìn)行聚合建模。Spark-Doris-Connector允許數(shù)據(jù)的相互同步，因此來(lái)自Doris的數(shù)據(jù)也可以用于建模以進(jìn)行更準(zhǔn)確的分析。

生產(chǎn)環(huán)境中的集群監(jiān)控

在生產(chǎn)環(huán)境中測(cè)試了這個(gè)新架構(gòu)，為此建立了兩個(gè)集群。

配置：

生產(chǎn)集群：4個(gè)前端+ 8個(gè)后端，m5d.16xlarge

備份集群：4個(gè)前端+ 4個(gè)后端，m5d.16xlarge

以下是監(jiān)控板：

如上圖所示，查詢速度很快。預(yù)計(jì)它至少需要10個(gè)節(jié)點(diǎn)，但在實(shí)際情況中，主要通過(guò)Catalogs進(jìn)行查詢，因此可以用相對(duì)較小的集群大小來(lái)處理這個(gè)問(wèn)題。兼容性也很好。它不會(huì)影響現(xiàn)有系統(tǒng)的其余部分。

快速數(shù)據(jù)集成指南

為了加速?gòu)腍ive到Apache Doris 1.2.2的常規(guī)數(shù)據(jù)攝取，以下有一個(gè)解決方案：

主要部件：

• Dolphin Scheduler 3.1.4
• SeaTunnel 2.1.3

對(duì)于當(dāng)前的硬件配置，使用DolphinScheduler的Shell腳本模式，并定期調(diào)用SeaTunnel腳本。數(shù)據(jù)同步任務(wù)的配置文件：

SQL 
  env{
 spark.app.name = “hive2doris-template”
  spark.executor.instances = 10
 spark.executor.cores = 5
 spark.executor.memory = “20g”
 }
 spark {
  spark.sql.catalogImplementation = “hive”
 }
 source {
  hive {
  pre_sql = “select * from ods.demo_tbl where dt=’2023-03-09’”
  result_table_name = “ods_demo_tbl”
  }
 }

 transform {
 }
 
 sink {
  doris {
  fenodes = “192.168.0.10:8030,192.168.0.11:8030,192.168.0.12:8030,192.168.0.13:8030”
  user = root
  password = “XXX”
  database = ods
  table = ods_demo_tbl
  batch_size = 500000
  max_retries = 1
  interval = 10000
  doris.column_separator = “\t”
  }
 }

這一解決方案消耗更少的資源和內(nèi)存，但在查詢和數(shù)據(jù)攝取方面帶來(lái)更高的性能。

更低的存儲(chǔ)成本

• 之前：Hive中的原始表有500個(gè)字段。它按天劃分為多個(gè)分區(qū)，每個(gè)分區(qū)有1.5億條數(shù)據(jù)。在HDFS中存儲(chǔ)需要810G存儲(chǔ)空間。
• 之后：為了數(shù)據(jù)同步，使用SeaTunnel在YARN上調(diào)用Spark。它可以在40分鐘內(nèi)完成，并且攝取的數(shù)據(jù)只占用270G的存儲(chǔ)空間。

更少的內(nèi)存使用和更高的查詢性能

• 之前：Hive中對(duì)上述表進(jìn)行GROUP BY查詢，占用720個(gè)內(nèi)核，占用YARN 1.44T，響應(yīng)時(shí)間為162秒。
• 之后：在Doris中使用Hive Catalog執(zhí)行聚合查詢，設(shè)置exec_mem_limit=16G，在58.531秒后收到結(jié)果。也嘗試將表放入Doris，并在Doris本身進(jìn)行同樣的查詢，只需要0.828秒。

其對(duì)應(yīng)語(yǔ)句如下:

• Hive查詢，響應(yīng)時(shí)間：162秒。

SQL 
 select count(*),product_no FROM ods.demo_tbl where dt='2023-03-09'
 group by product_no;

• 在Doris中使用Hive Catalog查詢，響應(yīng)時(shí)間：58.531秒。

SQL 
 set exec_mem_limit=16G；
 select count(*),product_no FROM hive.ods.demo_tbl where dt=’2023-03-09’
 group by product_no;

• 直接在Doris查詢，響應(yīng)時(shí)間：0.828秒。

SQL 
 select count(*),product_no FROM ods.demo_tbl where dt=’2023-03-09’
 group by product_no;

更快的數(shù)據(jù)攝取

• 之前：Hive的原始表有40個(gè)字段。它按天劃分為多個(gè)分區(qū)，每個(gè)分區(qū)有11億條數(shù)據(jù)。在HDFS中存儲(chǔ)需要806G的存儲(chǔ)空間。
• 之后：為了數(shù)據(jù)同步，使用SeaTunnel在YARN上調(diào)用Spark?？梢栽?1分鐘內(nèi)完成(每分鐘1億條)，并且所攝取的數(shù)據(jù)僅占用378G的存儲(chǔ)空間。

結(jié)語(yǔ)

構(gòu)建高性能風(fēng)險(xiǎn)數(shù)據(jù)集市的關(guān)鍵步驟是利用Apache Doris的Multi Catalog特性來(lái)統(tǒng)一異構(gòu)數(shù)據(jù)源。這不僅提高了查詢速度，而且還解決了以前的數(shù)據(jù)架構(gòu)帶來(lái)的許多問(wèn)題。

• 部署Apache Doris允許將日常批處理工作負(fù)載與臨時(shí)查詢解耦，因此它們不必爭(zhēng)奪資源。這將查詢響應(yīng)時(shí)間從幾分鐘縮短到幾秒鐘。
• 采用基于Elasticsearch集群構(gòu)建數(shù)據(jù)攝取接口，這在傳輸大量離線數(shù)據(jù)時(shí)可能會(huì)導(dǎo)致垃圾收集器抖動(dòng)。當(dāng)將接口服務(wù)數(shù)據(jù)集存儲(chǔ)在Doris上時(shí)，在數(shù)據(jù)寫入過(guò)程中沒(méi)有發(fā)現(xiàn)抖動(dòng)，并且能夠在10分鐘內(nèi)傳輸1000萬(wàn)行代碼。
• Apache Doris已經(jīng)在許多場(chǎng)景下進(jìn)行了優(yōu)化，包括平面表。與ClickHouse相比，Apache Doris 1.2在SSB-Flat-table基準(zhǔn)測(cè)試中的速度快了一倍，在TPC-H基準(zhǔn)測(cè)試中快了幾十倍。
• 在集群擴(kuò)展和更新方面，過(guò)去在修改配置后的恢復(fù)時(shí)間窗口很大。但是Doris支持熱插拔和易于擴(kuò)展，所以可以在幾秒鐘內(nèi)重新啟動(dòng)節(jié)點(diǎn)，并最大限度地減少集群擴(kuò)展對(duì)用戶造成的干擾。

原文標(biāo)題：Step-By-Step Guide to Building a High-Performing Risk Data Mart，作者：Jacob Chow