浙江电信Apache Doris实战之路

浙江电信 Apache Doris 实战之路浙江电信-大数据中心喻志强喻志强 浙江电信大数据中心平台侧负责人，资深通信运营商数据仓库和大数据平台建设专家分享嘉宾 - 中国电信浙江公司目录大数据建设历程01Apache Doris 实践02湖仓一体实践03后续规划探讨0401大数据建设历程浙江电信大数据平台建设历程建设内容：基于 Teradata 建设B域数据仓库与数据集市应用规模：20台支持存储：400TB建设内容：构建数据中台能力，基于中台开展作业、模型、报表迁移，数据治理及培训推广工作，并实现开发运营模式优化。规模：20+台建设内容：深化湖仓一体/流批一体架构应用，基于 Doris 构建查询库、BSS 运维库，深化Doris使用，完成从2.0.x到2.1.x版本实践规模：Doris 达到80节点建设内容：实时经分和网络大数据集群，基于 CDH 构建人力、业务稽核、网管、端到端应用、跨域分析等应用。规模：700+台支持存储：20PB建 设 内 容 ： 基 于 电 信 自 研 P a a S 翼MR/TDP+Iceberg+Doris 新建湖仓一体架构进行BMO域数据统一汇聚。逐步转型为以自有人员为主。规模：640+台20042016202120242023基于 Apache Doris 湖仓一体架构演进原有平台架构图基于 Apache Doris 湖仓一体架构（翼MapReduce）SparkTezFlinkHDFSKUDUHiveimpalaYarnMR数据孤岛数据冗余数据一致性运营成本高Vertica经分大数据数据仓库存储计算kyuubi/SparkFlinkHDFS............Iceberg/HiveDorisAmoroZookeeperRangerL D A PYarnMRESHBaseK a f k a流批一体运营便捷场景覆盖更全灵活可控Vertica数据集市02Apache Doris 实践实时数仓上线持续使用与深度保障 割接后新问题修复割接过程新问题出现首次生产尝试不断提升 逐步演化使用2.0.1版本问题：主要体现在与已有 BI 和数据中台适配性问题，如<=>符号识别异常报表性能较差、中台 FlinkSQL 采集任务适配问题，数据丢失Catalog 访问 Iceberg 大小写敏感、BE 节点 rpc 超时、BE 节点频繁掉落等问题迭代到2.0.3版本后解决2023年11月2024年1月-2月2023年11月-12月割接后遇到 jvm 溢出问题，导致集群变慢、在经历多次日志、火焰图排查、小版本迭代等方式2月2号更新到2.0.4版本稳定运行2024年2月—至今Doris数据写 Iceberg（已解决）Doris读取 Iceberg v2表数据量对应不上（待解决）SQL 内存溢出问题（已解决）Catalog访问 Iceberg data 类型查询返回空值问题（已解决）多次 count(*) 一张静态表数据量变化 bug 等-字段全为主键表（已解决）暴露 localshuffle 问题，导致集群故障，目前关闭此参数（待完全解决）2.1.x 相比 2.0.x，整体性能上提升了 30-50%2.1.5 相比 2.1.2，稳定性提升超 30%2.1.*2.0.42.0.32.0.1查询集市库上线持续使用与深度保障 割接过程新问题修复业务验证与上线尝试不断提升 逐步演化使用2.1.2版本问题：审计插件引起 FE 节点 jvm 异常，节点 down 掉，跨源 Catalog 访问存在时区问题（差8小时）补丁包进行两次更新时区问题初步解决采用 proxysql 负载均衡问题出现，（每秒提交上万 set autocommit=1到数据库）导致 FE 节点事务堆积异常2024年7月9号2024年8月8号2024年8月9号—至今使用 haproxysql 替换 proxysql 做链接负载均衡（已解决）在查询条件中多 or，出现访问 Iceberg 用老优化器执行(待解决)split_by_string 函数处理之后的值，无法法再用 array 相关函数处理，会报错（已解决）FE 节点元数据同步异常，导致事务偶发性报 tablet 版本不一致的问题（已解决）MySQL Catalog 的连接释放机制问题，导致进行堆积，达到上限侯引起访问异常， 2.1.5 版本改造为 Hikari 连接池（已解决）2.1.52.1.2-rc022.1.2改造实施开展ImpalaOracleVertica改造优化效益提升Impala+kuduDoris2.0数据数仓改造完成，实时类任务效率提升 3-5 倍Doris2.0.4Doris2.1.22.0.4到2.1.2平均任务效率提升 30%Doris2.1.2Doris2.1.52.1.2到2.1.5稳定性提升超30%，性能下降 5%-10%前期产品更倾向在大量新的核心功能以及底层的优化重构，导致了稳定性受到了影响。在 2.1 版本开始逐步进行稳定性打磨的倾斜和平衡。• 更完备测试体系，积累了千万量级的 sql 测试用例，提升测试覆盖率和产品质量；• 通过混沌测试模拟各种故障场景，复刻社区用户主动提供的场景，有几十个长期运行的仿生产测试场景的长稳测试场景；• 更严格的 PR 准入和 feature 开发流程，Doris 2.1 的开源测试 suite 比 2.0 增加了 150%。待探讨的问题异构化运营管理跨源访问03湖仓一体实践湖仓一体实践经历的过程312主要在 compaction 能力不够完善，实时写入小文件问题引起读问题突出，Amoro 的选择•数据湖组件方案 Hudi、Iceberg、Delta Lake•应用场景和计算引擎选择 Spark / Flink， MPP 引擎 Doris、Clickhouse 等•Doris 对 Iceberg v2表读写能力的需求和迭代•Doris 跨源访问的能力需求Iceberg & Amoro湖仓组件选型Doris & Iceberg• 基于 FlinkCDC 自研实时入湖平台，数据统一写入 Iceberg，对存在 compaction 问题由 Doris 预处理，对实时数仓需求核心数据同步写入 Doris• 实时数仓汇聚、生产加工和应用整体采用 Doris 完成，构建实时库• 离线数仓统一汇聚、生产加工采用Flink/Spark• 采用 Doris，完成对 BI 报表、营销等平台对接，构建数据集市应用与引擎的选型基于电信自研大数据 PaaS 产品，组成由 HA3+iceberg+Amoro+Spark/Flink+Doris 为主的湖仓一体架构湖仓核心组件湖仓一体架构介绍Spark JOB（批）Flink JOB（流）HA3IcebergSpark（kyuubi)/FlinkDoris/CK/TrinoETL湖仓一体（翼MR）ODSDWDDWSADSTeleDBTelePGESHBASERedisAmoro湖仓一体架构深入建设业务系统原有的报表库、运维库从 Oracle、PG、ES 逐步改造到 Doris，由此我们建了业务库的专区计算资源使用不合理、不充分，对