教你如何解決T+0的問題_ZenDei技術網路在線

摘要：T+0查詢是指實時數據查詢，數據查詢統計時將涉及到最新產生的數據。本文分享自華為雲社區《大數據解決方案：解決T+0問題》，作者：小虛竹。 T+0問題 T+0查詢是指實時數據查詢，數據查詢統計時將涉及到最新產生的數據。在數據量不大時，T+0很容易完成，直接基於生產資料庫查詢就可以了。但是， ...

摘要：T+0查詢是指實時數據查詢，數據查詢統計時將涉及到最新產生的數據。

本文分享自華為雲社區《大數據解決方案：解決T+0問題》，作者：小虛竹。

T+0問題

T+0查詢是指實時數據查詢，數據查詢統計時將涉及到最新產生的數據。在數據量不大時，T+0很容易完成，直接基於生產資料庫查詢就可以了。但是，當數據量積累到一定程度時，在生產庫中進行大數據量的查詢會消耗過多的資料庫資源，嚴重時會影響交易業務，這就不能接受了，畢竟生產交易是更關鍵的任務。所以，我們常常會把大量用於查詢分析的歷史數據從生產庫中分離出去，使用單獨的資料庫存儲和查詢，以保證查詢統計不會影響生產業務，這就是常說的冷熱數據分離。

數據分離後就會產生T+0問題。數據拆分到兩個資料庫中，要查詢全量數據就涉及跨庫查詢。而且，我們知道，用於交易的生產庫大多使用能夠保證事務一致性的RDB，而分離出來的冷數據（量大且不再修改）則會更多使用專門的分析型資料庫或數據平臺存儲，即使是關係資料庫也很可能與原來的生產庫類型不同，這就不僅涉及跨庫，還需要跨異構庫（源）查詢。遺憾的是，當前實現跨庫查詢的技術都存在這樣那樣的問題。

資料庫自身的跨庫查詢功能（如Oracle的DBLink、MySQL的FEDERATED、MSSQL的Linked Server等）通常是將遠程資料庫的數據拉到本地，再在本地完成包括過濾在內的大部分計算，整個過程十分低效。不僅如此，這種方式還存在數據傳輸不穩定、不支持大對象操作、可擴展性低等很多不足。

除了資料庫自身的跨庫查詢能力，使用高級語言硬編碼也可以完成跨庫查詢，畢竟沒有什麼問題不是硬編碼解決不了的。這種方式雖然靈活，但使用難度卻很大，尤其對於當前大部分應用的開發語言Java來說，缺少足夠的結構化數據計算類庫使得完成跨庫查詢後的計算很難完成，通常只能做簡單的列表式查詢，而涉及到統計彙總類的運算就會異常麻煩。

事實上，要解決分庫後的T+0查詢問題也並非難事，只要有具備這樣一些能力的計算引擎就可以實現：能夠對接多種數據源；擁有不依賴資料庫的完善計算能力以完成多庫數據歸集後的數據計算工作；還可以利用資料庫（源）的能力充分發揮資料庫的效能；提供簡單的數據計算介面；性能相對理想等。

引入SPL

可以藉助開源SPL可以實現這些目標。SPL是一款開源數據計算引擎，提供了大量結構化數據計算函數並擁有完備計算能力，支持多數據源混合計算，可以同時連接存儲熱數據的業務庫和存儲冷數據的歷史庫完成全量數據T+0查詢。

由於具備獨立且完善的計算能力，SPL可以分別從不同的資料庫取數計算，因此可以很好適應異構資料庫的情況，還可以根據資料庫的資源狀況決定計算是在資料庫還是SPL中實施，非常靈活。在計算實現上，SPL的敏捷語法與過程計算可以大大簡化T+0查詢中的複雜計算，提升開發效率，SPL解釋執行支持熱部署。更進一步，依托SPL的強計算能力還可以完成冷熱數據分離時的ETL任務。

SPL還提供了自有的高性能二進位文件存儲，對性能要求較高時可以將歷史冷數據使用文件存儲，再藉助SPL的高性能演算法與並行計算來提升查詢效率。此外，SPL封裝了標準應用介面（JDBC/ODBC/RESTful）供應用集成調用，也可以將SPL嵌入應用中使用，這樣應用就輕鬆具備了T+0查詢與複雜數據處理能力，將計算和存儲分離也更符合當代應用架構的需要。

冷熱混合計算

對於常見的冷熱分庫T+0查詢場景，SPL實現很簡單，這裡看一個例子。

