Query Engine团队的未来规划

历经千辛万苦，数据仓库已经构建成形并已收获成效，但是，还有几个明显的问题需要继续改进。

王澍说，最主要的问题，也是很多数据仓库都会面临的一个问题是：数据模型如果比较固定，业务上的一丁点变化就会对内部造成非常大的改动，如何去权衡模型的灵活性，业务与需求之间的差异可能目前处理的还不是很好。他进一步解释说，比如说会有一张特别宽的表，但在实际使用的时候发现，集中的Metrics和Dimension都会集中在几组上，这就是过度设计的问题。

第二，基于业务特点，如果在数据回填期间出现了一些问题需要重新计算部分数据，这时候如何去更新历史上的一批数据，一直是一项棘手的问题，因为发生问题的原因多种多样，需要改的东西也是连锁式的。

崔扬则认为，因为之前查询引擎重度依赖Presto，所以很多业务上的逻辑直接集成到Presto的查询引擎或者查询流程过程中，这样的做法是会和Presto之间有一定耦合。他告诉记者，之后的思路和方向是想把这部分与业务耦合的功能模块从Presto剥离出来，形成一个独立的模块。这样可以让更多的查询引擎复用这部分逻辑代码。这样相当于多条腿走路，多重保障。

王澍和崔扬也简单地谈了谈他们对于构建一个优秀数据仓库的看法与经验。

王澍表示，一个优秀的数据仓库的标准不少，但是最主要的一条，是如何去权衡数据仓库设计的抽象的层次，跟实际业务需求之间变化的可能。

他解释道，想做到任何需求都可以支持满足，那整个数据仓库也许只能存最明细的数据，但是这种情况下，是不太可能保证查询的性能的，因为所有的查询都会反复计算最明细的数据。如果把数据仓库汇总到较高的层次上也许能实现查询速度上的加速，但有细微的变化，就要重新引入一条新的ETL流程，去计算新的需求，如何平衡这两点，是非常考验设计的。

王澍认为，建数据仓库本身不是目的，目的是为了满足应用的需求，不应该把问题局限在如何搭建数据仓库上，而应该关注如何满足应用的需求上。他举例说，有一些应用查询对于响应时间的要求非常严格。例如用户想要在页面上，不可能等一段时间才让结果算出来，即使数据仓库模型再合理，计算引擎的效率非常高，算出了很多东西，但应用阶段并不关心这些，用户要一秒看到结果。所以在做数据仓库的建设的时候，每一层应该有什么样的存储结构、什么样的查询引擎，都是非常重要的。

崔扬也同样认为，优秀的数据仓库首先一定要满足业务的需求，其次是数据仓库一定要是分层，以满足不同的查询范围，或者查询的实时性要求。此外，底层的支撑框架或者支撑引擎应该多样化的，数据仓库也要足够开放，可以让用户去按照自己的需求、给用户一定的自由空间去做一些定制化的事情。

在问及团队今后的方向和目标时，崔扬说：

“目前虽然团队取得了阶段性的成就，也获得了公司及业内的认可，但是，团队仍有很长的路要走，技术更新换代太快，追求极致的道路是无止境的。未来，我们计划会引入分布式缓存系统，与Presto结合以缓解目前使用S3已经遇到的性能瓶颈问题。

我们正在升级我们的Presto版本到最新的0.214，届时会享受新版本给我们带来的更多的新特性以及更好的稳定性。同时，我们也在探索多样化的查询引擎，现在OLAP领域内已经涌现了非常多的SQL On Big Data的优秀框架，我们在不断调研和尝试新的技术，以期能与目前的技术框架互补。Presto是一个相当优秀的计算框架，它仍是我们未来重要的组成部分。我们也会积极回馈Presto社区，一起参与到Presto生态的共同建设之中。”