報表看起來是數據分析處理領域中的一個并不起眼兒的邊緣業務，數據工程師的關注點一般會在后端的大數據平臺和數據倉庫，即使是前端，架構師們也會更關注 BI 可視化等時髦的概念，報表則經常作為一個部分被湮沒在呈現模塊中，即使有時被單拎出來也就是在架構圖上放一個報表工具而已。這種忽視態度很可能造成對報表開發的成本估算嚴重不足，而應用中的報表又常常沒完沒了，總會有新的改的需求，導致整體開發成本被大幅度推高，任務完成也變得遙遙無期。事實上，在應用系統中，查詢分析的結果大都會以報表的形式呈現出來，外圍的線下跑批看似與報表沒有直接關聯，但大部分也是為了進一步出報表而服務的。報表在應用中可以說是無處不在的，它的開發成本在應用建設中也有著非常重要的占比。

這些都是應用中的報表

說到報表，大部分人想到的可能是這樣的表格：其實很多報表并沒有表格的樣子，比如這種列表式的呈現還有報表格式也并不完全都是這種比較規整的，比如下面這個考場分布和驗收報告另外報表不僅關注外觀，還會關注統計功能，比如這種分組統計的列表和多數據來源的分組分片匯總統計只要是和數據相關，要用于呈現和輸出的都可以廣義地算作報表

報表很難做嗎？

這些報表，看起來無非就是些 HTML 了，寫個頁面加點 JS，應該難不倒程序員，這會有很高的開發成本嗎？其實不然，那些報表樣子看起來簡單，但實際動手做起來就不簡單了先看格式，大部分的報表格子都不少，用 HTML 單純的讓那么多格子對齊就不是一件易事，而且報表往往還有斜線和各種合并格，處理起來難度就會更大，耗費的時間也會更多，后期用戶如果發現格式不太對，得修改，牽一發動全身，那改一次基本相當于得重新做一遍了但不管怎么說，格式只是個費勁的事，并不是難事，多花點時間總會把格式調整好，而格子中的匯總統計就是個難事了報表很多時候并不是只需要羅列數據就可以，還需要統計匯總，比如前面的分組統計的例子，數據如果來自單表還好說，來自多表甚至多庫的做起來就復雜的多了另外分組的需求也有很多種，并不僅僅是簡單的按地區，按部門分組這些，比如按段分組，按不同的區間分組還有只按某些指標分組，其他都統計到“其他”里的這些在頁面中也很難處理，放到 SQL 中去算也不簡單還有統計也不僅僅只是匯總，還有占比、同比、環比、排名、累積等等，這些如果手工開發，難度又如何，又得占用多少工作量呢？這么稍微一分析拆解，確實發現不是那么簡單了，有點麻煩了那么那種簡單的列表總是比較容易做吧?是，沒問題，對于開發人員來說是基本功了，沒多大工作量但是，報表是會變化的，它會越來越復雜，因為需求是在不斷的發掘并改變的，并不是一開始就能想的非常周全的比如剛開始只需要我們做一個訂單列表，后面發現還得加一些查詢的參數才行，比如按時間段，按地區，按銷售，再后來又發現想看具體訂單內容情況時看不了，又得加一個鉆取功能，鉆取到訂單明細頁面，訂單明細為了美觀又需要有固定格式，比如每頁顯示多少行，不夠的補空行，再后來又想到還得有分組匯總表，可以按地區，按部門統計不同時間段的業績，最好再加一個伸縮功能就這樣，需求變的越來越多，報表也就越做越多，越做越復雜了然而復雜化還不止于此，報表不光是用來看的，大部分時候還得打印成紙質的，或者導出成其他常見格式的本地文件才可以打印功能就不容易做了，HTML 直接打印的精度通常不會被接受，這就需要控制打印機，而且不同瀏覽器不同版本，支持的打印方式不同，該怎么才能做到周全，有些單據類的比如紙質發票，物流單等，需要精準的打印在打印紙上，又該如何控制，還有其他的比如一次打印多張，有的需要預覽，有的不要預覽，都是頭疼的問題再看導出，基本代碼網上可以找到，但是改造成自己的也得費挺大勁，關鍵是用戶并不是只導出一種格式，EXCEL,PDF,WORD,WPS,CSV 都會用到，這需要多大工作量如果再遇上下面這種少見的需求，需要生成動態的既有文字，而且有嚴格的排版要求，又得有實時數據的表格和圖形的 WORD 報告，專門開發一個這個功能得付出多少成本呢所以，簡單的、少量的表格，寫代碼直接開發還可以，復雜的，大量的報表，全靠寫代碼的話從能力上說是難不住開發人員，但從成本上算就代價太高了，效率太低了

報表工具來了

