什麼是報表的多樣性資料來源問題?如何解決?

bubblegum發表於2020-07-23

在報表開發早期,報表連線的資料來源基本只有關聯式資料庫,而且經常只有一種或者只有一個資料庫。

但今天就不一樣了,資料來源種類繁多,除了 RDBMS 還有
1.MongoDB、Cassandra、HBase、Redis 這些 NoSQL 資料庫;
2.TXT/CSV、Excel、JSON/XML 等檔案;
3.HDFS 等分散式檔案系統;
4.webService;
5.ES、Kafka 等其他資料來源形式
……

imagepng

當這些都成為報表資料來源,報表需要從這些資料來源分別或混合取數運算進行報表呈現時,報表就出現了多樣性資料來源問題。

具體是什麼樣的問題呢?

主要是兩個問題,複雜計算和多源關聯計算。

1. 複雜計算
我們知道,報表中的計算主要集中在兩處:

一處是資料準備階段。
透過 SQL/ 儲存過程 /Java 程式為報表準備資料,這個階段可能涉及非常複雜的資料處理邏輯。這樣, 計算能力尤其是集合計算能力較強的 SQL 就比較擅長了,透過 SQL、複雜 SQL 可以完成大部分的報表資料準備任務,有些涉及較多業務邏輯的計算還可以使用儲存過程,萬不得已時用 JAVA 自定義資料來源完成。

這是早期基於單一 RDBMS 開發報表時資料準備的常用手段,主要依靠 RDBMS(SQL)的計算能力來實現。

但這種方式在多樣性資料來源的場景下就行不通了,因為有的資料來源根本就不支援 SQL,甚至計算能力都比較弱(如 NoSQL),或者根本就沒有計算能力(如文字),這樣,資料準備計算計算無法在這個階段實現,就要看另外一處是否可以完成了?

二處是報表呈現階段
根據第一階段已準備的資料,在報表模板中填入繫結格子的報表表示式或圖形來呈現報表是使用報表工具開發報表的常用方式。這說明報表工具具備一定的計算能力,透過表示式可以實現分組彙總、過濾、排序,複雜一些的同比環比等計算。

但是,報表工具的計算能力是有限的。不考慮效能的情況下,單純從資料來源中讀取資料到報表呈現階段完成資料組織和報表呈現很多時候是做不到的,這也是為什麼我們會在資料準備階段進行復雜資料處理的原因了。

2. 多源關聯計算
與基於單一的某個資料來源進行的複雜計算不同,有時一個報表會同時連線多個資料來源,多個資料來源之間要混合計算,比如 MongoDB 的資料和 RDBMS 的資料關聯運算,文字和 Excel 關聯運算等。

這種跨異構資料來源的關聯無法直接透過資料來源自身的能力實現,只能藉助其他方法。


那報表的多樣性資料來源問題如何解決呢?

方法總比問題多。目前大家普遍採用兩種方式來解決報表多樣性資料來源的問題。

藉助 RDBMS
曲線救國。將多樣性資料來源的資料透過 ETL 灌到關係庫中,再基於關係庫出報表,這樣就可以避免多樣性資料來源的問題,轉而使用最熟悉的手段來解決。

不過,這種方式的侷限性很大。因為之所以出現多樣性資料來源,是因為各種資料來源有各自適用的場景,換句話說很多是關係庫搞不定的,所以才會用這些資料來源,比如 NoSQL 的 IO 吞吐能力很強,但計算能力較弱;文字 /Excel 檔案適合做臨時儲存且不需要持久化到 DB;Webservice 則非常靈活,入庫的動作就顯得過於笨重,…

且不說多樣性資料來源的資料是否能轉換到關係庫中,由於要經過 ETL 的過程,資料的實時性如何保證?資料量較大時除了 ETL 慢,RDBMS 的容量是否夠用?查詢效能是否滿足報表查詢要求?等等這些問題都是這種方式要面對的。

採用這種方式經常是“不得已”,因為解決某類問題上了其他資料來源,結果因為出報表又要用回關係庫,也不知道隱含了多少辛酸。

JAVA 硬編碼
透過 RDBMS 來解決報表多樣性資料來源的問題有這樣那樣的問題,那直接硬編碼怎麼樣?透過 JAVA 硬編碼對接多樣性資料來源為報表準備資料,畢竟硬編碼想幹啥就幹啥。

這種方式我們之前有分析過,除了編碼難、維護難的問題(報表開發人員基本搞不定),還存在無法熱切換(JAVA 是編譯型語言)和與業務應用緊耦合(程式碼要跟業務應用主程式一起打包部署)這些問題。這是我們之前聊過的:

硬編碼似乎也不理想。


事實上,我們只需要增強報表工具的計算能力就能解決這個問題。

1. 首先,提供多樣性資料來源的支援,透過報表工具可以連線這些資料來源,要實現這一步相對簡單;

2. 其次,提供複雜計算支援,讓所有的複雜計算都能在報表中完成。實現手段可以是強化呈現端的計算能力,透過報表格子表示式就能完成這些複雜計算。不過,對於繫結格子的計算(狀態式計算)想要支援複雜計算並不容易,在呈現端要兼顧資料處理和資料呈現很多計算就做不了了,而且呈現格會帶有很多呈現屬性(字型、顏色、邊框等等),帶著這些屬性計算會佔用過多記憶體,嚴重影響計算效能。

imagepng
很難在報表呈現格表示式中完成複雜計算(功能和效能都不滿足)

可以想到的另外一種方式是在報表中增加計算模組用來專門做多樣性資料來源混合計算,其位置與原來為報表準備資料的 SQL 和 JAVA 相當,只不過是內嵌在報表中,屬於報表自身的能力,結構大概是這樣

imagepng

在原有的基礎上增加了計算模組,計算模組可以透過可程式設計計算指令碼實現,但對這個指令碼能力有要求:

1. 提供多樣性資料來源訪問介面
能直接對接多樣性資料來源是基礎,種類越豐富對多樣性資料來源問題解決得越充分;

imagepng

2. 支援複雜計算
當資料來源自身不具備強計算能力時,透過指令碼可以完成報表資料準備階段的複雜計算邏輯,指令碼提供豐富的計算類庫,可以很方便地實現這類計算,最好比 SQL 和 JAVA 都簡單;

3. 支援多源關聯
可以跨異構資料來源關聯計算,這是也解決報表多樣性資料來源問題需要具備的重要能力;

4. 支援熱切換
指令碼修改後可以實時生效,而不會像 JAVA 一樣需要重啟應用。

當我們遇到報表多樣性資料來源問題需要選擇報表開發技術時不妨沿著這個方向考量一下。

參考資料:


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69957599/viewspace-2706422/,如需轉載,請註明出處,否則將追究法律責任。

相關文章