数据平台前端架构设计

本文已对数据进行脱敏，仅涉及技术层面的探讨。

一、背景

随着部门业务的不断增大，流量渠道的不断增加，公司对于个性化报表与数据分析的需求越来越强烈。非技术同学常常需要依赖 BI 来生成报表，而 BI 的人力有限，无法高效地支撑日常运营的报表与分析的需求。此外，因不同人员构建 SQL 语句的不同，即使是同一指标也可能导致数据口径不统一从而造成沟通上的隔阂。

为了满足高效的数据报表生成与分析需求， 实现更加精细的数字化运营目标，低使用门槛的自主数据分析平台 Bee-Known 应运而生。本文主要介绍自主数据分析平台前端的架构设计。

二、问题与挑战

Bee-Known 的核心价值在于如何为用户提供一个数据完善并且低使用门槛的数据分析平台。数据完善的部分主要由后端服务保障，通过收口底层表和统一的数据处理引擎保证了数据的丰富度及口径的一致性。低使用门槛则主要由系统体系设计及前端交互来承载，前端方面主要面临如下问题与挑战：

1. 快速生成数据报表的能力：面对需求不同、专业技术能力不同的用户人群，如何做到让新手也能轻松地获得自己想要的数据图表？
2. 个性化数据看板自主搭建的能力：如何做到千人千面、灵活自主地构建自己关注的数据看板？
3. 复杂数据处理及图表看板加载性能的能力：如何处理交织混杂的数据处理逻辑、看板数据请求众多的性能要求？

针对以上的一些问题挑战，我们做了如下的思路及前端架构设计来进行破解。

三、整体思路

自主数据分析平台的整体思路非常简单：创建图表 -> 搭建看板，前端架构则根据这两个核心功能点展开。

1. 快速生成数据报表的能力

相对于其他一些数据分析系统的第一步需要配置繁琐的数据源与数据字段等操作，Bee-Known 则将数据源内置化，提前为用户完成数据源配置相关的工作，前端界面只向用户提供指标、维度、人群、过滤条件、时间等选择项，用户无需任何代码能力，只需通过鼠标点选相关条件即可获得自己想要的数据图表，大大降低了使用门槛，提高了数据的产出效率。如下例子，用户只需选择 UV 指标即可查看到数据：

初始状态：

选择 UV 指标：

2. 个性化数据看板自主搭建的能力

图表生成问题的解决为我们后面看板的搭建打下了坚实的基础。通过自主分析能力，用户可以创建任何自己所需要的数据图表，进而可以通过自由组合这些图表搭建成一个体系化的目标看板。
看板搭建这一块我们依赖的核心组件是：react-grid-layout，将看板作为一个图表容器，在看板中添加完所需图表后，通过该组件提供的能力，我们可以自由地移动、放大、缩小看板中的图表，完成看板内图表的布局。如下例子，在看板中添加图表前后：

初始的空看板：

添加图表后的看板：

至此，用户使用层面所面临的问题挑战已经得到完美解决，针对 复杂数据处理及图表看板加载性能的能力 的部分，我们将在前端架构章节进行介绍。

四、前端架构

为了增加对项目整体的把控度以及减少对后端的依赖，我们选择的开发方式是 Midway Serverless，看一下系统的整体前端架构图：

根据架构图，从最顶层的对外业务对接到最底层的依赖部分，系统共分成以下6层：

4.1 业务层

在项目设计之初，考虑到数据图表看板的对外输出能力，我们接入 ICESTARK 来构建微前端应用，通过提供微应用的方式，我们可以方便地将数据平台的图表看板能力嵌入到任意需要图表的主应用中，大大拓宽了数据平台的适用范围。

4.2 UI层

UI 层主要分成页面和组件两大块。其中，页面的核心分成3块：数据图表的分析页面、看板编辑与预览页面、系统内部数据的管理页面。而组件的核心则是图表模块，主要依赖 @ant-design/charts 以及自建。通过对组件的封装解耦，将功能转化为一个个细颗粒度的模块元素，页面则依赖这些基础模块组合而成。

