摘要

流式SQL是指采用用于編寫數(shù)據(jù)庫查詢的相同的聲明式SQL，而在快速變化的數(shù)據(jù)流上運(yùn)行。

這很有用，因?yàn)椤?/p>

1. 當(dāng)你能迅速采取行動(dòng)時(shí)，數(shù)據(jù)往往更有價(jià)值
2. 現(xiàn)有的從數(shù)據(jù)流中獲得實(shí)時(shí)洞察力的工具過于復(fù)雜。

SQL的 "聲明 "性質(zhì)在解決第二點(diǎn)方面發(fā)揮了重要作用，因?yàn)樗试S用戶專注于他們想要什么，而讓底層引擎擔(dān)心如何完成。

在現(xiàn)實(shí)世界中，流式SQL被用來。

• 啟用新的內(nèi)部和面向客戶的洞察力、自動(dòng)化和應(yīng)用程序
• 通過為關(guān)鍵指標(biāo)提供單一的最新真相來源來提高商業(yè)智能數(shù)據(jù)的價(jià)值
• 通過取代代碼進(jìn)行數(shù)據(jù)協(xié)調(diào)和轉(zhuǎn)換來簡(jiǎn)化微服務(wù)

什么是流式SQL?

讓我們先具體說明一下我們說的流處理和SQL是什么意思。

流(事件流)

流指的是像Kafka、Kinesis或Pulsar這樣的消息中介，它們將數(shù)據(jù)作為事件或消息的連續(xù)流來處理。

事件流處理一切，從交易到用戶在網(wǎng)站或移動(dòng)應(yīng)用程序上的行動(dòng)、物聯(lián)網(wǎng)傳感器數(shù)據(jù)、服務(wù)器的指標(biāo)，甚至是傳統(tǒng)數(shù)據(jù)庫上的活動(dòng)，都通過 change data capture.

SQL

在流的背景下，SQL為用戶提供了一種聲明性語言，用于。

• 創(chuàng)建視圖，將流中的原始數(shù)據(jù)連接、過濾和分組為更有用的輸出(CREATE MATERIALIZED VIEW)
• 從源和視圖中選擇數(shù)據(jù)(SELECT)

注意：CREATE MATERIALIZED VIEW命令是流式SQL的核心概念。它來自于 databases來的，在那里它被用來提前計(jì)算視圖，以防數(shù)據(jù)發(fā)生變化。在流媒體中，數(shù)據(jù)一直在變化，所以查詢?cè)诰S護(hù)成物化視圖時(shí)往往更有用。

其他常見的SQL動(dòng)詞如INSERT、UPDATE和DELETE在流式SQL中也有作用，但在這篇文章中，我們將重點(diǎn)討論從流中讀取、連接/過濾/轉(zhuǎn)換這些流的核心概念，并使其輸出可查詢或 寫到一個(gè)新的流。

流上的SQL和數(shù)據(jù)庫之間的區(qū)別

一旦你嘗試在流上使用SQL，一些關(guān)鍵的區(qū)別就會(huì)變得很明顯。

時(shí)間點(diǎn)查詢與連續(xù)查詢

在傳統(tǒng)數(shù)據(jù)庫上運(yùn)行SQL查詢，會(huì)從一個(gè)時(shí)間點(diǎn)上返回一組靜態(tài)的結(jié)果。

以這個(gè)疑問為例：

SELECT SUM(amount) as total_amount FROM invoices;

當(dāng)你運(yùn)行它時(shí)，數(shù)據(jù)庫引擎會(huì)掃描在查詢時(shí)存在的所有的Invoices，并返回其金額之和。

使用流式SQL，你可以運(yùn)行上面的確切查詢，并得到一個(gè)時(shí)間點(diǎn)的答案。但是你查詢的是快速變化的數(shù)據(jù)流，一旦你得到了結(jié)果，它們可能就已經(jīng)過時(shí)了。在許多情況下，一個(gè)持續(xù)更新的查詢(物化視圖)在以下幾個(gè)方面更有用，我們將在下面描述。

要把上面的查詢變成一個(gè)物化的視圖，你要寫。

CREATE MATERIALIZED VIEW invoice_summary AS
SELECT SUM(amount) as total_amount FROM invoices;

當(dāng)你第一次創(chuàng)建時(shí)，SQL引擎將處理它所能訪問的整個(gè)Invoice事件歷史，直到現(xiàn)在，然后隨著新的發(fā)票事件的到來繼續(xù)更新。

響應(yīng)時(shí)間與滯后

