現代應用已經進入多數據源階段了，不再是一個單一的數據庫包打天下，一個應用中會涉及除關系數據庫外各種數據源，如文本文件類數據、NOSQL、多維數據庫、HTML Webservice 等等，即使是關系數據庫，也可能不止一個應用這樣了，那么應用中的報表自然也會涉及到多樣性的數據源了現在的報表，基本都是用
報表工具來做，很多報表工具都號稱支持多數據源，是不是能解決這個問題呢？其實只能搞定一點點
報表工具能輕松搞定的多源數據長什么樣
簡單的說，來自關系數據庫的多源數據都比較好搞定，不管是多表，還是多庫，都很簡單，用 SQL 把各個來源的數據都取出來，放到報表中去關聯、計算、呈現就可以
這樣的多源數據，好一點的報表工具都可以輕松應對
報表工具不好搞定的多源數據長什么樣
也可以簡單的說，不是單純的關系數據庫的多源數據，報表工具都不太好做進入大數據時代以來，數據不僅是大了，而且存儲的方式也多了，除了傳統的關系數據庫外，還有：
1. TXT/CSV、Excel、JSON/XML 等文件；
2. MongoDB、Cassandra、HBase、Redis 這些 NoSQL 數據庫；
3. HDFS 等分布式文件系統；
4. webService；
5. ES、Kafka 等其他數據源形式
文件類的某些報表工具還能搞定，但也只限于讀，而不會算，只能先全部讀入到報表中，然后再利用報表的計算能力來計算處理，數據量大時，讀取的效率和空間容量都可能會成為問題，（極個別的工具可以邊讀邊匯總過濾，還能并行流式讀取，會好很多）；其它類的數據源大部分報表工具就連讀都不會了，因為沒有標準，每家有各自的 API，想要讀取，大部分都得通過 JAVA 自定義數據集的方式了
讀取都比較費勁，而這些數據常常在業務邏輯上又有關聯，做報表的時候大部分時候都會涉及到多個數據源之間的關聯混算，單憑報表工具提供的多源關聯能力處理起來就更困難了
報表工具解決不了只能硬編碼
報表工具解決不了，但也難不倒工程師，因為工程師會編碼，沒有什么是編碼解決不了的
工程師可以先把異構的數據變成同構的，比如把文件的數據先導入到 RDB 中，由 RDB 計算后再給報表用，而那些不會讀的，就只能再一次依靠所有報表工具都提供的所謂自定義數據原接口了，用 JAVA 讀入并處理好，再傳給報表。
項目中，很多困難的多源混算情況，都是這么處理的，都能搞定，但是這么做其實弊端很多
異構變同構，其實大部分時候是把不同的數據強行裝入到常見關系數據庫中，然后再利用 SQL 的方式來處理計算，這樣做，首先得考慮數據庫本身的管理和壓力，管理上是否允許這樣操作，容量是否夠，每次遇到這樣的庫外數據都要往數據庫中放？
然后還得考慮時效，數據的導入都需要時間，量少的耗時短可能無所謂，量大的可能進度都被耽誤了，而且一般業務數據都是實時變動的，導入數據的方式也基本很難保證數據的實時性，還有些變不了或者變起來極困難的，像 json/xml 多層數據（mongodb 也是這種），要建很多表，想變都變不了
JAVA 處理的話，要好很多，不用考慮入庫的一系列問題，實時性也可以保證，但是開發成本高，還會破壞應用架構
JAVA 開發人員的成本本身就高，然后 JAVA 計算數據的能力還很弱，寫起來工作量很大，簡單做個求和運算都需要寫數行代碼的循環來實現，更別說邏輯復雜的運算了，動輒幾百行的代碼，一個報表還可以承受，報表一多，就承受不了這樣的高成本了
另外 JAVA 代碼需要和項目應用一起編譯，也會帶來報表和應用高耦合的問題，還會影響報表本身熱切換的能力。
（部分內容來源網絡，如有侵權請聯系刪除）
