今天聊：BI 仪表盘及数据导出技术难点分析

前端早早聊大会，与掘金联合举办。加 codingdreamer 进大会技术群，赢在新的起跑线。html

第二十九届|前端数据可视化专场，高强度一次性洞察可视化的前端玩法，7-17 全天直播，9 位讲师，报名上车👉 )：前端

正文以下

本文是第十五届 - 前端早早聊报表专场，也是早早聊第 109 场，来自字节 - Jerry 的分享。git

1、开场

简单的自我介绍

Hello 你们好，我是来自字节跳动商业产品客增大前端团队的前端工程师 Jerry，很荣幸今天能表明团队向你们一块儿分享咱们最近的一些业务实践，由于咱们如今恰好在作一款商业 BI 系统，因此适逢今天的主题，我将为你们带来一场 title 为《如何实现商业报表的仪表盘及导出分享功能》的技术沉淀。github

字节跳动最“挣钱”的前端团队

首先先介绍一下咱们的团队：咱们是一个已经有百号人的前端团队，咱们的同窗也遍及在北京、上海、杭州以及北美这些地方，这些城市都有咱们的 base，咱们在作的事情，是致力于提供互联网商业变现的最佳解决方案，践行“信息创造价值”理念。web

在这里，你将对接字节跳动百亿流量的全产品矩阵，见证公司全新业务线的孵化成长，支撑公司千亿规模的收入增加。在这里的每一分每一秒，你都能亲身感觉到字节跳动的蓬勃生机。虽然咱们是业务团队，但咱们也在作不少与时俱进的技术建设，其中包括有：前端现代化工程化体系升级、Node 能力探索、一键式 CD 工具、组件服务化、前端国际化通用解决方案、可视化页面搭建系统、商业智能 BI 系统、前端自动化 E2E 测试、面向将来的微前端设计模式等等。面试

在支撑业务不断演进的过程当中，咱们尝试不断探索技术赋能业务的更优实践。而且在分享的最后也有咱们的福利环节噢，我将为你们献上我们团队的内推绿色通道，若是你们听完个人分享，以为咱们在作的事情颇有趣，你对此感兴趣，那就欢迎快来投递哟。数据库

好吧，那题外话我们就很少说啦。在咱们正式开始今天分享以前，首先须要感谢下咱们的组织同窗。辛苦咱们的主持人花花帮咱们暖场，也感谢 Scott 提供了这样一个让我与你们可以一块儿交流的机会。那咱们如今开始直奔我们的主题吧。canvas

分享大纲

这是我们今天分享的大纲：我会逐步带着你们切入我们要开发一个报表系统的几个核心细节，带着你们从业务实际需求场景入手，一步步完成一个前端商业报表系统的搭建。其实我今天准备了五十多页的 PPT，由于作一个 BI 系统有太多有意思或者说值得去讲的东西了，我很但愿把全部的都分享给你们，但由于时间关系，我可能只能抽出其中一部分，所以我尽量让它们能更加通俗易懂，而且我会更多地专一在前端的一些主要功能的实现思路，固然一个 BI 系统确定远远不止这些。整个分享的过程或许会比较漫长，但愿今天来听个人分享的同窗，听完以后也都能有所收获。后端

因此我们今天的分享主要有如下几个部分：

大数据时代下的前端商业分析方案
定制化数据分析能力的实现
仪表板制做
大数据分享及处处
对业务更深的思考与对将来的展望

那如今，开始咱们第一个主题吧。

2、大数据时代下的前端商业分析方案

大时代的趋势

做为作互联网的咱们，其实对过去几十年的历史进程都历历在目。首先，20 世纪的前十年，是 PC 端的时代，各种门户网站的崛起，也启蒙了现代的许多互联网巨头；过去的十年，是移动端的时代，各路诸侯都在争夺互联网的战场，最终的赢家，奠基了现现在的互联网格局。而如今，是数据的时代，由于不少时候，大量的数据或是强大的数据分析能力，可以成为一家公司的核心竞争力。所以，数据，是这个时代最核心的资源。如今不管是 B 端仍是 C 端的团队，都会有大量的数据积累，例如咱们平时常见的页面埋点、PV、UV，亦或是一些业务数据，都如同一座座数据金矿，等待咱们去发掘其中价值。

业务的实际场景

