譯者 | 李睿

審校 | 重樓

開發人員追求數據驅動的管理，他們的目標是在數據平臺開發中滿足四個需求：監控和警報、查詢和分析、儀表板和數據建模。出于這些目的，他們基于Greenplum和CDH構建了數據處理架構。其中最重要的部分是風險數據集市。

風險數據集市：Apache Hive

以下介紹風險數據集市是如何按照數據流工作的：

（1）業務數據被導入Greenplum進行實時分析以生成商業智能（BI）報告。這些數據的一部分也會進入Apache Hive進行查詢和建模分析。

（2）風險控制變量在Elasticsearch中通過消息隊列實時更新，同時Elasticsearch也將數據攝取到Hive中進行分析。

（3）將風險管理決策數據從MongoDB傳遞給Hive進行風控分析和建模。

這是風險數據集市的三個數據源。

整個架構是用CDH 6.0構建的，其中的工作流程可分為實時數據流和離線風險分析。

• 實時數據流：來自Apache Kafka的實時數據將被Apache Flink清理，然后寫入Elasticsearch。Elasticsearch會匯總接收到的部分數據，并將其發送給風險管理作為參考。
• 線下風險分析：基于CDH解決方案，利用Sqoop對其進行線下數據攝取。然后將這些數據與來自MongoDB的第三方數據放在一起。然后，經過數據清洗之后，將所有這些數據輸入Hive中進行日常的批量處理和數據查詢。

簡要概述一下，這些組件支持數據處理平臺的四個功能：

如上圖所見，Apache Hive是這個架構的核心。但在實踐中，Apache Hive執行分析需要幾分鐘，因此下一步是提高查詢速度。

是什么拖慢了查詢速度?

外部表中的巨大數據量

基于Hive的數據集市現在承載著超過300TB的數據。大約有2萬個表和500萬個字段。將它們全部放在外部表中是維護密集型的。此外，數據攝取可能是一個令人頭疼的問題。

更大的平面表

由于風險管理中規則引擎的復雜性，企業在變量的推導上投入了大量的資金。在某些維度上，有數千個甚至更多的變量。因此，Hive中一些常用的平面表有超過3000個字段。因此，可以想象這些查詢是多么耗時。

不穩定的接口

日常離線批處理產生的結果將定期發送到Elasticsearch集群 (這些更新中的數據量很大，接口調用可能會過期) 。這一過程可能導致高I/O并引入垃圾收集器抖動，從而進一步導致接口服務不穩定。

此外，由于風控分析師和建模工程師使用Hive和Spark，不斷擴展的數據架構也拖累了查詢性能。

統一查詢網關

在此需要一個統一的網關來管理異構數據源。這就是為什么介紹Apache Doris的原因。

但這不會讓事情變得更復雜嗎?事實上并沒有。

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

在Apache Doris中創建Elasticsearch Catalog和Hive Catalog。這些目錄映射到Elasticsearch和Hive中的外部數據，因此可以使用Apache Doris作為統一網關跨這些數據源執行查詢。此外，使用Spark-Doris- connector來實現Spark和Doris之間的數據通信。所以基本上，用Apache Doris代替Apache Hive作為數據架構的中心樞紐。

這對數據處理效率有何影響?

• 監控和警報：這是關于對實時數據的查詢。使用Apache Doris中的Elasticsearch Catalog訪問Elasticsearch集群中的實時數據。然后直接在Apache Doris中執行查詢。它能夠在幾秒鐘內返回結果，而不是使用Hive時的幾分鐘級別的響應時間。
• 查詢和分析：在Hive中有20,000個表，所以將它們全部映射到Hive中的外部表是沒有意義的。這需要花費一大筆維護費用。與其相反，利用Apache Doris 1.2的Multi Catalog特性。它支持目錄級別的數據映射，因此可以簡單地在Doris中創建一個Hive Catalog。然后再進行查詢。這將查詢操作從Hive的日常批量處理工作量中分離出來，從而減少資源沖突。
• 儀表板：使用Tableau和Doris提供儀表板服務。這將查詢響應時間縮短到幾秒和幾毫秒，而在“Tableau + Hive”時則需要幾分鐘。
• 建模：使用Spark和Doris進行聚合建模。Spark-Doris-Connector允許數據的相互同步，因此來自Doris的數據也可以用于建模以進行更準確的分析。

生產環境中的集群監控

在生產環境中測試了這個新架構，為此建立了兩個集群。

配置：

生產集群：4個前端+ 8個后端，m5d.16xlarge

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

以下是監控板：

如上圖所示，查詢速度很快。預計它至少需要10個節點，但在實際情況中，主要通過Catalogs進行查詢，因此可以用相對較小的集群大小來處理這個問題。兼容性也很好。它不會影響現有系統的其余部分。

快速數據集成指南

為了加速從Hive到Apache Doris 1.2.2的常規數據攝取，以下有一個解決方案：

主要部件：

• Dolphin Scheduler 3.1.4
• SeaTunnel 2.1.3

對于當前的硬件配置，使用DolphinScheduler的Shell腳本模式，并定期調用SeaTunnel腳本。數據同步任務的配置文件：

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”
  }
 }

這一解決方案消耗更少的資源和內存，但在查詢和數據攝取方面帶來更高的性能。

更低的存儲成本

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

更少的內存使用和更高的查詢性能

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

其對應語句如下:

• Hive查詢，響應時間：162秒。

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

• 在Doris中使用Hive Catalog查詢，響應時間：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查詢，響應時間：0.828秒。

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

更快的數據攝取

• 之前：Hive的原始表有40個字段。它按天劃分為多個分區，每個分區有11億條數據。在HDFS中存儲需要806G的存儲空間。
• 之后：為了數據同步，使用SeaTunnel在YARN上調用Spark。可以在11分鐘內完成(每分鐘1億條)，并且所攝取的數據僅占用378G的存儲空間。

結語

構建高性能風險數據集市的關鍵步驟是利用Apache Doris的Multi Catalog特性來統一異構數據源。這不僅提高了查詢速度，而且還解決了以前的數據架構帶來的許多問題。

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

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