浙江電信Apache Doris實戰(zhàn)之路

浙江電信-大數(shù)據(jù)中心喻志強01大數(shù)據(jù)建設(shè)歷程02ApacheDoris實踐03湖倉一體實踐04后續(xù)規(guī)劃探討01大數(shù)據(jù)建設(shè)歷程浙江電信大數(shù)據(jù)平臺建設(shè)歷程20042024A202120042024A2021建設(shè)內(nèi)容：基于Teradata建設(shè)B域數(shù)據(jù)倉庫與數(shù)據(jù)集市應(yīng)用規(guī)模：20臺支持存儲：400TB建設(shè)內(nèi)容：構(gòu)建數(shù)據(jù)中臺能力建設(shè)內(nèi)容：基于Teradata建設(shè)B域數(shù)據(jù)倉庫與數(shù)據(jù)集市應(yīng)用規(guī)模：20臺支持存儲：400TB建設(shè)內(nèi)容：構(gòu)建數(shù)據(jù)中臺能力，基于中臺開展作業(yè)、模型、報表遷移，數(shù)據(jù)治理及培訓(xùn)推廣工作，并實現(xiàn)開發(fā)運營模式優(yōu)化。規(guī)模：Doris達(dá)到80節(jié)點MR/TDP+Iceberg+Doris新建湖倉一體MR/TDP+Iceberg+Doris新建湖倉一體架構(gòu)進(jìn)行BMO域數(shù)據(jù)統(tǒng)一匯聚。逐步轉(zhuǎn)型為以自有人員為主。規(guī)模：640+臺規(guī)模：700+臺支持存儲：20PB202320162023基于ApacheDoris湖倉一體架構(gòu)演進(jìn)原有平臺架構(gòu)圖經(jīng)分大數(shù)據(jù)impalaSparkTezHiveYarnHDFSFlinkKUDU經(jīng)分大數(shù)據(jù)impalaSparkTezHiveYarnHDFSFlinkKUDU數(shù)據(jù)集市VerticaVertica數(shù)據(jù)倉庫VerticaVertica基于基于ApacheDoris湖倉一體架構(gòu)（翼MapReduce）ZookeeperRangerZookeeperRangerFlinkFlink......Doris計算kyuubi/Sparkkyuubi/Spark......存儲Amoro......存儲AmoroIceberg/Iceberg/HiveYarnYarnHDFSHDFSESHESHBase02不斷提升逐步演化不斷提升逐步演化實時數(shù)倉上線2.1.*2.0.42.1.*2.0.42.0.12.0.32.0.12.0.32024年2月—至今2024年1月-2月持續(xù)使用與深度保障2024年1月-2月2023年11月-12月割接后新問題修復(fù)2023年11月-12月Doris數(shù)據(jù)寫Iceberg（已解決）割接過程新問題出現(xiàn)2023年11月首次生產(chǎn)嘗試割接后遇到j(luò)vm溢出問題，導(dǎo)致集群變慢、在經(jīng)歷多次日志割接過程新問題出現(xiàn)2023年11月首次生產(chǎn)嘗試割接后遇到j(luò)vm溢出問題，導(dǎo)致集群變慢、在經(jīng)歷多次日志、火焰圖排查、小版本迭代等方式2月2號更新到2.0.4版本穩(wěn)定運行SQL內(nèi)存溢出問題（已解決）Catalog訪問Iceberg大小寫敏感、BE節(jié)點Catalog訪問Iceberg大小寫敏感、BE節(jié)點rpc超時、BE節(jié)點頻繁掉落等問題迭代到2.0.3版本后解決使用2.0.1版本問題：主要體現(xiàn)在與已有BI和數(shù)據(jù)中臺適配性問題，如<=>符號識別異常報表性能較差、中臺FlinkSQL采集任務(wù)適配問題，數(shù)據(jù)丟失多次count(*)一張靜態(tài)表數(shù)據(jù)量變化bug等-字段全為主鍵表（已解決）暴露localshuffle問題，導(dǎo)致集群故障，目前關(guān)閉此參數(shù)（待完全解決）2.1.x相比2.0.x，整體性能上提升了30-50%2.1.5相比2.1.2，穩(wěn)定性提升超30%不斷提升逐步演化不斷提升逐步演化查詢集市庫上線2.1.22.1.2-rc022.1.22.1.2-rc022.1.52024年8月9號—至今持續(xù)使用與深度保障2024年8月8號割接過程新問題修復(fù)2024年7月9號業(yè)務(wù)驗證與上線嘗試使用haproxysql替換proxysql做鏈接負(fù)載均衡（已解決）割接過程新問題修復(fù)2024年7月9號業(yè)務(wù)驗證與上線嘗試在查詢條件中多or，出現(xiàn)訪問Iceberg用老優(yōu)化器執(zhí)行(待解決)補丁包進(jìn)行兩次更新時區(qū)問題初步解決采用proxysql負(fù)載均衡問題出現(xiàn)，（每秒提交上萬setautocommit=1到數(shù)據(jù)庫）補丁包進(jìn)行兩次更新時區(qū)問題初步解決采用proxysql負(fù)載均衡問題出現(xiàn)，（每秒提交上萬setautocommit=1到數(shù)據(jù)庫）導(dǎo)致FE節(jié)點事務(wù)堆積異常使用2使用2.1.2版本問題：審計插件引起FE節(jié)點jvm異常，節(jié)點down掉，跨源Catalog訪問存在時區(qū)問題（差8小時）FE節(jié)點元數(shù)據(jù)同步異常，導(dǎo)致事務(wù)偶發(fā)性報tablet版本不一致的問題（已解決）MySQLCatalog的連接釋放機制問題，導(dǎo)致進(jìn)行堆積，達(dá)到上限侯引起訪問異常，2.1.5版本改造為Hikari連接池（已解決）改造實施開展OracleOracle改造優(yōu)化效益提升前期產(chǎn)品更傾向在大量新的核心功能前期產(chǎn)品更傾向在大量新的核心功能以及底層的優(yōu)化重構(gòu)，導(dǎo)致了穩(wěn)定性受到了影響。在2.1版本開始逐步進(jìn)行穩(wěn)定性打磨的傾斜和平衡。?更完備測試體系，積累了千萬量級的sql測試用例，提升測試覆蓋率和產(chǎn)品質(zhì)量；?通過混沌測試模擬各種故障場景，復(fù)刻社區(qū)用戶主動提供的場景，有幾十個長期運行的仿生產(chǎn)測試場景的長穩(wěn)測試場景；?更嚴(yán)格的PR準(zhǔn)入和feature開發(fā)流程，Doris2.1的開源測試suite比2.0增加了150%。數(shù)據(jù)數(shù)倉改造完成，實時類任務(wù)數(shù)據(jù)數(shù)倉改造完成，實時類任務(wù)效率提升3-5倍2.0.4到2.1.2平均任務(wù)效率提升2.1.2到2.1.5穩(wěn)定性提升超待探討的問題異構(gòu)化運營管理跨源訪問03湖倉一體實踐湖倉一體實踐經(jīng)歷的過程的需求和迭代11不夠完善，實時寫入小文件3湖倉一體架構(gòu)介紹湖倉核心組件基于電信自研大數(shù)據(jù)PaaS產(chǎn)品，組成由HA3+iceberg+Amoro+Spark/Flink+Doris為主的湖倉一體架構(gòu)應(yīng)用與引擎的選型?基于FlinkCDC自研實時入湖平臺，數(shù)據(jù)統(tǒng)一寫入Iceberg，對存在compaction問題由Doris預(yù)處理，對實時數(shù)倉需求核心數(shù)據(jù)同步寫入Doris?實時數(shù)倉匯聚、生產(chǎn)加工和應(yīng)用整體采用Doris完成，構(gòu)建實時庫?離線數(shù)倉統(tǒng)一匯聚、生產(chǎn)加工采用Flink/Spark?采用Doris，完成對BI報表、營銷等平臺對接，構(gòu)建數(shù)據(jù)集市湖倉一體（翼MR）HBASEHBASETelePGRedisESTeleDBTelePGRedisESTeleDBETLSparkJOBETLSparkJOBDoris/CK/Trino湖倉一體架構(gòu)深入建設(shè)業(yè)務(wù)系統(tǒng)原有的報表庫、運維庫從Oracle、PG、ES逐步改造到Doris，由此我們建了業(yè)務(wù)庫的專區(qū)計算資源使用不合理、不充分，對容器化彈性資源調(diào)度探索和應(yīng)用（目前還只是針對Spark&Flink，Doris在探討中）Iceberg對實時湖倉能力不足的問題，探索Paimon是否得到了解決（目前還在驗證，還未正式上線）04后續(xù)規(guī)劃探討Dor