傳統(tǒng)的數(shù)據(jù)庫有查詢響應(yīng)時(shí)間的概念：你運(yùn)行一個(gè)查詢，在引擎計(jì)算結(jié)果的過程中會(huì)經(jīng)過一些時(shí)間，然后你得到響應(yīng)。

在流處理中，最初的響應(yīng)時(shí)間只是在你第一次物化一個(gè)視圖時(shí)的一個(gè)因素。但是，如果我們的輸入事件突然激增，在流結(jié)果中一定會(huì)有某種時(shí)間上的懲罰。這種懲罰就是時(shí)間滯后：輸出比輸入落后多少時(shí)間?

就像傳統(tǒng)數(shù)據(jù)庫的響應(yīng)時(shí)間一樣，大多數(shù)終端用戶不需要考慮流式系統(tǒng)的時(shí)滯問題，但知道它的存在有助于以避免問題的方式編寫和使用流式SQL。

不同的行動(dòng)為底層引擎創(chuàng)造工作

在讀取方面，傳統(tǒng)的數(shù)據(jù)庫引擎一直在閑置，直到它收到一個(gè)查詢，然后它計(jì)劃和優(yōu)化它，并開始工作提供結(jié)果。一旦它回復(fù)了結(jié)果，它就會(huì)再次閑置，直到它收到另一個(gè)查詢。發(fā)送查詢是為引擎創(chuàng)造工作。

如果你回到上面的物化視圖，來自流的新數(shù)據(jù)為引擎創(chuàng)造了工作。在Materialize中，這種方法是通過增量計(jì)算實(shí)現(xiàn)的：更新視圖所做的工作與進(jìn)來的數(shù)據(jù)成比例，而不是與查詢的復(fù)雜性成比例。我們不需要對(duì)數(shù)據(jù)進(jìn)行全面的重新掃描來更新結(jié)果。

這種模式的轉(zhuǎn)變使得流式SQL最適合于反復(fù)詢問同一問題的查詢(如儀表盤、報(bào)告、自動(dòng)化、大多數(shù)應(yīng)用程序代碼)，而不是臨時(shí)性的查詢。

為什么流式SQL是有用的?

1.數(shù)據(jù)最初出現(xiàn)時(shí)往往是最有價(jià)值的

這有兩個(gè)原因，一個(gè)很明顯，一個(gè)不太明顯。

1. 更快的數(shù)據(jù)=更快的決策--股票市場(chǎng)是這個(gè)想法發(fā)揮到極致的一個(gè)明顯例子。
2. 但它也適用于SaaS企業(yè)，像市場(chǎng)、旅游、活動(dòng)等需要對(duì)費(fèi)率和庫存做出快速?zèng)Q策的垂直行業(yè)，以及零售和物流業(yè)，因?yàn)榭焖贈(zèng)Q策可以減少低效率，等等。
3. 數(shù)據(jù)離它的源頭越近，被誤解的機(jī)會(huì)就越少--數(shù)據(jù)從創(chuàng)建的地方到使用的地方，每一步都會(huì)增加出錯(cuò)的可能性，即終端用戶(人或機(jī)器)認(rèn)為數(shù)據(jù)代表的東西并不存在。時(shí)間在其中起到了作用，它迫使人們圍繞操作順序和工作的一致性進(jìn)行協(xié)調(diào)。在這種情況下，切換到流數(shù)據(jù)并不是因?yàn)樗?，而是因?yàn)槟悴辉傩枰紤]時(shí)間問題。

2.SQL是一種從流式數(shù)據(jù)中獲得洞察力的偉大手段

這里是另一個(gè)關(guān)于流式事件的物化視圖的例子。

 CREATE MATERIALIZED VIEW experiments AS
   SELECT
     experiment_views.name,
     experiment_views.variant,
     COUNT(DISTINCT(experiment_views.user_id)) as unique_users,
     COUNT(DISTINCT(conversions.user_id)) as unique_conversions
   FROM experiment_views
   LEFT JOIN conversions ON
     conversions.user_id = experiment_views.user_id 
     AND conversions.created_at > experiment_views.created_at
   GROUP BY experiment_views.name, experiment_views.variant;

• SQL并不是流處理所特有的--當(dāng)數(shù)據(jù)從流轉(zhuǎn)移到數(shù)據(jù)庫時(shí)，其意義并沒有改變，所以我們查詢的方式也不應(yīng)該改變。
• 它的聲明性提高了生產(chǎn)力 - 開發(fā)人員幾乎不需要做任何優(yōu)化決定，特別是與代碼中的相同任務(wù)相比。

