spark2.0有一个很重要的趋势，就是推动大家使用structure的api，比如dataframe/dataset，以及新推出的structure streaming。spark submit 2016上有两talk介绍了spark2.0在structure方向的一些进展。

Structuring Apache Spark 2.0: SQL, DataFrames, Datasets And Streaming - by Michael Armbrust

相比于直接使用rdd，structure rdd的表现能力是不如rdd灵活的，但是易用性比rdd强。同时structure使得系统更容易对用户的程序进行优化优化。这些优势具体体现在一下几方面。

语法解析

使用Structured API的优势是可以在compile time发现语法错误（函数不存在），或者analysis error(列不存在，Datasets)

使用dataframe的function可以让spark更好的理解你的操作，从而做出相应的优化。而如果用lambda func，spark只知道需要调用一个func，并无法做出相应的优化，比如下图所示：

两个具体的优化例子

谓词下推：直接从数据库读取filter后的数据，相比spark先load全部数据再从内存filter，效率要高

join。通过对需要join的列排序做merge，将复杂度降低到nlogn

Tngsten‘s Compact encoding:对于数据，可以直接将jvm object在runtime翻译成二进制编码。从而节约内存，并提高序列化效率。

更为可怕的在于，dataframe可以直接对serialized data进行操作，不需要序列化。据说这种情况下执行效率只比c++慢10%-15%，几乎是native code的速度。

structure streaming的终极目标是处理所有流相关的问题，用户几乎不用感知流。

API: Dateframes or dataset。

内部model：input->result（需要处理的输入部分）->output

对比一下spark sql和structure streaming的执行步骤的区别

首先是batch execution on spark sql：

其中planner做了这样几件事

而对于structure streaming，planner知道如何将其翻译成incremental execution plan。

plan： WAL in hdfs。失败后通过log回复

source： kafka用offset，设计是就保证source是可被plan恢复的

state：plan会维护state的version

sink:通过设计成可以感知输出的版本的形式来避免重新执行时的重复写入

通过这几个容错，structure streaming可以实现end-to-end的exactly-once保证。

下面两个网址可以看这两个talk的ppt和video，貌似需要翻墙

本文采用创作共用保留署名-非商业-禁止演绎4.0国际许可证，欢迎转载，但转载请注明来自http://thousandhu.github.io，并保持转载后文章内容的完整。本人保留所有版权相关权利。