常做數據信息化、數據分析的同學基本都遇到過這個問題，看著不起眼的報表任務，做起來卻占用了很多時間，總是不斷的有新報表要做，老報表要改，總是有難纏的數據準備要去寫復雜 SQL 或者存儲過程甚至 JAVA 代碼，原本以為初級工程師就可以搞定的事情卻始終都得有高級工程師跟著，報表給人的感覺像是沒完沒了的，資源的投入也沒完沒了，成本始終居高不下，一個簡單的報表模塊，卻每每成了項目的拖累

報表為什么沒完沒了？

報表沒完沒了確實是存在的，也是一個無法規避的事實，因為報表的業務穩定性本身就比較差，在統計和分析的過程中，總會碰撞和催生出新的、或者更合理的需求，那就需要修改或者做新的才可以，這與實施方和用戶的經驗無關，誰都避免不了有同學會說，BI 不就可以解決用戶的報表沒完沒了的問題嗎，給客戶上一套 BI，有需求用戶自己去做就可以了，我們就解脫了，確實有人這么做過，但還是解決不了，因為 BI 有局限性，感興趣的同學可以參考這個帖子，這里就不細說這個話題了自助報表和 BI 能解決多少事？報表沒完沒了無法規避，開發成本就只能居高不下嗎？不然我們先來分析一下開發成本高的地方在哪里，然后再看有沒有辦法降低成本

開發成本為什么居高不下？

被報表沒完沒了困擾的開發團隊，基本上都會用報表工具來提升開發效率，不用工具的很少。報表工具也的確不負眾望，可以很大程度的提升效率，節省開發成本，但是報表工具本身也有差異，效率也就有高低之分，就算是效率稍微差那么一點點，長年累月無數個項目累積下來，也是一個不小的數字開發成本居高不下的原因，很有可能就是選了開發效率低的工具好的報表工具確實可以很好地提升制表方面的效率，降低成本，但是報表開發的難題，并不全在制表上，還有相當一部分在數據準備上應用中的報表，有 80% 的數據來源和計算都比較簡單，很多一個簡單的 SQL 語句就搞定了，但還有 20% 的情況中，數據準備工作就沒有那么好做了，一些過程式的多步驟復雜計算，常常要寫很長的多層嵌套的 SQL 或者存儲過程才能搞定，如果數據來源再復雜一些，要對各類數據源混算，一些非關系數據庫或者文本數據源都不支持 SQL 了，那還得用 JAVA 等語言來寫，SQL 10 幾行能寫完的，JAVA 恨不得寫出幾百行來，編碼難度和效率就更糟糕了然而恰恰就是這僅占 20% 的需要硬編碼來做復雜數據準備的報表，可能會占去我們 80% 的工作量，讓開發成本徒增有人可能會想到，數據源準備，也不屬于報表工具的能力范疇啊，所以這個開發困難，成本高的鍋不能讓報表工具來背，確實是的，數據源準備太困難不能怪報表工具，但仍然屬于報表開發的范圍，我們也得解決，報表工具解決不了可以尋找其他工具！上面說到的，有些報表會涉及很長的存儲過程和自定義 JAVA 代碼，這樣會造成報表模塊和整個業務系統的高度耦合，維護修改報表的時候，整個應用系統可能都得一起停擺、重啟，維護起來不方便，成本就會高而且這些復雜的 SQL，存儲過程，自定義 JAVA，以及性能問題的排查，全部都得高級技術人員去做才可以， 什么都用高級人員，成本自然又會變高除了技術原因外，溝通和管理上的問題也會導致開發成本上升，比如用戶要求做表，做完以后才發現用戶說的概念術語和我們理解的有偏差，統計的不對，那就得修改，返工。再比如有些報表是可以復用的，或者稍加改動就可以吻合新的報表需求，就不需要重做了，但是開發人員太多，如果報表管理做的不好，就每個表都得做一次，浪費很多開發量這些就是成本居高不下的主要原因，找到原因后，我們就可以挨個想辦法去解決了

解決方案

用報表工具，尤其是高效的工具，可以顯著提升報表設計與呈現的效率，降低開發成本

要用高效的，大家都知道，但怎么選高效的，卻不是一件簡單的事情，驗證工具的效率，需要一套科學嚴謹的的方法，有需要的可以仔細看看這篇帖子怎樣考察報表工具的開發效率？具體的方法帖子里都有詳細說明，本文就不展開聊了，只說一個驗證時候最容易掉的陷阱 --- 初學者陷阱有一些工具把易于初學者學習的一步步的可視操作當成賣點，宣稱開發效率高，零編碼，考察人員也覺得這樣確實很好用，很簡單，但這樣就掉進陷阱中了，初學者易上手絕對不等于效率高！反而一步步的可視化的引導操作會成為提升開發效率的很大障礙因為開發報表的大都是技術人員，技術人員是很容易從一個初學者變成熟手的， 對于一個熟手來說，幾秒鐘寫個表達式，其表達能力要遠遠比一步步的通過對話框設置各種計算條件要強大得多也簡單的多，各種可視化設置就成了初學者之蜜糖，熟手之砒霜了當然如果沒有時間詳細考察也無妨，選一些老牌的大家常用的工具就可以，像潤乾報表這樣的，已經有 20 年經驗和歷史的，經歷了無數用戶驗證的，開發效率都是遠高于其他工具的高效的報表工具，可以提升報表設計和呈現的效率，但對報表數據準備階段的開發壓力卻仍舊無能為力