本例中，Oracle作為生產庫存儲當期熱數據，MySQL存儲歷史冷數據。前端傳入一句標準SQL（A2），再藉助SPL的轉換功能將標準SQL轉換成對應資料庫的語法（B3）併發給資料庫查詢（B4），最後歸併結果進行最後的彙總運算（A5）。這裡使用了多線程並行方式（A3）同時執行兩個SQL，效率更高。

在這裡，SPL不僅完成了兩個資料庫的跨庫查詢，還提供了SQL轉換方法，更利於前端應用使用，同時擁有合併兩個資料庫計算結果後的繼續計算能力，本例是分組彙總。SPL還有更豐富的結構化數據對象及其上的豐富運算，除了分組彙總、迴圈分支、排序過濾、集合運算等基礎計算外，位置計算、排序排名、不規則分組也不在話下。

除了RDB，對於有些場景涉及的NoSQL、Hadoop等數據源也能支持，SPL具備多源混算能力，無論基於何種數據源都可以進行混合查詢實現T+0。比如MongoDB與MySQL混合查詢：

SPL的計算能力還能用於ETL，將生產數據轉移到歷史庫中，還經常伴隨一些轉換計算，這些都可以使用SPL來完成。比如出於某些原因，要將生產數據某些編碼欄位通過某個對照表轉換成另一種編碼（遵守一致性的編碼規則、整理數據類型獲得更好性能等），而對照表通常並不會存在生產庫中，而不能直接在生產庫中計算好，這就涉及多數據源計算了。

高性能

歷史冷數據量可能很大，使用RDB存儲容易受到資源容量等因素限制，而且數據讀取效率很差。相比之下，文件存儲具備很多優勢，不僅讀取效率更高，還可以有效利用文件壓縮、並行等機制提速，同時也不會像資料庫容易受到容量的限制。不過，開放的文本格式使用效率不高（無壓縮、解析數據類型慢等），一般會使用二進位格式文件。另外，文件存儲的最大問題是沒有計算能力，不像資料庫使用SQL可以很方便完成數據處理，通過硬編碼處理的難度很大。

這些問題都可以通過SPL來解決，SPL提供了兩種高性能二進位數據存儲格式集文件和組表，再藉助SPL的獨立計算能力可以直接基於文件和資料庫混合計算實現高效T+0查詢。比如前面的例子，可以使用SPL文件存儲歷史冷數據與生產庫熱數據混合查詢。

將歷史數據存儲在文件後與生產庫混合查詢，歷史數據使用游標可以支持大數據場景，A4針對文件游標進行分組彙總，A5歸併數據並彙總分組結果。這裡使用了SPL提供的二進位集文件（btx），相對文本更加高效。集文件採用了壓縮技術（占用空間更小讀取更快），存儲了數據類型（無需解析數據類型讀取更快），支持可追加數據的倍增分段機制，利用分段策略很容易實現並行計算，保證計算性能。

SPL還有另外一種支持列存的高效存儲形式組表，在參與計算的列數（欄位）較少時會有巨大優勢。組表上還實現了minmax索引，也支持倍增分段，這樣不僅能享受到列存的優勢，也更容易並行提升計算性能。

SPL還支持各種高性能演算法。比如常見的TopN運算，在SPL中TopN被理解為聚合運算，這樣可以將高複雜度的排序轉換成低複雜度的聚合運算，而且很還能擴展應用範圍。

這裡的語句中沒有排序字樣，也不會產生大排序的動作，在全集還是分組中計算TopN的語法基本一致，而且都會有較高的性能，類似的演算法在SPL中還有很多。

SPL也很容易實施並行計算，發揮多CPU的優勢。SPL有很多計算函數都提供並行機制，如文件讀取、過濾、排序只要增加一個@m選項就可以自動實施並行計算，簡單方便。

易集成

SPL封裝了標準JDBC和ODBC介面供應用調用，特別對於Java應用可以將SPL嵌入應用內使用，T+0查詢能力在應用端實現，不再依賴數據源，這樣可以充分解耦應用與數據源，獲得很好的移植性和可擴展性。

JDBC調用SPL 代碼示例：

Class.forName("com.esproc.jdbc.InternalDriver");
Connection conn =DriverManager.getConnection("jdbc:esproc:local://");
Statement st = connection.();
CallableStatement st = conn.prepareCall("{call splscript(?, ?)}");
st.setObject(1, 3000);
st.setObject(2, 5000);
ResultSet result=st.execute();