产研最前线｜分贝通在线数据分析体系构建

在数字化浪潮下，“软件+支付”的“分贝通模式”已经成为越来越多企业推动自身支出管理改造升级的首选。从多银行账户到利用强大支付引擎实现“一个账户”管理企业所有费用，从财务多系统、离散化管理到“一个平台”形成的专属财务OS，从传统、手动的Excel式数据分析，到依托AI、大数据等前沿技术穿透每一个员工的因公消费习惯...这些企业支出管理数字化改造成功实践的背后，除了对行业痛点的准确洞察外，也离不开先进且坚实的硬核技术保障。

作为企业支出管理的先行者，分贝通从成立之初便迅速搭建起一支技术过硬的产研团队。如今，在商务消费、办公采购、补助福利、备用金、员工报销、对公付款6大场景，分贝通为客户提供兼具效率和效果的管理，均需要依托分贝通产研人严密的底层技术逻辑和架构、一次次测试和多类技术能力的精巧组合。

分贝通特设【产研最前线】专栏，将目光落于分贝通产品、大前端、后端、质量保障、大数据、AI算法等层级的技术前线，从一串串代码深处探索分贝通的这批SaaS极客，如何用0和1构建起坚固的企业支出管理数字化基础设施。

首期聚焦「数据分析功能」背后的技术实践。

对于提供企业服务的公司而言，数据分析对客户来说是一个强需求，为客户提供强大的在线数据分析能力也是整个行业的共识，甚至很多企业愿意为此能力单独买单。企业依托于其在线分析能力，可以进行快速的数据探查，甚至可以结合自身已有的数据源进行整合分析，发现自身企业内部某些制度或流程方面的问题。拿财务举例，传统的数据分析多数是通过线下 Excel 统计的方式进行，可能存在数据获取困难、数据清洗难度高、耗时长、可视化过程复杂度高、问题定位周期长等各类问题，而快捷的在线分析能力，可以让财务告别这些痛点，迅速获取关键信息，提高财务决策能力。

如今数据分析功能不仅产生了线上化趋势，对易用性和有效性的要求也越来越高，而这离不开底层合理的技术架构和优秀的技术能力支撑。分贝通作为一家企业支出管理领域的 SaaS 企业，深度洞察到客户企业在数据分析方面的迫切诉求和传统分析模式的桎梏。基于此，分贝通产研团队基于自身大数据技术架构优势，通过集成嵌入式BI 能力，建立了一套既能满足客户日益增长的大数据分析需求，又能实现客户数据自动隔离的在线数据分析体系，全面提升客户企业财务数据分析的便捷性、有效性，同时确保数据安全性。

技术架构

一套完备的在线数据分析体系至少需要具备以下能力：

• 多维分析能力，包括从多个维度进行统计分析、图表联动、图表上卷下钻等。

• 数据权限控制，可以根据企业内部需求，不同角色看到不同的报表，或者同一个报表看到不同的数据。

• 数据安全隔离，不同公司之间的数据是完全隔离的，只能通过私有链接访问。

• 用户分析体验，基本上所有的报表响应速度应该在3S以内，甚至1S以内。

传统的“前后端+业务数据库”报表开发模式开发周期长，与业务高度耦合，不利于产品的快速迭代，无法适应客户灵活多变的数据分析需求。我们目前采用的架构是嵌入式BI架构（图1），这也是目前一种典型的在线数据分析体系架构，共包含四大模块：底层数据加工层、OLAP 引擎、BI 展现层和前端页面，并可以实现各个模块解耦（可以根据实际情况更改任何一个模块的技术实现方案）：

• 底层数据加工，依托数据仓库能力，如借助离线数仓进行跑批计算，定时刷新报表数据，甚至可以实现实时计算和刷新。

• OLAP 引擎，采用可扩展的大规模并行处理（MPP）架构和分布式处理 SQL，支持每秒数十万 QPS 高性能服务型点查。

• BI 展现层，采用自研或第三方 BI 工具，根据业务逻辑灵活配置所展示报表内容，实现可视化、低代码，降低开发人员使用门槛，缩短开发迭代周期。

• 前端页面利用网页或 iframe 内嵌 BI 展现层，通过报表地址 API 提供动态获取报表页面功能。

我们具体的实现方案是，底层数据加工依托于已有的云端阿里云数据仓库，OLAP 引擎选用的是阿里云端的 HATP 数据库 Hologres，BI 引擎选用的是国内衡石科技的 HENGSHI SENSE 云端私有化部署版本。前端页面主要解决BI报表的嵌入及权限认证的过程，在数据安全里重点描述。

下面对后端的三个模块分别进行细节阐述。

1.1 底层数据加工 

我们致力于建设一套完善的指标管理体系，将大量的明细数据结合业务逻辑加工封装为指标供上层应用使用，这样既有效避免前端数据量过大，浪费计算和存储资源，同时有利于指标的沉淀和复用，防止指标定义不统一。对于个别无法预计算的指标（需要根据前端的查询条件进行实时汇总），比如某时间段内的访问 UV 或者去重订单数这样的指标，只能提供明细数据，每次查询时根据前端输入的筛选条件实时进行计算。

针对每一个指标，其命名定义、计算逻辑、空值率以及其他相关的数据质量标准在上线前都会经过严格的内部评审和测试。指标发布上线后，某一个或者某几个指标由于业务需要发生变化，其影响范围可以准确预估。而指标的跨看板复用，则可以做到只要修改一处指标的计算逻辑，所有使用它的看板都可以随之同步。

指标加工的过程和其他数据仓库ETL过程无异，这里就不再赘述。 

1.2 OLAP 引擎

