朱诗雄：Apache Spark中的全新流式引擎Structured St

Apache Spark在2016年的时候启动了Structured Streaming项目，一个基于Spark SQL的全新流计算引擎Structured Streaming，让用户像编写批处理程序一样简单地编写高性能的流处理程序。经过一年多的改进和完善，目前Structured Streaming已经在Databricks内部和客户广泛使用，InfoQ采访了Structured Streaming的核心开发朱诗雄来具体了解这个项目。

朱诗雄，Databricks软件开发工程师，Apache Spark PMC和Committer。曾任职于小米、微策略。作为Structured Streaming的核心开发人员，贡献了大量的特性和改进，打造了基于Spark SQL的全新流计算引擎Structured Streaming。同时也是Databricks Delta的核心开发人员，致力于构建一个基于Cloud的统一批处理和流处理的数据平台。他也为Spark Core和Spark Streaming贡献了大量代码，是目前Spark RPC框架的主要作者。此外，他还是著名的响应式编程库RxJava的Committer。

问： 能否先简单介绍一下Spark Streaming和Structured Streaming?

朱诗雄：Spark Streaming是Spark早期基于RDD开发的流式系统，用户使用DStream API来编写代码，支持高吞吐和良好的容错。其背后的主要模型是Micro Batch，也就是将数据流切成等时间间隔的小批量任务来执行。

Structured Streaming则是在Spark 2.0加入的经过重新设计的全新流式引擎。它的模型十分简洁，易于理解。一个流的数据源从逻辑上来说就是一个不断增长的动态表格，随着时间的推移，新数据被持续不断地添加到表格的末尾。用户可以使用Dataset/DataFrame或者SQL来对这个动态数据源进行实时查询。每次查询在逻辑上就是对当前的表格内容执行一次SQL查询。如何执行查询则是由用户通过触发器(Trigger)来设定。用户既可以设定定期执行，也可以让查询尽可能快地执行，从而达到实时的效果。一个流的输出有多种模式，既可以是基于整个输入执行查询后的完整结果，也可以选择只输出与上次查询相比的差异，或者就是简单地追加最新的结果。这个模型对于熟悉SQL的用户来说很容易掌握，对流的查询跟查询一个表格几乎完全一样。

问：是不是可以把Structured Streaming理解为对Spark Streaming的改进?Structured Streaming的设计初衷是为了解决什么具体问题的能介绍下吗?

朱诗雄：Structured Streaming并不是对Spark Streaming的简单改进，而是我们吸取了过去几年在开发Spark SQL和Spark Streaming过程中的经验教训，以及Spark社区和Databricks众多客户的反馈，重新开发的全新流式引擎，致力于为批处理和流处理提供统一的高性能API。同时，在这个新的引擎中，我们也很容易实现之前在Spark Streaming中很难实现的一些功能，比如Event Time的支持，Stream-Stream Join(2.3.0新增的功能)，毫秒级延迟(2.3.0即将加入的Continuous Processing)。

类似于Dataset/DataFrame代替Spark Core的RDD成为为Spark用户编写批处理程序的首选，Dataset/DataFrame也将替代Spark Streaming的DStream，成为编写流处理程序的首选。

问：有了Structured Streaming，是否意味着Spark不仅具有卓越的批处理能力，也同时具备了优秀的流处理能力，可以用Spark来构建统一批处理和流处理的大数据平台?这样子的平台是否更能适应未来人工智能快速发展，对更大数据量、更多样化的数据处理的需求?

朱诗雄：是的。Structured Streaming决定使用Dataset/DataFrame API最主要的一个原因就是希望用户不再需要分别为批处理和流处理编写代码，而是直接使用同一套代码。目前我们也在Databricks Delta项目中探索如何基于Cloud构建一个统一的批处理和流处理的数据平台。

这样的一个数据平台会对人工智能有很大帮助。Google之前有一篇paper提到了，在一个机器学习系统中的机器学习代码只占一小部分，有很大一部分是用来进行数据收集、清理、验证、特征提取、分析等各种操作[1]。 而后面这些工作都是Spark所擅长的。

[1] "Hidden Technical Debt in Machine Learning Systems" Google NIPS 2015

问：可以聊聊有了Structured Streaming的Spark有什么优劣势吗?

朱诗雄：Structured Streaming的主要优势体现在下面几点：

简洁的模型。Structured Streaming的模型很简洁，易于理解。用户可以直接把一个流想象成是无限增长的表格。

一致的API。由于和Spark SQL共用大部分API，对Spaprk SQL熟悉的用户很容易上手，代码也十分简洁。同时批处理和流处理程序还可以共用代码，不需要开发两套不同的代码，显著提高了开发效率。

卓越的性能。Structured Streaming在与Spark SQL共用API的同时，也直接使用了Spark SQL的Catalyst优化器和Tungsten，数据处理性能十分出色。此外，Structured Streaming还可以直接从未来Spark SQL的各种性能优化中受益。

多语言支持。Structured Streaming直接支持目前Spark SQL支持的语言，包括Scala，Java，Python，R和SQL。用户可以选择自己喜欢的语言进行开发。

问：可以介绍一下在Databricks内部，哪些地方在使用Structured Streaming么?效果如何?

朱诗雄：我们内部使用Structured Streaming开发了自己的日志处理系统，相比原来的批处理系统，延迟从几十分钟下降到了几分钟。我们还利用Structured Streaming来分析Databricks的客户日志，监控客户使用Structured Streaming的情况。一旦发现用户的程序有问题，会自动触发报警。得益于Structured Streaming的高性能和低延时，我们甚至可以在客户发现问题之前，提前帮助他们解决。

Databricks的很多客户也在使用Structured Streaming，每天有100多个Structured Streaming的应用程序在生产环境中运行，最大的应用程序每个月可以处理几十万亿条数据。

问：Structured Streaming跟其他的流处理技术相比，算是比较年轻的技术吧?目前有什么已知待解决的问题?未来有什么新增功能和优化的计划能否介绍下?

朱诗雄：是的，Structured Streaming从开始开发到现在也就两年时间，相当年轻，也存在一些待解决的问题。比如由于开发资源有限，一些不常用的功能还没有完成，例如Update输出模式。另外，Spark的动态资源分配对Structured Streaming的支持不是很好，无法根据用户的流处理程序很好地调整资源。大家可以到Spark的JIRA上查看Structured Streaming的相关Issue。

在即将发布的Spark 2.3.0中，最令人期待的是支持毫秒级延迟的Continuous Processing。同时，也新增了对Stream-Stream Join的支持。此外，在这个版本中，还将发布新的Source和Sink API，让用户方便地开发各种Streaming数据源。

在未来的后续版本中，我们会继续对Continuous Processing进行改进。同时，也会支持Update输出模式，推出更多的Streaming数据源。

问：您对于未来Structured Streaming的发展和应用范围有什么预期吗?

朱诗雄：我个人希望有更多的用户来使用Structure Streaming，包括新用户和Spark Streaming已有的用户。同时也希望能看到有更多的机器学习和图处理算法支持Structured Streaming。