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

---

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

HTAP（Hybrid Transaction and Analytical Process，混合事務(wù)和分析處理）自2014年明確提出以后成為了很多數(shù)據(jù)庫廠商努力的方向。其實HATP并不新鮮，早年RDB剛興起時本來就是用一個數(shù)據(jù)庫同時做事務(wù)和分析，但隨著數(shù)據(jù)規(guī)模不斷變大再直接基于業(yè)務(wù)庫做分析就會影響業(yè)務(wù)，這時數(shù)據(jù)倉庫出現(xiàn)了，將業(yè)務(wù)數(shù)據(jù)導(dǎo)入數(shù)據(jù)倉庫來專門應(yīng)對分析需求，同時與業(yè)務(wù)庫隔離，這樣不僅可以更好地服務(wù)分析場景，又不會對業(yè)務(wù)系統(tǒng)產(chǎn)生影響，這是“合久必分”的階段。但是由于數(shù)據(jù)倉庫將歷史數(shù)據(jù)與實時數(shù)據(jù)分開了，有時經(jīng)常還會采用異構(gòu)數(shù)據(jù)庫（或大數(shù)據(jù)平臺），如果要分析實時全量數(shù)據(jù)（T+0）就非常困難了，而T+0又是很多及時性業(yè)務(wù)必須的，這就造成了“數(shù)據(jù)倉庫之殤”。為了解決這個問題，能不能把AP和TP在一個數(shù)據(jù)庫內(nèi)同時滿足呢？于是HTAP再次登場了，這又到了“分久必合”的階段。

但我們知道，AP和TP兩個場景有顯著不同，前者涉及的數(shù)據(jù)量很大，并且計算邏輯復(fù)雜，但并發(fā)量往往不大，沒有數(shù)據(jù)一致性要求，甚至經(jīng)常為了使用方便可以不滿足范式；后者恰恰相反，數(shù)據(jù)量不大且數(shù)據(jù)處理邏輯簡單，但并發(fā)量很大，有數(shù)據(jù)強一致性要求。從功能上講，TP數(shù)據(jù)庫本來就能執(zhí)行SQL，也本來就具有一定的AP功能。當(dāng)初之所以要把TP和AP分開，就是因為巨大數(shù)據(jù)量時，繼續(xù)采用偏向TP的技術(shù)就不能高效地處理AP的需求（比如AP要求高性能需要使用列存，但TP為了寫入更新便利需要使用行存），TP和AP的這些巨大差異就決定了這兩個場景不能采用一個技術(shù)體系來同時滿足，而這件事到現(xiàn)在并沒有實質(zhì)性地改變。

即使如此，還是有一些廠商嘗試在同一引擎中同時滿足TP和AP的需求，實現(xiàn)上有幾種方式。一種是采用多副本的方式，其中某一個副本（可能使用列存）專門用來滿足AP的需求；一種是采用行列混合存儲，行存和列存各一份，二者之間自動轉(zhuǎn)換；還有一種方式可以不區(qū)分行列存儲，通過單一存儲引擎支撐TP和AP場景，常見的是某些內(nèi)存數(shù)據(jù)庫。這類HTAP數(shù)據(jù)庫在實現(xiàn)上會優(yōu)先滿足TP的需要，在此基礎(chǔ)上再發(fā)展AP的功能，因此在滿足AP需求時相對一般專用的AP產(chǎn)品往往會有很大差距。

另一種HTAP數(shù)據(jù)庫的做法是在底層仍然將兩個場景分離，以“模塊化”的方式來設(shè)計存儲，業(yè)務(wù)數(shù)據(jù)產(chǎn)生后就會被復(fù)制兩份（不考慮副本的情況），一份仍然使用行存用于交易，一份復(fù)制使用列存用于分析。相應(yīng)的存儲和計算再借助原本在TP和AP領(lǐng)域已經(jīng)成熟的技術(shù)進(jìn)行封裝和優(yōu)化，同時設(shè)計統(tǒng)一的對外訪問接口，底層的差異對應(yīng)用層完全透明，這樣就形成了可用的HTAP產(chǎn)品。

HTAP數(shù)據(jù)庫面臨的問題

遷移風(fēng)險大成本高

