報表自動化: 如何選擇可視化大屏開發利器?www.coologic.cn

我們在前文完成了各種數據的準備：原始數據、指標數據、報表表格等等，但仍然無法解決“閱者”難以理解龐大數據。我們需要用圖文并茂的形式來提高信息的可理解性、易理解性，并以固定的排布方式使“閱者”逐漸構成數據-狀態、數據-決策的“反射弧”。

工具選擇

常規的數據可視化方式我們可以選擇直接讀取數據庫，通過繪圖軟件/庫進行繪制，最終構成自建的前端顯示效果，比如使用 Apache ECharts (incubating) 等工具。

除此以外，追求效率的我們還可以選擇成熟的報表套件，這類套件往往具有一系列的圖表模板+支持推拽且可視化的配置頁面，方便我們快速的構建出可視化大屏。其實大部分套件的機理差異并不大，為了降低文章內容量，本文直接講解某一種套件，

當然報表套件又分為三類：

• 桌面應用產品，生成的是桌面端程序，程序往往直接連接云端數據庫，需要數據庫開放公網 ip。也有部分會有服務端提供 crud api 來降低數據泄露風險
• web 端直連數據庫 / 自建后端產品，這種產品較少，畢竟已經做到 web 了再配個服務器豈不是更好，否則還是要數據庫開放 ip
• B-S 產品，服務端提供與多源數據庫的連接、數據提取、前端頁面生成，前端負責顯示、用戶交互與動態刷新等等

本文選擇第三類的一款套件作為講解 -- 帆軟的 FineReport，選擇此產品原因：1、中文文檔、中文配置界面，對于國內讀者友好度高；2、無意間看到此產品

請勿將本文內容當做推薦 or 引戰，我盡量從可視化報表工具的角度出發描述，而不是針對某個具體的產品，只是為了形象且可查證會給出 FR 在下面各方面的實踐方式 / 方案，不作任何額外評價

既然是個套件應該有很多完整成熟的功能，我們以這幾個維度來聊聊：

• 環境與基礎設施：設計環境搭建，生產環境搭建，故障傳遞與追溯，數據安全，協作開發，功能擴展性
• 視覺效果與用戶交互：布局，配色，交互，可復用組件，組件自定義

設計環境搭建

首先說說環境的類型：

• 傳統的桌面應用的設計器，前者往往直接安裝打開使用即可，對于 B-S 類的產品，往往設計器安裝包會自帶一個服務在啟動后自動運行可用于調試的服務環境
• 基于 Web 的設計器，這種設計器有些是支持同時設計與提供展示服務的，即一次搭建后根據登錄賬號的 role 進入不同的環境，有些是完全分離的兩套環境。

FineReport 屬于前者，對于不同系統均由輕松安裝的安裝包，不需要復雜配置。

生產環境搭建

對于 B-S 產品，和搭建后端類似，只是不需要復雜的配置了，直接根據教程安裝一下就即可啟動服務（一般來說是這樣的）

對于后續要說的功能擴展性，可能會影響此步驟，如果產品具有功能擴展性，那么額外擴展的功能需要單獨部署在服務上并配置相關連接，如果是基于插件化的擴展需要在服務端安裝對應插件。

此部分建議構建完整的環境搭建文檔，如果產品可以通過腳本安裝，建議直接將部署過程腳本化。

FineReport 環境安裝也是安裝包直接搞定，其具有插件平臺，若有補充插件需要通過 web 登錄后添加對應插件

故障傳遞與追溯

往往數據可視化以后就逐漸地產生了可視化大屏，單頁面信息含量極其豐富、跨越的業務部門繁多、數據分析維度全面，我們需要保證單一故障不會大面積的波及其他信息。

• 設計器出現故障是否會影響服務端？尤其是通過 role 區分環境的 web 設計器。
• 個別數據庫通訊問題是否會影響整個產品服務的運行？
• 個別指標的計算錯誤是否會導致同頁面其他指標均無法顯示？
• 個別指標計算緩慢是否影響同頁面其他指標均無法刷新？

