30｜Structured Streaming：从“流动的Word Count”开始

作者回复: 好问题，Spark Streaming、Spark MLlib（RDD based）、GraphX，和Structured Streaming、Spark MLlib（DataFrame based）、GraphFrames，都是相对的，前者都是基于Spark Core，都是基于RDD的计算子框架，而后者，都是基于DataFrame，可以共享Spark SQL性能红利的子框架。 简单来说，后者是前者的“继任者”，Spark社区官方，会推荐大家从老的RDD based子框架，迁移到新的DataFrame based、Spark SQL powered 子框架。 不过呢，出于历史原因，很多企业在很早就adopt了Spark，比如早在1.x版本，就开始采用Spark了，那个时候，大家用的还都是RDD based子框架，应用代码也都是基于那些子框架开发的，这里面有个迁移成本的问题。所以，据我所知，到现在为止，还有一些公司，出于怕麻烦的原因，还没有迁移，还在沿用老的子框架。 不过，如果是公司新的业务需求，或者新上马Spark，那么我建议都采用DataFrame based、Spark SQL powered新框架，来共享Spark SQL提供的执行性能。当然了，新框架的开发、完善，还需要一定的过程，不过到目前为止，在功能方面，新框架基本上都支持了，而且像Structured Streaming，相比老的Spark Streaming，还提供了Event time、Late data、Watermark这些更丰富的功能支持。所以说，如果受公司所限，不得不维护老框架，那这个确实比较麻烦一些，还要学老框架；但如果是新项目、新部署，那么还是推荐新框架，来同时收获完善的功能和高效的执行性能~

作者回复: 好问题~ 完全正确：“理论上说，一个消费者组中消费者数目和分区数一致，是效率最高的”，不过，更具体地说，Kafka Partitions的数量，应该和Spark Executors所拥有的总cores相对应。 举个例子，一个Kafka Topic，有60个Partitions，那么一个Spark集群，不管有多少个Executors，总cores可以被60整除，就是比较好的设置。比方说，有10个Executors，每个Executors有3个core，总共30 cores，这个是个好配置。再比如，30个Executors，每个Executor一个core，这个设置也行。在或者，30个Executors，每个Executor两个core，也可以的~ 不过，像你说的，如果Kafka总共60个Partitions，但是Spark集群起的Executors cores大于这个数字，那多余的CPU就会浪费掉。比如说，起20个Executors，但是每个Executors给4个core，那多出来的20个core，就完全浪费掉了。 其实，对于Kafka Partitions与Spark的对应关系，你不妨这样简单理解： 就把Kafka当成HDFS，把Kafka的Topic，当成是HDFS上的一个分布式文件，Kafka Topic的Partitions，其实可以类比分布式文件在HDFS上的数据分片。这样来理解，很多设置就迎刃而解了~