建立高性能風險數據集市的分步指南
譯文譯者 | 李睿
審校 | 重樓
開發人員追求數據驅動的管理，他們的目標是在數據平臺開發中滿足四個需求：監控和警報、查詢和分析、儀表板和數據建模。出于這些目的，他們基于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