對于故障還有額外要做的是實時處理方式：

• 關鍵指標計算錯誤是否也要報警？因為可視化大屏運行狀態也許也是一個指標呢
• 指標計算錯誤時顯示 0 還是現實錯誤信息？尤其注意在指標具有其獨特的存在性意義時，不建議隨意的用同類型數據作為展示，避免錯誤統計

雖然我們保證了故障波及的可控性，但我們還希望能夠追溯到問題產生的原因，這就需要確定相關產品是否有足夠的日志，尤其是需要在于數據庫交互式的執行語句與執行響應。

繼續說 FR 的情況：
報表單一指標計算錯誤不會影響其他指標顯示。
單一指標計算速度慢不會影響整體打開速度，會逐步更新算的指標值，但初始打開時計算過程中未算得結果的在頁面布局上有一定概率不正確，此問題會逐步計算后動態的調整布局，最終效果正確。
設計調試階段有完整執行日志，可查詢執行的 sql 指令追溯計算錯誤問題，但對于復雜多層嵌套/頁面聯動等行為追溯相對復雜可考慮開發日志處理工具
生產環境（服務器版）部署后的日志并未調研

數據安全

理想狀態我們的數據庫不應該使用公網 IP，這方面針對前面提到的三種類型：

• 桌面應用程序：此類程序往往也支持不直接連接數據庫，可以通過自建的后端或套件的后端來獲取數據。
• web 直連產品：此類產品只提供了基于 Web 的 UI 快速搭建，類似于后臺框架等等，具體的數據讀取方式可以選擇 API or 直連數據庫，需要自行維護數據安全
• B-S 產品：此類型產品完整的提供了前后端，后端負責和多源數據庫的連接，前端只負責接受數據、傳遞指令，相對可以更好地保護數據庫安全，只需要將服務端與數據庫放到同一云供應商，避免開啟公網 IP 即可。但同樣的風險轉嫁到了此類型產品的后端，無論是后端服務還是此產品提供的基于 Web 的后臺。

FR 作為 B - S 產品，有完整的服務端，前后端交互在數據方面一般以 POST 請求。
簡單查看：請求參數是控件 id、控件內容、行為等，不會涉及到要執行的 sql。返回結果為控件信息及控件內數據。不確定是否有遺漏的情況。再加上使用 SSL 可進一步提高安全性
另外注意，其具有插件平臺，部分插件由第三方開發，不確定各種外帶的插件是否能保證數據庫結構的零泄露。

協作開發

報表并不是一件簡單的事情，無論是經過數倉的手段還是數據中臺的手段，從業務角度來看，我們都是先打破了部門壁壘，然后讓各部門數據相互碰撞，挖掘出更多的剩余價值，這就導致了我們報表業務的復雜性以及開發的工作量，我們不得不進行協作開發，尤其是可視化大屏。

一個可視化大屏可能有幾十個模塊，每個模塊有三五個甚至更多一些的分析指標，一個頁面上輕松可以出現過百的指標，因此能夠讓開發過程可協作是極其重要的環節。

首先對于協作我們需要考慮下面幾個問題：

• 協作過程數據庫如何連接：由于數據庫在云上，為了安全也不會開放對外接口，此時推薦三種方式：1、使用 QA 環境，如果 QA 環境已經積攢了足夠多的虛假數據且對數據結構安全性并不敏感，可考慮此方案，但不太推薦。2、使用 VPN，讓我們能夠在本地經過 VPN 連上數據庫。3、使用云服務器，通過云上開發來實現在內網訪問數據庫。
• 單一頁面分工開發方法：一個頁面過百指標數量，根據業務內容進行一定分組安排任務，但同時要考慮如何此工具的記錄文件是否能夠自動 merge，如果不能自動 merge 如何進行人工 merge，merge 時能否正常的保留邏輯以及布局等信息……
• 重復性樣式是否可方便復用：當樣式重復只是邏輯和標題/標簽差異時，是否能復用，是否有模板的概念，復用后是否能保證只是邏輯改變其他具有完全一致性以保證風格統一
• ……

