The Future of SQL: Databases Meet Stream Processing

https://www.confluent.io/blog/databases-meet-stream-processing-the-future-of-sql/

首先時代的改變，導致SQL所面對的場景的改變，以前是靜態資料，而當前更多是 data is always in motion，其實就是StreamingSQL的概念

再者，tables只是記錄了current，靜態資料，而logs可以記錄動態資料，其實就是流表一體的概念，通過流可以回放出表

給個例子，

這個SQL就是流表一體，不光會返回靜態資料，還會動態的emit新的資料

接著，提出

data-passive, query-active，可以認為是pull

data-active, query-passive，可以認為是push

這個是傳統資料庫和流式資料庫最大的不同

pull有個問題，當資料量越來越大的時候，每次都全量去檢索，效率比較低

也就是說對於delta資料，沒有一個有效的方式

我突然覺得對於lambda架構的理解又加深了，一個emit changes，就是一個lambda架構的體現

pull更適合靜態的全量資料，因為有強索引，不需要掃描所有資料

而push流式處理更適合解決delta的問題

對於流式資料庫的一個問題，流式資料流過就沒了

如果把查詢關了，再查又需要掃一遍資料，這個太費，所有自然的想法是persistence，也就是物化檢視

有物化檢視，這裡實現可以是一個kafka的topic或是一個database，其他的查詢就可以直接讀到，就可以形成topology

流式資料庫的擴充套件語法

首先是視窗，dataflow模型，熟悉Flink的無需多言

Join

這塊分為兩塊，

stream-stream joins

這塊沒啥好說的，注意CEP場景

stream-table joins

這塊反而更有意思一些，

其實就是維表問題，而且還是一個拉鍊表問題，不是一個靜態維表

所以底層實現，應該和stream-stream joins沒有區別

如何處理late資料？丟棄？

同時支援大量的connector，

4 Key Design Principles and Guarantees of Streaming Databases

Lambda架構在結合實時和batch的時候會產生不精確性，

當前他這樣講是基於Linkedin提出的Kappa架構，基於Kafka可以低成本的對於全量資料的回放

他底下的兩點的問題，

1. 如果對於真正的海量資料，Kappa架構也不好用

2. 高並行獨立或輕量協調的執行，自動failover，但是對於有全域性狀態的情況怎解決？

4個原則

第一條，自動恢復，尤其是對於有狀態的任務

第二條，Exactly-once

 第三條，對亂序的處理

 第四條，查詢結果的一致性

下面說下confluent是如何用 “A persistent log-based approach” 保障上面4條原則的

0.11開始kafka開始支援事務寫，保障同時寫到多個topic的log的原子性

Exactly Once

把state，看成一個changelog topic，所以，只需要保證data topic和changelog topic事務寫就可以保證 

完整性保證

對於亂序，或者聚合時間很長這種，是不是要等到所有資料到到期了再emit

答案肯定是否定，dataflow論文裡面對這個分析的已經比較清楚

這裡的方案是，先emit，後面有亂序資料來的時候，refine並再次emit

不同他也說了，這個要求downstream查詢的處理邏輯是單調的，這個假設不一定成立

對於KSqlDB這種最終一致性，如果要保證更強的一致性，怎麼搞

如圖中，如何保證KsqlDB和OLTP查詢的一致性

兩種方式，傳統就是寫OLTP和KsqlDB同一個事務

一般的方式，也是Ksql的方式，就是限制讀