转载

360联查引擎新版发布，究竟是变形金刚还是瑞士军刀？

前言

伴随着格林尼治的时间戳自增至2020年，计算机内的时钟振荡器在Tick-Tock声中也荡过50个年头。在这50年的计算机发展史上，我们见证了摩尔定律的准确预测和逐步失效，也见证了安迪比尔定律在IT产业中的市场催生。从硅谷仙童半导体公司的兴起，到英特尔与德州仪器的取而代之，再到华为海思芯片的破局。这些计算机产业的不间断变革，被CPU中这片不休止的小小时钟电路见证铭记。

当然，在这悠悠的岁月长河中，360的联查引擎也悄然在上面刻下记号，从去年1月份开源，到7月份全球架构师峰会的分享，我们从一个小小的项目经过不断孵化，最终站在了大家眼前。我们很高兴地看到各大公司也都相继推出了自己的联查解决方案，成功服务了自己的业务，这代表联查的落地场景经受住了考验，背后潜藏的价值逐渐被企业发现。当然，此消彼长的质疑与赞誉声也推动我们不断巩固社区，丰富功能，以期带来更大价值。

导读

本次联查引擎Quicksql发布的版本是0.7，距离上个版本0.6已经时隔了大半年时间，这段时间里Quicksql到底有哪些优化和更新？是否有重大特性的升级？到底是像变形金刚一样功能强大，变换自如？还是像瑞士军刀一样小巧精悍，衔接方便？

接下来将详细阐述本次发版带来的新特性，一睹为快吧！

整体架构能力持续优化增强

在0.6发布后的很长一段时间内，不断有人问我们：” Presto也支持联查，Quicksql和Presto有什么区别呢？ ”，” Quicksql底层使用Spark，Spark自身也支持数据源下推，有什么区别呢？ ”。由于功能的局限，这两个问题犹如太乙的捆仙绳，股股缠绕Quicksql使其难脱其困。终于，在0.7版终于有了用事实说话的能力。Quicksql在新版中引入了Flink计算引擎，使Flink也可以作为中间引擎弥合原生数据源不具备的能力，至此，Quicksql在架构上具备了多引擎切换的能力，可以作为中间件适配在原有的IT设施上，使业务原生的计算引擎在不用二次开发的基础上具备联邦查询能力，即便业务没有部署Presto，或Presto无法满足相应的计算量及可靠性保障时，都可以由Quicksql配合原生计算引擎完成。这就意味着，不但离线计算可以满足联邦能力，实时计算同样也可以由Quicksql囊括其中。Quicksql的架构能力能够适应不断演进的引擎存储。

360联查引擎新版发布，究竟是变形金刚还是瑞士军刀？

引擎和数据源类型不断丰富

在新版本中，Quicksql实现了基于Flink引擎的联查能力，在Flink的批处理能力基础上，用户可以对MySQL和Hive进行任意的跨源跨库统一查询，为未来目标构建流批合一的业务提供联查支持，也为下阶段Quicksql引入Flink流式计算作好铺垫。此外，作为对Spark引擎的增强， Quicksql新版增加了对Kylin数据源的支持，使得主体依托Kylin作OLAP分析的业务能够搞定复杂联合查询场景。在引入新引擎和数据源的基础上，Quicksql新版也进一步完善了计算逻辑的下推能力，对于谓词关联比较等场景进行了深度优化。

360联查引擎新版发布，究竟是变形金刚还是瑞士军刀？

接入方式多样化

旧版Quicksql的接入方式尚且单一，不具备应用对接的能力。在0.7版本中，Quicksql实现了基于Avatica改造的JDBC接入方式。通过预先启动Quicksql Server，在应用端引入Quicksql Driver并使用标准的JDBC协议进行交互，完全实现与应用端的解耦。使得Quicksql既可以独立部署作为工具使用，也可以以服务的形式被应用集成。JDBC整体架构如下图，即在数据源上方启动引擎对应的常驻JDBC Server，并维持现有资源，Driver端通过指定URL连接对应的引擎Server，Server充当数据源的JDBC门面，所有数据源都可以使用同一个Quicksql Driver进行连接查询。

360联查引擎新版发布，究竟是变形金刚还是瑞士军刀？

丰富的使用文档和测试用例

在新版中，我们尤其重视对社区的规范化建设，采纳了社区内很多小伙伴的意见，我们重制了大部分文档，尽可能将用户使用过程中可能遇到的问题及疑惑在文档中进行解答，更加专业并详细地介绍项目已有的沉淀和后续的发展方向。在项目构建方面，社区进一步完善了相应测试用例，并构建了CI/CD，以提升项目敏捷性和快速构建的能力。

360联查引擎新版发布，究竟是变形金刚还是瑞士军刀？