無論采用哪種方式設(shè)計HTAP數(shù)據(jù)庫，在應(yīng)用時都會碰到一個問題，如果原來的業(yè)務(wù)數(shù)據(jù)庫不是（大概率）采用HTAP數(shù)據(jù)庫就要涉及數(shù)據(jù)庫遷移，這將面臨巨大的風(fēng)險和成本。不僅要考量數(shù)據(jù)類型差異導(dǎo)致的數(shù)據(jù)結(jié)構(gòu)遷移過程中需要進(jìn)行改造和處理，還會涉及視圖、存儲過程以及復(fù)雜SQL的改造等，還有在遷移工程中遇到的種種問題要解決，可謂坑多且深。由此帶來的業(yè)務(wù)影響可能會帶來極大價值損耗。

無法獲得多樣源的優(yōu)勢

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

性能不達(dá)標(biāo)

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

遷移風(fēng)險大、成本高、有損失、性能還可能不達(dá)標(biāo)，考慮到這些問題，我們不禁會問：HTAP數(shù)據(jù)庫這個技術(shù)路線對嗎？

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

其實就是為了進(jìn)行全量數(shù)據(jù)實時查詢統(tǒng)計，也就是T+0！

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

但集算器SPL可以。

SPL實現(xiàn)HTAP需求

集算器SPL（Structured Process Language），一個專門面向結(jié)構(gòu)化數(shù)據(jù)計算的開源計算引擎和程序語言。除了提供了豐富的計算類庫使其擁有不依賴數(shù)據(jù)庫的獨立計算能力外，SPL可以對接多種數(shù)據(jù)源并完成多源混合計算，從而輕松完成跨數(shù)據(jù)源的T+0查詢。

SPL通過與現(xiàn)有系統(tǒng)融合的方式實現(xiàn)HTAP，這樣原有系統(tǒng)的改動很小，TP部分幾乎不動，甚至原有的AP數(shù)據(jù)源也可以繼續(xù)工作，逐步使用SPL接管AP業(yè)務(wù)。SPL部分或全部接管AP業(yè)務(wù)后，歷史冷數(shù)據(jù)使用SPL高性能文件存儲，原來針對業(yè)務(wù)庫到數(shù)據(jù)倉庫的ETL過程可以直接移植到SPL上。冷數(shù)據(jù)量大且不再變化使用SPL高性能文件存儲可以獲得更高地計算性能；熱數(shù)據(jù)量小仍然存放在原有TP數(shù)據(jù)源中，SPL直接讀取計算，由于熱數(shù)據(jù)量并不大，直接基于TP數(shù)據(jù)源查詢也不會對其造成太大影響，訪問時間也不會太長。再利用SPL的冷熱數(shù)據(jù)混合計算能力，就可以獲得針對全量數(shù)據(jù)的T+0實時查詢。我們只要定期將變冷的數(shù)據(jù)固化到SPL的高性能存儲中，原數(shù)據(jù)源只需要保持少量近期新產(chǎn)生的熱數(shù)據(jù)即可。這樣不僅實現(xiàn)了HTAP，而且還是高性能的HTAP，且對應(yīng)用架構(gòu)沖擊很小。

平滑遷至HTAP

現(xiàn)代信息系統(tǒng)中建設(shè)數(shù)據(jù)倉庫等專門服務(wù)分析場景已然十分常見，加之?dāng)?shù)據(jù)源種類繁多，將這些數(shù)據(jù)都遷移到一處代價太大了，對于這點前文我們已經(jīng)分析過。如果能在現(xiàn)有架構(gòu)的基礎(chǔ)上增加跨數(shù)據(jù)源的實時混合計算能力，就相當(dāng)于插上了HTAP的翅膀，在不改變現(xiàn)有架構(gòu)的情況下快速實現(xiàn)HTAP的需求，而這正是SPL的強項。

SPL支持多種數(shù)據(jù)源，RDB、NoSQL以及RESTful等都可以直接使用，還可以解析JSON/XML等類型數(shù)據(jù)，可以對接Elasticsearch、Kafka等數(shù)據(jù)源，此外傳統(tǒng)/新興數(shù)據(jù)倉庫、大數(shù)據(jù)平臺等也可以直接取數(shù)計算。