FR 支持通過更改工作目錄為遠端的工作目錄的方式，直接開始協作開發，此方式只是將設計文件的存儲位置放到了遠端，真正操作執行等還是在本地，類似于一個設計文件版本管理器，但無法解決數據庫無公網 IP 問題，會導致本地無法查閱效果，且開發過程中有關數據操作的配置頻繁報錯（無法連接獲取信息）
復用相關請見下

功能擴展性

產品是否提供了模塊化 or 插件化平臺，以通過公開流程關鍵節點的接口或其他方式來支持第三方插件、自定義組件的接入，來實現“無限可能”的未來。

插件包括但不限于：

• 更多地圖表模板
• 用戶交互過程更多的動畫效果
• 花式提示框
• 設計階段布局工具
• 運行階段日志處理工具
• 整體的配色方案（皮膚? 主題?）
• 自定義計算模板/公式、領域專業公式集
• 鑒權認證插件
• 數據庫驅動
• ……

FR 有插件平臺，包含多種分類分組，有官方插件及第三方插件，且有插件開發 API 文檔

布局與配色

• 是否有整體的配色方案？便于在不追求高度定制的情況下快速成型，比如夜間模式……
• 設計階段是否能進行規范的布局：水平、垂直、柵格、流、填表專用（label+editbox）……
• 圖層、透明度、可見性、盒模型
• 特效方面是否可控制事件流
• 響應式布局
• ……

沒有過多的研究，初步感覺有一套自帶的默認配色
布局上可以選擇絕對布局（一切靠手拖拽），或者選擇自適應布局，其可以配置雙向單項（水平、垂直、柵格）同時可配置內邊距與組件間邊距，但沒有發現明顯的瀑布流布局。
布局需要有層次傳遞性，對多層復雜布局的傳遞效果與可控性未做研究

交互

• 圖自動刷新
• 圖表聯動
• 參數配置聯動
• 動畫效果
• 提示窗口

可復用組件

可復用性也直接或間接地影響到了協作開發的效率、最終展示效果一致性等多方面。

FR 提供了網頁插件，可通過插入網頁控件來引用其他的組件，以嵌套的方式組合多種顯示塊，但初步測試感覺此功能破壞了布局逐層傳遞性
還提供了模板插件，通過將選中的多個組件打包成一個模板，同時打包了組件間布局關系、數據操作邏輯，實現了邏輯、關系與控件的整體遷移復用，但其只能記憶布局關系，無法記憶布局最終尺寸，在多次復用后需要調整整體的尺寸問題。

組件自定義

此類型工具是通過將多種常用功能進行持久化的方式提高開發效率，但難免遇到特殊的需要，這時候就需要高度的自由行，比如提供插件平臺、組件設計方式、API 接口、可編程……

FR 提供了對 JS 的支持，可以在很多空間里在點擊等操作時觸發對應的 JS 腳本。。。后面就看自己的了
同時有插件平臺，可將重復使用的功能通過插件的方式持久化
同時有模板插件，可將重復的組件/組件集進行持久化

感謝閱讀，歡迎關注微信公眾號：coologic

報表相關的系列文章請參考：

• 報表自動化: 商業智能背后的秘密
• 報表自動化: 打開數據倉庫的大門
• 報表自動化: 沒有壓力的維度建模
• 報表自動化: 抓住時間流逝的瞬間
• 報表自動化: 薅出數字背后的價值
• 報表自動化: 事實、維度與指標的三方會談
• 報表自動化: 數據倉庫建模實踐經驗干貨
• 報表自動化: 神奇的粘合劑 ETL 工具

總結

以上是生活随笔為你收集整理的润乾报表列太多导致渲染速度慢_报表自动化: 如何选择可视化大屏开发利器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。