而咱们，刚好在作这样一件事情。由于咱们是商业化大部门下的团队，因此在咱们的大部门中，沉淀了不少有意义有价值的数据，好比咱们的一些销售业绩、或者是一些客户数据。为此，在咱们的部门下，也聘请了不少专业的数据分析师同窗，亦或是销售本身，平时可能都会作一些报表、周报，用以汇总数据，观察趋势，就以下面的这张图所示，左侧的日报图，就是咱们业务中实际产出的报表，咱们的同窗可能会作一些日报类的报表，用以披露部门内的一些销售业绩动态。他们会本身经过 Excel 等工具，在拿到数据后本身绘制各类各样的图表，而后像这样组装起来，再发送出去。而右侧的报表图，就是咱们的同窗使用了咱们研发的系统后，本身组装完成的报表，效果也符合他们的预期。

业内的竞品

并且这样的业务场景实际上是一件很常见的事，并非说只在字节存在，就像咱们刚刚提到的，在现在的时代大背景下，每家公司沉淀出了大量待发掘的数据已是一件再普通不过的事情了，所以，也有不少公司发现了这样的商机，在业内也作出了不少成熟的产品。好比比较有名的 Tableau，虽然它已经开始逐步放弃中国市场了，可是功能和交互，也值得不少系统参考，国内也有不少很给力的产品，像阿里的 QuickBI，由于做为云服务的提供方，BI 类系统的产生能够说是再正常不过了。

咱们为何要作这样一件事？

那业内已经有这么多成熟的产品了，为何咱们还须要作这样重复的事情呢？咱们是在重复造轮子吗？

其实主要是处于如下四点缘由：

部门内现存大量有价值的数据：刚刚咱们提到，由于咱们是商业化部门，所以有大量的营销类数据沉淀也是一件再正常不过的事情了。
大量重复性的报表工做：刚刚咱们提到，其实咱们的销售同窗，或者数据分析师，都是下载了数据以后，本身经过 Excel 或者其余工具绘制好图表，而后制做成报表，并且周而复始，每次发周报，或者双月总结，都要不断重复作一样的事情。咱们但愿能帮助他们，提供能力自动化帮他们完成一些重复的工做。
须要有特定的数据权限管控：众所周知，其实数据在公司内是很敏感的，对于数据的权限也是须要严格管控的。传统的模式，用户直接讲数据下载走以后，数据的流向以及最后的分发，咱们都没法追踪，这实际上是一件颇有风险的事情，咱们但愿借助咱们商业化现有的鉴权体系，对咱们的数据加以更严格的管控。
咱们但愿用户在一个系统里，就能作完全部事：咱们不但愿就是用户还得在咱们的系统里面下数据，而后切换到 Excel 里面去拼装数据，而后又获得另外一个系统里面去发周报，咱们但愿能让用户，在咱们本身研发的一个系统里，就能完成他们平时工做中的全部事情。

咱们该怎么作？

根据咱们刚刚的分析，其实用户每周的工做，主要就是如下三个核心的流程：制做他们所须要的每一张图表 -> 将这些图表组装成仪表板 -> 最终将这张图表以周报的形式分享出去，或者定时用以给本身回溯。顺着这样一套流程和思路，咱们开始来逐步分析每个阶段都须要哪些功能模块，而且又有哪些技术选型可以帮助咱们实现。

3、定制化数据分析能力实现

接下来来看业务流程的第一个环节，也是一份报表最核心的组成单元 —— 图表。那图表从哪来呢，天然，咱们须要为用户提供图表的生产能力，也就是咱们的定制化数据分析能力。

用户需求分析

那用户指望的效果又是怎么样的呢？参考业内的系统实现，用户其实根本不须要关心背后繁杂的 SQL 逻辑来知足本身的数据查询，也不用本身绘制图表，只须要经过简单的经过一些拖拖拽拽，就像咱们图中的动图所示，好比说拖拽一些咱们提供好的数据字段，咱们就能够快速地查询出这样的一个他所想要的数据，或者说是快速地帮他绘制出来一张图表，而后用户也能够自由地选择图表的类型，好比说想要作成一个折线图，或者是咱们普通的这样一个 Table 样的交叉表。

技术体系梳理

因此要实现一个定制化的数据分析能力，咱们大概须要哪些功能点去支撑呢？这里咱们总体能够分为以下这几部分：