草坪總需要修剪，人工剪效率低，割草機就來了莊家每年都得種，人工種效率低，播種機收割機就來了報表總得做，總得改，人工做效率低，報表工具就來了而且人工開發報表效率低這事情，其實并不是現在才有的，從 20 多年前各企業剛開始信息化建設時就普遍存在了，所以，報表工具在 20 年以前就已經誕生并流行了報表工具的誕生，不僅解決了那些我們可以想到的，常規常見的報表需求，同時也解決了許多應用中少見罕見的不太像傳統報表的特殊報表需求，不管需求如何變化，也不管遇到的報表有多么復雜，它都可以輕松應對，持續發揮它降本增效的作用而且報表工具的出現還在一定程度上優化了原本的應用結構，降低了后期維護的成本報表工具制作的報表是模板化的，數據和表格的信息都存在模板中，報表的業務穩定性是比較差的，總需要修改數據或者樣式，在模板中修改這些就很方便，修改完以后替換到應用中，直接就可以不用重啟做到熱切換，如果是全手工開發的，那報表和應用的耦合度就會比較高，修改起來動的地方就會很多，就會比較麻煩報表工具的大致工作流程

工具也有成本

工具確實能提升效率降低開發成本，但工具本身也有成本，報表工具需要多少成本呢？談一個軟件類產品的成本，對于大多數開發人員來說，都應該是零才對，因為有開源啊，不想用開源的開發不是一個好開發報表產品也有開源的，一直都有，但不幸的是，開源的報表都是外國的，而且大都不好用，簡單的列表還能做，但格式稍微復雜一些的，就做不了了，比如前面提到的多數據源分片報表，還有其他的什么不規則分組、動態列、動態合并單元格、折疊報表等，開源的基本都做不了，做不了那就得通過 api 手工做，實際應用中這類復雜的報表又不是少數，那就相當于大部分都得寫代碼開發了開源報表工具雖然不要錢，成本是零，但細算下來，復雜情況下多耗費的人工成本其實早就超過商用工具的成本了商用報表成本又如何呢？商用的，各家情況都不一樣，但能做這些復雜報表的大都比較貴，目前主流報表工具中，只有潤乾報表相對便宜而且透明，性價比高，1W 一套，3W 就可以一年隨便用，1W 的版本有些什么功能呢，夠用嗎，答案是夠用，報表呈現環節的需求，只需要這 1W 的版本就可以全部滿足了，具體的功能可以看這個帖子潤乾報表版本解析 - 樸實無華的功能列表背后藏了哪些不為人知的東西http://c.raqsoft.com.cn/article/1594121964870至于更深層次的潤乾為什么便宜呢，為什么會有這樣的戰略決策，可以看這里我們公司沒銷售 - 疫情下企業軟件的互聯網營銷

小結：開源的不一定真的成本低，商用的也不一定就都成本高，有潤乾報表這樣的標準存在，工具本身的成本，都沒有工程師 2 周的工資高了

自助報表怎么樣？

傳說有種自助報表，可以讓業務用戶自己拖拖拽拽做出報表，那些 BI 工具都是這么宣稱的，零編碼，不需要技術人員，也不需要自己懂技術，只要有需求就誰都能做…這不就能把工作和成本都轉給業務部門或用戶了嗎？還落個靈活方便的好處且慢！想得美一是 BI、自助報表沒有這么神自助報表和 BI 的定位是由業務人員去靈活的進行一些簡單的數據分析，格式簡單，計算簡單時，BI 還勉強可以勝任能力強一些的工具也可以做一些涉及格間計算的同比，環比這些格式和計算更復雜的時候，BI 工具和業務人員就都應付不來了，還得用報表工具才可以關于 BI 能做什么，可以參考：自助報表和 BI 能解決多少事？二是 BI 的成本更高當然，BI 和自助報表多少也有點用的，能上一套這東西，確實也能省一些事但是，我們還要再說一句“但是”，BI 的成本可不低，這概念時髦，雖然沒太大用，但價格通常比報表工具要貴得多國內商用的都是幾十萬一套，這個成本不管是誰來承擔，那都不是一個小數目，是選一個 1W 成本就能解決問題的報表工具呢，還是選一個成本高又解決不好問題的 BI 呢？BI 就沒開源的嗎？有，GitHub 就有好多評分不錯的，雖然說大都是國外的，但是國內的同學想用也可以拿來，只是界面改造麻煩一些，因為 BI 是頁面為主的產品，那么多英文的頁面都得改，工作量會大一些，成本依然比較高改造成本比較低的開源 BI 有沒有？之前沒有，現在有了，潤乾報表里就有一個開源 BI潤乾報表在業界口碑好，BI 和報表本是同源，潤乾的 BI 也一樣，功能全面好用，這樣使用成本就會比較低，不需要自己開發補足功能，另外頁面是中文的，改造成本也很低，改改就成了自己的 BI 模塊了潤乾零成本開源 BI 套件，不再掏錢給廠家

小結：BI 和自助報表并不是解決報表需求的好工具，它做不了復雜報表，而且商用的成本要遠高于報表工具，即使真有 BI 多維分析需求，也可以找開源好用的，這樣才能既解決問題又控制成本

使用的成本

