目录

前言

一、业务痛点

二、早期架构挑战

三、架构升级

四、一体化指标数据平台

4.1 构建指标体系

4.2 构建指标平台功能

五、Doris指标应用实践

六、未来规划

---

  原文大佬的这篇指标中台的应用实践有借鉴意义，这里摘抄下来用作学习和知识沉淀。

前言

   在搭建数字化解决方案的过程中，面对传统报表制作过程中指标口径不统一、计算重复与交付效率低等痛点，金融壹账通决定基于Doris搭建一体化指标数据服务平台，实现指标的集中构建和管理，减少ETL开发工作量等业务目标。

一、业务痛点

 早期报表制作方式是由不同的业务线人员根据自己的业务范围，使用不同的分析工具去定义指标，这种传统的方式在跨业务合作时会带来两大痛点：

•  指标口径、标准不统一：各个业务线生成的报表及堆积如山，由于使用不同分析工具，使对接数据源多样复杂，导致指标口径互相打架的问题；
• 指标重复计算，交付效率低：开发流程需要业务方提出后，由IT人员下探到数据源并加工，再制作报表，上线验收。整个过程中，IT 需要和业务多次沟通进行信息同步，因此导致普通报表开发需要两周时间完成。

    为了解决这两大问题，集团内部决定自研一体化指标数据服务平台实现指标集中构建和管理。同时，使用 OLAP 查询引擎助力指标开发与应用，让业务人员能够快速找到所需数据，减少 ETL 开发工作量、缩短报表开发周期、加速指标发布与可视化看板生成的时间。

    在数据服务平台建设过程中，金融壹账通经历了两代数仓架构演进。第一代架构基于Kylin 预计算的方式查询指标数据，架构使用后发现其查询性能不足的问题。为了满足业务诉求，我们进一步开展 OLAP 选型调研，最终引入 Doris进行架构升级，借助Doris 的高性能分析能力为指标高效查询保驾护航。

   下问将介绍金融壹账通两代架构的演进过程，分享如何基于Doris 搭建指标统一构建、查询、治理的一体化数据平台，并在多表关联与高并发场景下实现毫秒级查询响应。

二、早期架构挑战

 架构 1.0 ：Hadoop + Presto + Apache Kylin

  在业务初期，我们基于Kylin进行T+1报表开发，上图是指标构建和查询的过程，在指标构建过程中，开发人员会根据选择的指标和维度进行SQL拼接，通过API调用 Kylin的方式对各个维度进行上卷计算，完成模型构建和数据加载。在指标查询的过程中，采用快速查询和下压查询的组合策略，如果查询字段命中Cube，可以在Kylin 直接查询；如果没有命中，则下压至 Presto 再进行查询。

     随着业务量不断增长，使用平台的业务用户越来越多，在面向客户推广与集团内部使用过程中，发现该架构在以下方面表现不足，无法满足我们的业务诉求：

• 灵活分析：Kylin预计算只能满足部分场景需求，没有办法满足更灵活的分析需求；

• 查询性能：当查询字段未命中 Cube 时，需要下压至 Presto。而 Presto 的查询性能得不到保障，特别是在查询码值的场景下，会遇到查询超时的现象，阻碍指标发布。

• 使用与运维成本：Kylin架构在查询与开发过程中需使用多套组件，造成了过高的维护成本。

    基于第一代架构的使用经验，需找到一个既可支持指标多表关联查询的场景，又可以达到降本增效的 OLAP 引擎。对比了当下比较热门的 OLAP 引擎进行系统选型，从多表关联场景、使用协议、使用成本、金融应用场景与案例四大方面进行比较。

• OLAP选型对比

     首先排除了 TiDB ，主要因为其更倾向于满足 TP 需求，在应对大数据量分析场景时性能相对不足。其次，我们也排除了 Clickhouse 和 Greenplum。由于 Greenplum 单机性能较差，不适用于我们的查询场景；Clickhouse 虽然在单表查询性能表现不错，但是不支持 MySQL 协议，多表 Join 无法发挥性能，因此两款产品均不能满足我们对于海量数据在多表关联场景下的查询诉求。

    发现Doris符合诉求，之后基于Doris 进行架构升级，主要原因如下：

• 开发简易方便：Doris不仅兼容 MySQL 协议，还能够支持标准的 SQL 语法使开发简单方便。

• 复杂场景多表关联查询性能：Doris 支持分布式 Join、明细聚合等方式，在进行多表 Join 时能够提供多种优化机制，提升查询效率。同时Doris还支持物化视图与索引功能来完成预计算效果，在命中物化视图时实现快速查询响应。

• 运维简单、方便扩展：Doris的整体部署只有 FE与 BE 两种角色，极大简化了架构链路，使架构无需再依赖其他组件，实现低成本运维。

