本文从技术和工具的角度分享可视化大屏的开发！
主要是对报表工具开发可视化大屏做测评！
可视化大屏开发工具选择
常规的数据可视化方式我们可以选择直接读取数据库，通过绘图软件/库进行绘制，最终构成自建的前端显示效果，比如使用 Apache ECharts (incubating) 等工具。
除此以外，追求效率的我们还可以选择成熟的报表套件，这类套件往往具有一系列的图表模板 支持推拽且可视化的配置页面，方便我们快速的构建出可视化大屏。其实大部分套件的机理差异并不大，为了降低文章内容量，本文直接讲解某一种套件，
当然报表套件又分为三类：
- 桌面应用产品，生成的是桌面端程序，程序往往直接连接云端数据库，需要数据库开放公网 ip。也有部分会有服务端提供 crud api 来降低数据泄露风险
- web 端直连数据库 / 自建后端产品，这种产品较少，毕竟已经做到 web 了再配个服务器岂不是更好，否则还是要数据库开放 ip
- B-S 产品，服务端提供与多源数据库的连接、数据提取、前端页面生成，前端负责显示、用户交互与动态刷新等等
本文选择第三类的一款套件作为讲解 -- 帆软的 FineReport，选择此产品原因：
1、国产软件，中文文档、中文配置界面，对于国内用户友好度高
2、国内基本最领先的报表工具，可视化大屏开发成熟
（注：我尽量从可视化报表工具的角度出发描述，而不是针对某个具体的产品，只是为了形象且可查证会给出 FineReport 在下面各方面的实践方式 / 方案，不作任何额外评价）
既然是个套件应该有很多完整成熟的功能，我们以这几个维度来聊聊：
- 环境与基础设施：设计平台，安装环境，故障传递与追溯，数据安全，协作开发，功能扩展性
- 视觉效果与用户交互：布局，配色，交互，可复用组件，组件自定义
设计平台
首先说说设计平台，一般分为两类类：
- 传统的桌面应用的设计器，前者往往直接安装打开使用即可，对于 B/S 类的产品，往往设计器安装包会自带一个服务在启动后自动运行可用于调试的服务环境
- 基于 Web 的设计器，这种设计器有些是支持同时设计与提供展示服务的，即一次搭建后根据登录账号的 role 进入不同的环境，有些是完全分离的两套环境。
FineReport 属于前者，对于不同系统均由轻松安装的安装包，不需要复杂配置。
安装环境
对于 B/S 产品，和搭建后端类似，只是不需要复杂的配置了，直接根据教程安装一下就即可启动服务.
对于后续要说的功能扩展性，可能会影响此步骤，如果产品具有功能扩展性，那么额外扩展的功能需要单独部署在服务上并配置相关连接，如果是基于插件化的扩展需要在服务端安装对应插件。此部分建议构建完整的环境搭建文档，如果产品可以通过脚本安装，建议直接将部署过程脚本化。
FineReport 环境安装也是安装包直接搞定，其具有插件平台，若有补充插件需要通过 web 登录后添加对应插件。
故障传递与追溯
企业数据应用阶段，往往数据可视化以后就逐渐地产生了可视化大屏。可视化大屏往往单页面信息含量极其丰富、跨越的业务部门繁多、数据分析维度全面。所以从技术角度来讲，我们需要保证单一故障不会大面积的波及其他信息，比如：
- 设计器出现故障是否会影响服务端？尤其是通过 role 区分环境的 web 设计器。
- 个别指标的计算错误是否会导致同页面其他指标均无法显示？
- 个别指标计算缓慢是否影响同页面其他指标均无法刷新？
对于故障还有额外要做的是实时处理方式：
- 关键指标计算错误是否也要报警？因为可视化大屏运行状态也许也是一个指标呢
- 指标计算错误时显示 0 还是现实错误信息？尤其注意在指标具有其独特的存在性意义时，不建议随意的用同类型数据作为展示，避免错误统计
- 虽然我们保证了故障波及的可控性，但我们还希望能够追溯到问题产生的原因，这就需要确定相关产品是否有足够的日志，尤其是需要在于数据库交互式的执行语句与执行响应。
继续说 FineReport的情况：
- 报表单一指标计算错误不会影响其他指标显示。
- 单一指标计算速度慢不会影响整体打开速度，会逐步更新算的指标值，但初始打开时计算过程中未算得结果的在页面布局上有一定概率不正确，此问题会逐步计算后动态的调整布局，最终效果正确。
- 设计调试阶段有完整执行日志，可查询执行的 sql 指令追溯计算错误问题，但对于复杂多层嵌套/页面联动等行为追溯相对复杂可考虑开发日志处理工具
- 生产环境（服务器版）部署后的日志并未调研
数据安全
理想状态下，我们的数据库不应该使用公网 IP，这方面针对前面提到的三种类型：
- 桌面应用程序：此类程序往往也支持不直接连接数据库，可以通过自建的后端或套件的后端来获取数据。
- web 直连产品：此类产品只提供了基于 Web 的 UI 快速搭建，类似于后台框架等等，具体的数据读取方式可以选择 API or 直连数据库，需要自行维护数据安全。
- B-S 产品：此类型产品完整的提供了前后端，后端负责和多源数据库的连接，前端只负责接受数据、传递指令，相对可以更好地保护数据库安全，只需要将服务端与数据库放到同一云供应商，避免开启公网 IP 即可。但同样的风险转嫁到了此类型产品的后端，无论是后端服务还是此产品提供的基于 Web 的后台。
FineReport作为 B/S 产品，有完整的服务端，前后端交互在数据方面一般以 POST 请求。
简单查看：请求参数是控件 id、控件内容、行为等，不会涉及到要执行的 sql。返回结果为控件信息及控件内数据。不确定是否有遗漏的情况，再加上使用 SSL 可进一步提高安全性。
协作开发
报表并不是一件简单的事情，无论是经过数仓的手段还是数据中台的手段，从业务角度来看，我们都是先打破了部门壁垒，然后让各部门数据相互碰撞，挖掘出更多的剩余价值，这就导致了我们报表业务的复杂性以及开发的工作量，我们不得不进行协作开发，尤其是可视化大屏。
一个可视化大屏可能有几十个模块，每个模块有三五个甚至更多一些的分析指标，一个页面上轻松可以出现过百的指标，因此能够让开发过程可协作是极其重要的环节。
首先对于协作我们需要考虑下面几个问题：
- 协作过程数据库如何连接：由于数据库在云上，为了安全也不会开放对外接口，此时推荐三种方式：① 使用 QA 环境，如果 QA 环境已经积攒了足够多的虚假数据且对数据结构安全性并不敏感，可考虑此方案，但不太推荐。② 使用VPN，让我们能够在本地经过 VPN 连上数据库。③ 使用云服务器，通过云上开发来实现在内网访问数据库。
- 单一页面分工开发方法：一个页面过百指标数量，根据业务内容进行一定分组安排任务，但同时要考虑如何此工具的记录文件是否能够自动 merge，如果不能自动 merge 如何进行人工 merge，merge 时能否正常的保留逻辑以及布局等信息……
- 重复性样式是否可方便复用：当样式重复只是逻辑和标题/标签差异时，是否能复用，是否有模板的概念，复用后是否能保证只是逻辑改变其他具有完全一致性以保证风格统一
……
FineReport支持通过更改工作目录为远端的工作目录的方式，直接开始协作开发，此方式只是将设计文件的存储位置放到了远端，真正操作执行等还是在本地，类似于一个设计文件版本管理器。
功能扩展性
产品是否提供了模块化 or 插件化平台，以通过公开流程关键节点的接口或其他方式来支持第三方插件、自定义组件的接入，来实现“无限可能”的未来。
插件包括但不限于：
- 更多地图表模板
- 用户交互过程更多的动画效果
- 花式提示框
- 设计阶段布局工具
- 运行阶段日志处理工具
- 整体的配色方案（皮肤? 主题?）
- 自定义计算模板/公式、领域专业公式集
- 鉴权认证插件
- 数据库驱动
- ……
FineReport有插件平台，包含多种分类分组，有官方插件及第三方插件，且有插件开发 API 文档
布局与配色
- 是否有整体的配色方案？便于在不追求高度定制的情况下快速成型，比如夜间模式……
- 设计阶段是否能进行规范的布局：水平、垂直、栅格、流、填表专用（label editbox）……
- 图层、透明度、可见性、盒模型
- 特效方面是否可控制事件流
- 响应式布局
FineReport布局上可以选择绝对布局（一切靠手拖拽），或者选择自适应布局，其可以配置双向单项（水平、垂直、栅格）同时可配置内边距与组件间边距。
交互
- 图自动刷新
- 图表联动
- 参数配置联动
- 动画效果
- 提示窗口
可复用组件
可复用性也直接或间接地影响到了协作开发的效率、最终展示效果一致性等多方面。
FineReport提供了网页插件，可通过插入网页控件来引用其他的组件，以嵌套的方式组合多种显示块。
还提供了模板插件，通过将选中的多个组件打包成一个模板，同时打包了组件间布局关系、数据操作逻辑，实现了逻辑、关系与控件的整体迁移复用，但其只能记忆布局关系，无法记忆布局最终尺寸，在多次复用后需要调整整体的尺寸问题。
组件自定义
此类型工具是通过将多种常用功能进行持久化的方式提高开发效率，但难免遇到特殊的需要，这时候就需要高度的自由行，比如提供插件平台、组件设计方式、API 接口、可编程……
FineReport提供了对 JS 的支持，可以在很多空间里在点击等操作时触发对应的 JS 脚本，后面就看开发自己的了。
同时有插件平台，可将重复使用的功能通过插件的方式持久化，有模板插件，可将重复的组件/组件集进行持久化。
