天津企業(yè)建站系統(tǒng),婚慶網(wǎng)頁(yè)設(shè)計(jì)作品dw,網(wǎng)站tdk標(biāo)簽,旅游網(wǎng)站前臺(tái)模板導(dǎo)讀#xff1a;中通快遞基于 SelectDB 構(gòu)建了湖倉(cāng)分析架構(gòu)#xff0c;補(bǔ)齊 OLAP 分析能力。在離線場(chǎng)景中#xff0c;實(shí)現(xiàn) 2000 QPS 并發(fā)點(diǎn)查#xff1b;在實(shí)時(shí)場(chǎng)景中#xff0c;僅以 1/3 原集群機(jī)器數(shù)量覆蓋所有業(yè)務(wù)#xff0c;90% 分析任務(wù)從 10 分鐘縮短至 1 分鐘內(nèi)中通快遞基于 SelectDB 構(gòu)建了湖倉(cāng)分析架構(gòu)補(bǔ)齊 OLAP 分析能力。在離線場(chǎng)景中實(shí)現(xiàn) 2000 QPS 并發(fā)點(diǎn)查在實(shí)時(shí)場(chǎng)景中僅以 1/3 原集群機(jī)器數(shù)量覆蓋所有業(yè)務(wù)90% 分析任務(wù)從 10 分鐘縮短至 1 分鐘內(nèi)投入產(chǎn)出比大幅提升。作者童孝天中通快遞高級(jí)數(shù)據(jù)工程師中通快遞作為快遞行業(yè)領(lǐng)軍企業(yè)之一年包裹數(shù)達(dá)數(shù)百億件市場(chǎng)份額穩(wěn)定在 20% 左右展現(xiàn)出強(qiáng)勁的市場(chǎng)競(jìng)爭(zhēng)力和持續(xù)發(fā)展態(tài)勢(shì)。在業(yè)務(wù)規(guī)模持續(xù)擴(kuò)張下其對(duì)大數(shù)據(jù)基礎(chǔ)設(shè)施建設(shè)要求日益提高對(duì)數(shù)據(jù)處理及分析的需求也持續(xù)增加。中通快遞原先使用以 Hadoop 為核心的離線數(shù)倉(cāng)但隨著數(shù)據(jù)的不斷增長(zhǎng)、數(shù)據(jù)處理需求不斷變化 Hadoop 這一多套異構(gòu)的復(fù)雜架構(gòu)逐步暴露瓶頸面臨數(shù)據(jù)時(shí)效性、查詢性能、并發(fā)能力、維護(hù)成本等多種挑戰(zhàn)。在此背景下引入基于 Apache Doris 內(nèi)核的 SelectDB 構(gòu)建了湖倉(cāng)分析架構(gòu)補(bǔ)齊 OLAP 分析能力為離線、實(shí)時(shí)分析提供了高效的查詢能力。在離線場(chǎng)景中實(shí)現(xiàn) 2000 QPS 并發(fā)點(diǎn)查在實(shí)時(shí)場(chǎng)景中僅以 1/3 原集群機(jī)器數(shù)量覆蓋所有業(yè)務(wù)90% 分析任務(wù)從 10 分鐘縮短至 1 分鐘內(nèi)投入產(chǎn)出比大幅提升。一、早期架構(gòu)及挑戰(zhàn)在引入 SelectDB 之前中通基于 Hadoop 構(gòu)建離線數(shù)倉(cāng)應(yīng)對(duì)數(shù)據(jù)分析需求。在業(yè)務(wù)量高速增長(zhǎng)的背景下該架構(gòu)面臨嚴(yán)峻挑戰(zhàn)數(shù)據(jù)時(shí)效性不足離線數(shù)倉(cāng) T1 數(shù)據(jù)抽取產(chǎn)出模式無(wú)法滿足報(bào)表和數(shù)據(jù)大盤實(shí)時(shí)更新的需求查詢性能較差離線數(shù)倉(cāng)讀取、寫入等操作均基于 HDFS 進(jìn)行耗時(shí)普遍為分鐘級(jí)別以及 Spark SQL 的處理時(shí)間亦為分鐘級(jí)嚴(yán)重影響查詢效率無(wú)法支持需要秒級(jí)響應(yīng)的交互式分析場(chǎng)景。查詢穩(wěn)定性與高并發(fā)支持能力弱在超大的 Hadoop 集群規(guī)模下NameNode 的輕微抖動(dòng)就會(huì)嚴(yán)重影響短平快的即席查詢和報(bào)表分析的穩(wěn)定性Trino 在處理高并發(fā)查詢時(shí)效率也遠(yuǎn)低于預(yù)期難以支撐日益增長(zhǎng)的高并發(fā)需求。二、基于 SelectDB 的湖倉(cāng)分析架構(gòu)隨著業(yè)務(wù)的不斷發(fā)展昔日雙 11 的業(yè)務(wù)高峰現(xiàn)已成為每日常態(tài)。為了滿足各大場(chǎng)景對(duì)實(shí)時(shí)分析時(shí)效的要求并確保數(shù)據(jù)的快速寫入和高效查詢亟需合適的 OLAP 引擎來(lái)補(bǔ)充現(xiàn)有架構(gòu)。1. 技術(shù)選型中通技術(shù)團(tuán)隊(duì)通過(guò)深入的技術(shù)調(diào)研和測(cè)試驗(yàn)證了解到 基于 Apache Doris 內(nèi)核構(gòu)建的 SelectDB。SelectDB 以高效的向量化引擎、Pipeline 執(zhí)行模式、完善的緩存機(jī)制支持、高度兼容的 SQL 語(yǔ)法以及靈活的湖倉(cāng)分析能力吸引了他們?yōu)榱蓑?yàn)證 SelectDB 向量化引擎和 Pipeline 執(zhí)行模式的高性能查詢能力團(tuán)隊(duì)進(jìn)行了多輪對(duì)比測(cè)試以評(píng)估二者之間的性能差異在生產(chǎn)環(huán)境 SQL 測(cè)試中單表 100GB 數(shù)據(jù)量的查詢場(chǎng)景下SelectDB 相比 Trino 有 1-2 倍的性能提升在 1TB TPC-DS 標(biāo)準(zhǔn)測(cè)試中SelectDB 完成 99 個(gè)查詢的總耗時(shí)僅為 Trino 的 1/5。2. 湖倉(cāng)分析實(shí)時(shí)架構(gòu)中通基于 SelectDB 構(gòu)建了新一代的湖倉(cāng)分析架構(gòu)其核心是將 SelectDB 作為統(tǒng)一、高性能的查詢加速引擎覆蓋在數(shù)據(jù)湖之上。數(shù)據(jù)依然存儲(chǔ)在 Hive 數(shù)據(jù)湖中保持其經(jīng)濟(jì)性和容納海量原始數(shù)據(jù)的能力。具體而言SelectDB 通過(guò) Multi-Catalog 直接對(duì)接 Hive Metastore無(wú)需數(shù)據(jù)遷移即可創(chuàng)建外部表實(shí)現(xiàn)對(duì) Hive 湖中數(shù)據(jù)的直接、高速查詢。為了進(jìn)一步提升查詢體驗(yàn)中通廣泛采用了 SelectDB 的緩存加速、數(shù)據(jù)預(yù)熱、索引體系、分區(qū)分桶等能力有效保障了系統(tǒng)的穩(wěn)定性及查詢的高效性。截止當(dāng)前在 OLAP 分析層面 Trino 集群規(guī)模已超過(guò) 130 臺(tái)日峰值響應(yīng)接近 56 萬(wàn)個(gè)查詢。相比之下SelectDB 雖僅擁有三套集群規(guī)?？倲?shù)為 60 臺(tái)但日峰值響應(yīng)量接近 90 萬(wàn)個(gè)查詢。這一數(shù)據(jù)表明SelectDB 在實(shí)時(shí)計(jì)算的響應(yīng)能力方面具有顯著優(yōu)勢(shì)能夠更加高效地滿足大量查詢需求。三、場(chǎng)景實(shí)踐1. BI 報(bào)表與離線分析在 BI 報(bào)表和離線分析場(chǎng)景中原有 Trino 架構(gòu)面臨查詢穩(wěn)定性差和并發(fā)能力不足的雙重挑戰(zhàn)。特別是在早高峰時(shí)段業(yè)務(wù)人員集中訪問(wèn)報(bào)表系統(tǒng)頻繁出現(xiàn)查詢超時(shí)和系統(tǒng)卡頓。同時(shí)Trino 和 SparkSQL 在在面對(duì)高并發(fā)查詢時(shí)處理效率與預(yù)期存在較大差距。在查詢超時(shí)問(wèn)題上我們開(kāi)啟了數(shù)據(jù)緩存Data Cache功能并配置大容量本地磁盤將熱數(shù)據(jù)持久化緩存。在每日數(shù)據(jù)就緒后通過(guò)定時(shí)任務(wù)觸發(fā)對(duì)關(guān)鍵報(bào)表數(shù)據(jù)的預(yù)加載使其在業(yè)務(wù)高峰前已緩存至本地。避免了查詢延遲高的問(wèn)題同時(shí)降低早高峰期間集中訪問(wèn)導(dǎo)致帶寬拉滿的問(wèn)題。在同等查詢量下SelectDB 的慢 SQL10s僅為 Trino 的百分之一。在高并發(fā)查詢挑戰(zhàn)的應(yīng)對(duì)上中通快遞在實(shí)時(shí)數(shù)倉(cāng)建設(shè)階段將離線數(shù)據(jù) DIM 維度層、應(yīng)用層的數(shù)據(jù)通過(guò) SeaTunnel 寫入了 SelectDB 中實(shí)現(xiàn)了結(jié)果表的查詢加速。從而實(shí)現(xiàn) 2000 QPS 并發(fā)點(diǎn)查數(shù)據(jù)報(bào)表更新及時(shí)度大大提高。其次SelectDB 提供了靈活豐富的 SQL 函數(shù)公式并擁有高吞吐量的計(jì)算能力數(shù)據(jù)分析師、產(chǎn)品經(jīng)理等業(yè)務(wù)人員通過(guò)可視化報(bào)表工具 SelectDB 即可基本滿足 BI 的數(shù)據(jù)探索需求大部分查詢響應(yīng)速度都在秒級(jí)完成。該場(chǎng)景下在保持高性能、高并發(fā)的同時(shí)顯著節(jié)約了計(jì)算資源SelectDB 集群規(guī)模約為 Trino 的 1/4。2. 實(shí)時(shí)數(shù)據(jù)分析面向決策層和運(yùn)營(yíng)監(jiān)控的實(shí)時(shí)數(shù)據(jù)大屏對(duì)查詢時(shí)效性要求極高需要支持靈活的多維篩選和聚合分析。該場(chǎng)景涉及一張日增量超 6 億、總量超 45 億、字段超 200 列的超級(jí)寬表并需基于該寬表進(jìn)行分鐘級(jí)準(zhǔn)實(shí)時(shí)分析。原有 OLAP 引擎在任務(wù)增多時(shí)負(fù)載過(guò)高時(shí)任務(wù)執(zhí)行時(shí)效難以保證。比如當(dāng)總?cè)蝿?wù)數(shù)超 50 時(shí)執(zhí)行時(shí)間達(dá) 5-10 分鐘效率極為低下。因此基于 SelectDB 以下特性成功解決上述問(wèn)題查詢加速借助倒排、BloomFilter 來(lái)支持多維分析通過(guò)合理的分區(qū)分桶在查詢時(shí)過(guò)濾非必要的數(shù)據(jù)使數(shù)據(jù)掃描快速定位加速查詢響應(yīng)時(shí)間。使 90% 以上的查詢從 10 分鐘左右縮短到 1 分鐘內(nèi)部分達(dá)到秒級(jí)性能提升 10 倍。數(shù)據(jù)寫入秒級(jí)可見(jiàn)SelectDB 支持主鍵表Unique Key并對(duì) Upsert、條件更新 / 條件刪除、部分列更新、分區(qū)覆蓋等各類更新提供了完備的支持借助 Flink可完成對(duì)數(shù)據(jù)的秒級(jí)可見(jiàn)滿足高效靈活的數(shù)據(jù)更新需求注意對(duì)表結(jié)構(gòu)的設(shè)計(jì)需要結(jié)合業(yè)務(wù)、因地制宜合理規(guī)劃 Key 和分區(qū)分桶列一般將 where 條件或者 join 的字段定義成分桶較為合適在該場(chǎng)景下SelectDB 僅使用原集群 1/3 的資源就覆蓋了所有業(yè)務(wù)實(shí)現(xiàn)了高效且經(jīng)濟(jì)的運(yùn)行。滿足了業(yè)務(wù)方對(duì)數(shù)據(jù) “既快又準(zhǔn)” 的嚴(yán)格要求提升了監(jiān)控和決策的效率。四、成果及價(jià)值中通引入 SelectDB 后查詢性能實(shí)現(xiàn)巨大飛躍延遲大幅下降并發(fā)能力顯著提升同時(shí)成本大幅降低系統(tǒng)穩(wěn)定性與易維護(hù)性也得到增強(qiáng)。未來(lái)中通將會(huì)深化與 SelectDB 的合作提升易用性利用 SelectDB 提供的更精煉、直觀的 Profile 信息降低 SQL 調(diào)優(yōu)的難度和復(fù)雜度提升開(kāi)發(fā)運(yùn)維效率增強(qiáng)系統(tǒng)可觀測(cè)性強(qiáng)化文件緩存等功能的可觀測(cè)性加強(qiáng)數(shù)據(jù)傾斜處理能力以提升整個(gè)系統(tǒng)的可靠性與可維護(hù)性深化湖倉(cāng)一體加強(qiáng) Multi Catalog 功能的應(yīng)用提升湖倉(cāng)分析能力并測(cè)試 SelectDB 讀寫 Hive 外表的能力實(shí)現(xiàn)更靈活的數(shù)據(jù)流轉(zhuǎn)打通權(quán)限與集成推動(dòng)實(shí)現(xiàn) Hive Catalog 權(quán)限通過(guò) JDBC 賬號(hào)的透?jìng)髋c公司現(xiàn)有大數(shù)據(jù)權(quán)限體系無(wú)縫融合確保數(shù)據(jù)安全。加入交流群聚集眾多 SelectDB 與 Apache Doris 開(kāi)發(fā)者、用戶以及合作伙伴歡迎隨時(shí)提出和討論技術(shù)問(wèn)題、 分享和收獲技術(shù)經(jīng)驗(yàn)與社區(qū)互動(dòng)交流。https://www.selectdb.com/join-community#join-group