4.3 图表数据加工层

不同类型图表的展示对数据的格式结构要求存在差异，开发者对接口返回数据的加工繁多复杂：数据的结构化调整、中间数据的计算转化、字段删减、数据展示替换、排序等。为了逻辑的复用以及对数据的统一管理，我们抽象出一层数据加工层来对数据相关的处理进行收口。

4.4 状态层

在复杂的页面结构中，逻辑相关的状态代码和视图相关的 UI 代码混合在一个组件内的编码模式不利于开发与维护，并且组件间属性状态数据的层层传递导致问题跟踪困难，因此我们将逻辑状态部分的代码从组件中抽离形成状态层。
状态层主要分成2块：简单的逻辑处理及 UI 操作则直接使用 React 的 Hooks 方式管理，复杂逻辑状态处理则通过 mobx 状态仓库进行管理。当然，随着功能的迭代，简单组件也可能逐步变成了复杂组件，此时可以根据实际需要将 hooks 重构为 mobx 的方式。数据仓库可以根据自身的需要抽象出仓库对应的 model 来管理基础数据，数据仓库间也可以像组件一样组合成更大的数据仓库。

4.5 接口层

因为项目采用的是 Serverless 的开发方式，所以接口方面的调用非常简单，API 中 lambda 函数即为接口，调用lambda 函数就相当于调用接口，无需复杂配置。此外对于其他一些动态参数查询接口则使用 ice 提供的 request 来实现。

4.6 底层依赖

底层依赖主要是 package.json 中引用的包，核心依赖于：React、icejs、midwayjs、@ice/stark、antd、@ant-design、mobx 等。

经过以上对前端架构设计的说明，我们来回答下「复杂数据处理及图表看板加载性能的能力」问题是如何解决的：

1. 复杂数据处理：通过归纳总结，将散落在各个图表中的数据处理操作收口到图表数据加工层中统一管理，可以大大减少代码的冗余度，结构分层清晰方便修改维护。此外，数据平台的很多元数据（指标、维度、人群、端信息等）以及元数据衍生数据在各种地方重复使用到，我们通过为这些元数据创建 store 管理仓库，在页面首次加载时获取数据并实例化，此后在平台的使用过程中无需再次请求元数据，使用 store 仓库的缓存数据即可，整个过程只发起1次请求。
2. 图表及看板加载性能：第一，通过图表的懒加载减少首屏不必要的请求：当看板中的图表数量众多时，屏幕可视区域并不能展示所有图表，因此在首屏加载时没有必要展示在可视窗口外的图表。懒加载功能依赖于 react-intersection-revealer 包来监听图表元素是否在浏览器可视窗口中来实现，当图表在可视窗内时才进行数据请求。第二，部分图表需要组合各种数据后才能进行展示，而浏览器对请求并发数有限制，对于这种情况，我们将各个数据的请求参数合并成一个请求后再在后端对请求参数进行分解复原，从而绕过了浏览器的限制。第三，通过为每个图表建立图表状态 store 来缓存请求数据及请求条件，在组件触发渲染时对比前后的图表请求参数，若未发生变更则阻断渲染，从而实现最小化图表渲染次数。

五、总结

在流量竞争愈发激烈的环境下，每一个行业获取用户和留住用户的难度大大增加，及时准确地了解用户需求并根据用户需求快速迭代产品来适应时代的发展成为了业务能否生存下来的关键。因此，依赖数据分析提供科学的依据来辅助决策变得越来越重要，数据分析平台也变得不可或缺。
本篇文章主要介绍 Bee-Known 数据平台的整体思路及前端架构，其实该设计方案不仅仅只适用于目前所在公司的平台，对比其他行业本质上只有数据源的不同而已，通过抽象，只要适配好对应的行业数据源，参考本文的设计思路，你也可以创建属于自己行业的数据分析平台！

PS：系统核心逻辑架构图：

价值：
业务上：无门槛高效产出数据报表、灵活创建数据看板，解放对 BI 的依赖
技术上解决的关键痛点：图表引擎构建、数据处理逻辑层抽象、元数据管理、页面性能