繼續回到開發報表的成本話題上來工具除了價格成本外，還有使用的成本，其實就是開發效率的高低簡單的報表可能看不出效率差異，格式和計算復雜一些后，差異就出來了，同樣的報表，用 A 工具做半小時，用 B 工具做 3 小時，那 B 工具的使用成本就是 A 的 6 倍了選一個工具，價格其實是次要因素，最主要的因素還是它用起來效率高不高，做的好不好潤乾報表用戶多，大家選它也并不只是因為價格低，而更是因為它的開發效率是經歷過無數個項目實戰檢驗過的，能解決問題，又性價比高，才是大家選擇潤乾報表的原因而一個工具的開發效率并不是那么輕易能考察出來的，有一些工具把易于初學者學習的一步步的可視操作當成賣點，宣傳點，宣稱開發效率高，零編碼，考察人員也覺得這樣確實很好用，很簡單，但其實有可能掉進陷阱中，那就是開發報表的大都是技術人員，技術人員是很容易從一個初學者變成熟手的， 對于一個熟手來說，幾秒鐘寫個表達式，要遠遠比一步步的通過對話框設置各種計算條件要簡單的多，各種可視化設置就成了初學者之蜜糖，熟手之砒霜了那到底開發效率怎么考察，所謂的零編碼是不是真的，怎樣才能找到使用成本低的工具，感興趣的可以看下面的帖子怎樣考察報表工具的開發效率？零編碼制作報表真地可能嗎？這里也小結一下：開發效率高的工具，使用成本才低

進一步的成本

在報表的開發過程中，有時候我們還會發現，有一部分報表本身的制作并不難，工具能很快做出來表樣來，但還是會耗費掉很多的時間去開發和維護，仔細分析后我們會發現，是數據源的準備過程和性能問題占用了過多的時間，這一下就又讓開發成本增加了不少數據源準備的成本 好的報表工具確實可以很好地解決制表方面的困難，但是報表開發的難題，并不全在制表上，還有相當一部分在數據準備上，應用中的報表，有 80% 的數據來源和計算都比較簡單，很多一個簡單的 SQL 語句就搞定了，但還有 20% 的情況中，數據準備工作就沒有那么好做了，一些過程式的多步驟復雜計算，常常要寫很長的多層嵌套的 SQL 或者存儲過程才能搞定，如果數據來源再復雜一些，要對各類數據源混算，一些非關系數據庫或者文本數據源都不支持 SQL 了，那還得用 JAVA 等語言來寫，SQL 10 幾行能寫完的，JAVA 恨不得寫出幾百行來，編碼難度和效率就更糟糕了然而恰恰就是這僅占 20% 的需要硬編碼來做復雜數據準備的報表，可能會占去我們 80% 的 工作量，讓開發成本徒增有人可能會想到，數據源準備，也不屬于報表的能力范疇啊，所以這個開發困難的鍋不能讓報表工具來背，確實是的，數據源準備太困難不能怪報表，但不屬于報表的范圍就不用解決嗎？有能力的，還是要替用戶想辦法解決的潤乾報表內置了開源 SPL 計算引擎，就可以很好的解決數據準備的難題，極大的提升數據準備過程的開發效率，節省大量的人工成本具體的數據準備的難點在哪里，開源 SPL 是怎么解決數據準備的難題的，可以參考：為什么用了大牌工具后報表開發依然頭痛

再小結：有數據源準備工具的，開發難度就會低很多，成本也會低很多性能問題解決成本?

性能問題也是一個直接影響成本高低的重要因素，沒有性能問題還好，如果遇上了，那人工成本就會急劇上升，而且性能問題，一般都得派高級的技術人員去救火才行，搞不搞得定是另外一回事，沒完沒了的持續投入就誰也受不了報表的呈現周期中，大致可以分為下圖的 4 個環節，4 個環節都有可能造成報表的性能問題，但概率較高的是前兩個環節，數據準備和數據傳輸（圖中黃色電池電量圖，代表了出問題的程度）數據準備就是前面說過的，它不僅開發困難，而且開發出的東西性能基本也不好，很多時候我們會發現上百行的 SQL 和存儲過程已經完全沒辦法再優化了，遇到性能問題就只能硬挺數據傳輸一般是由 JDBC 傳輸速率慢導致的，這個可以通過并行的方式解決，但大部分報表工具也并沒有這個功能，只能是坐著等數據慢慢傳了后兩個就是報表工具的基本工了，得計算引擎做的好，函數設計的好，才能算的快，跑的快所以報表工具要想性能好，就得既要打鐵自身硬，把后兩個環節解決好，還得有解決外圍難題的金剛鉆，把前兩個環節也一并解決好才行報表的性能問題，具體的可以參考怎樣提高報表呈現的性能再小結：性能好的工具，投入的人工成本才少

總結

仔細分析后，我們發現，使用報表工具能有效降低開發成本，而開發報表的總成本中，工具本身的成本其實并不高，尤其是現在潤乾報表這樣的主流工具降價后成本都比不上一個初級工程師兩周的工資了真正占大頭的，其實是購買后隱形的使用成本以及遇到困難解決困難的人工成本，所以想要成本低，就得選一個開發效率高，性能好，又能協助解決數據準備難題的工具才可以，這樣才能做到真正的低成本。