好比刚刚一下就映入眼帘的拖拽能力，这也是市面上的竞品作的比较常见的一个能力，咱们能够借助像 react-dnd 这样的优秀的开源实践，来帮助咱们去实现这样一个能力。

第二点的话是用户可能不会知足于咱们提供好的一些默认字段，像好比说咱们能够看到系统左侧这部分的字段 List，可能这些字段并不能知足用户他实际的更复杂的数据分析场景，用户可能须要本身来生产一些这样的一个字段表达式，其中可能包含像求和、求平均等一系列复杂的计算操做，可以让有更加定制化的能力。因此为了让功能更加定制化，咱们也会提供自定义字段（或者更形象点说就是自定义查询查询表达式）的能力。

固然咱们的这样一个定制化的分析的页面，核心确定仍是咱们的图表展现。咱们能够基于 antd 的 Table，去实现 Table 类型的像好比交叉表这类的数据呈现，而且咱们可使用 ECharts，来实现像图表类的数据呈现。咱们能够选择 Mobx 做为数据流支撑，由于它很“灵活”，至于为何，我们来看下面这张图：

咱们将刚才页面其实能够作一下相似图中各部分的功能拆分。首先是咱们左侧的这样一个字段拖拽的 List，用户能够从这边去把字段拖入到像咱们刚才看到这样的一个有行、列、数值分类的一个个容器里面，这部分的区域咱们就叫他分析区，由于他是用来产出可用于后端查询的一个字段分析配置。借助 Mbox 的 Autorun 能力，当分析区配置变化以后，会自动触发后端查询获取到对应的图表数据，交给咱们底部的面积比较大的核心图标展现区，用于展现咱们绘制后的图表。

不只如此，咱们还能够看到在页面的右侧还有这样一个侧边栏，提供给用户选择图表类型的这样一个能力，还有一些让用户可以自由定制化图表样式像好比说什么开启或关闭合并单格，或者是添加一些表格样式，好比隔行变色这样一些比较常见的能力。当配置改变以后，能够经过 Mbox 的 Observer 机制自动去更新一些图表的元数据或者状态，触发图表的从新渲染。

那梳理完清晰架构设计以后，咱们就开始去逐个去击破吧

字段拖拽

首先来看咱们最开始说到的字段拖拽能力。前端如何实现一个拖拽功能呢？了解过这方面的同窗确定会想到好比 HTML 原生的 drag 事件等等。固然，咱们也能借助一些工具库帮咱们快速完成，好比咱们系统中使用的 react-dnd，就是很不错的选择。

回到主题，咱们想要实现一个拖拽能力，核心就是把握住 PPT 上的拖拽三要素，由于不论你的业务逻辑是什么样，这三个要素始终是你全部功能的基点：

拖拽环境（DragDropContext）：相似于咱们平时包裹数据流的时候都须要用到的 Provider，可以为它的全部子元素提供这样一个拖拽底层支持的全局上下文；
拖拽项（DragSource）：就是咱们实际拖拽的东西，好比你们刚刚看到的一个个字段；
放置容器（DropTarget）：咱们拖拽的东西确定不能一直拖着吧，它确定须要被放到某个地方去，那这个地方就是咱们所说的放置容器。

那要如何用实际的代码逻辑实现拖拽三要素呢？咱们能够借助 react-dnd 为咱们提供的 DragSource 和 DragTarget 方法，对咱们的组件进行包装便可，咱们只要定义好可拖拽的类型、拖拽事件的回调、亦或是咱们想要自定义的能力，好比图中所述，咱们对拖拽中的元素会赋予特定的样式 —— 透明度增大，就能完成一个拖拽要素的封装。

而且，咱们将重复的流程封装了高阶组件（由于咱们的项目在启动时，react-hooks 还只是刚火起来的提案），这样当咱们要快速包装组件的时候，一切是否是变得简单了许多呢：

这样一来，咱们想要为系统中的哪一个元素赋予一些拖拽能力，只须要包裹一个装饰器就 OK 啦。这样的工具函数，就能实现咱们的拖拽能力“随时插拔，随处复用”。

而且细心的同窗可能会发现，咱们的字段实际上是有不一样的类型，分析区内也有不一样的位置，而且顾名思义，像行、列这些分析区，在交叉表内天然是不一样的逻辑或者呈现，举一个比较简单例子，像好比说咱们把日期类的这样一个字段拖入到过滤器里面，它应该呈现的是一个像日历这样的一个组件，而后咱们把一些维度类的字段拖入到过滤器里面，它可能展现的就是一个向下拉枚举或者说是一个搜索框的这样一个组件呈现。