三、架构升级

 架构 2.0 ：Apache Doris

    在数据迁移过程中，Doris替代了第一代架构中Kylin 与Presto，统一进行指标数据存储、处理、计算，并利用 Duplicate Key 模型对明细数据进行查询，使用Range进行时间分区并制定维度关联键作为 Key，有效解决了早期架构中Presto明细查询时性能不足、并发不够的痛点。同时，Doris 在查询引擎方面采用了MPP模型，具备高并发、低延迟的计算能力，使节点间和节点内都能够并行执行，支持多个大表分布式 Shuffle Join，能够满足我们对复杂场景下多表关联查询的需求。

   在应用方面，我们重写了 MySQL 兼容的查询引擎，当使用指标平台进行查询时，不再需要借助架构 1.0 中Kylin 调用接口、从页面中点击重跑指标等一系列比较繁琐的工作，开发人员可以基于 Doris直接使用 MySQL 语法进行查询，极大简化了指标发布过程。

四、一体化指标数据平台

     在架构升级完成后，我们可以建设统一的指标体系，通过指标内容、BI 与 AI 技术构建平台功能，共同建设一体化指标数据平台。

4.1 构建指标体系

    金融壹账通借助归因关系分析帮助机构自上而下对指标进行建设，梳理核心 KPI 并逐层拆建指标，保障指标体系的完整性与可落地性。根据指标生成的方式，将指标类型进行细分，以银行营销场景举例，针对银行资产管理中对客户资产总值的衡量指标（AUM）可以细分为以下三种类型：

• 原子指标：通过数据源接入到指标平台的最细粒度指标，一般为表字段，例如 AUM 余额。

• 衍生指标：为了进一步指标分析，平台自动衍生一系列指标，如 AUM 同比、环比净增等。

• 派生指标：为了满足复杂的指标分析场景，基于原子指标，添加过滤条件或者结合其他指标进行运算，帮助用户自助配置看板，节省取数过程。例如用户希望生成客均 AUM 余额进行分析，平台可以借助原子指标 AUM 余额与全量客户数生成该指标。

4.2 构建指标平台功能

   指平台的功能实现主要依赖于Doris 数仓架构的支持，整体指标线上流程基于开发和业务配合完成。开发人员首先统一在平台进行元数据管理和指标录入，包括对加工报表的底表进行注册，配置中间表的数据粒度和更新频率等，接着对表进行关联，录入指标名称和指标口径信息。在输入指标基础信息之后，交由业务人员负责，选择对指标分析所需维度，对指标进行发布。

   基于以上两个步骤，我们可以在平台中对指标数据进一步分析。如上图左侧所示，指标平台提供了各种柱状分析视图，业务人员能够可视化地查看指标排行榜看板，分析各银行分行 AUM 排名情况。同时，我们融入了 AI 智能算法，借助时序模型检测指标异常，通过根因分析算法辅助 KPI 检视，并分析指标异动原因。对于存量指标，平台提供了价值评分体系，能够及时下线价值低的指标，达到边使用边治理的目的。

五、Doris指标应用实践

  一体化数据平台的建设完全解决了金融壹账通在传统报表开发时指标口径不一致和指标重复计算的问题。在分析效率方面，我们希望在复杂的多表关联场景下，实现接口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 缓存，节省服务器资源

     采取宽表构建方案后，为了进一步提升查询性能，我们还启用了 SQL 缓存，帮助 T+1 报表场景实现高效查询性能：

• 在启用缓存之后，基本所有查询时长都在个位数，最终达到单用户访问页面在 4 秒内加载的成果；
• 在 30 个指标同时进行时（SQL 指令超 120 条），接口都可以满足 600ms 内返回；
• 在并发场景下，最优 TPS 达到 300， CPU、内存、磁盘和 IO 满足 80% 以下；
• 经评估，我们发现在官网推荐的测试集群规模下，Doris 都可以缓存上万指标，极大节省了资源

六、未来规划

    目前，金融壹账通基于Doris 实现了指标统一构建、查询、治理的一体化数据平台，为金融机构提供了全面的指标分析与展示，智能的指标生命周期管理等服务。在这样的平台建设下，集团内外多场景取得了非常显著的成果，截止目前，完成上万活跃指标、上千分析维度的积累，加工形成了上万个看板，减少了30 % ETL开发工作量。未来，公司将基于Doris 不断探索与优化，我们将重点推进以下几个方面的工作：

• 平台实时分析：基于Doris 构建湖仓一体，结合 Flink CDC、Apache Iceberg 共同构建统一实时分析。
• 平台物化视图：期待新版本亮点，探索多表关联下的查询优化，比如构建多表物化视图。
• 其他产品迁移：将中台的其他产品迁移至Doris，目前，标签平台基于 Elasticsearch 存在一定的使用问题，未来我们也准备将该平台迁入Doris。

参考文章：

Apache Doris 在金融壹账通指标中台的应用实践