共计 5704 个字符，预计需要花费 15 分钟才能阅读完成。
本文导读：
金融壹账通作为中国安全团体的联营公司，依靠安全团体 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 + Apache Kylin
在业务初期，咱们基于 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 模型， 具备高并发、低提早的计算能力，使节点间和节点内都可能并行执行，反对多个大表分布式 Shuffle Join，可能满足咱们对简单场景下多表关联查问的需要。
在利用方面，咱们重写了 MySQL 兼容的查问引擎，当应用指标平台进行查问时，不再须要借助架构 1.0 中 Apache Kylin 调用接口、从页面中点击重跑指标等一系列比拟繁琐的工作， 开发人员能够基于 Apache Doris 间接应用 MySQL 语法进行查问，极大简化了指标公布过程。
Apache Kylin vs. Apache Doris
咱们选取了指标平台常见的多表关联场景对 Apache Kylin 与 Apache Doris 进行性能比照，发现 Apache Doris 在查问性能与指标开发效率上体现都更为优异。如上图所示，Apache Doris 在数十万数据集关联状况下，查问响应根本达到毫秒级。同时，咱们不再须要期待 Apache Kylin 实现 Segment 构建后应用指标，指标公布从原来的均匀 30 分钟到当初的即发即用，显著晋升指标开发效率。
Apache Doris 的引入还大大节俭了指标存储空间，合乎团体降本的需要。团体外部的其余业务线（产险、寿险）也因而开始对 Apache Doris 进行铺开应用。新架构的降级不论是从硬件、人力、工夫上都实现了十分高效能的晋升，成为一体化数字指标平台建设的弱小后盾。
一体化指标数据平台
在架构降级实现后，咱们能够建设对立的指标体系，通过指标内容、BI 与 AI 技术构建平台性能，独特建设一体化指标数据平台。
构建指标体系
金融壹账通借助归因关系剖析帮忙机构自上而下对指标进行建设，梳理外围 KPI 并逐层拆建指标，保障指标体系的完整性与可落地性。依据指标生成的形式，将指标类型进行细分，以银行营销场景举例，针对银行资产治理中对客户资产总值的掂量指标（AUM）能够细分为以下三种类型：
- 原子指标：通过数据源接入到指标平台的最细粒度指标，个别为表字段，例如 AUM 余额。
- 衍生指标：为了进一步指标剖析，平台主动衍生一系列指标，如 AUM 同比、环比净增等。
- 派生指标：为了满足简单的指标剖析场景，基于原子指标，增加过滤条件或者联合其余指标进行运算，帮忙用户自助配置看板，节俭取数过程。例如用户心愿生成客均 AUM 余额进行剖析，平台能够借助原子指标 AUM 余额与全量客户数生成该指标。
构建指标平台性能
指标平台的性能实现次要依赖于 Apache Doris 数仓架构的反对，整体指标线上流程基于开发和业务配合实现。开发人员首先对立在平台进行元数据管理和指标录入，包含对加工报表的底表进行注册，配置两头表的数据粒度和更新频率等，接着对表进行关联、录入指标名称和指标口径信息。在输出指标根底信息之后，交由业务人员负责，抉择对指标剖析所需维度，对指标进行公布。
基于以上两个步骤，咱们能够在平台中对指标数据进一步剖析。如上图左侧所示，指标平台提供了各种柱状剖析视图，业务人员可能可视化地查看指标排行榜看板，剖析各银行分行 AUM 排名状况。同时，咱们融入了 AI 智能算法，借助时序模型检测指标异样，通过根因剖析算法辅助 KPI 检视，并剖析指标异动起因。对于存量指标，平台提供了价值评分体系，可能及时下线价值低的指标，达到边应用边治理的目标。
基于 Apache Doris 指标利用实际
一体化数据平台的建设齐全解决了金融壹账通在传统报表开发时指标口径不对立和指标反复计算的问题。在剖析效率方面，咱们心愿在简单的多表关联场景下，实现接口 600 毫秒响应工夫、查问响应在 100 毫秒内的指标。因而，咱们对 Apache Doris 进行了测试与调优，从数据的后期筹备、集群部署、模型调优三方面分享 Apache Doris 在该场景下的利用实际。
在后期数据筹备过程中，思考到咱们的数据集和官网测试的 SSB 数据集很类似，咱们抉择了官网举荐的开发测试环境配置，选用 Apache Doris 1.1 版本进行测试。因为咱们是通过 Python Mock 数据间接生成 CSV 文件，所以咱们采纳 Stream Load 的形式分批导数，每次导入的 CSV 文件都在 Stream Load 举荐的文件大小 1 – 10G 以内，最终数据压缩比达到 3 : 1，但单节点导入速度超过 40 MB /s。
在集群部署过程中，为了对指标性能和服务器监控（CPU、IO、磁盘和内存），咱们借助 Prometheus 导入 Apache Doris 监控模版对集群部署监控，由 Prometheus 接管 Apache Doris 裸露监控项，再借助 Grafana 进行可视化出现。
在筹备工作实现后即可开始进行大表关联查问，咱们抉择了耗时较长的 SQL 来查问指标趋势图。基于毫秒级查问指标，咱们施行了两个优化解决方案。第一个计划是利用 Colocation Join 将数据在建表时提前聚合。第二个计划是借助 Audit Loader 的形式收集高频 SQL，反向优化数仓的表构建以及改写 SQL，应用偏宽表设计代替之前的星型 / 雪花模型。通过两个计划的测试与评估，咱们发现第二个计划可能在查问响应、服务资源节俭中达到更加显著的收益。
亿级数据多表关联查问，实现毫秒级查问响应
咱们将 SQL 查问执行工夫进行了统计，如上图所示在采取计划一 Colocation Join 的形式时，查问响应工夫从之前的 5 秒晋升至 1 秒。尽管查问效率有所晋升，然而咱们心愿可能更进一步缩短响应工夫，实现预期指标。在采纳计划二来调整数据模型后，SQL 执行工夫从原来的 5 秒达到 63 毫秒响应工夫，查问响应工夫失去显著晋升，满足咱们对查问响应毫秒级的指标。
同时，咱们借助 Grafana 查看 Apache Doris 查问性能，发现宽表构建的计划可能使查问工夫从原来的十多秒缩短至百毫秒内，服务器也不再呈现抖动的状况。
启用 SQL 缓存，节俭服务器资源
采取宽表构建计划后，为了进一步晋升查问性能，咱们还启用了 SQL 缓存，帮忙 T+1 报表场景实现高效查问性能：
- 在启用缓存之后，根本所有查问时长都在个位数，最终达到单用户拜访页面在 4 秒内加载的成绩；
- 在 30 个指标同时进行时（SQL 指令超 120 条），接口都能够满足 600ms 内返回；
- 在并发场景下，最优 TPS 达到 300，CPU、内存、磁盘和 IO 满足 80% 以下；
- 经评估，咱们发现在官网举荐的测试集群规模下，Apache Doris 都能够缓存上万指标，极大节俭了资源。
将来布局
目前，金融壹账通基于 Apache Doris 实现了指标对立构建、查问、治理的一体化数据平台，为银行提供了全面的指标剖析与展现，智能的指标生命周期治理等服务。在这样的平台建设下， 团体内银行场景获得了十分显著的成绩，截止目前，实现上万沉闷指标、上千剖析维度的积攒，加工造成了上万个看板，缩小了 30 % ETL 开发工作量。 将来，公司将基于 Apache Doris 一直摸索与优化，咱们将重点推动以下几个方面的工作：
- 平台实时剖析 ： 基于 Apache Doris 构建湖仓一体，联合 Flink CDC、Apache Iceberg 独特构建对立实时剖析。
- 平台物化视图： 期待新版本亮点，摸索多表关联下的查问优化，比方构建多表物化视图。
- 其余产品迁徙： 将中台的其余产品迁徙至 Apache Doris。目前，标签平台基于 Elasticsearch 存在肯定的应用问题，将来咱们也筹备将该平台迁入 Apache Doris。
在此特别感谢 SelectDB 技术团队和 Apache Doris 社区在应用过程中遇到任何问题都能及时响应，为咱们升高了许多试错老本。将来，咱们也会更积极参与社区奉献及流动，与社区共同进步和成长！