Apache Kylin 云原生架构的思考及规划

最后一块，前面的五步做完了之后，扔到云上去就可以了，还差一块，也就是查询引擎。其实做到这个地方，作为一个分析的工具，SQL 的查询引擎是最难的，SQL 的查询引擎我们最早用的是 Apache Calcite， Calcite 应该是现在业界用得最多的 SQL 引擎。

当时我们用起来挺好的，但我们发现在大数据场景下就不行了。SQL 进来，plan 出来，优化好，从存储层将数据拿出来就好了，很快的。但是返回结果集的数据量非常大的场景下，尤其在咱们中国人多，在我们这里，返回来几百万条太正常了。所有的场景，我要把数据取回来，你会发现没有任何办法去缩小最终的数据集。Calcite 是一个单线程的设计，所以这个时候麻烦就大了，底下的存储引擎的计算速度很快，可能十几二十个毫秒就把数据取回来了，结果到Calcite这里是单线程，就只能等 Query 节点的 CPU 资源了，所以还是不合适的。

我们现在花了巨大的力气把它改成了 Spark 的方式，完全变成分布式的。变成这个以后，你会发现以前 cube 是因为存在 HBase 上，它是分布式的，所以我能够在各个节点把数据拉回来。收集完各个节点数据进行 Filter 开始就慢了，因为是单线程的。所以我们改变了一个方式，现在完全是用分布式了，所以你可以看打在上面的 sort 都是分布式的，你不需要在一个进程进行大量数据的 sort。这个情况，今天很多客户说在 Kylin 的节点上会去做优化，但是有时候不能解决性能瓶颈，只有这种分布式方式去做才能根本上解决性问题。但是这块的坑更大，因为这里面太复杂了。我们现在花很多力气，现在也在开发和测试，我们在看是不是可以和社区一起去做，我们把大部分的东西已经做完了。