當(dāng)前隨著企業(yè)內(nèi)外部數(shù)據(jù)源的不斷擴(kuò)展和積累，數(shù)據(jù)呈現(xiàn)出大規(guī)模、多樣化、質(zhì)量參差不齊等顯著特征。如何有效激活這些結(jié)構(gòu)復(fù)雜且類型多樣的數(shù)據(jù)資產(chǎn)，挖掘其深層價(jià)值，已成為眾多企業(yè)亟待解決的實(shí)際挑戰(zhàn)。
袋鼠云數(shù)棧作為新一代一站式大數(shù)據(jù)基礎(chǔ)軟件，其核心優(yōu)勢(shì)在于不僅提供了快速便捷、易于上手的底層數(shù)據(jù)開(kāi)發(fā)模塊，更推出了涵蓋質(zhì)量、標(biāo)簽及指標(biāo)等上層偏業(yè)務(wù)功能模塊。這些模塊旨在實(shí)現(xiàn)對(duì)數(shù)據(jù)質(zhì)量的有效校驗(yàn)、提升數(shù)據(jù)加工處理效能以及規(guī)范檢索流程，從而賦能最上層的業(yè)務(wù)人員進(jìn)行自主分析與直觀展示。
因此，在技術(shù)選型過(guò)程中，關(guān)鍵一步便是選擇一款集數(shù)據(jù)ETL、聯(lián)邦比對(duì)、Ad-hoc 查詢以及報(bào)表展示等一系列功能于一體的全能型底層計(jì)算引擎，以驅(qū)動(dòng)整個(gè)平臺(tái)高效運(yùn)作。
袋鼠云數(shù)棧經(jīng)過(guò)技術(shù)沉淀與實(shí)踐，探索出以 Trino 作為底層計(jì)算引擎的解決方案，并將此回饋給開(kāi)發(fā)者們。
為什么是 Trino？
Trino 是一種分布式 SQL 查詢引擎，旨在查詢分布在一個(gè)或多個(gè)異構(gòu)數(shù)據(jù)源上的大型數(shù)據(jù)集。它通過(guò)在整個(gè)集群的服務(wù)器上分配處理任務(wù)來(lái)實(shí)現(xiàn)橫向擴(kuò)展，基于這種架構(gòu)，Trino 查詢引擎可以在集群內(nèi)的計(jì)算節(jié)點(diǎn)并行處理海量數(shù)據(jù)的 SQL 查詢。
Trino 作為一個(gè)典型的存算分離 OLAP 引擎，采用了經(jīng)典的 Master-Slave 架構(gòu)，即 Coordinator+多個(gè) Worker。其中，Coordinator 主要做以下三件事：
· 接收、處理 Client 的請(qǐng)求，返回查詢結(jié)果給 Client
· 對(duì) SQL 進(jìn)行詞法解析，隨后進(jìn)行語(yǔ)法/語(yǔ)義分析并優(yōu)化生成執(zhí)行計(jì)劃
· 將物理執(zhí)行計(jì)劃以 TASK 的方式分發(fā)到 Worker 節(jié)點(diǎn)去執(zhí)行并將結(jié)果進(jìn)行匯總
Worker 是實(shí)際的執(zhí)行節(jié)點(diǎn)，主要就做一件事情，執(zhí)行 Coordinator 分發(fā)下來(lái)的 TASK。
Trino 的前身便是大名鼎鼎的 Presto。Trino 和 PrestoDB 的架構(gòu)是類似的，在這里附上 PrestoDB 的架構(gòu)圖：
我們對(duì)于底層計(jì)算引擎的選型同樣經(jīng)歷了從 PresotDB 到 Trino 的過(guò)程，中間對(duì)這兩者從功能、性能、社區(qū)活躍度幾個(gè)維度進(jìn)行過(guò)詳細(xì)的調(diào)研。通過(guò)對(duì)比，我們發(fā)現(xiàn) Trino 相較于 PrestoDB 有以下幾個(gè)優(yōu)勢(shì)：
· 動(dòng)態(tài)過(guò)濾優(yōu)化
· 賬號(hào)安全認(rèn)證集成度
· 審計(jì)日志集成度
· 更多的 RBO 優(yōu)化規(guī)則
· 享受 Spark 統(tǒng)計(jì)信息加成
· 更多的 UDF 函數(shù)
· 更多基于 ORC 表格式的查詢優(yōu)化
· 社區(qū)的高活躍度，在技術(shù)上更加激進(jìn)
其中，社區(qū)的高活躍度、更多的 RBO 優(yōu)化規(guī)則以及享受 Spark 統(tǒng)計(jì)信息加成是我們選擇 Trino 的根本原因。
Trino 在數(shù)棧的部署架構(gòu)
Trino 在袋鼠云數(shù)棧落地的探索實(shí)踐中經(jīng)歷了兩種方式的迭代：混合部署方式和資源物理隔離方式。
混合部署方式
在剛剛將 Trino 選定為指標(biāo)、標(biāo)簽平臺(tái)底層計(jì)算引擎時(shí)，考慮到部分企業(yè)的業(yè)務(wù)量以及數(shù)據(jù)量規(guī)模，我們決定采取 Trino Worker 與 HDFS DataNode 混合部署的策略，這樣可以避免跨網(wǎng)絡(luò)節(jié)點(diǎn)的數(shù)據(jù)拉取帶來(lái)的查詢延遲問(wèn)題。
在企業(yè)業(yè)務(wù)量和數(shù)據(jù)規(guī)模相對(duì)較小的情況下，這種混合部署方式確實(shí)能夠在滿足客戶業(yè)務(wù)需求的 SLA 的同時(shí)，還能夠達(dá)到降本增效的效果。但是當(dāng)客戶的業(yè)務(wù)量以及數(shù)據(jù)量達(dá)到一定規(guī)模時(shí)，這種混合部署方式也會(huì)隨之帶來(lái)一系列資源競(jìng)爭(zhēng)衍生出的穩(wěn)定性問(wèn)題。
具體來(lái)說(shuō)，當(dāng)數(shù)據(jù)量不斷攀升時(shí)，Trino Worker 節(jié)點(diǎn)處理每次查詢所需內(nèi)存峰值也會(huì)相應(yīng)增大。當(dāng)峰值增長(zhǎng)太快而 Trino 來(lái)不及做內(nèi)存回撤時(shí)，會(huì)直接增加 Worker 的堆內(nèi)存使用，進(jìn)而影響其他的業(yè)務(wù)查詢。此外，還可能會(huì)間接性增加整個(gè) Worker 的堆外內(nèi)存的使用量，導(dǎo)致 HDFS 的 DataNode 與 Woker 進(jìn)行資源的搶占，從而降低了兩個(gè)系統(tǒng)的穩(wěn)定性。
資源物理隔離方式
為應(yīng)對(duì)大型企業(yè)在數(shù)棧指標(biāo)、標(biāo)簽平臺(tái)每日面臨的海量 ETL 處理、Ad-hoc 查詢以及 API 報(bào)表分析等業(yè)務(wù)需求，并考慮到 Trino 只能做軟性資源隔離的劣勢(shì)，我們采取了資源物理隔離的解決方案。同時(shí)基于客戶業(yè)務(wù)的時(shí)效性要求，我們將原來(lái)的一個(gè)集群劃分成了離線集群和 API 集群，以分別高效地處理客戶的 ETL 任務(wù)和 API 報(bào)表分析等業(yè)務(wù)，同時(shí)利用袋鼠云 EMR 運(yùn)維工具進(jìn)行集群部署和管理。
針對(duì)負(fù)責(zé)客戶 ETL 任務(wù)的離線集群，我們采取了降低任務(wù)并發(fā)、增加任務(wù)的容錯(cuò)配置以及寫(xiě)入并發(fā)控制等優(yōu)化策略，從而顯著提升 ETL 任務(wù)的穩(wěn)定性；而對(duì)于 API 報(bào)表分析等業(yè)務(wù)，則通過(guò)適當(dāng)增加任務(wù)并發(fā)、算子并行度等手段，來(lái)降低客戶 API 報(bào)表業(yè)務(wù)的延時(shí)性，確保了整體服務(wù)性能和用戶體驗(yàn)。
挑戰(zhàn)、問(wèn)題及解決方案
在以 Trino 為底層計(jì)算引擎，袋鼠云數(shù)棧服務(wù)企業(yè)的過(guò)程中，我們也遇到了一些具有代表性的問(wèn)題以及痛點(diǎn)，在這里分享一部分?jǐn)?shù)棧的解決方案。
任務(wù)并發(fā)運(yùn)行數(shù)量大帶來(lái)的任務(wù)間穩(wěn)定性問(wèn)題
日常情況下，我們同時(shí)使用 Trino 的在線用戶可能在個(gè)位數(shù)，運(yùn)行 SQL 的并發(fā)數(shù)量屈指可數(shù)，因此不會(huì)存在用戶任務(wù)之間資源競(jìng)爭(zhēng)的問(wèn)題。但是當(dāng)我們面臨的客戶群體規(guī)模是「總行+N分行」時(shí)，在線用戶數(shù)和 SQL 執(zhí)行的并發(fā)請(qǐng)求量會(huì)顯著增加。在這種情況下，受限于當(dāng)前有限的系統(tǒng)資源，一旦某個(gè)分行的任務(wù)運(yùn)行時(shí)間較長(zhǎng)且占用大量資源，就極有可能導(dǎo)致其他分行的任務(wù)響應(yīng)速度大幅降低，甚至出現(xiàn)任務(wù)執(zhí)行失敗的情況。
● 原因分析
Trino 不能夠承擔(dān)很高的并發(fā)運(yùn)行情況，主要在于兩點(diǎn)：
· 海量的數(shù)據(jù)規(guī)模導(dǎo)致 Trino 不得不消耗大量的資源去進(jìn)行快速計(jì)算
· TCP 通信的連接數(shù)限制會(huì)導(dǎo)致大量任務(wù)并發(fā)運(yùn)行時(shí) block 或者直接失敗掉
● 解決思路
根據(jù)當(dāng)前的 Trino 集群情況，通過(guò)配置資源組，合理限制各個(gè)分行的任務(wù)并發(fā)數(shù)量，同時(shí)限制任務(wù)運(yùn)行的最大執(zhí)行時(shí)長(zhǎng)、Memory 大小、CPU 使用時(shí)長(zhǎng)。這樣，既能夠保證正在運(yùn)行的任務(wù)穩(wěn)定性，同時(shí)也主動(dòng)過(guò)濾了不合理的任務(wù)異常占用資源的情況。更重要的是，通過(guò)任務(wù)排隊(duì)的方式，降低任務(wù)的失敗率，避免影響下游任務(wù)的出數(shù)。
底層 HiveMetastore 負(fù)載過(guò)高，任務(wù)大量超時(shí)失敗
數(shù)棧客戶的主要業(yè)務(wù)場(chǎng)景之一是通過(guò) Trino 來(lái)加速對(duì) Hive 數(shù)據(jù)的處理以及查詢。Trino 與 Hive 的最主要區(qū)別是 RunTime 層面不同，一個(gè)是基于內(nèi)存的計(jì)算，一個(gè)是基于 MR 的計(jì)算。本質(zhì)上 Trino 的 Hive 插件還是依賴 HiveMetastore（下文簡(jiǎn)稱 HMS） 以及 HDFS 做數(shù)據(jù)的處理以及查詢。因此當(dāng)客戶端業(yè)務(wù)量比較大的情況下，會(huì)因?yàn)轭l繁訪問(wèn) HMS，出現(xiàn) HMS 內(nèi)存異常高且訪問(wèn)超時(shí)的問(wèn)題。
● 原因分析
在分析為什么會(huì)導(dǎo)致 HMS 負(fù)載過(guò)高之前，我們得先弄明白 Trino 在哪些步驟會(huì)訪問(wèn) HMS。
通過(guò)源碼分析發(fā)現(xiàn)，Trino 在 SQL 語(yǔ)義分析階段會(huì)通過(guò)訪問(wèn) HMS 來(lái)完善每個(gè) Node 的元數(shù)據(jù)相關(guān)信息，后續(xù)會(huì)借助這些元數(shù)據(jù)信息生成邏輯執(zhí)行計(jì)劃。在對(duì)數(shù)據(jù)進(jìn)行 DDL 時(shí)或者執(zhí)行 DML 時(shí)，也會(huì)出現(xiàn)有 HMS 的操作。另外 Trino 基于 Thrift 協(xié)議自己實(shí)現(xiàn)了一套 HMS 的 Client 端，并實(shí)現(xiàn)了失敗重試以及高可用功能。
但是我們發(fā)現(xiàn) Trino HMS Client 的失敗重試只是針對(duì)于連接失敗，當(dāng)一臺(tái) HMS 連接不上會(huì)去連接另外一臺(tái) HMS，而我們現(xiàn)在是 socket read timeout 類的失敗。這樣的話，即使任務(wù)失敗了，那么下一次 Trino 還是會(huì)連接這臺(tái) HMS，從而導(dǎo)致 HMS 持續(xù)高負(fù)載低響應(yīng)。其中，由于 Trino 和 PrestoDB 在執(zhí)行過(guò)程上差別不大，在這里附上 PrestoDB 的 SQL 執(zhí)行過(guò)程原理：
隨后我們又基于 HMS 的 gc 日志以及火焰圖進(jìn)行分析，發(fā)現(xiàn)平臺(tái)性能瓶頸都出現(xiàn)在 String.intern() 這個(gè)方法上。具體來(lái)說(shuō)，當(dāng) String.intern() 被調(diào)用后，底層會(huì)從一個(gè) hash table 的數(shù)據(jù)結(jié)構(gòu)中找同名字符串，在數(shù)量較大時(shí)會(huì)導(dǎo)致 hash 碰撞使 CPU 占用升高。
除此之外，我們從 HMS 的元信息數(shù)據(jù)庫(kù) MySQL 中看到表數(shù)量和分區(qū)數(shù)分別達(dá)到了十萬(wàn)級(jí)別跟百萬(wàn)級(jí)別。
● 解決思路
基于上述分析，我們決定從 HMS 和 Trino 兩方面入手。
在 HMS 層面，我們調(diào)整了 JVM 參數(shù)：
-XX：StringTableSize=20000000
但是好景不長(zhǎng)，半個(gè)月左右問(wèn)題再次復(fù)現(xiàn)，鑒于此，我們開(kāi)始質(zhì)疑問(wèn)題可能并非僅局限于 StringTable 本身，而是懷疑是 StringTable 中的數(shù)據(jù)沒(méi)有釋放。
在網(wǎng)上搜索“G1 CMS StringTable”關(guān)鍵字查找到 JDK 的一個(gè)相關(guān) bug：https://bugs.openjdk.org/browse/JDK-8180048
G1 垃圾回收器在回收 StringTable 上存在問(wèn)題，效率不及 CMS。最后通過(guò)將 Hive MetaStore 的垃圾回收器由 G1 調(diào)整為 CMS，問(wèn)題得以解決。
在 Trino 層面，我們開(kāi)啟了 Metastore 的緩存，考慮到 Coorinator 內(nèi)存的限制，我們?cè)O(shè)置了緩存的最大數(shù)量。其配置如下：
hive.metastore-cache-ttl=2h
hive.metastore-refresh-interval=1h
hive.metastore-cache-maximum-size=5000000
hive.metastore-refresh-max-threads=30
hive.metastore-cache.cache-partitions=true
另外，基于客戶當(dāng)前的數(shù)據(jù)量規(guī)模，我們發(fā)現(xiàn)在某些特殊的場(chǎng)景下 HMS 接口調(diào)用20s的超時(shí)時(shí)間是遠(yuǎn)遠(yuǎn)不夠的，而 Hive 社區(qū)在0.14版本就已經(jīng)將 HMS 20s的超時(shí)時(shí)間調(diào)整到600s來(lái)提高穩(wěn)定性，因此我們也將 Trino HMS 超時(shí)時(shí)間調(diào)整到了600s：
hive.metastore-timeout=600s
最后，我們優(yōu)化了 Trino HMS 的訪問(wèn)策略，增加了 RoundRobin 模式，來(lái)對(duì) HMS 的請(qǐng)求做負(fù)載均衡，避免單臺(tái) HMS 的請(qǐng)求負(fù)載過(guò)高。其配置如下：
hive.metastore.round-robin=true
● 實(shí)際使用效果
通過(guò)上述的調(diào)整之后，數(shù)棧的 Trino 集群基本上能夠滿足日均10w+ETL 任務(wù)的快速穩(wěn)定運(yùn)行。在這里附上內(nèi)部離線集群部分日均調(diào)用情況：
Catalog 配置后冷重啟導(dǎo)致業(yè)務(wù)中斷
在客戶使用數(shù)棧時(shí)，經(jīng)常有很多需要跨數(shù)據(jù)源的聯(lián)邦查詢場(chǎng)景，因此不得不頻繁對(duì) Trino 配置靜態(tài) Catalog 文件并進(jìn)行重啟，這樣就會(huì)影響當(dāng)前正在運(yùn)行的任務(wù)。因此，我們開(kāi)始思考如何實(shí)現(xiàn) Catalog 的動(dòng)態(tài)添加與注冊(cè)。
● 解決思路
如何持久化 Catalog 元數(shù)據(jù)?
在早期的動(dòng)態(tài)配置 Catalog 方案中，我們選擇將 Catalog 元數(shù)據(jù)保存在 zookeeper 上，默認(rèn)路徑為 /trino/catalog/meta，每一個(gè) Catalog 都會(huì)在保存路徑下創(chuàng)建一個(gè)節(jié)點(diǎn)并寫(xiě)入 Catalog 元數(shù)據(jù)信息。在相應(yīng)的 Catalog 節(jié)點(diǎn)下會(huì)存在若干子節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)代表 Trino 中的一個(gè) Node，節(jié)點(diǎn)內(nèi)容為該 Node 上的該 Catalog 狀態(tài)信息，該狀態(tài)信息由各個(gè) Node 定時(shí)檢測(cè)并匯報(bào)。
如何操作管理 Catalog？
· 在 Coordinator 中提供出管理 Catalog 的 rest 接口進(jìn)行訪問(wèn)
· Coordinator 收到請(qǐng)求后會(huì)往 zk 上的元數(shù)據(jù)保存路徑下新增一個(gè) Catalog 節(jié)點(diǎn)并將 Catalog 元數(shù)據(jù)信息寫(xiě)入 Catalog 節(jié)點(diǎn)
· 隨后各個(gè) Node（包含 Coordinator 和 Worker）內(nèi)的監(jiān)聽(tīng)線程根據(jù)元數(shù)據(jù)保存路徑下的節(jié)點(diǎn)事件來(lái)通過(guò) CatalogManager 進(jìn)行操作
· Coordinator 節(jié)點(diǎn)在操作完 Catalog 并匯報(bào)操作結(jié)果后會(huì)等待所有節(jié)點(diǎn)的操作結(jié)果，若在超時(shí)時(shí)間內(nèi)獲取 Node 的操作結(jié)果且都操作成功，那么則認(rèn)為此次 Catalog 操作成功，否則會(huì)認(rèn)為失敗
· 若 Catalog 操作失敗，Coorinator 節(jié)點(diǎn)會(huì)進(jìn)行事務(wù)回滾操作，刪除 zk 上的 Catalog 節(jié)點(diǎn)以及所有子節(jié)點(diǎn)
下圖為 Trino 添加 Catalog 的原理圖：
● 實(shí)際使用效果
從客戶使用層面來(lái)講，通過(guò)在頁(yè)面動(dòng)態(tài)配置 Trino Catalog，大幅度提升了客戶使用平臺(tái)的效率，同時(shí)降低了客戶運(yùn)維側(cè)的成本。
《數(shù)棧產(chǎn)品白皮書(shū)》下載地址：https://www.dtstack.com/resources/1004?src=szsm
《數(shù)據(jù)治理行業(yè)實(shí)踐白皮書(shū)》下載地址：https://www.dtstack.com/resources/1001?src=szsm文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-805129.html
想了解或咨詢更多有關(guān)大數(shù)據(jù)產(chǎn)品、行業(yè)解決方案、客戶案例的朋友，瀏覽袋鼠云官網(wǎng)：https://www.dtstack.com/?src=szbky文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-805129.html
到了這里，關(guān)于實(shí)戰(zhàn)講解｜Trino 在袋鼠云數(shù)棧的探索與實(shí)踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