咱们能够用不少判断去堆砌，但怎样才能更优雅地去维护这块的逻辑呢？其实细心的同窗可能发现了，咱们将字段拖入分析区的结果，实际上是一个二维的过程，它取决于字段的类型和拖拽终点的类型，所以咱们使用一个矩阵来表述这样的过程，矩阵最终的求值，就对应着不一样状况下，咱们所需的组件和配置。好比咱们右侧这样一个示例代码，咱们把日期类这样一个字段，去拖入到咱们这样的一个行中，它就映射到了咱们这样的一个矩阵中的 date 字段下的第一项，而后这个配置就是对应着字段最终要产生的组件，还有它数据初始化元信息或者说一系列的配置信息。

这样一来，咱们后面想要维护这样的一份配置，配合上直观的注释，其实就很简单了，像好比咱们如今想要加一些什么分析区的配置，其实就只要在矩阵里面去额外的去增长一些项目就能够了。

自定义计算表达式

有了字段拖拽以后，用户并不知足于咱们提供的默认字段，不少时候，用户都但愿本身能有自定义字段表达式的能力。咱们可能不会让用户完整去写复杂的 SQL，咱们但愿这个系统可以更加简易，可以下降门槛服务于更多的用户，所以咱们有了自定义的语法结构，好比由咱们提供的函数和字段，用户就能够快速地组装好一个表达式，正如咱们图中的动图所示。

借助 CodeMirror，咱们很快就能实现这样的能力。

首先，CodeMirror 可以为咱们提供很是优秀的关键字高亮能力。了解过编译原理的同窗必定知道，对于一段字符串的解析过程，会分为词法解析和语法解析等几个步骤，在这里，CodeMirror 为咱们提供了在词法解析的环节，咱们能够定制化处理关键字的能力，咱们能够抛出每一个 token 对应的类型，CodeMirror 就会为咱们指定的关键字赋予特定的 class，咱们就能为其定制想要的样式：

不只如此，CodeMirror 还支持让咱们自定义语法提示菜单。咱们只要准备好待提示的 List，在用户输入或者粘贴的时候，filter 好 list 喂给 CodeMirror 就好了。借助每一个 list item 的 render 方法，咱们还能够自由定制下拉菜单里的样式，开发起来起来就像使用 Echarts 或者 Antd 这样的组件库同样温馨。

这里有一个小技巧，其实自动补全后光标是位于补全文案的最后的，对于函数类的文案，咱们可能会更但愿它的光标是落在函数的括号 ( ) 里，所以当咱们检测到用户在经过自动补全键入函数的时候，手动操做移动光标，将它移动到括号内：

图表渲染

有了字段，天然就能够从后端查询数据啦。那对于前端来讲，咱们最终要渲染的是如图所示的这样一张交叉表，很明显咱们须要的是结构化的数据，然后端直接将字段经过 SELECT 查询出来的结果数据必定是铺平的，从接口响应到数据渲染，必然会须要有个数据格式化的过程。那这个过程谁去完成呢，若是前端来作，对服务器性能更友好，后端就不须要关注数据格式化，能够专一在数据分析而查询，而若是后端来作，对我更友好，哈哈，开个小玩笑。固然，确定是极致的性能更为重要。那数据格式化咱们有怎样的思路呢？

咱们能够对数据图表进行细化，若是要渲染一个单元格的数据，那么这个数据单元格必定会有一个惟一的坐标，坐标从哪来呢？其实就是他的行列字段所组成的数据索引。咱们能够封装一个数据处理器，就是咱们图中的 Processor，对后端给到的数据 list 进行结构化，变成更加直观的 DataMap。

咱们能够看到，通过格式化以后的 DataMap 里，一级的 Key，就对应着 DataSource 里的一行数据，而二级的 Key，就对应着当前数据所在的列，这样每个单元格的数据，均可以经过这样的“坐标”被明确表示出来，当咱们再拿着这个 DataMap 去生成 Antd 的 DataSource 和 Columns 时，一切是否是就清晰明朗多了。其实这个过程就是一个再普通不过的树生成逻辑，咱们部门面试常考题噢，哈哈划重点。

