HTAP（Hybrid Transaction and Analytical Process，混合事務和分析處理）自 2014 年明確提出以後成為了很多數據庫廠商努力的方向。其實 HATP 並不新鮮，早年 RDB 剛興起時本來就是用壹個數據庫同時做事務和分析，但隨著數據規模不斷變大再直接基於業務庫做分析就會影響業務，這時數據倉庫出現了，將業務數據導入數據倉庫來專門應對分析需求，同時與業務庫隔離，這樣不僅可以更好地服務分析場景，又不會對業務系統產生影響，這是“合久必分”的階段。但是由於數據倉庫將 歷史 數據與實時數據分開了，有時經常還會采用異構數據庫（或大數據平臺），如果要分析實時全量數據（T+0）就非常困難了，而 T+0 又是很多及時性業務必須的，這就造成了“數據倉庫之殤”。為了解決這個問題，能不能把 AP 和 TP 在壹個數據庫內同時滿足呢？於是 HTAP 再次登場了，這又到了“分久必合”的階段。
但我們知道，AP 和 TP 兩個場景有顯著不同，前者涉及的數據量很大，並且計算邏輯復雜，但並發量往往不大，沒有數據壹致性要求，甚至經常為了使用方便可以不滿足範式；後者恰恰相反，數據量不大且數據處理邏輯簡單，但並發量很大，有數據強壹致性要求。從功能上講，TP 數據庫本來就能執行 SQL，也本來就具有壹定的 AP 功能。當初之所以要把 TP 和 AP 分開，就是因為巨大數據量時，繼續采用偏向 TP 的技術就不能高效地處理 AP 的需求（比如 AP 要求高性能需要使用列存，但 TP 為了寫入更新便利需要使用行存），TP 和 AP 的這些巨大差異就決定了這兩個場景不能采用壹個技術體系來同時滿足，而這件事到現在並沒有實質性地改變。
即使如此，還是有壹些廠商嘗試在同壹引擎中同時滿足 TP 和 AP 的需求，實現上有幾種方式。壹種是采用多副本的方式，其中某壹個副本（可能使用列存）專門用來滿足 AP 的需求；壹種是采用行列混合存儲，行存和列存各壹份，二者之間自動轉換；還有壹種方式可以不區分行列存儲，通過單壹存儲引擎支撐 TP 和 AP 場景，常見的是某些內存數據庫。這類 HTAP 數據庫在實現上會優先滿足 TP 的需要，在此基礎上再發展 AP 的功能，因此在滿足 AP 需求時相對壹般專用的 AP 產品往往會有很大差距。
另壹種 HTAP 數據庫的做法是在底層仍然將兩個場景分離，以“模塊化”的方式來設計存儲，業務數據產生後就會被復制兩份（不考慮副本的情況），壹份仍然使用行存用於交易，壹份復制使用列存用於分析。相應的存儲和計算再借助原本在 TP 和 AP 領域已經成熟的技術進行封裝和優化，同時設計統壹的對外訪問接口，底層的差異對應用層完全透明，這樣就形成了可用的 HTAP 產品。
無論采用哪種方式設計 HTAP 數據庫，在應用時都會碰到壹個問題，如果原來的業務數據庫不是（大概率）采用 HTAP 數據庫就要涉及數據庫遷移，這將面臨巨大的風險和成本。不僅要考量數據類型差異導致的數據結構遷移過程中需要進行改造和處理，還會涉及視圖、存儲過程以及復雜 SQL 的改造等，還有在遷移工程中遇到的種種問題要解決，可謂坑多且深。由此帶來的業務影響可能會帶來極大價值損耗。
此外，現代業務系統不僅涉及 RDB，還有 MongoDB、InfluxDB 等 NoSQL，以及各種自己封裝的業務數據源，種類很多五花八門。這些數據源要遷移到新數據庫就沒那麽簡單了，像 MongoDB 數據轉存到 RDB 會發現實現很困難。MongoDB 中的很多數據類型和集合之間的關系在 RDB 中並不存在，比如嵌入式的數據結構、數組和哈希等集合類型、多對多關系的實現。這些問題並不是簡單通過數據遷移就能解決的，需要在遷移之前先對部分數據結構進行重構，這需要事先投入相當多的人工和時間成本去梳理業務並設計目標數據組織方式。即使最後花費很大代價把業務數據源遷移到 HTAP 上，原來那些多樣性數據源自身的優勢卻又喪失了，得失之間有時甚至很難權衡是否值得。
我們知道，數據計算性能和數據組織密不可分，在 AP 類場景中通常要使用列存來發揮計算優勢，但只有列存是遠遠不夠的，有些復雜計算需要針對計算特點專門設計數據存儲形式（比如有序存儲、數據類型轉換、預計算等）。而這些對性能要求高的復雜計算在 AP 類場景中並不少見，但無論采用何種方式的 HTAP，簡單“自動化”地行存轉列存並不能實現相對“個性化”的效果，性能往往無法達標。這個道理也很簡單，天下沒有什麽都好的事兒，妳想融合就必須容忍在某壹或某些方面的不足。
遷移風險大、成本高、有損失、性能還可能不達標，考慮到這些問題，我們不禁會問：HTAP 數據庫這個技術路線對嗎？
說到這裏我們再回頭看壹下 HTAP 的目的，為什麽要用 HTAP？
其實就是為了進行全量數據實時查詢統計，也就是 T+0！
如果數據倉庫等相關技術能搞定這個問題，那自然也就不需要 HTAP 了。不過很遺憾，數據倉庫仍然延用了關系數據庫的封閉體系，數據要先入庫才能計算，而且入庫又有較強約束。這些導致數據倉庫無法很好實現跨數據源尤其是異構和非關系型數據源的混合計算，很難實現 T+0 的目標。
但集算器 SPL 可以。
集算器 SPL（Structured Process Language），壹個專門面向結構化數據計算的 開源 計算引擎和程序語言。除了提供了豐富的計算類庫使其擁有不依賴數據庫的獨立計算能力外，SPL 可以對接多種數據源並完成多源混合計算，從而輕松完成跨數據源的 T+0 查詢。
SPL 通過與現有系統融合的方式實現 HTAP，這樣原有系統的改動很小，TP 部分幾乎不動，甚至原有的 AP 數據源也可以繼續工作，逐步使用 SPL 接管 AP 業務。SPL 部分或全部接管 AP 業務後， 歷史 冷數據使用 SPL 高性能文件存儲，原來針對業務庫到數據倉庫的 ETL 過程可以直接移植到 SPL 上。冷數據量大且不再變化使用 SPL 高性能文件存儲可以獲得更高地計算性能；熱數據量小仍然存放在原有 TP 數據源中，SPL 直接讀取計算，由於熱數據量並不大，直接基於 TP 數據源查詢也不會對其造成太大影響，訪問時間也不會太長。再利用 SPL 的冷熱數據混合計算能力，就可以獲得針對全量數據的 T+0 實時查詢。我們只要定期將變冷的數據固化到 SPL 的高性能存儲中，原數據源只需要保持少量近期新產生的熱數據即可。這樣不僅實現了 HTAP，而且還是高性能的 HTAP，且對應用架構沖擊很小。
現代信息系統中建設數據倉庫等專門服務分析場景已然十分常見，加之數據源種類繁多，將這些數據都遷移到壹處代價太大了，對於這點前文我們已經分析過。如果能在現有架構的基礎上增加跨數據源的實時混合計算能力，就相當於插上了 HTAP 的翅膀，在不改變現有架構的情況下快速實現 HTAP 的需求，而這正是 SPL 的強項。
SPL 支持多種數據源，RDB、NoSQL 以及 RESTful 等都可以直接使用，還可以解析 JSON/XML 等類型數據，可以對接 Elasticsearch、Kafka 等數據源，此外傳統 / 新興數據倉庫、大數據平臺等也可以直接取數計算。
在對接的同時可以針對任意多種數據源進行混合計算，這樣實時數據從生產庫中讀與取自 歷史 庫 / 數據倉庫 / 大數據平臺的冷數據混合計算就可以實現 T+0 全量實時數據查詢。這樣原有應用架構幾乎不用變動（尤其是生產庫）就可以獲得 HTAP（架構層面）期望的效果，成本極低。
使用 SPL 在現有架構上輸出 HTAP 能力還有壹個好處是可以充分保留原有數據源的優勢。NoSQL 仍然可以繼續使用而不必強行將結構拉成 RDB 的形式，自己封裝的數據訪問與交互接口也不必費心去遷就新數據庫，原來的優勢與個性化仍然保持，風險很低的同時價值幾乎沒有損耗。
在分析側也壹樣，基於 SPL 也可以繼續使用原本建設好的分析平臺。但如前所述，分析場景面臨的數據量大且計算邏輯復雜，尤其需要高性能。SPL 還提供了高性能計算機制，可以全面接管原來分析側（AP）的業務實現高性能數據計算。
我們知道，高性能計算涉及兩方面，壹個是數據組織方式即數據存儲，另壹個是算法，這二者密不可分，很多高性能算法需要將數據組織成相應格式（如有序）才能發揮作用。SPL 提供了自有的高性能存儲機制，直接采用文件系統。將數據存儲特定格式的文件中，不僅可以獲得更高的 IO 存取效率以及文件系統靈活的管理能力，還可以充分利用自有格式的列存、有序、壓縮、並行分段等數據存儲優勢，從而高效地發揮高性能算法效力。
而在算法方面，SPL 提供了十分豐富的高性能算法庫。遍歷復用、有序歸並、外鍵預關聯、標簽位維度、並行計算等，都已經封裝好，可以直接使用，配合 SPL 的存儲機制就能獲得高性能。而且這其中有很多算法都是 SPL 獨創的，在業內也是首次提出。
如果簡單地將 TP 中的行存轉換成 SPL 中的列存，工作量也非常低。但為了獲得高性能，常常還需要精心設計存儲方式，這時，將會有壹定量的 ETL 動作，但這個工作與原來從業務系統 ETL 數據到數據倉庫基本是壹樣的，並不會更復雜，而且這個工作對於高性能是少不了的。和壹般 HTAP 數據庫很難實施經過有效設計的存儲相比，SPL 將冷熱數據分離後可以從容不迫地像以前 TP/AP 分離時那樣實施更高效的存儲組織，這樣更能將 TP 和 AP 雙邊的性能發揮到極致。相對大幅的性能提升，數據組織的工作往往是值得的。
在實戰中，使用 SPL 存儲和算法提升數倍數十倍性能的案例很多。比如在某保險公司車險保單跑批的案例（ 開源 SPL 優化保險公司跑批優從 2 小時到 17 分鐘 ）中，使用 SPL 將計算時間從 2 小時縮短到 17 分鐘。這裏使用 SPL 接管存儲後再利用 SPL 特有的遍歷復用技術（在對大數據的壹次遍歷過程中實現多種運算）有效地減少外了存訪問量，同時將涉及對壹個大表進行三次關聯和匯總的運算只需要遍歷壹次（SQL 要將大表遍歷三次），並在關聯運算上采用了不同的算法，因此獲得了巨大的性能提升。
還有在 開源 SPL 將銀行手機賬戶查詢的預先關聯變成實時關聯 的案例中，使用 SPL 將原本只能預關聯的手機賬戶查詢變成實時關聯，同時服務器數量從 6 臺降為 1 臺。這裏充分利用了 SPL 的有序存儲機制，壹次性讀取整個賬戶數據時可以有效減少硬盤時間（物理存儲連續），再借助區分維表和事實表的外鍵實時關聯技術使用單機就能完成實時關聯查詢，性能提升明顯，硬件需求也降低了許多。
基於 SPL 的 HTAP，並不止於 T+0 和高性能。
數據計算（主要指 OLAP 場景）壹向有兩個難點，跑得慢（性能）和寫得簡單（開發效率）。前者我們說過了，後者使用 SPL 還可以獲得很大改善。
現在我們處理數據還主要基於 SQL（其他高級語言太麻煩），但 SQL 仍然有很多不好描述的運算，這個原因主要是 SQL 的理論限制，這裏我們不多說，感興趣的小夥伴可以閱讀這篇文章： 寫著簡單跑得又快的數據庫語言 SPL
鑒於 SQL 在復雜計算方面的描述能力（開發效率）太差，SPL 並沒有沿用 SQL 體系，而是基於新的理論重新設計了壹套敏捷計算語法，基於這個語法再實施計算尤其復雜計算會更有優勢，寫法也更簡單。
我們可以通過電商系統中常見的漏鬥運算來感受壹下 SPL 的簡潔性。
SQL（oracle）實現：
SPL 實現：
oracle 的 SQL 寫出來要三十多行，理解起來有相當的難度。而且這段代碼和漏鬥的步驟數量相關，每增加壹步數就要再增加壹段子查詢。這種 SQL，寫出來就已經不易，性能優化更是無從談起。
相比之下，SPL 就簡單得多，處理任意步驟數都是這段代碼。
好了，說到這裏各位看官應該了解了，SPL 並不是壹個 HTAP 數據庫，而是提供了壹種新思路來滿足 HTAP 的需要。HTAP 數據庫很熱，廠商的宣傳口號很容易讓我們陷入只能使用壹種數據庫來解決 HTAP 問題的藩籬而不自知。但只要我們再多想壹點就會發現，HTAP 是壹種合理的業務需求，滿足它或許並不需要壹種新數據庫，而是能夠解決問題的新技術和架構，而 SPL 提供了這種可能。
SPL下載地址：/article/1595816810031
SPL開源地址：/SPLWare/esProc