之前Spark 2.0 刚发布不久后的第一个小版本，Structured Streaming 终于支持Kafka了，但是只支持Kafka 1.0 而不支持Kafka 0.8。用Spark的开发可是没办法决定基础设施Kafka的版本的，而且你知道在一个业务成熟的公司更换这种如此重要的基础设置的版本的阻力和风险有多大么？这简直让我们这些渴望能体验Spark新功能的痛心疾首。
接着为了推动大家迁移到Scala 2.11 版本而不再提供基于scala 2.10预编译的Assembly包，要知道，这会给使用spark的公司会带来的很大的困难。本来用Spark就是因为便于编程，功能强大，但是有多少程序员有能力自己去编译？ 公司累积了一堆的2.10的库难道都因为为了体验下2.0版本而要重新编译？
我只是觉得Spark不是为我等欢快的工作而努力，而是为了他们的技术追求和审美的强迫症而努力。或许这是技术人员难以逾越的坑吧
Spark 过于专注他所谓的架构，忽略了对用户问题的解决。为了所谓的统一(DataFrame API)导致公司精力都放在了内核的重构上，这也直接让Spark在很多方面慢了一大拍.
原本对机器学习库我是抱以厚望的，然而其算法和功能都相对来说很贫乏，并且一直没有得到质的提升。Spark 团队将其主要精力放在了API的简化尤其是DataFrame的统一上，让其错过了16年深度学习崛起的年代，终于沦为一个普通的带算法的计算框架上了。
对流式的支持也是磕磕盼盼，要知道，流式已经是大势所趋。相对于原先的Spark Streaming, Structure Streaming 带来了很多新概念，但是本质没有什么变化，只是强迫症患者的一个强迫而已（要使用Dataframe）。Spark Streaming 足够灵活，就是问题比较多。你新的Structure Streaming 还把追加，写入等各种拆分开了，学习曲线陡然上身。因为执着于RDD概念，没有勇气打破Spark的基石，一直无法实现真正的流式，倒是给了Flink巨大的机会。同样的，也让Storm一直活得很潇洒。新的Structure Streaming不行，但是他们似乎已然放弃Spark Streaming的努力，包括从Spark Streaming诞生就被广受吐槽的checkpoint 问题，也从来没有得到关注，也没有得到改善。让你带着爱被虐着，然后就眼睁睁的看着流式时代在自己的眼皮底下流过。
SQL的支持也是磕磕盼盼，到现在还还没覆盖Hive SQL的大部分功能,Hive 已然是大数据SQL的事实标准，又想摆脱Hive，我原先很赞赏Spark的做法，因为hive确实重啊，结果 1.6 里一些基础UADF都不支持。。。。很多情况其实没办法用的。而新的版本2.0对SQL支持好了很多，结果前面各种问题限制你使用。
我觉得一个开源产品，用户才是自己的最关键的。用户只关注了一个新的版本有什么新的功能，解决了老的什么痛点，并且提高了多少稳定性和速度，如此而已。至于内核的重构，API的统一，这不能成为自己全身心去投入的事情。