至于 Echarts 相关的图表，今天我就不作过多介绍啦，我相信前端早早聊大会以前的数据可视化专场已经有不少类似的议题啦。

终于搞定了咱们的图表来源了，接下来就是我们系统的核心，组装图表。

4、仪表板制做

为何咱们要把一张张图表组装起来呢？

由于：多张图表组合产生的价值，必定大于全部图表单张价值的总和。多张图表去作一个协同分析或者作一个数据关联的话，确定是可以迸发出更多的价值。

那用户实际须要的，又是怎样的呢？

用户需求分析

用户在业务中去制做的这样的一个报表，也就是像咱们下方的图示，报表中会披露一些指标，会有一些图，其实就是我们前一步作好的那些图表，同时也会有一些这样一个文案总结，好比总结一下部门或者说团队这个月去有没有什么上升的趋势。

而要支撑起一个仪表板功能，咱们须要哪些部分呢？

仪表板技术架构

从下而上，咱们可使用这些技术为仪表板提供能力支撑。仪表板中会有一些原子组件组成仪表板的必要元素，好比咱们刚刚作完的图表，还有一些富文本卡片，或者说是一些图片组件，固然也有在仪表板中很常见的全局筛选器，用以让用户全量地去过滤一些数据。

有了原子组件以后，咱们也但愿能赋予用户拖拽布局的能力，让用户能够在系统中自由组装这些原子组件，而后产出一份能让他本身满意的报表。

梳理清晰了技术体系，那咱们就自下而上逐步攻坚吧。

富文本能力实现

原子组件里，比较有挑战的，应该就算是富文本编辑器了，这个曾经做为前端三大难题的技术点，现在优秀的前端社区已经为咱们准备好了成熟的解决方案 —— Quill，它不只能帮助咱们快速实现富文本编辑功能，还可以让咱们自由地自定义各项能力，这相比于其余的工具而言是更优秀的。

好比咱们能够自定义工具栏的内容。咱们能够经过自由组装 HTML 标签的形式，自定义富文本工具栏的呈现。好比说 Button 元素，它最终在这样一个工具栏中渲染出来的就是一个按钮，好比说咱们这样的一个加粗功能的按钮，或者是一个添加下划线的功能按钮。而后像有一些下拉菜单这样的功能，咱们能够经过 select 配合 option 快速实现，好比选择字体字号，这也是一个比较经常使用的实现。

不只如此，咱们还能够为 Quill 增长一些自定义的功能，好比 Quill 默认只支持四种字号，因此咱们也能赋予它定制化字号：

得益于 Quill 灵活的定制化能力，咱们能接下不少 PM 给到的各式各样的定制化需求。

拖拽布局能力

有了仪表板的基本元素以后，咱们就能够开始关注自定义布局的实现了。其实社区已经有一款特别好的实现了，就是咱们的使用的 react-grid-layout，能够看它官方提供的 demo，其实效果就已经足够知足咱们的需求了。

不过这里有一个小优化，你们也能够关注一下。就是官方提供了一个自适应宽度的能力，可是它本质是监听了window 的 resize 事件，而后你们刚刚若是有注意的话，其实咱们的系统是有一个可伸缩的侧边栏的，因此当咱们去伸缩侧边栏的时候，这个仪表板它不会去适配这样一个宽度。所以咱们能够借助 react-resize-detector 对他进行一个扩展，简单优化一下官方的这个小痛点。

为了让数据管理更加清晰，咱们将布局和数据的渲染逻辑拆分开来，有单独的配置维护布局数据，另外一份配置维护组件元数据。因此仪表板整理的布局流程就是相似图中所示：首先咱们真正存在后端的，就是一份完整的仪表板数据，像好比说它里面有哪些组件，而且有怎样的布局。而后前端系统经过请求拉到这样的一个数据信息以后，咱们会作一个解析，咱们会把这样的布局信息映射到每个对应的组件上。最终这些绑定了布局信息的各个原子组件，通过咱们的布局器布局，最终呈现出来的就是用户自由组装的美观的仪表板啦。

全局筛选器

全局筛选器对于一份 BI 仪表板而言是再常见不过的一个功能了，不少时候，咱们都会提供一个仪表板层面的筛选器，供给用户自定义筛选数据的能力。筛选器能够与任一图表相关联，而且这些筛选项也只会对关联的图表生效。

