作者：石臻臻, CSDN博客之星Top5、Kafka Contributor 、nacos Contributor、華為云 MVP ,騰訊云TVP, 滴滴Kafka技術專家 、 LogiKM PMC(改名KnowStreaming)。

---

LogiKM(改名KnowStreaming) 是滴滴開源的Kafka運維管控平臺, 有興趣一起參與參與開發的同學,但是怕自己能力不夠的同學,可以聯系我,當你導師帶你參與開源！ 。

文章目錄

• • HTAP數據庫面臨的問題
  • • 遷移風險大成本高
    • 無法獲得多樣源的優勢
    • 性能不達標
  • SPL實現HTAP需求
  • • 平滑遷至HTAP
    • 還可以更快
    • 也可以更簡單
  • SPL資料

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數據庫，在應用時都會碰到一個問題，如果原來的業務數據庫不是（大概率）采用HTAP數據庫就要涉及數據庫遷移，這將面臨巨大的風險和成本。不僅要考量數據類型差異導致的數據結構遷移過程中需要進行改造和處理，還會涉及視圖、存儲過程以及復雜SQL的改造等，還有在遷移工程中遇到的種種問題要解決，可謂坑多且深。由此帶來的業務影響可能會帶來極大價值損耗。

無法獲得多樣源的優勢

此外，現代業務系統不僅涉及RDB，還有MongoDB、InfluxDB等NoSQL，以及各種自己封裝的業務數據源，種類很多五花八門。這些數據源要遷移到新數據庫就沒那么簡單了，像MongoDB 數據轉存到RDB會發現實現很困難。MongoDB 中的很多數據類型和集合之間的關系在RDB中并不存在，比如嵌入式的數據結構、數組和哈希等集合類型、多對多關系的實現。這些問題并不是簡單通過數據遷移就能解決的，需要在遷移之前先對部分數據結構進行重構，這需要事先投入相當多的人工和時間成本去梳理業務并設計目標數據組織方式。即使最后花費很大代價把業務數據源遷移到HTAP上，原來那些多樣性數據源自身的優勢卻又喪失了，得失之間有時甚至很難權衡是否值得。

性能不達標

我們知道，數據計算性能和數據組織密不可分，在AP類場景中通常要使用列存來發揮計算優勢，但只有列存是遠遠不夠的，有些復雜計算需要針對計算特點專門設計數據存儲形式（比如有序存儲、數據類型轉換、預計算等）。而這些對性能要求高的復雜計算在AP類場景中并不少見，但無論采用何種方式的HTAP，簡單“自動化”地行存轉列存并不能實現相對“個性化”的效果，性能往往無法達標。這個道理也很簡單，天下沒有什么都好的事兒，你想融合就必須容忍在某一或某些方面的不足。

遷移風險大、成本高、有損失、性能還可能不達標，考慮到這些問題，我們不禁會問：HTAP數據庫這個技術路線對嗎？

說到這里我們再回頭看一下HTAP的目的，為什么要用HTAP？

其實就是為了進行全量數據實時查詢統計，也就是T+0！

如果數據倉庫等相關技術能搞定這個問題，那自然也就不需要HTAP了。不過很遺憾，數據倉庫仍然延用了關系數據庫的封閉體系，數據要先入庫才能計算，而且入庫又有較強約束。這些導致數據倉庫無法很好實現跨數據源尤其是異構和非關系型數據源的混合計算，很難實現T+0的目標。

但集算器SPL可以。

SPL實現HTAP需求

集算器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的翅膀，在不改變現有架構的情況下快速實現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）實現：

with e1 as (select gid,1 as step1,min(etime) as t1from Twhere etime>= to_date('2021-01-10', 'yyyy-MM-dd') and etime<to_date('2021-01-25', 'yyyy-MM-dd')and eventtype='eventtype1' and …group by 1 ), with e2 as (select gid,1 as step2,min(e1.t1) as t1,min(e2.etime) as t2from T as e2inner join e1 on e2.gid = e1.gidwhere e2.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e2.etime<to_date('2021-01-25', 'yyyy-MM-dd') and e2.etime > t1and e2.etime < t1 + 7and eventtype='eventtype2' and …group by 1 ), with e3 as (select gid,1 as step3,min(e2.t1) as t1,min(e3.etime) as t3from T as e3inner join e2 on e3.gid = e2.gidwhere e3.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e3.etime<to_date('2021-01-25', 'yyyy-MM-dd') and e3.etime > t2and e3.etime < t1 + 7and eventtype='eventtype3' and …group by 1 ) selectsum(step1) as step1,sum(step2) as step2,sum(step3) as step3 frome1left join e2 on e1.gid = e2.gidleft join e3 on e2.gid = e3.gid

SPL實現：

	A	B
1	=["etype1","etype2","etype3"]	=file("event.ctx").open()
2	=B1.cursor(id,etime,etype;etime>=date("2021-01-10") && etime<date("2021-01-25") && A1.contain(etype) && …)
3	=A2.group(id).(~.sort(etime))	=A3.new(~.select@1(etype==A1(1)):first,~:all).select(first)
4	=B3.(A1.(t=if(#==1,t1=first.etime,if(t,all.select@1(etype==A1.~ && etime>t && etime<t1+7).etime, null))))
5	=A4.groups(;count(~(1)):STEP1,count(~(2)):STEP2,count(~(3)):STEP3)

oracle的 SQL 寫出來要三十多行，理解起來有相當的難度。而且這段代碼和漏斗的步驟數量相關，每增加一步數就要再增加一段子查詢。這種SQL，寫出來就已經不易，性能優化更是無從談起。

相比之下，SPL 就簡單得多，處理任意步驟數都是這段代碼。

好了，說到這里各位看官應該了解了，SPL并不是一個HTAP數據庫，而是提供了一種新思路來滿足HTAP的需要。HTAP數據庫很熱，廠商的宣傳口號很容易讓我們陷入只能使用一種數據庫來解決HTAP問題的藩籬而不自知。但只要我們再多想一點就會發現，HTAP是一種合理的業務需求，滿足它或許并不需要一種新數據庫，而是能夠解決問題的新技術和架構，而SPL提供了這種可能。

SPL資料

• SPL下載
• SPL源代碼

總結

以上是生活随笔為你收集整理的HTAP应该是一种需求 而不是一种产品的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。