T+0 的概念，運用比較廣泛的是在金融領域，T（Transaction）表示交易日期，+0 就是指交易當天，+N 就代表交易的 N 天后現在大數據、
數據分析領域，也總用到這個概念，含義仍然相同，T+0 表示當天的實時數據，T+N 則表示當天的數據 N 天后才能看到放到報表中 T+0 就是今天的報表就可以看到今天實時的數據，T+1 就是今天的數據，明天才能看到T+0 報表的難點在哪里
如果所有數據都存在一個數據庫中，那 T+0 報表其實沒什么難度，直接查就是最新的實時數據但實際應用中，很多場景下，數據是會分開存儲的，比如下圖這樣，由于歷史數據過于龐大，為了保證業務庫的性能不受影響，就只能把老的歷史數據遷移到別的庫去存儲，這時候，如果報表需要同時分析歷史數據和當前最新數據做 T+0 報表，就需要從不同的分庫中同時取數，而且歷史庫和業務庫很多時候又不是一個類型，
怎么跨庫查詢取數就成了一難題，
這也正是 T+0 報表的難點所在如果解決不了這個難題，那就只能用 ETL 等方式，定時把冷熱庫的數據抽取到一起，然后再出報表，那就是 T+1 甚至嚴重到會 T+7 了
目前有什么手段
好一些的報表工具，其實提供了一個初級的解決方案，就是報表本身的多數據集功能，它可以直接進行跨庫查詢，獲取最新數據，做出 T+0 報表，比如下面這樣的
但是報表工具計算能力有限，只能做一些初級簡單的，比如上面的分組匯總，兩個數據集的分組情況如果相同，或者第一個數據集包含第二個的，那可以這樣做，否則分組就會錯亂，就不好做了，就得用自定義數據集提前把數據合并好了還有一些其他復雜的計算單憑報表的計算能力也無法實現，也得用定義數據集算另外分庫的數據一般數據量非常大，全部把計算放到報表內，在性能上也不一定能保證，不是很適用所以報表工具的多源混算在簡單場景下可以做出 T+0 報表，復雜情況下不能勝任，是比較初級的功能數據庫本身也有跨庫查詢的功能，比如 Oracle 的 DBLink，MySQL 的 FEDERATED 引擎，都可以進行跨庫查詢，也可以做到 T+0 查詢，再把數據給到報表，就能做出 T+0 報表，但是這些功能都對異構數據支持的不是很好，對非關系型數據源更是無能為力，適用的場景也比較窄這是工程師的殺手锏，沒有好辦法，那就敲代碼唄，沒有什么是代碼搞不定的，一個跨庫取數難不倒 JAVA, 不管你是同構異構還是非關系數據庫，各種情況都能搞定但話又說回來，但凡有更簡單的辦法，誰愿意做個查詢取數還得用 JAVA 實現呢JAVA 寫起來難，算起來慢JAVA 這類高級語言，對結構化數據的計算支持很有限，雖然都能做，但卻能力比較弱，寫起來非常繁瑣，簡單做個求和運算都需要寫數行代碼的循環來實現，而報表數據源處理則大量涉及批量數據運算，采用高級語言開發時會導致動輒數百行的冗長代碼，編寫、調試和后續維護都會很困難，而且性能也無法保證，高手懂算法，寫出來的就算的快一些，普通人寫的可能就會出現性能問題JAVA 還破壞應用架構JAVA 代碼需要和應用程序一起編譯、打包，造成和應用的高度耦合，給后續維護帶來困難每次修改，都得重新編譯，就需要整個應用陪著重啟甚至停機，影響應用穩定所以 JAVA 雖然什么都可以搞定，能力很強，但卻也不是一個很好的選擇更好的方法
看過各種手段的不足后，我們也就明了了，更好的方案，需要它支持跨庫運算，支持同構異構數據，支持各類不同數據源，支持大數據量，書寫簡單，性能好，不會破壞應用有這樣的方案嗎？報表集成SPL 集算器以后就具備了這樣的能力
SPL 是一款流行的專業的數據計算處理工具，很多項目開發商都在用，因為它不僅好用，而且還免費，開源，是常年做項目，總需要做數據處理的工程師的好幫手集成 SPL 后，報表相當于多了一個計算層，這個計算層支持常見的各類數據源，可以同時計算來自不同數據源的數據，不管它是同構還是異構，不管你怎么分庫，分到哪里，都能做到 T+0
|
|
A
|
|
|
1
|
=cold=db1.cursor(“select * from orders where odate
|
/ 冷數據從歷史庫中取，昨天及以前的數據
|
|
2
|
=hot=db2.cursor(“select * from orders where odate>=?”,date(now()))
|
/ 熱數據從生產庫中取，今天的數據
|
|
3
|
=[cold,hot].conjx()
|
|
|
4
|
=A3.groups(area,customer;sum(amout):amout)
|
|
SPL 不僅可以像上面的代碼一樣，簡單寫出跨庫的取數查詢，比 JAVA 簡單的多，它還比 SQL 寫起來簡單看個小例：
查出各科成績都在前 10 名的學生用 SQL 寫起來，比較復雜，也很難理解from (select name from (select name, rank() over(partition by subject order by score DESC) ranking from score_table) where ranking<=10)group by namehaving count(*)=(select count(distinct subject) from score_table)
用 SPL，則按思路過程寫出計算就行，寫起來簡單，還容易理解，性能也比 SQL 要更好，而且在 SPL 中， 這樣的高性能函數和算法還有很多，誰都可以直接用，不需要非得高手才能寫出性能好的算法了
|
|
A
|
|
1
|
=score_table.group(subject)
|
|
2
|
=A1.(~.rank(score).pselect@a(~<=10))
|
|
3
|
=A1.(~(A2(#)).(name)).isect()
|
說到性能，還要提到開源 SPL 有自己的存儲，它提供了高效的二進制文件存儲方式，文件存儲具備很多優勢，不僅讀取效率更高，還可以有效利用文件壓縮、并行等機制提速，同時還不會像數據庫那樣容易受到容量的限制，在一些傳統的歷史庫無法保證計算性能和時效的情況下，甚至可以用 SPL 的二進制文件存儲當做歷史庫來提升性能了
SPL 作為報表的計算層，它編寫的計算腳本是存儲在報表模板里的，是解釋執行的，這就避免了和應用的耦合解釋執行的 SPL 同時也具備了熱切換的能力，不會像 JAVA 一樣影響應用的穩定了
總結
大數據時代，數據的分庫存儲很常見，T+0 實時報表的需求更常見，用常規的手段來做，簡單的、少量的情況還能應付，復雜，大量的時候，就需要用更好更新的技術了。
（部分內容來源網絡，如有侵權請聯系刪除）