这里咱们就举一个形象一点的例子（下图）。好比在咱们的仪表板中有三个筛选器，筛选器 123，而后他们分别关联了不一样的图表，筛选器 1 关联了图表 1，筛选器 2 关联了图表 1 和图表 2，筛选器 3 关联了图表 2，天然，当咱们操做筛选器 1 的时候，只有图表 1 会刷新，操做筛选器 2 的时候，图表 1 和图表 2 都须要刷新，而操做图表 3 的时候，也只能有图表 2 刷新。

那这样的逻辑又要如何用技术实现呢？整理的流程就像咱们图中所示，咱们能够在 Store 里去统一收集全部的筛选器，筛选器上都会有一个字段标明关联的图表的信息，当筛选器发生变化时，就会自动更新咱们的 Store，Store 会自动触发筛选器的生成器，针对不一样的图表生成不一样的筛选项，图表再根据不一样的筛选项去向后端请求数据。

这样一来，一个仪表板的核心骨架功能基本就已经搭建完成了，你们能够看看咱们仪表板的最终使用效果。

但其实咱们尚未完成全部的事情。

5、大数据分享及导出

首先有一点咱们须要明确，那就是：用户制做的报表，必定是但愿它能被带到更多系统以外的地方去展示。由于用户制做的报表，确定不是本身作着玩的，或者本身欣赏它的“美”，更多的时候，他确定是但愿拿着这样的一份报表去发周报，或者是或者说去作这样的一个数据分析结果的汇报。

所以，可以将数据导出或者分享，也是一个 BI 系统不可或缺的能力。

数据分享的形态

数据的导出分享，其实能够概括为如下三种形态：

连接分享：好比用户直接 copy 了浏览器地址栏里的系统连接，或者是咱们的页面里有个按钮叫作相似“复制连接”，用户点击如下，就能自动把图表的连接复制到剪切板中，这样就能将他本身作的图表或者报表直接分享出去；
图表导出：用户可能但愿本身作的图表或者报表，可以导出成一张图片或者 Excel 文件，这样在他须要发送邮件或者消息的时候，就能更加直观；
周报订阅：一个比较智能的系统，确定不会说让用户每周或者每次他须要的时候，来系统里截个图，才能把它的报表分享出去，咱们彻底能够作的更智能化，好比说把这样一个流程作的更加自动，用户只须要快速配置，咱们就能够定时地为用户去推送他所须要的报表信息，好比截图、连接等等。

连接分享

咱们先来看分享的第一种形态 —— 连接分享。用户点击 Button 以后，就能把内容自动复制到剪切板。其实这也是一个比较常见的实现，咱们只要建立好一个 input 标签，将须要复制的内容填充到里面，执行 input.select() 选中全部的内容，再经过浏览器提供的 document.execCommand('copy')，就能把对应的内容复制到剪切板中啦。这样的逻辑，咱们也能够封装成经常使用的工具函数，用于其余场景下的复用。

图表导出

对于图表导出的话，咱们须要先掌握前端下载能力的实现。若是前端想要让用户下载一个文件的话，其实要作的事情很简单，就是建立一个 a 标签，它支持咱们为 href 赋予 Blob 这样的 ObjectURL，而且再为它赋予一个 download 属性用来表示下载后的文件的文件名，这样咱们只须要执行一下这个 a 标签的 click 操做，就能模拟出用户下载文件啦。

对于咱们的文件而言，比较常见的就是一个 file string，图片类型的，大部分也能够导出一个 base64，咱们均可以封装好工具函数，将他们转化成 Blob 对象。最终让用户可以灵活地完成下载。

有了前端下载能力的支持，就能够针对不一样的文件进行定制化的处理。对于页面上的 Table 类元素，用户可能更但愿的是导出一份所见即所得的 Excel 文件，咱们能够借助 js-xlsx，它为咱们提供了一个方法叫作 table_to_sheet，只须要传入一个咱们页面中的 table HTML 元素，这个工具就会自动帮咱们解析成 Excel 文件格式的数据，而且也会保留咱们页面中的合并单元格等样式，最后生成一段 file string，咱们直接就能使用刚刚提到的文件下载能力，将文件导出啦。

而对于图表类型的图表，熟悉 canvas 的同窗可能就会比较亲切了，canvas 提供了一个名叫 toDataURL 的 API，可以快速将 canvas 内的内容导出一份 base64 数据。而对于一些非 canvas 的元素，好比咱们的指标卡图表，他可能就是一个纯粹的 Card，咱们也可使用 html2canvas 快速将它变成一张图片。

