新粉请关注我的公众号
今天聊聊这个由Kyligence和Intel一起搞的开源项目Gluten。
Gluten是什么呢？简单来说，这个项目的作用是给Spark引擎的执行赋予调用Native Vectorized engine，比如ClickHouse的能力。
要具体来说呢，就是在Spark查询Plan生成的时候，Gluten把一些Spark的查询计划拦截下来，让下面的native 引擎比如ClickHouse去执行。
当然，由于native引擎的问题，有些东西干不了，Gluten对干不了的operator重新fallback回Spark的代码执行。
总之就是干这样一件事情，Gluten本身不提供native引擎，而只是把Spark和native引擎用胶水Glue在一起。
这个项目的出发点和优点都显而易见，native引擎快啊，不然的话，Databricks有了Spark以后为什么还要搞Photon呢？
这东西给Kyligence用挺好的，Kyligence的用户在前端输入什么，都不需要关心下面到底用了什么计算引擎，要是能提高查询执行效率，比如说用Spark搭配ClickHouse，那就是客户满意，Kyligence也满意的结果。
但是开源给大家用，这个项目的前景就不好说了。这个项目有一个比较致命的问题。这个致命的问题在于，Spark对一些算子函数的处理，和底下的那个native引擎，在细节上未必是一致的。
比如说对小数点的处理，Spark自己跑是一回事，用了native 引擎可能就会有一些误差。也就是说我用Gluten和不用Gluten，结果可能不一致。
这种结果上的不一致有多难处理呢？我举个例子。Spark很早以前就开启了HIVE兼容模式，几年以后HIVE兼容模式里面还有很多bug要修复。
可见，一个引擎要在细节上和另外一个引擎能保持一致，是一件很不容易的事情。
这样一来Gluten想要把一个native引擎比如ClickHouse和Spark混在一起，第三方依赖Spark的客户是否愿意牺牲一致性来提高速度，就说不清楚了。
当然对Kyligence不是问题，因为只要Spark和Native引擎都选好了，对Kyligence的用户来说，其结果依然是一致的，只要每次哪些东西严格属于Spark哪些东西属于native引擎都有一致性的定义。这一点在Kyligence里面要做到不难。
所以，Kyligence够用，不代表着开源以后，那些本来用Spark的也够用。
这个项目的另外一个问题是，Spark社区是由Databricks牢牢掌握的，Gluten只能游离于Spark的开源项目之外，永远不会被整合进Spark里面去。这直接导致了这个项目的影响力很有问题。
那为什么我希望它能成功呢？理由也很简单。如果它成功了，或者类似的项目成功了，我们才有可能见到Photon开源的那一天。
Databricks这个公司是很鸡贼的，能不开源绝不开源。举个例子来说Delta Lake按理来说完全没机会开源。但是开源社区搞了一个Iceberg，所以没办法了，Delta Lake2019年终于开源了一个残废的版本。
Databricks那个时候的想法还是我用这个残废的版本吸引用户，然后用户会为我更牛逼的版本花钱。
可是这个事情大概是出乎了Databricks的意料之外。两三年下来，Iceberg是如火如荼，很多公司都来支持了，连Snowflake都来支持了。所以今年Delta Lake终于完全开源出来了。
如果说开源社区没有一个东西可以刺激一下Photon的话，那我觉得大概率，Databricks连开源一个乞丐版的Photon都不愿意，更不用说完全开源Photon了。
所以，我内心是真希望Gluten能够做成功。这样我们才能早点见到鸡贼的Databricks能够开源Photon。就当Gluten给大家做点好事吧。
但是这个项目按照目前这种搞法，要成功还是有点难。我觉得最好还是聚焦到一个native引擎上来。Clickhouse虽然快，但是问题也很多，很多operator尤其是join支持的不行。如果有谁能集中精力搞出一个又好又快的native引擎，这个事情才真的有点希望了。
