作者：金融壹账通数据挖掘工程师，兰后
导读：金融壹账通作为中国平安集团的联营公司，依托平安集团30多年金融行业的丰富经验及自主科研能力，向客户提供“横向一体化、纵向全覆盖”的整合产品，以“技术+业务”为独特竞争力，帮助客户提升效率、提升服务、降低成本、降低风险，实现数字化转型。在搭建数字化解决方案的过程中，面对传统报表制作过程中指标口径不统一、计算重复与交付效率低等痛点，金融壹账通决定基于Apache Doris搭建一体化指标数据服务平台，实现指标集中构建和管理、减少ETL 开发工作量等业务目标。本文将详细介绍金融壹账通两代架构的演进过程，分享数据服务平台的建设经验与应用实践，向大家展示如何基于Apache Doris在多表关联与高并发场景下实现毫秒级查询响应。
金融壹账通是面向金融机构的商业科技服务提供商(Technology-as-a-Service Provider),为国家高新技术企业。作为中国平安集团的联营公司，金融壹账通依托平安集团30 多年金融行业的丰富经验及自主科研能力，向客户提供“横向一体化、纵向全覆盖”的整合产品，包括数字化银行、数字化保险和提供金融科技数字基础设施的加马平台，以“技术+业务”为独特竞争力，帮助客户提升效率、提升服务、降低成本、降低风险，实现数字化转型。
业务痛点
在搭建数字化解决方案过程中，我们主要利用指标(如银行经营业绩指标：客户AUM) 来直观地反映企业经营状态，通过指标开发报表以帮助业务人员进行数据分析，进而驱动管理决策、赋能数字化经营。我们早期的报表制作方式是由不同的业务线人员根据自己的业务范围，使用不同的分析工具去定义指标，这种传统的方式在跨业务合作时会带来两大痛点：
● 指标口径、标准不统一：各个业务线生成的报表堆积如山，由于使用不同分析工具，使对接数据源多样复杂，导致指标口径相互打架的问题。
● 指标计算重复、交付效率低：开发流程需要业务方提出后，由IT 人员下探数据源并加工，再制作报表、上线验收。整个过程中，IT 需要和业务多次沟通来同步信息，导致普通报表开发需要两周时间完成。
为了解决这两大问题，我们集团内部决定自研一体化指标数据服务平台，通过建立指标体系贴合客户战略目的，借助服务平台规范开发流程和使用方式，实现指标集中构建和管理。同时，使用OLAP 查询引擎助力指标开发与应用，让业务人员能够快速找到所需数据，减少ETL 开发工作量、缩短报表开发周期、加速指标发布与可视化看板生成的时间。
在数据服务平台建设过程中，金融壹账通经历了两代数仓架构演进。第一代架构基于 Apache Kylin 预计算的方式查询指标数据，并在架构使用后，发现其查询性能不足的问题。为了满足业务诉求，我们进一步开展OLAP 选型调研，最终引入Apache Doris 进行架构升级，借助Apache Doris 的高性能分析能力为指标高效查询保驾护航。
本文将详细介绍金融壹账通两代架构的演进过程，分享如何基于 Apache Doris 搭建指标统一构建、查询、治理的一体化数据平台，并在多表关联与高并发场景下实现毫秒级查询响应。
早期架构挑战
架构1.0:Hadoop+Presto +ApacheKylin 
在业务初期，我们基于 Apache Kylin 进行 T+1 报表开发，上图是指标构建和查询的过程。在指标构建过程中，开发人员会根据选择的指标和维度进行SQL 拼接， 通过 API 调用 Apache Kylin 的方式对各个维度进行与计算，完成模型构建和数据加载。在指标查询的过程中，采用快速查询和下压查询的组合策略，如果查询字段命中 Cube, 我们可以在 Apache Kylin 直接查询；如果没有命中，则下压至 Presto 再进行查询。
随着业务量不断增长，使用平台的业务用户越来越多，在面向客户推广与集团内部使用过程中，我们发现该架构在以下方面表现不足，无法满足我们的业务诉求：
● 灵活分析：Apache Kylin 预计算只能满足部分场景需求，没有办法满足更灵活的分析需求。
● 查询性能：当查询字段未命中Cube时，需要下压至Presto。而 Presto的查询性能得不到保障，特别是在查询码值的场景下，会遇到查询超时的现象，阻碍指标发布。
● 使用与运维成本： Apache Kylin 架构在查询与开发过程中需要使用多套组件，造成了过高的维护成本。
基于第一代架构的使用经验，我们急需找到一个既可支持指标多表关联查询的场景，又可以达到降本增效的OLAP 引擎。带着这样的诉求，我们对比了当下比较热门的 OLAP引擎进行系统选型，从多表关联场景、使用协议、使用成本、金融应用场景与案例四大方面进行比较。
OLAP 选型对比 
我们首先排除了 TiDB, 主要因为其更倾向于满足TP需求，在应对大数据量分析场景时性能相对不足。其次，我们也排除了 Clickhouse 和 Greenplum。由于Greenplum 单机性能较差，不适用于我们的查询场景；Clickhouse 虽然在单表查询性能表现不错，但是不支持 MySQL 协议，多表 Join 无法发挥性能，因此两款产品均不能满足我们对于海量数据在多表关联场景下的查询诉求。
最终，在集团内部其他子公司的使用反馈与推荐下，我们发现 Apache Doris 非常符合我们的诉求，并坚定不移地选择Apache Doris进行架构升级，主要原因如下：
● 开发简易方便：Apache Doris 不仅兼容 MySQL 协议，还能够支持标准的 SQL 查询语法使开发简单方便。
● 复杂场景多表关联查询性能：Apache Doris 支持分布式Join 、明细聚合等方式，在进行多表Join时能够提供多种优化机制，提升查询效率。同时Apache Doris还支持物化视图与索引功能来完成预计算效果，在命中物化视图时实现快速查询响应。
●运维简单、方便扩展： Apache Doris 的整体部署只有 FE 与 BE 两种角色，极大简化了架构链路，使架构无需再依赖其他组件，实现低成本运维。
基于Apache Doris 架构升级
架构2.0:Apache Doris 
基于 Apache Doris 的性能优势，我们从数据迁移和应用两方面进行了架构升级。在数据迁移过程中，Apache Doris 替代了第一代架构中 Apache Kylin 与 Presto, 统一进行指标数据存储、处理、计算，并利用 Duplicate Key 模型对明细数据进行查询，使用 Range 进行时间分区并制定维度关联键作为 Key,有效解决了早期架构中Presto 明细查询时性能不足、并发不够的痛点。同时， Apache Doris在查询引擎方面采用了MPP 模型，具备高并发、低延迟的计算能力，使节点间和节点内都能够并行执行，支持多个大表分布式ShuffleJoin,能够满足我们对复杂场景下多表关联查询的需求。
在应用方面，我们重写了MySQL 兼容的查询引擎，当使用指标平台进行查询时，不再需要借助架构1.0 中Apache Kylin 调用接口、从页面中点击重跑指标等一系列比较繁琐的工作，开发人员可以基于Apache Doris 直接使用MySQL 语法进行查询，极大简化了指标发布过程。
ApacheKylin vs.ApacheDoris
我们选取了指标平台常见的多表关联场景对Apache Kylin与 Apache Doris 进行性能对比，发现Apache Doris在查询性能与指标开发效率上表现都更为优异。如上图所示，Apache Doris在数十万数据集关联情况下，查询响应基本达到毫秒级。同时，我们不再需要等待Apache Kylin 完成Segment 构建后使用指标，指标发布从原来的平均30分钟到现在的即发即用，显著提升指标开发效率。
Apache Doris 的引入还大大节省了指标存储空间，符合集团降本的需求。集团内部的其他业务线(产险、寿险)也因此开始对 Apache Doris 进行铺开使用。新架构的升级不论是从硬件、人力、时间上都实现了非常高效能的提升，成为一体化数字指标平台建设的强大后盾。
更多精彩内容，欢迎观看
带你读《Apache Doris 案例集》——03 Apache Doris 在金融壹账通指标中台的应用实践（2）:https://developer.aliyun.com/article/1405767