在對接的同時可以針對任意多種數(shù)據(jù)源進(jìn)行混合計算，這樣實時數(shù)據(jù)從生產(chǎn)庫中讀與取自歷史庫/數(shù)據(jù)倉庫/大數(shù)據(jù)平臺的冷數(shù)據(jù)混合計算就可以實現(xiàn)T+0全量實時數(shù)據(jù)查詢。這樣原有應(yīng)用架構(gòu)幾乎不用變動（尤其是生產(chǎn)庫）就可以獲得HTAP（架構(gòu)層面）期望的效果，成本極低。

使用SPL在現(xiàn)有架構(gòu)上輸出HTAP能力還有一個好處是可以充分保留原有數(shù)據(jù)源的優(yōu)勢。NoSQL仍然可以繼續(xù)使用而不必強行將結(jié)構(gòu)拉成RDB的形式，自己封裝的數(shù)據(jù)訪問與交互接口也不必費心去遷就新數(shù)據(jù)庫，原來的優(yōu)勢與個性化仍然保持，風(fēng)險很低的同時價值幾乎沒有損耗。

還可以更快

在分析側(cè)也一樣，基于SPL也可以繼續(xù)使用原本建設(shè)好的分析平臺。但如前所述，分析場景面臨的數(shù)據(jù)量大且計算邏輯復(fù)雜，尤其需要高性能。SPL還提供了高性能計算機制，可以全面接管原來分析側(cè)（AP）的業(yè)務(wù)實現(xiàn)高性能數(shù)據(jù)計算。

我們知道，高性能計算涉及兩方面，一個是數(shù)據(jù)組織方式即數(shù)據(jù)存儲，另一個是算法，這二者密不可分，很多高性能算法需要將數(shù)據(jù)組織成相應(yīng)格式（如有序）才能發(fā)揮作用。SPL提供了自有的高性能存儲機制，直接采用文件系統(tǒng)。將數(shù)據(jù)存儲特定格式的文件中，不僅可以獲得更高的IO存取效率以及文件系統(tǒng)靈活的管理能力，還可以充分利用自有格式的列存、有序、壓縮、并行分段等數(shù)據(jù)存儲優(yōu)勢，從而高效地發(fā)揮高性能算法效力。

而在算法方面，SPL提供了十分豐富的高性能算法庫。遍歷復(fù)用、有序歸并、外鍵預(yù)關(guān)聯(lián)、標(biāo)簽位維度、并行計算等，都已經(jīng)封裝好，可以直接使用，配合SPL的存儲機制就能獲得高性能。而且這其中有很多算法都是SPL獨創(chuàng)的，在業(yè)內(nèi)也是首次提出。

如果簡單地將TP中的行存轉(zhuǎn)換成SPL中的列存，工作量也非常低。但為了獲得高性能，常常還需要精心設(shè)計存儲方式，這時，將會有一定量的ETL動作，但這個工作與原來從業(yè)務(wù)系統(tǒng)ETL數(shù)據(jù)到數(shù)據(jù)倉庫基本是一樣的，并不會更復(fù)雜，而且這個工作對于高性能是少不了的。和一般HTAP數(shù)據(jù)庫很難實施經(jīng)過有效設(shè)計的存儲相比，SPL將冷熱數(shù)據(jù)分離后可以從容不迫地像以前TP/AP分離時那樣實施更高效的存儲組織，這樣更能將TP和AP雙邊的性能發(fā)揮到極致。相對大幅的性能提升，數(shù)據(jù)組織的工作往往是值得的。

在實戰(zhàn)中，使用SPL存儲和算法提升數(shù)倍數(shù)十倍性能的案例很多。比如在某保險公司車險保單跑批的案例（ 開源 SPL 優(yōu)化保險公司跑批優(yōu)從 2 小時到 17 分鐘 ）中，使用SPL將計算時間從2小時縮短到17分鐘。這里使用SPL接管存儲后再利用SPL特有的遍歷復(fù)用技術(shù)（在對大數(shù)據(jù)的一次遍歷過程中實現(xiàn)多種運算）有效地減少外了存訪問量，同時將涉及對一個大表進(jìn)行三次關(guān)聯(lián)和匯總的運算只需要遍歷一次（SQL要將大表遍歷三次），并在關(guān)聯(lián)運算上采用了不同的算法，因此獲得了巨大的性能提升。

