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的方式，就是限制读

 

 

标签：stream,Database,数据,流式,Readings,topic,Streaming,data,emit
来源： https://www.cnblogs.com/fxjwind/p/16077879.html