本文首发微信公众号：飞总聊IT
Velox是Facebook（Meta)开源的一个新的大数据项目。今年VLDB的会议上，Velox团队也发了论文。
我每年都有阅读论文的习惯，一般就是看看SIGMOD/VLDB，之前也去开会，疫情以后这方面都懈怠了。
今年的VLDB有几篇挺有意思的文章，所以我打算找时间看一下。
我第一篇看的就是这个大名鼎鼎的Velox。具体Velox是什么的可以看看官方宣传：
https://engineering.fb.com/2022/08/31/open-source/velox/
简单的来讲，就是一个单机/单节点的C 的向量化query runtime实现，里面包括了类型，函数，表达式，aggregate function，operator，I/O，还有一些管理资源的utility。
Velox的目标就是用这个东西的runtime来取代Spark/Presto/Pytorch等等的东西的单节点runtime，以取得加速的效果。
这个项目在Facebook内部的成功是可以想象的。因为它可以在“完美”兼容Facebook内外部已经有的系统的前提条件下，提供更快的运行速度，消耗更少的运行资源。
而且由于是个内部项目，只要上面大领导愿意强力推动，各个相关技术都自愿或者不自愿去和Velox对接。最终大概率能够做得很成功。
这个项目开源的话，那就有Facebook开源的一贯味道：管杀不管埋。
先说一下对接其他项目的问题，这种对接并不是无缝对接，往往需要一个中间层，比如说，Spark需要通过Gluten去对接，Presto需要用Prestissimo这个C 的worker实现去取代Java的实现。
这种并不是无缝对接的方式，本身就意味着，除非开源项目愿意放弃自己已经写了很久的实现，而完全去用你的Velox的c 实现作为单机runtime，并且愿意把你的中间层也放进开源项目的主干代码库，否则的话，这一上来就很割裂了。
但是这些开源项目有可能放弃自己的东西，来和你无缝对接吗？我觉得不可能。毕竟放弃的是自己辛辛苦苦写的东西。对接到你这里来，这个项目已经失去一半主导权了。
Velox的另外一个问题，就是它想取代的东西太多了。虽然说它提供了各种各样的扩展，但是无论如何，Velox不可能第一时间去支持所有这些项目的新功能和新实现。Velox团队必须有优先级选择。
这样一来各个项目相当于把一半的命运交给了Velox，而Velox却可以决定哪些东西优先做，哪些东西不优先做，这背后要形成一种什么样的关系，讲政治来看都太复杂了。
所以，我觉得Velox作为Facebook的内部项目，大概率还是可以成功的。Velox开源出来，其实就是和各个它想取代的项目打仗，这争权夺利的故事就不好玩了。大家都不愿意带着它玩。
但是大范围内不成功，不代表一些特定场景下不会成功。我觉得两个场景下它有价值。
第一就是类似Facebook，有另外的公司，打算在全公司范围内用Velox取代开源大数据/ML项目的单节点引擎。这在一个公司范围内，是有机会成功的。
第二是某些产品，背后选择了某个开源项目作为自己的引擎。举例来说比如Kyligence，当然我知道的还有不少其他的，背后都有Spark作为引擎，或者引擎之一。
这些公司如果用了Velox，可以提高产品性能，但是由于它又包了一层，用户并不知道底下是什么，所以这样的方式，也能成功。
当然Velox还有一个作用，就是让那些藏着的家伙把干货开源出来，比如说，有没有可能逼得Databricks开源它们的向量化引擎Photon。想想很美好，实际上不知道。
但是不管怎么样呢，我都不看好这个项目未来在大范围内的成功。