這就需要有新的工具才可以解決，一種比編寫復雜 SQL，存儲過程，JAVA 更高效，成本更低的計算工具才可以這樣的工具其實并不新鮮，早就有了，潤乾出品的集算器 SPL 就是專業的計算工具，因為簡單高效，而且開源免費，已經是比較流行的工具了，它有如下幾個特點
1 易于編碼SPL 包含豐富的計算類庫，可以很方便地完成各類數據計算任務；提供可視化的編輯調試環境, 初級工程師就可以很快上手，不需要全程都得高級工程師跟進了
2 支持熱切換SPL 采用解釋執行機制，可以很好地和前端報表呈現模板結合在一起，報表修改后可以實時生效，無需重啟整個應用

3 支持多樣性數據源支持 RDB、NoSQL、文本、Excel、hadoop json 等多樣性數據源，可以進行混合計算（如 Excel 和 RDB 的表 join）；
4 高性能SPL 的性能在大部分場景下都已經被驗證過是高于甚至是遠高于 SQL 的

當頻繁復雜困難的數據準備過程，也有了趁手的工具可以解決以后，開發就變的簡單輕松了，成本也自然就低了另外再強調一點，SPL 是開源免費的，是一個通用的計算工具，不僅潤乾報表可以用它，其他報表工具以及各類前端應用，也都可以用它報表與業務系統的高度耦合，導致報表不易維護，還影響了業務系統的穩定，那我們就想辦法把報表模塊獨立出來，原先是沒有這個條件，現在有了計算工具以后，存儲過程，各種中間表，JAVA 程序就可以慢慢剝離開了，報表就完全可以和業務系統解耦了
1 梳理數據源首先梳理數據源，將報表業務相關的數據源都整理出來，以后的報表開發只需要和這些數據源打交道；同時為下一步剝離報表業務做準備
2 剝離報表業務將數據源和業務應用中與報表相關的數據準備（復雜 SQL、存儲過程、中間匯總表、自定義 JAVA 類）全部轉移到報表工具，計算工具中實現；同時將這些內容從數據庫和業務應用中清除，完成報表業務剝離
3 獨立報表模塊報表業務完全剝離后，報表就可以獨立于數據源和業務模塊存儲，不再與業務系統和數據源緊密耦合了，解釋執行報表和計算模塊支持熱切換，即改即用，無需重啟應用；不管報表要怎么加怎么改，都不會影響到業務模塊了，而且獨立的報表 + 計算模塊，維護起來也更簡單了，不需要投入太多成本了

原先因為總有困難的數據準備任務，不是得寫大段復雜的存儲過程，就是得做 JAVA 開發，處處離不開高級工程師，有了計算工具后，困難的事情都變簡單了，復雜的數據準備工作不存在了，疑難的性能問題也沒有了，自然就不需要浪費高級人員了

不需要去應對復雜的應用環境，也不用管什么架構，只需要專注開發報表就可以，那建設一支應屆生報表團隊就完全沒問題了，既節省了成本，還讓新人挑起了重擔，歷練了新人
另外報表開發簡化后，還可以嘗試將持續的報表開發工作移交給客戶方的本地運維人員，這樣不僅能降低開發商的成本，也可以讓客戶更自由方便一些，對雙方都是好事情溝通成本高，而且總有偏差，可以通過建立知識庫來解決，比如統計好行業常用的指標計算方式，記錄好每個客戶業務術語的含義比如用戶要做一個大客戶信息表，我們就可以先查一下知識庫中有沒有記錄“大客戶”是怎么定義的，這樣就可以有效的避免偏差返工，節省成本
報表總是重復去做，也可以通過報表知識庫來解決，把歷史的報表都保存好，做好注釋備注，遇到同樣的或類似的報表時，就可以直接拿來改改用了

至此，導致成本過高的幾個難題，就都一一擊破了，一套組合拳打出后，回頭再看，只剩下一地紙老虎了

總結

報表總是得做新的改舊的，總是沒完沒了的，這的確是一個讓人頭疼的事情，而且這還是一個合理的、讓人無法規避的事情。躲不了，那就得想辦法解決，不能讓它一直困擾我們，更不能讓成本白白被消耗掉，傳統的單一報表工具形式已經明顯無力解決這個難題，而要采用文中提到的組合拳才可以有效應對而且這套組合拳，不僅可以把高昂的開發成本打下來，還能讓我們在工具成本上也大省一筆，雖然多了一個計算工具，但它是開源免費的，配上 1W 一套，3W 隨便用的潤乾報表，就可以去隨便 KO 各種報表開發難題了