BI 数据可视化平台建设（1）—交叉表组件演变实战

表格和表单在前端里面是最复杂的两类需求，在BI工具平台上，这2类组件需求更多，并且需要实现一些特有的交互展示。目前在敏捷BI平台上进行报表配置，表格类组件的使用占比达到了1/3，在可视化组件库里使用范围很广。为了满足不同的数据分析场景，表格组件主要分为分组表、交叉表、明细表三种类型，其中又以交叉表功能最为丰富强大。随着敏捷BI的业务的发展，交叉表组件也经历了多次设计改版以支持高性能的数据渲染和个性化的展示配置。本文主要通过交叉表组件的升级实践给大家讲解一下如何设计开发高性能的表格组件。 

交叉表（Cross Tabulations）是一种常用的由 行、列、汇总字段 三个元素组成分类汇总表格。利用交叉表查询数据非常直观明了，在进行数据分析中也被广泛应用。这里牵涉到另外一个概念即分组报表，分组报表是所有报表当中最普通，最常见的报表类型，也是所有报表工具都支持的一种报表格式。从一般概念上来讲，分组报表就是只有纵向的分组，传统的分组报表制作方式是把报表划分为条带状，用户根据一个数据绑定向导指定分组，汇总字段，生成标准的分组报表。交叉表有多列查询能力、分类汇总、多角度排序、交互式分析等特性。

为了提高交叉表的数据渲染性能和功能扩展能力，敏捷BI的表格组件经历了三次的设计升级。最开始用的jQuery拼接表格方式实现，随着组件化方案的推行，采用了组件化的方式实现升级，随着业务的发展，用多维度、多指标交叉分析场景越来越多了，尤其是通过交叉表进行分析时，大数据量出现了渲染崩溃等问题，所以我们最后通过微前端方式实现。  下面我们从开发难度，性能，功能扩展性，学习成本等方面的调研来讲解对底层表格的升级实践。

3.1 V1版表格

// 简单的拼接代码demofunction createTable() {  var data = new Array();      data.push('<table border=1><tbody>');   for (var i = 0; i < 2000; i++) {     data.push('<tr>');     for (var j = 0; j < 5; j++) {       data.push('<td>' + i + ',' + j + '</td>');     }     data.push('</tr>');   }   data.push('</tbody><table>');         document.getElementById('table1').innerHTML = data.join(''); }

3.2 V2版表格

随着系统整体架构升级，前后端分离的推进，我们从原生的table组件迁移到Vue组件化上，开发了V2版表格组件。  平台的整体架构全面迁移到vue+ant-design-vue上面。

1. 功能拓展

鉴于ant-design-vue上正好有table组件，对此我们对比了antd的table组件和element的table组件。2 种表格对比来看，ant-design-vue参照ant.design的React版开发出来，配置相对element更丰富，考虑到本身复杂场景支持性，更适合深度定制，最终选择了ant.design的vue版本。

V2版的表格主要支持这几类场景配置（条件格式，合计行/列，单元格/行样式/内容定制等）：

业务场景&具体实现

（1）数据展示

（2）数据排序

（3）数据过滤

（4）单元格自定义渲染

（5）多级表头定制

这个实现难点主要在于把已有的列如何放到新增的表头里，保持树形children结构具体实现代码也比较复杂，总共80行。

（6）条件格式渲染(条形图，热力图）

根据设定的条件，定制表格内单元格内容的样式

（7）合计行/列配置

添加合计列和行，内置min，max，avg，sum表达式，支持自定义简易字段表达式运算这个功能难点在于合计列与行交叉的场景，也就是如何计算合计列的合计行。

2. 架构设计

3. 渲染优化

这个阶段的交叉表，在功能上已经能够满足绝大多数分析场景，但是一些数据量大的表格反馈渲染白屏时间过长，经常会出现浏览器崩溃，表格的性能面临新的挑战。另外表格在渲染时，CPU会占满，导致其他图表也会卡住等待，形成假死的现象。我们通过分析大数据表格渲染流程，发现有30%的时间会花销在数据适配，因此我们思考能不能把数据计算部分隔离出来，计算的时候，不阻塞渲染主进程，这样的话，浏览器渲染就可以处理其他的渲染任务。在做性能优化调研时，我们引入了service worker，worker在处理cpu密集型任务有独特的优势，所以我们把数据预处理的过程交给了Worker。之前没有使用worker时，我们前端逻辑会处理很多数据初始化和计算的操作，对于一个数据量很大的表格，会导致渲染卡顿2~3s，有些个别情况会导致浏览器崩溃的现象。

3.3 V3版表格

在开发V2表格时，我们意识到数据处理部分不应该交给前端，列拼接上掺杂了太多的业务场景处理，另外渲染性能和崩溃问题急需解决，对此我们进行了V3版本迭代，提前对表格版本进行了技术升级，为之后的新一批列汇总行汇总，分组小计等高级交叉分析需求做好技术储备。

1. 技术选型

我们对比了react，vue及canvas生态有代表性的表格组件。综合三者优劣势最终确定了基于react的table组件。

2. 架构设计

运作流程图如下：

3. 升级实践

（1）架构升级：

（2）底层渲染：

4.1 技术架构对比

1. Quick BI

2. 敏捷BI

4.2 应用场景对比

1. Quick BI

2. 网易有数

3. 敏捷BI

4.3 部分核心代码实现

应用场景① ：表头筛选

应用场景②：按维度合并

4.4 渲染性能对比

1. Quick BI

（1）数据量级 <50列

（2）数据量级 ≥ 200列

（3）数据量级 > 1W列

极端情况下，表格渲染崩溃

2. 敏捷BI

（1）数据量级 <50列

（2）数据量级 ≥ 200列

（3）数据量级 > 1W列

4.5 总结