周报订阅

刚才咱们还说到一点，咱们还能够把报表的导出流程作的更加自动化，用户没必要要每次须要报表的时候再来咱们的 BI 系统里生成一份报表导出，咱们能够提供让用户自由配置的能力，好比用户选好何时须要为它推送报表，或者说是按期给某些人，系统就会自动去定时为用户推送报表。

最终一个形式化其实就是相似于咱们右边这张图的呈现。若是用户订阅好了一份报表，系统就会定时地在飞书上为它推送这样一条消息，其中就包含了用户制做的报表的一个截图，而后还有一个报表对应的连接。

而后若是要实现这样一个订阅能力的话，若是你们有了解过 Linux 的话，就会知道 crontab 这样的一个实现定时能力的命令，总体的思路其实就是借助这样的能力去支撑，咱们公司为咱们封装好了这样的一个能力，咱们称它为 cronjob，而后用户他若是建立了一个订阅任务以后，咱们就能够把它写到咱们的定时调度数据库里面，接下来去建立这样一个定时任务，当触发的时机到了的时候，咱们就能够借助无头浏览器，相似业内比较成熟的 puppteer，自动打开报表为咱们的用户去作报表的截图，最终再将截图带着咱们的一些报表信息推送给用户。

6、对业务更深地思考与将来的展望

其实在整个业务的迭代演进过程当中，咱们的 BI 系统也有了一个更深的思考，并且咱们也但愿对将来有更远的展望。其实咱们是更但愿如今 BI 系统可以成为一个更灵活的数据中台，不仅仅去服务于业务，像好比咱们如今已经实现的能力，若是别的业务想要复用咱们系统制做的报表，他直接经过 iframe 的形式将咱们系统内的报表嵌入到他们的系统中。而且咱们将来也但愿能借助像微前端这样的能力，让咱们系统中的报表，亦或是一些图表组件，可以不局限于咱们的开发框架，也能快速地被其余系统更灵活地复用。

数据中台的真正意义，不仅仅是业务上的可复用性，咱们也会不断探索技术上的可复用能力。

因此对咱们而言：一切还只是开始，将来仍存挑战。咱们后面还有微前端、移动端、大屏展现等等能力想要去作，咱们也相信，很快咱们也能作到，因此对咱们所作的事情感兴趣的小伙伴，快快加入咱们吧，我们一块儿去作有挑战的事。

7、总结

因此咱们再总体回顾一下咱们刚刚讲完的内容，咱们也能够借助业内优秀的实践做为咱们的技术底层实现，快速支撑起咱们的报表系统的技术选型和基建，再将各类各样的技术抽象成通用的能力封装，创造出咱们的定制化数据分析能力（提供了图表来源）、仪表板原子组件（提供仪表板的必要组成元素）以及数据导出分享能力（支持 BI 系统的必要功能），最终再将咱们所拥有的资源进行整合封装，就产出了咱们提供给用户的定制化报表解决方案。

8、福利环节

书籍推荐

而后前端早早聊有一个惯例，就是每次分享的嘉宾都须要分享一本书，这里我推荐的就是这本《The Grammar Of Graphics》，当时 D3.js 的做者，就是看完了这本书以后，有了灵感，写出了 d3.js 这么优秀的框架。但其实我更想表达的，就是在 BI 系统的这段历程下来，我更深入地理解到：作一个商业分析系统，最重要的事不是攻克哪些技术难点，而是要善于去发现数据的价值，用技术为数据赋予生命。所以我以为这本书，再合适不过了。

这里我也想要表达一下我对团队的感谢，一个系统的搭建，确定不是一我的就能完美完成的，在这里我不只要特别感谢一路来和我一同奋斗的同事们，这些成果是你们共同努力的结晶，咱们也但愿将来还能有更多的同窗可以参与进来，由于就像咱们刚刚说的，咱们作的都还只是开始，咱们还要作的事情还有不少，咱们须要你。

前端路漫漫，与君共勉，你们对于大厂选拔标准有任何疑问，均可以在评论区留言，我都会回复，或者加我也行（codingdream），还能够围观我朋友圈。

别忘了第二十九届|前端数据可视化专场，7-17 全天直播，报名上车👉 )：