還有在 開源 SPL 將銀行手機賬戶查詢的預(yù)先關(guān)聯(lián)變成實時關(guān)聯(lián) 的案例中，使用SPL將原本只能預(yù)關(guān)聯(lián)的手機賬戶查詢變成實時關(guān)聯(lián)，同時服務(wù)器數(shù)量從6臺降為1臺。這里充分利用了SPL的有序存儲機制，一次性讀取整個賬戶數(shù)據(jù)時可以有效減少硬盤時間（物理存儲連續(xù)），再借助區(qū)分維表和事實表的外鍵實時關(guān)聯(lián)技術(shù)使用單機就能完成實時關(guān)聯(lián)查詢，性能提升明顯，硬件需求也降低了許多。

也可以更簡單

基于SPL的HTAP，并不止于T+0和高性能。

數(shù)據(jù)計算（主要指OLAP場景）一向有兩個難點，跑得慢（性能）和寫得簡單（開發(fā)效率）。前者我們說過了，后者使用SPL還可以獲得很大改善。

現(xiàn)在我們處理數(shù)據(jù)還主要基于SQL（其他高級語言太麻煩），但SQL仍然有很多不好描述的運算，這個原因主要是SQL的理論限制，這里我們不多說，感興趣的小伙伴可以閱讀這篇文章： 寫著簡單跑得又快的數(shù)據(jù)庫語言 SPL

鑒于SQL在復(fù)雜計算方面的描述能力（開發(fā)效率）太差，SPL并沒有沿用SQL體系，而是基于新的理論重新設(shè)計了一套敏捷計算語法，基于這個語法再實施計算尤其復(fù)雜計算會更有優(yōu)勢，寫法也更簡單。

我們可以通過電商系統(tǒng)中常見的漏斗運算來感受一下SPL的簡潔性。

SQL（oracle）實現(xiàn)：

with e1 as (
	select gid,1 as step1,min(etime) as t1
	from T
	where 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 t2
	from T as e2
	inner join e1 on e2.gid = e1.gid
	where e2.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e2.etime<to_date('2021-01-25', 'yyyy-MM-dd') 
and e2.etime > t1
		and e2.etime < t1 + 7
		and eventtype='eventtype2' and …
	group by 1
),
with e3 as (
	select gid,1 as step3,min(e2.t1) as t1,min(e3.etime) as t3
	from T as e3
	inner join e2 on e3.gid = e2.gid
	where e3.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e3.etime<to_date('2021-01-25', 'yyyy-MM-dd') 
and e3.etime > t2
		and e3.etime < t1 + 7
		and eventtype='eventtype3' and …
	group by 1
)
select
  sum(step1) as step1,
  sum(step2) as step2,
  sum(step3) as step3
from
  e1
  left join e2 on e1.gid = e2.gid
  left join e3 on e2.gid = e3.gid

SPL實現(xiàn)：

oracle的 SQL 寫出來要三十多行，理解起來有相當(dāng)?shù)碾y度。而且這段代碼和漏斗的步驟數(shù)量相關(guān)，每增加一步數(shù)就要再增加一段子查詢。這種SQL，寫出來就已經(jīng)不易，性能優(yōu)化更是無從談起。

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

好了，說到這里各位看官應(yīng)該了解了，SPL并不是一個HTAP數(shù)據(jù)庫，而是提供了一種新思路來滿足HTAP的需要。HTAP數(shù)據(jù)庫很熱，廠商的宣傳口號很容易讓我們陷入只能使用一種數(shù)據(jù)庫來解決HTAP問題的藩籬而不自知。但只要我們再多想一點就會發(fā)現(xiàn)，HTAP是一種合理的業(yè)務(wù)需求，滿足它或許并不需要一種新數(shù)據(jù)庫，而是能夠解決問題的新技術(shù)和架構(gòu)，而SPL提供了這種可能。文章來源地址http://www.zghlxwxcb.cn/news/detail-806372.html

SPL資料

• SPL下載
• SPL源代碼

到了這里，關(guān)于HTAP應(yīng)該是一種需求 而不是一種產(chǎn)品的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！