基于 Apache Doris 的传统行业实时数仓建设实践

汪克忠平台软件研发部大数据技术架构师 目录 浪潮海岳数据中台介绍01 inDataX基于ApacheDoris的传统行业实时数仓建设实践02 未来思考与展望03 分享嘉宾–浪潮数字企业技术有限公司 汪克忠 平台软件研发部大数据技术架构师 浪潮海岳数据中台介绍 数字企业-浪潮海岳 企业ERP产品市场领先 创新理念行业先进 技术研发实力国家认可 中国aPaaS市场竞争力第一装备制造MES解决方案市场第一首创“财务云”概念 自研国内首个低代码开源模型UBML入选Forrester国内首份低代码报告有效发明专利417项，登记软著713项 承担国家核高基、863研发计划，国际先进国际标准3项、国家标准23项4个省部级重点实验室、创新平台 浪潮海岳inDataX企业采存治算用一体化数智平台 提供“采、存、治、算、用”的数据全生命周期管理工具及数据管理解决方案，打造五大核心数据能力，助力企业实现内外部数据高效汇聚，满足企业全方位、多类型数据采集需求，快速变现数据资产价值 数据应用 智能化数据呈现 百优案例检验的数据治理能力 大规模数据采集和存储能力 数据计算 某矿产集团：数据日采集量10亿条，36GB、时序总数据量18TB 数据治理 丰富多样的智能决策能力 安全可控的数据共享能力 数据存储 某水务、某能源：供水量预测、井下设备故障预警(省部级奖项)某省国资委：企业健康度评价模型 某省国资委：1.5亿条数据，委内13部门共享 浪潮海岳inDataX企业采存治算用一体化数智平台 inDataX基于Doris的传统行业实时数仓建设实践 传统行业实时数仓建设的难点 线下业务流程多 组织架构和权责管理严 业务流程审批过程多，线下审批多，流程慢业务流程涉及的权责部门多问题矫正周期长、依赖自上而下推动 影响面大，涉及国计民生、国家安全，权责管控严格条块化管理架构，行政上级和业务上级双重管理组织架构分层明显、层级划分细 信息化进程慢 应用和数据架构复杂 团队技术能力较弱，技术能力欠缺信息化起步晚、转型慢，新技术引进较为谨慎技术架构规划弱、治理能力弱，运维能力不足信创要求高，技术栈多样化，硬件、数据库种类多技术安全需求：不联网离线安装部署要求多 不同时期不同厂商建设，数据口径不一致基础设施较弱，硬件、网络资源少，性能相对不足行业专业化知识多，数据指标计算逻辑复杂流量低，查询QPS低，RT要求低场景复杂，设备、系统种类多，数据种类多、数据存储、共享方式不一致 为什么选择Doris 提供便捷的MultiCatalog兼容已有库表兼容MySQL协议，系统切换方便多种数据格式转储方式便捷高效支持信创服务器、CPU架构 联邦查询能力，直连，保持企业现有数据架构和设施不变数据种类支持多，支持半结构化、文件分析高维数据分析，适合专业化部门多(维度多)的场景运维相较于CK等简单便捷 数据分析性能强悍 技术栈自主可控 基于MPP架构超强的数据查询分析能力允许用户随意即席查询，响应快，不怕折腾向量化执行引擎、物化视图等多种内置优化策略 依赖Java和C++，技术栈自主可控，不受政经因素影响开源代码可根据不同信创场景进行适应性改造，国产化支撑能力可按照国产ARM硬件进行自主编译、离线安装，适合不联网的高安全需求企业 Doris Summit Asia 2024 inDataX实时数仓建设案例一：某能源集团数据治理 数据来源复杂 系统异构化严重、分散，链路长 数据计算需求复杂，查询入口多 有边缘端(煤矿)设备数据(MySQL、XML文件）、有集团端数据仓库(HDFS、Hive)、有分公司数据(集团同城数据，瀚高) 数据架构复杂，工具多，维护难，故障多原始指标简单，数仓数据加工链路长业务系统由不同厂商构建 业务专业化强，公式复杂，计算逻辑复杂数据质量依赖HiveSQL，执行效率慢在Hive、ES、MySQL多处提供查询，散乱 客户需求 •兼容已有Hadoop数仓•集成边缘端数据、分公司数据•提供即席查询能力，统一入口•复杂SQL分析能力(计算复杂逻辑) inDataX实时数仓建设案例一：某能源集团数据治理 统一查询计算中心 新建Doris集群作为统一分析和查询中心直连(只读)集团Hadoop和子公司异构数据库，不改变现有数据架构数据质量功能迁移至Doris跑批实现 (准)实时同步边缘数据 采用FlinkCDC同步边缘数据至集团侧DorisETL解析边缘XML文件数据同步至集团侧 Catalog连接子公司库 Catalog连接子公司库进行授权数据访问 inDataX实时数仓建设案例一：某能源集团数据治理 数据质量任务跑批性能提升 •原DQC由HiveSQL承担，改造后由DorisSQL承担，性能平均提升98%。 •Catalog读取原有架构，开闭式架构兼容；•Catalog替换ETL链路，架构更加简洁；•替换部分老架构组件(Presto等)；•查询入口全部由Doris承担、数仓和即席查询库统一。 inDataX实时数仓建设案例二：某港口集团数仓升级 孤岛系统化，隔离严重 Flink实时采集、计算 数据链路长 各业务系统隔离，未打通不同厂商建设、版本不统一 使用Flink做多系统join，大窗口join使用RDBMS做数仓供报表查询 组织架构臃肿、业务流程冗长、审批慢，数据在各系统中一致性差，T+N离线同步 •Flink流join为兼容不同系统时间差，大TTL•GC频繁，Flink节点宕机机概率较高•GC影响了数据流的传输，影响全链路时效性•RDBMS无法支撑复杂报表逻辑，报表任务卡死频繁，报表应用OOM频繁•链路SLA低，平均2次/月故障率 inDataX实时数仓建设案例二：某港口集团数仓升级 引入Doris，改善架构 •Doris表与业务系统表映射•Flink做一对一表数据同步•利用DorisAggregateModel实现数据仓内实时聚合•Doris承担报表查询SQL执行•固定报表业务改造：SQL由Oracle查询形式改为DorisSQL inDataX实时数仓建设案例二：某港口集团数仓升级 Flink集群TM宕机频率 •全链路(从业务发生到大屏数据生效平均时长)时效性提高60%。 •OOM引起的taskmanager节点宕机频率降低92%。 •FullGC频率下降80%。 inDataX实时数仓建设案例二：某港口集团数仓升级 SELECThelpdesk_ticket.id,--50+其他字段FROMhelpdesk_ticketLEFTJOIN(SELECTres_users.id,res_partner.name,res_users.loginFROMres_usersJOINres_partnerONres_partner.id=res_users.partner_id)ASusertabONusertab.id=helpdesk_ticket.User_idLEFTJOINhelpdesk_ticket_typeONhelpdesk_ticket_type.id=helpdesk_ticket.Ticket_type_idLEFTJOINhelpdesk_stageONhelpdesk_stage.id=helpdesk_ticket.Stage_idLEFTJOIN(SELECTmail_message.res_id,MIN(mail_tracking_value.new_value_datetime)ASfirstPlanfixdateFROMmail_messageLEFTJOINmail_tracking_valueONmail_tracking_value.mail_message_id=mail_message.idLEFTJOINhelpdesk_ticketONmail_message.res_id=helpdesk_ticket.idWHEREmail_tracking_value.field='plan_fix_date'GROUPBYmail_message.res_id)ASplan1fixdateONplan1fixdate.res_id=helpdesk_ticket.idWHERE… 单表千万数据量级场景下多表Join查询DorisMySQL 查询速度提升 inDataX基于Flink+Doris架构打造了实时数仓链路构建功能，在数据分析中做到多种数据库兼容，实时同步数据查询，将原数据库中的复杂SQL查询从10分钟级提升到秒级。 未来思考与展望 对Doris数据库的期望 ThanksforWatching！