SQL有一個(gè)額外的好處，那就是它是一種成熟的語言，建立了30多年，周圍有一個(gè)工具和教育的生態(tài)系統(tǒng)。這意味著更多的開發(fā)者可以使用流媒體數(shù)據(jù)，并輕松地將其整合到他們的堆棧的其他部分。

流式SQL的用例

今天，任何已經(jīng)在使用像Kafka這樣的消息代理的人都可以開始使用流式SQL，而不需要付出很大努力。在未來，隨著CDC軟件的成熟，這一標(biāo)準(zhǔn)將擴(kuò)展到 "任何擁有數(shù)據(jù)庫的人"。"以下是一些使用流式SQL的例子。

商業(yè)智能和分析

當(dāng)決定 "什么是賦予我們的內(nèi)部團(tuán)隊(duì)從數(shù)據(jù)中做出智能決策的最佳方式 "時(shí)，流式SQL是一個(gè)需要考慮的選項(xiàng)，它的權(quán)衡使它對(duì)某些情況比其他情況更好。

在許多情況下，用流式SQL完成的主源數(shù)據(jù)的物化視圖是一個(gè)更簡(jiǎn)單的 data pipeline.除了實(shí)時(shí)數(shù)據(jù)的好處外，企業(yè)使用這種方法還可以回避以下問題。

• 批量處理中的時(shí)間間隔和操作順序的協(xié)調(diào)
• 在下一個(gè)批次運(yùn)行前無法修復(fù)或測(cè)試的錯(cuò)誤所導(dǎo)致的長(zhǎng)時(shí)間停工
• 儀表盤加載緩慢
• 緩存、反規(guī)范化造成的不一致問題

微服務(wù)

流式SQL被用來取代在微服務(wù)中做復(fù)雜數(shù)據(jù)協(xié)調(diào)和轉(zhuǎn)換的代碼。

像kafka這樣的事件流通常已經(jīng)是微服務(wù)架構(gòu)中的第一等公民。工程師們經(jīng)常發(fā)現(xiàn)自己在構(gòu)建和維護(hù)復(fù)雜的應(yīng)用程序，從kafka中消費(fèi)。例如：從事件日志中讀取的應(yīng)用程序，以產(chǎn)生對(duì)SaaS應(yīng)用程序的API使用的洞察力和測(cè)量。

微服務(wù)中任何看起來像查詢的組件都可能被流式SQL所取代。

實(shí)時(shí)應(yīng)用

如果你的應(yīng)用程序的價(jià)值取決于你實(shí)時(shí)交付更新和數(shù)據(jù)的能力，流式SQL可能是建立一個(gè)昂貴或復(fù)雜的多組件堆棧的替代方案。

新的能力

1. 面向用戶的實(shí)時(shí)分析--以前，只有像LinkedIn和Google這樣的技術(shù)巨頭才有規(guī)模和工程團(tuán)隊(duì)來建立面向用戶的實(shí)時(shí)分析(如LinkedIn的 "誰瀏覽了你的個(gè)人資料 "頁面或Google Analytics的實(shí)時(shí)儀表板)。通過降低復(fù)雜性，流式SQL向更多的公司開放了神奇的實(shí)時(shí)用戶分析功能。
2. 業(yè)務(wù)自動(dòng)化 - 一旦你有了實(shí)時(shí)儀表盤的流式SQL，一個(gè)自然的進(jìn)展就是開始在相同的數(shù)據(jù)上做出自動(dòng)化的決定。(例如。如果你的電子商務(wù)網(wǎng)站從某一特定來源獲得的流量激增，就在主頁上增加一個(gè)促銷活動(dòng))。

總結(jié)

Materialize提供了一個(gè)流式SQL實(shí)現(xiàn)，它在兩個(gè)重要方面是獨(dú)一無二的。

在Materialize中，你可以用與postgres兼容的SQL編寫查詢。我們認(rèn)為值得花費(fèi)額外的精力來構(gòu)建這個(gè)系統(tǒng)，因?yàn)橹挥性谶@種級(jí)別的SQL兼容中，你才能獲得與現(xiàn)有工具集成的好處，并消除用戶對(duì)高級(jí)流處理概念的負(fù)擔(dān)。

查詢引擎使用增量計(jì)算(Differential Dataflow)來更有效地維護(hù)物化視圖，因?yàn)樾碌臄?shù)據(jù)進(jìn)來了。