Hologres 是阿里巴巴自主研发的一站式实时数仓引擎（Real-Time Data Warehouse），支持海量数据实时写入、实时更新、实时分析，支持PB级数据多维分析（OLAP）。起初我们考虑数据存储采用外部表同步数仓数据，该方案具有无额外存储成本、Schema 维护成本低、数据自动同步等优点，但在测试时，我们发现其查询效率存在严重问题，达到秒级（跟配置有关），且 OLAP 连接数有限，在 BI 查询队列满后会出现报表服务中断的情况。于是我们将外部表切换为内部表，用存储换取效率，并对关键字段建立索引，查询效率提升至毫秒级。对于数据更新任务，我们也进行一些优化措施，如图2所示。通过复用数据仓库调度引擎，建立临时外部表，创建临时内部表后替换，由 OLAP 引擎侧拉取数据仓库数据，而非由数据仓库刷写 OLAP 数据表，充分发挥 OLAP 事务操作的 ACID 特性，在保证服务不中断的同时，将数据更新时间由分钟级下降至秒级。

1.3 BI 展现层

BI 展现层作为报表服务的主要载体，可能会影响整体服务的响应速度和可靠性。在初期部署衡石 BI 时我们考虑过三套技术方案：单机版本、负载均衡版本、集群版本，其中：

• 单机版本方案成本最低，但存在单点故障风险，适合服务负载低，对服务可靠性要求低的内部使用环境，内部开发测试环境采用单机版本部署。

• 负载均衡版本能够满足高可用和性能要求，但开发量大，采购综合费用高。

我们最终采用优化后的集群版计算，将集群服务器的元数据库部署上云，集群服务器的 Zookeeper 和 gateway 组件在每个节点均部署，前置 Nginx，实现服务高可用。

整体 BI 展现层技术架构如图4所示，系统主要由 report api server 和 report server 两大部分构成：report api server 主要提供查询/下载等 api 交互功能，通过云主机的函数计算 FC 功能，动态进行弹性资源扩容，实现高可用和资源使用率的有效平衡；report server 为衡石 BI 集群版，提供核心的数据拉取、计算、效果图表的渲染功能；在 report api server 和 report server 之间，生成唯一键关联每张报表的图表样式、计算逻辑，通过数据映射关系实现快速的跨环境、跨版本的报表切换，并提供多版本兼容的能力，更好地帮助用户进行报表数据分析。

为了配合研发前端整体的灰度上线流程，报表服务也进行了灰度发布控制，灰度发布流程如图5所示。

大致步骤如下：

1) 在开发环境基于报表需求进行数据开发和数据测试，通过后导出报表模版。

2) 将模版部署生产服务器（B环境报表），逐级对接dev/fat、uat环境进行数据和效果验证，验证后纳入待发布范围。

3) 跟随前端灰度发布，流量逐步从原线上报表（A环境报表）切换至新部署报表（B环境报表），同步进行灰度环境验证。

4) B环境报表成为线上报表，A环境报表下线。

数据安全

数据安全主要解决客户身份鉴权及报表数据隔离的问题。我们的方案是通过前端页面解决客户的身份认证以及BI系统的SSO登录问题，同时通过BI报表自带的数据权限控制功能展示客户自己的数据。

从 BI 报表的前端请求开始，通过全链路数据安全控制，来确保用户的数据安全。全链路具体步骤，如下：

1) 前端页面在加载报表前，先向用户中心（UC）进行身份校验，并查询菜单权限配置。确认客户有权查看在线数据分析后，前端向用户中心（UC）申请token。考虑重新申请 token，而非直接采用登录 token，主要出于 token密钥的隔离保护原因。

2) 前端获取 token 后，向BI展现层请求报表地址。

3) BI 展现层根据请求参数返回对应的报表地址，由前端页面向BI展现层请求对应报表数据。

4) BI 展现层根据地址信息，启动相关报表模板，加载相关图表数据，生成图表页面框架。

5) 前端根据结果进行渲染，最终生成展示页面。

同时，BI 系统数据鉴权方面，我们选择 JWT 参数方式进行认证。按照 JWT 规范，将用户基本信息进行签名 / 加密，通过 url 传递给 BI 系统，兼顾安全性和便利性，如图6所示。通过前端 web server 控制用户的登录和菜单展示，通过 report api server 进行报表地址API鉴权，通过 report server 对报表的数据权限进行 JWT 二次鉴权，保证数据全流程的授权安全访问。

SAAS的在线报表模块并发量不会很高，同一时刻用户的访问量基本上在百级别。为了确保其稳定性，我们模拟并测试并发在千级别时系统的访问性能，采用的是Locust（开源分布式的用户负载测试框架，可以仿真百万个用户，主要用于网站或者其他系统进行负载测试）对系统整体性能进行压力测试，摸底性能极限。压力测试方案设计通过分析在线报表加载链路，选取典型页面模拟用户查看报表时的每一个访问请求，随机查询参数减少缓存影响。

图7 压力测试 RPS 趋势图

 

图8 压力测试响应时间趋势图

 

图9 压力测试并发用户数增长趋势图

 

图10 压力测试服务响应报错信息

从以上图中可以看到，响应时间控制在3秒以内可以承受1000以内的并发用户、RPS500以内的并发请求，可以满足现阶段甚至未来一段时间我们系统的访问需求。

下一步工作

目前这套架构对于满足大部分的客户需求是没有问题的，但仍有一些客户对我们提出了更高的要求，包括自定义报表分析、实时数据分析、多数据源数据融合、以及更安全的权限管理等，这些对我们底层的报表分析引擎优化、实时计算引擎都是很大的一个挑战。后续我们也希望在数据侧引入更多智能的规则和算法，帮助客户快速判断自己的整体支出是否合理，以及可以在哪些方面可以更好地节省成本。

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里！

 

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里！

 

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里！