前面的那篇文章《再谈流计算的基本概念》提到了 Dataflow 模型,这个模型从更高的维度去看待看似隔离的批处理和流处理过程,把批处理过程认为是流处理过程的特例。基于这个模型,诞生了Spark Structure Streaming、Flink 和 Apache Beam 等一系列工具。
Dataflow 依然是存在缺憾的,它并没有把数据工程师常用的 SQL 整合进去。对于一个数据工程师而言,dataflow 虽然解决了批处理和流处理的统一问题,但是还是要学习那么多额外的编程语言及其函数或者是转换过程,很不爽,为什么流处理就不能就像处理表一样写SQL呢?
在回答这个问题之前,首先我们得把表和流统一了。
什么是表呢?常规意义上的表指的是一堆拥有行列性质的数据,每一行都有着唯一的主键(无论是隐性还是显性的),在某种程度上,一张表的存储结构是一个只增不减的log(LSM树或者是B树),事务就是对这个log上的某条记录快照的更改及最终应用在log上。
那什么是流呢?流是一系列变化数据的无穷集合,流犹如一条河流,生生不息。也就是只增不减的log
而流和表的联系就在于这个log了。
对这个概念的通俗理解就是Oracle里的物化视图。一张物化视图就是将一系列原始表的变更日志应用在原始表上的结果表。
所以我们可以这么理解:
上述的思想在 Kafka 得到了验证,并以此衍生出了 Kafka SQL。