什么是流式SQL，它有什么用？
摘要
流式SQL是指采用用于編寫數據庫查詢的相同的聲明式SQL，而在快速變化的數據流上運行。
這很有用，因為。
- 當你能迅速采取行動時，數據往往更有價值
- 現有的從數據流中獲得實時洞察力的工具過于復雜。
SQL的 "聲明 "性質在解決第二點方面發(fā)揮了重要作用，因為它允許用戶專注于他們想要什么，而讓底層引擎擔心如何完成。
在現實世界中，流式SQL被用來。
- 啟用新的內部和面向客戶的洞察力、自動化和應用程序
- 通過為關鍵指標提供單一的最新真相來源來提高商業(yè)智能數據的價值
- 通過取代代碼進行數據協調和轉換來簡化微服務
什么是流式SQL?
讓我們先具體說明一下我們說的流處理和SQL是什么意思。
流(事件流)
流指的是像Kafka、Kinesis或Pulsar這樣的消息中介，它們將數據作為事件或消息的連續(xù)流來處理。
事件流處理一切，從交易到用戶在網站或移動應用程序上的行動、物聯網傳感器數據、服務器的指標，甚至是傳統數據庫上的活動，都通過 change data capture.
SQL
在流的背景下，SQL為用戶提供了一種聲明性語言，用于。
- 創(chuàng)建視圖，將流中的原始數據連接、過濾和分組為更有用的輸出(CREATE MATERIALIZED VIEW)
- 從源和視圖中選擇數據(SELECT)
注意：CREATE MATERIALIZED VIEW命令是流式SQL的核心概念。它來自于 databases來的，在那里它被用來提前計算視圖，以防數據發(fā)生變化。在流媒體中，數據一直在變化，所以查詢在維護成物化視圖時往往更有用。
其他常見的SQL動詞如INSERT、UPDATE和DELETE在流式SQL中也有作用，但在這篇文章中，我們將重點討論從流中讀取、連接/過濾/轉換這些流的核心概念，并使其輸出可查詢或 寫到一個新的流。
流上的SQL和數據庫之間的區(qū)別
一旦你嘗試在流上使用SQL，一些關鍵的區(qū)別就會變得很明顯。
時間點查詢與連續(xù)查詢
在傳統數據庫上運行SQL查詢，會從一個時間點上返回一組靜態(tài)的結果。
以這個疑問為例：
SELECT SUM(amount) as total_amount FROM invoices;
當你運行它時，數據庫引擎會掃描在查詢時存在的所有的Invoices，并返回其金額之和。
使用流式SQL，你可以運行上面的確切查詢，并得到一個時間點的答案。但是你查詢的是快速變化的數據流，一旦你得到了結果，它們可能就已經過時了。在許多情況下，一個持續(xù)更新的查詢(物化視圖)在以下幾個方面更有用，我們將在下面描述。
要把上面的查詢變成一個物化的視圖，你要寫。
CREATE MATERIALIZED VIEW invoice_summary AS
SELECT SUM(amount) as total_amount FROM invoices;
當你第一次創(chuàng)建時，SQL引擎將處理它所能訪問的整個Invoice事件歷史，直到現在，然后隨著新的發(fā)票事件的到來繼續(xù)更新。
響應時間與滯后
傳統的數據庫有查詢響應時間的概念：你運行一個查詢，在引擎計算結果的過程中會經過一些時間，然后你得到響應。
在流處理中，最初的響應時間只是在你第一次物化一個視圖時的一個因素。但是，如果我們的輸入事件突然激增，在流結果中一定會有某種時間上的懲罰。這種懲罰就是時間滯后：輸出比輸入落后多少時間?
就像傳統數據庫的響應時間一樣，大多數終端用戶不需要考慮流式系統的時滯問題，但知道它的存在有助于以避免問題的方式編寫和使用流式SQL。
不同的行動為底層引擎創(chuàng)造工作
在讀取方面，傳統的數據庫引擎一直在閑置，直到它收到一個查詢，然后它計劃和優(yōu)化它，并開始工作提供結果。一旦它回復了結果，它就會再次閑置，直到它收到另一個查詢。發(fā)送查詢是為引擎創(chuàng)造工作。
如果你回到上面的物化視圖，來自流的新數據為引擎創(chuàng)造了工作。在Materialize中，這種方法是通過增量計算實現的：更新視圖所做的工作與進來的數據成比例，而不是與查詢的復雜性成比例。我們不需要對數據進行全面的重新掃描來更新結果。
這種模式的轉變使得流式SQL最適合于反復詢問同一問題的查詢(如儀表盤、報告、自動化、大多數應用程序代碼)，而不是臨時性的查詢。
為什么流式SQL是有用的?
1.數據最初出現時往往是最有價值的
這有兩個原因，一個很明顯，一個不太明顯。
- 更快的數據=更快的決策--股票市場是這個想法發(fā)揮到極致的一個明顯例子。
- 但它也適用于SaaS企業(yè)，像市場、旅游、活動等需要對費率和庫存做出快速決策的垂直行業(yè)，以及零售和物流業(yè)，因為快速決策可以減少低效率，等等。
- 數據離它的源頭越近，被誤解的機會就越少--數據從創(chuàng)建的地方到使用的地方，每一步都會增加出錯的可能性，即終端用戶(人或機器)認為數據代表的東西并不存在。時間在其中起到了作用，它迫使人們圍繞操作順序和工作的一致性進行協調。在這種情況下，切換到流數據并不是因為它更快，而是因為你不再需要考慮時間問題。
2.SQL是一種從流式數據中獲得洞察力的偉大手段
這里是另一個關于流式事件的物化視圖的例子。
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并不是流處理所特有的--當數據從流轉移到數據庫時，其意義并沒有改變，所以我們查詢的方式也不應該改變。
- 它的聲明性提高了生產力 - 開發(fā)人員幾乎不需要做任何優(yōu)化決定，特別是與代碼中的相同任務相比。
SQL有一個額外的好處，那就是它是一種成熟的語言，建立了30多年，周圍有一個工具和教育的生態(tài)系統。這意味著更多的開發(fā)者可以使用流媒體數據，并輕松地將其整合到他們的堆棧的其他部分。
流式SQL的用例
今天，任何已經在使用像Kafka這樣的消息代理的人都可以開始使用流式SQL，而不需要付出很大努力。在未來，隨著CDC軟件的成熟，這一標準將擴展到 "任何擁有數據庫的人"。"以下是一些使用流式SQL的例子。
商業(yè)智能和分析
當決定 "什么是賦予我們的內部團隊從數據中做出智能決策的最佳方式 "時，流式SQL是一個需要考慮的選項，它的權衡使它對某些情況比其他情況更好。
在許多情況下，用流式SQL完成的主源數據的物化視圖是一個更簡單的 data pipeline.除了實時數據的好處外，企業(yè)使用這種方法還可以回避以下問題。
- 批量處理中的時間間隔和操作順序的協調
- 在下一個批次運行前無法修復或測試的錯誤所導致的長時間停工
- 儀表盤加載緩慢
- 緩存、反規(guī)范化造成的不一致問題
微服務
流式SQL被用來取代在微服務中做復雜數據協調和轉換的代碼。
像kafka這樣的事件流通常已經是微服務架構中的第一等公民。工程師們經常發(fā)現自己在構建和維護復雜的應用程序，從kafka中消費。例如：從事件日志中讀取的應用程序，以產生對SaaS應用程序的API使用的洞察力和測量。
微服務中任何看起來像查詢的組件都可能被流式SQL所取代。
實時應用
如果你的應用程序的價值取決于你實時交付更新和數據的能力，流式SQL可能是建立一個昂貴或復雜的多組件堆棧的替代方案。
新的能力
- 面向用戶的實時分析--以前，只有像LinkedIn和Google這樣的技術巨頭才有規(guī)模和工程團隊來建立面向用戶的實時分析(如LinkedIn的 "誰瀏覽了你的個人資料 "頁面或Google Analytics的實時儀表板)。通過降低復雜性，流式SQL向更多的公司開放了神奇的實時用戶分析功能。
- 業(yè)務自動化 - 一旦你有了實時儀表盤的流式SQL，一個自然的進展就是開始在相同的數據上做出自動化的決定。(例如。如果你的電子商務網站從某一特定來源獲得的流量激增，就在主頁上增加一個促銷活動)。
總結
Materialize提供了一個流式SQL實現，它在兩個重要方面是獨一無二的。
在Materialize中，你可以用與postgres兼容的SQL編寫查詢。我們認為值得花費額外的精力來構建這個系統，因為只有在這種級別的SQL兼容中，你才能獲得與現有工具集成的好處，并消除用戶對高級流處理概念的負擔。
查詢引擎使用增量計算(Differential Dataflow)來更有效地維護物化視圖，因為新的數據進來了。
