本文首发微信公众号：飞总聊IT

Spark Connect是我想写的一个大数据相关的选题。但是由于各种原因一直拖拖拉拉的，就拖到了2022年的最后几天。
2022年的欠债，还是要在2022年做完。虽然我知道写技术性的东西，在当下公众号不会有什么阅读量，但是有些选题还是要写的。
Spark Connect是一个新的开源项目，由Databricks在今年的年度Data+AI大会的keynote上官宣。
具体的内容大家可以看看视频或者看看这篇博文：

https://www.databricks.com/blog/2022/07/07/introducing-spark-connect-the-power-of-apache-spark-everywhere.html
我简单讲一下，有很多的应用程序喜欢用Spark做后端。举个例子，比如说我写了一个ETL的软件，然后用Spark作为后端，前端用户在UI上拖拖拉拉的就搞出一个pipeline,后端则是在一个集群上跑Spark的代码。
这样的应用很常见，那么问题来了，前端把用户的UI行为转化成Spark代码发给后端的集群去处理，这个代码要怎么办？
业界就我看到的，有三种思路：
1.前端用Spark先编译一下，看看有没有问题，有问题就在前端直接拒了。
2.前端就生成一串字符串，作为黑箱发给后端，后端正常提交编译运行，有错返回。

3.前端自己写一些代码处理一些常见错误以后用2的方式发给后端。

方法2的问题是非常明显的，任何错误都会被提交到后端才触发，一些简单的语法错误的话，就很浪费后端服务器资源了。3比2稍微强一点，但是3没有用Spark官方的编译器。

这么看起来1是最好的选项了，但是1同样也有很大的问题，今天如果你的软件要绑定Spark的话，你不可能只绑一个简单的编译器，而是要把所有的runtime之类的代码全部都绑进去。这就让软件显得特别大。

所以很多软件选择用2或者3。因此，Databricks注意到，客户有需求在后端跑生成的Spark，然后前端发送Spark代码过来。前端做本地的各种语法检查就比较两难。

这就是Spark Connect这个项目出发的核心逻辑，通过重构Spark代码，生成一个轻量级的客户端。客户端有编译器，可以生成可以被序列化的log-op tree/dag 发送给后端。
这就同时解决了之前1,2,3这些方法的问题。那么问题来了，这种需求到底是伪需求，还是真的有很多客户需要。Databricks说有很多客户需要。我还是比较相信Databricks的，因为我本人在我司就见到了若干款产品，有这样的需求。
那么为什么说黄花菜都凉了呢？这个项目说白了，没有技术难度，有的是很多繁琐的工程性的东西。如果要完成的快点，就需要多投入一些人。
我对compiler/optimizer相关的都还有比较懂。所以我多少也能确定这个项目并不存在single-point failure这样的情况，人力可以很好的做并行开发。简单来说，人投入多了，项目进展就大了，人投入少了项目进展就小了。
项目从开始到现在小半年过去了，进展怎么样呢？不能说一点事情都没做吧，但是我只能说Databricks投入的人力，和很多人期望的进展之间，是有矛盾的。
而另外一个问题，更是让我觉得很多软件确实等不及也不想等了。简单来说，虽然客户端发送的Spark代码确实可能存在错误，但是大部分代码都是自动生成的，通过迭代除bug，很多软件时至今日，已经很少会有bug了。
既然绝大部分的情况下，都没有bug，那么裸发字符串的选项2，对一个成熟的软件来说，也不是不能接受的选项。所以当产品成熟以后，很多产品就凑合着用选项2吧。实际上，这些产品对Spark Connect的盼望和热情，一直都在下降。那么Spark Connect也就没有想象中的重要了。

说实话，这个项目真的就是多砸一些人，努努力就可以干成干好的。但是我觉得有点雷声大雨点少了。也许这种不赚钱的项目，确实不是一个商业化公司的发展和投资重点吧。
继续阅读
阅读原文