Kafka猛然醒来，突然变成了数据库

有时候，数据库就像一堆蜡板，可以堆叠和归整来进行更新；而如今，有时候数据库更像一条河流，形状取决于流经的地域，但是数据库在不断变化和流动，而这种流动恰恰比其他任何因素更加定义了驱动业务发展的信息。没有时间使数据库持久化、整理并查询数据库。

在这种情况下，将数据库径直嵌入到该数据流中有其道理，这也正是Confluent所做的，这家公司使Apache Kafka实现了商业化，而Apache Kafka是由商务社交网络LinkedIn创建，在2011年初开源的一种分布式消息队列架构。众所周知，Kafka最初是一种数据流服务，将数据传送到诸如Hadoop之类的系统，但是它本身正在逐渐成为一个平台。实际上，KSQL数据流数据库正是将Kafka转变成一种正宗平台的那个缺失的环节，也是Confluent的联合创始人尼哈·纳克赫德（Neha Narkhede）长期想要搞的技术，他当初帮助开发了Kafka及相关的Samza数据流处理框架，这种框架在LinkedIn将Kafka和Hadoop混合起来。

我们生活在一个完全颠倒的世界，数据库正试图添加数据流函数，而数据流服务器正变成数据库。许多现代应用系统以消息传送为中心（比如金融服务应用已存在了几十年），尤其是需要为数百万、数千万甚至数十亿用户确保高性能的那些应用系统，然后数据流服务和数据库服务依托于这些应用。

KSQL覆盖在Kafka上面有其道理，但这并不意味着因此很容易将源源不断的数据流转换到外观感觉如同传统的SQL驱动型关系数据库的数据库。纳克赫德告诉IT外媒The Next Platform，SQL接口的主要目的是，为使用基于Kafka的数据流服务降低准入门槛，这就好比Hadoop上的SQL覆盖层旨在让普通的SQL用户更容易充分利用在Hadoop上运行的数据湖，而过去不得不编写MapReduce脚本，以便对它提出问题。

Kafka本身是结合Scala和Java编写而成的，Kafka Streams数据流处理器好比Spark Streaming、Flink及类似系统，将其表覆盖内容存储到分布式RocksDB数据存储系统中。（RocksDB是一种低级存储引擎（http://rocksdb.org/），处于谷歌Spanner数据存储系统的CockroachDB克隆版的核心，RocksDB本身源自Google开源、受到谷歌的BigTable和Spanner数据库服务启发的LevelDB键/值存储引擎。）RocksDB数据存储区在服务器集群上加以分片和分布，这恰恰为Kafka赋予了带宽和弹性。Samza将Hadoop的YARN作业调度程序和数据复制功能与Kafka（因而现在的KSQL）整合成一个应用程序框架。

编者注：当然了，如果哪天早上Kafka醒来，发现已变成了CockroachDB，那将会有趣得多。

KSQL是完全用Java编写的，这是Confluent从头开始创建的一种分布式实时SQL引擎，如今该公司开源该SQL引擎（采用Apache 2.0许可证），这与LinkedIn当初开源Kafka如出一辙。KSQL覆盖层支持各种数据流函数，比如开窗聚合以便流式传送表连接，目前正处于开发者预览版状态。纳克赫德表示，Confluent想在接下来的四到六个月，征集Kafka社区的反馈意见，看看如何才能最好地调整或改动，然后将其商用、用于生产环境。KSQL还没有准备好迎来黄金时段。

对于刚接触数据流的人来说，一个显而易见的问题是：为什么将数据库放到数据流层。

纳克赫德解释道：“大多数关系数据库用于对存储的数据执行按需查找和修改这类操作。KSQL目前还不是旨在执行查询――它很快会支持这种功能，而是旨在执行连续查询；从某种意义上来说，它正在彻底颠覆数据库。关系数据库拥有事务日志，这是系统的数据源或真相源（source of truth），而它拥有从该日志派生而来的表，表是最重要的构件。如果使用Kafka和KSQL，日志是最重要的构件，表是派生视图，并存储在RocksDB中，对这些表所作的更新可建模成数据流。KSQL就是位于Kafka数据流表上面的接口，你可以将数据作为数据流来读取（每个更新独立于所有其他更新），也可以作为表来读取（每个更新可能是对进入到数据流的上一个更新的更新）。一旦你有了数据流表，可以将它们连接起来，或者对它们执行聚合操作，或者在将来某个时候查询这些表。这样的好处是，表实际上与传统数据库中的表全然不同，原因就在于每当新的事件到达数据流，表不断加以更新。数据流进来时，查询会生成更多事件，或者更新表。”

关系数据库有一个类似的概念，名为物化视图（materialized view）：信息发生变化后，物化视图会自动更新从许多数据库表的连接和聚合而来的派生表。源表中的数据若有更新，不断运行的查询会运行，但是这些数据和派生表必须不断被写入到数据库底层的磁盘存储设备。KSQL是为一直变化的数据设计的，而不是为很少变化的数据设计的，并不断流式传送可实时查询的物化视图。

往数据流引擎上添加SQL层的并非只有Confluent这一家。与之竞争的Apache Flink数据流处理框架有一个基于Apache Calcite项目的SQL引擎，该框架脱胎于柏林技术大学、柏林洪堡大学和波茨坦大学哈索普拉特纳研究所三方合作的Stratosphere项目。 PipelineDB是一个数据流数据库层，作为PostgreSQL数据库和Vertica数据库的扩展而运行。Spark Streaming是Spark内存数据库的数据流层，它有自己的DataFrame和SQL层，允许查询数据流。

严格来说，面向Kafka的KSQL数据库层不符合ANSI SQL标准，这主要是由于流媒体平台所需要的数据流函数不是那些数据库标准的一部分。关系数据库以表为中心，Kafka和KSQL以数据流为中心，KSAL数据库实际上来源于数据流。（就像Facebook创建的HBase数据库覆盖层其实来源于Hadoop分布式文件系统。）纳克赫德表示，关系数据库上司空见惯的SQL开窗函数需要大量修改，才能支持数据流。他补充说，在数据流系统上的所有SQL层都是如此。

Kafka Streams和KSQL不需要很庞大的系统。如果一台标准的X86服务器在两个插槽上有16个到24个核心，另外搭载合理的内存和磁盘数量，如果输入输出需要的话，可能还需要一些闪存，它就可以胜任重任。对于大多数客户来说，集群中Kafka节点之间的10 Gbps以太网结构（Ethernet fabric）就足够了。这完全取决于数据的性质和使用数据的应用。在延迟很重要的场合，可能需要容量更多的内存和闪存以及速度更快的网络，甚至可能需要更多的计算，或至少需要速度更快的计算。如果你需要更强大的数据流功能，只需要为Kafka集群添加更多节点。

商业级KSQL的包装和定价细节还没有透露，价格不太可能透露。