赞
踩
目录
原文大佬的这篇指标中台的应用实践有借鉴意义,这里摘抄下来用作学习和知识沉淀。如有侵权请告知~
在搭建数字化解决方案的过程中,面对传统报表制作过程中指标口径不统一、计算重复与交付效率低等痛点,金融壹账通决定基于Doris搭建一体化指标数据服务平台,实现指标的集中构建和管理,减少ETL开发工作量等业务目标。
早期报表制作方式是由不同的业务线人员根据自己的业务范围,使用不同的分析工具去定义指标,这种传统的方式在跨业务合作时会带来两大痛点:
为了解决这两大问题,集团内部决定自研一体化指标数据服务平台实现指标集中构建和管理。同时,使用 OLAP 查询引擎助力指标开发与应用,让业务人员能够快速找到所需数据,减少 ETL 开发工作量、缩短报表开发周期、加速指标发布与可视化看板生成的时间。
在数据服务平台建设过程中,金融壹账通经历了两代数仓架构演进。第一代架构基于Kylin预计算的方式查询指标数据,架构使用后发现其查询性能不足的问题。为了满足业务诉求,进一步开展 OLAP 选型调研,最终引入 Doris进行架构升级,借助Doris 的高性能分析能力为指标高效查询保驾护航。
下问将介绍金融壹账通两代架构的演进过程,分享如何基于Doris 搭建指标统一构建、查询、治理的一体化数据平台,并在多表关联与高并发场景下实现毫秒级查询响应。
架构 1.0 :Hadoop + Presto + Apache Kylin
在业务初期,我们基于Kylin进行T+1报表开发,上图是指标构建和查询的过程,在指标构建过程中,开发人员会根据选择的指标和维度进行SQL拼接,通过API调用 Kylin的方式对各个维度进行上卷计算,完成模型构建和数据加载。在指标查询的过程中,采用快速查询和下压查询的组合策略,如果查询字段命中Cube,可以在Kylin 直接查询;如果没有命中,则下压至 Presto 再进行查询。
随着业务量不断增长,使用平台的业务用户越来越多,在面向客户推广与集团内部使用过程中,发现该架构在以下方面表现不足,无法满足我们的业务诉求:
基于第一代架构的使用经验,需找到一个既可支持指标多表关联查询的场景,又可以达到降本增效的 OLAP 引擎。对比了当下比较热门的 OLAP 引擎进行系统选型,从多表关联场景、使用协议、使用成本、金融应用场景与案例四大方面进行比较。
首先排除了 TiDB ,主要因为其更倾向于满足 TP (事务,点查场景)需求,在应对大数据量分析场景时性能相对不足。其次也排除了 Clickhouse 和 Greenplum。由于 Greenplum 单机性能较差,不适用于查询场景;Clickhouse 虽然在单表查询性能表现不错,但是不支持 MySQL 协议,多表Join无法发挥性能,因此两款产品均不能满足对于海量数据在多表关联场景下的查询诉求。
发现Doris符合诉求,之后基于Doris 进行架构升级,主要原因如下:
架构 2.0 :Apache Doris
在数据迁移过程中,Doris替代了第一代架构中Kylin 与Presto,统一进行指标数据存储、处理、计算,并利用 Duplicate Key 模型对明细数据进行查询,使用Range进行时间分区并制定维度关联键作为 Key,有效解决了早期架构中Presto明细查询时性能不足、并发不够的痛点。同时,Doris 在查询引擎方面采用了MPP模型,具备高并发、低延迟的计算能力,使节点间和节点内都能够并行执行,支持多个大表分布式 Shuffle Join,能够满足对复杂场景下多表关联查询的需求。
在应用方面,重写了 MySQL 兼容的查询引擎,当使用指标平台进行查询时,不再需要借助架构 1.0 中Kylin 调用接口、从页面中点击重跑指标等一系列比较繁琐的工作,开发人员可以基于 Doris直接使用 MySQL 语法进行查询,极大简化了指标发布过程。
在架构升级完成后,可以建设统一的指标体系,通过指标内容、BI 与 AI 技术构建平台功能,共同建设一体化指标数据平台。
金融壹账通借助归因关系分析帮助机构自上而下对指标进行建设,梳理核心 KPI 并逐层拆建指标,保障指标体系的完整性与可落地性。
根据指标生成的方式,将指标类型进行细分,以银行营销场景举例,针对银行资产管理中对客户资产总值的衡量指标(AUM)可以细分为以下三种类型:
指平台的功能实现主要依赖于Doris 数仓架构的支持,整体指标线上流程基于开发和业务配合完成。开发人员首先统一在平台进行元数据管理和指标录入,包括对加工报表的底表进行注册,配置中间表的数据粒度和更新频率等,接着对表进行关联,录入指标名称和指标口径信息。在输入指标基础信息之后,交由业务人员负责,选择对指标分析所需维度,对指标进行发布。
基于以上两个步骤,我们可以在平台中对指标数据进一步分析。如上图左侧所示,指标平台提供了各种柱状分析视图,业务人员能够可视化地查看指标排行榜看板,分析各银行分行 AUM 排名情况。同时,我们融入了 AI 智能算法,借助时序模型检测指标异常,通过根因分析算法辅助 KPI 检视,并分析指标异动原因。对于存量指标,平台提供了价值评分体系,能够及时下线价值低的指标,达到边使用边治理的目的。
一体化数据平台的建设完全解决了金融壹账通在传统报表开发时指标口径不一致和指标重复计算的问题。在分析效率方面,希望在复杂的多表关联场景下,实现接口600毫秒响应时间、查询响应在100毫秒内的目标。因此对Doris进行了测试与调优,从数据的前期准备、集群部署、模型调优三方面分享Doris 在该场景下的应用实践。
在前期数据准备过程中,考虑到数据集和官网测试的 SSB 数据集很相似,选择了官网推荐的开发测试环境配置,选用Doris 1.1 版本进行测试。因为是通过 Python Mock 数据直接生成 CSV 文件,所以采用Stream Load的方式分批导数,每次导入的CSV 文件都在Stream Load 推荐的文件大小 1 - 10G 以内,最终数据压缩比达到 3 : 1 ,但单节点导入速度超过 40 MB /s。
在集群部署过程中,为了对指标性能和服务器监控(CPU、IO、磁盘和内存),借助 Prometheus导入Doris 监控模版对集群部署监控,由 Prometheus 接收Doris 暴露监控项,再借助 Grafana 进行可视化呈现。
在准备工作完成后即可开始进行大表关联查询,我们选择了耗时较长的 SQL 来查询指标趋势图。基于毫秒级查询目标,我们实施了两个优化解决方案。第一个方案是利用 Colocation Join 将数据在建表时提前聚合。第二个方案是借助 Audit Loader 的方式收集高频 SQL,反向优化数仓的表构建以及改写 SQL,使用偏宽表设计代替之前的星型 / 雪花模型。通过两个方案的测试与评估,我们发现第二个方案能够在查询响应、服务资源节省中达到更加显著的收益。
将 SQL 查询执行时间进行了统计,如上图所示在采取方案一 Colocation Join 的方式时,查询响应时间从之前的 5 秒提升至 1 秒。虽然查询效率有所提升,但是希望能够更进一步缩短响应时间,完成预期目标。在采用方案二来调整数据模型后,SQL 执行时间从原来的 5 秒达到 63 毫秒响应时间,查询响应时间得到显著提升,满足我们对查询响应毫秒级的目标。
同时借助 Grafana 查看Doris 查询性能,发现宽表构建的方案能够使查询时间从原来的十多秒缩短至百毫秒内,服务器也不再出现抖动的情况。
采取宽表构建方案后,为了进一步提升查询性能,还启用了SQL缓存,帮助 T+1 报表场景实现高效查询性能:
目前,金融壹账通基于Doris 实现了指标统一构建、查询、治理的一体化数据平台,为金融机构提供了全面的指标分析与展示,智能的指标生命周期管理等服务。在这样的平台建设下,集团内外多场景取得了非常显著的成果,截止目前,完成上万活跃指标、上千分析维度的积累,加工形成了上万个看板,减少了30 % ETL开发工作量。未来,公司将基于Doris 不断探索与优化,将重点推进以下几个方面的工作:
参考文章:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。