最近 Presto 社区在它的发源地 Facebook 公司举行了它历史上的第一次 Summit, 目前 PPT 已经都放出来了，看了一遍，还是有不少收获的，这里介绍一下 Facebook、Starburst、LinkedIn以及Lyft 这几个公司分享的内容。
Facebook 的 Martin 分享了一下 Presto 这个项目目前的状态。 从 2012年8月8日 Martin 同学写下第一行代码算起，Presto 已经有6年历史了，目前在 Facebook 部署了 1000 多个节点，每天要处理 100 多 PB的数据，70%以上的新数仓负载都是由 Presto 来承载的。
项目方面这一年的进展很大，总的 Contributor 数是330个。安全性方面支持了客户端证书、密码以及JSON Web Token的认证；支持节点之间的数据加密；支持行级别的权限控制。查询执行方面支持分区化的查询执行(Partitioned query Execution)以及分布式排序。SQL语法方面比较大的改进是支持了新的 Geospatial 函数和Lateral JOIN。
将来的计划是要支持更大的集群：超过1000个节点；支持故障恢复；自动处理数据倾斜；工作负载重新平衡化；支持临时表；多阶段查询执行；语言方面支持UDF；支持SQL 2016的特性，比如 Row Matching 等等。
Starburst
Starburst 的PPT是所有PPT里面最具商务气息的，这跟它们公司成立不久，需要更多的曝光度有关，它们整个 PPT 的前半部分都在介绍 Starburst 这个公司。他们提的一点蛮有意思，说他们公司是一个没有风投，员工做主，能盈利的公司，在这个风投遍地的时代还是有点另类的。他们的主要优势是:
- 公司是由 Presto 的 Commiter 组成的，真正的意思上的一个技术型公司。
- 他们对 Presto 已经有了3年多的贡献历史。
- 他们支持了大型的企业用户。
- 他们贡献了一些很关键的特性，比如“spill to disk”, CBO优化器等等。
真正的技术分享篇幅倒是很短，简单介绍了一下最近开发的关键特性: Cost-Base Optimizer, 主要是因为CBO本身在数据处理领域不是一个新概念，而且他们之前也有专门文章介绍过，感兴趣的可以看下他们之前的博客: Introduction to Presto Cost-Based Optimizer。
Linkedin 介绍的角度是作为一个新使用 Presto 的公司，如何解决碰到的各种问题。对于想要采用 Presto 的公司比较有参考意义。
刚开始的时候 Linkedin 的数据都是以 Hadoop 为中心来组织的，为了使用 Presto ， 部署了单独的 Presto 集群，为了能够把数据灌到这个集群里面去，需要做一些数据集成的事情，比如数据复制。LinkedIn 是采用 Apache Gobblin 来简化这些问题。Gobblin 是一个分布式的数据集成框架，它能简化关于数据集成的方方面面，比如数据摄取，数据复制，数据组织，以及生命周期管理，比较牛的地方是它不止支持离线数据，还支持实时数据。
引入一个新的框架之后，很关键的一点是要看看用户对这个新的框架的感受如何，在这一点上面他们利用了 Presto 的 EventListener 机制记录下了用户使用过程中的各种元数据，比如多少用户在用，哪些查询耗费了大量的资源，数据的血缘关系是什么样的，用户使用数据的时候碰到了什么问题等等。
public interface EventListener {
void queryCreated(QueryCreatedEvent queryCreatedEvent);
void queryCompleted(QueryCompletedEvent queryCompletedEvent);
void splitCompleted(SplitCompletedEvent splitCompletedEvent);
}
通过这个接口把数据灌进 Kafka ，之后再把数据倒回 Presto 进行分析，也算是 Dog eat dog‘s food 了。
在最初验证完概念之后，如何进一步推进 Presto 的使用? 要把数据全部都导入 Presto 是不现实的，因为没有人愿意花那么大代价把数据从 Hadoop 搬到 Presto 上面来；同时也要考虑怎么让这个 Presto 的新框架能够与公司内部老的工具很好的集成；而且公司内的数据除了 Hadoop, Presto上的，还有各种其他的数据源，比如 JDBC, Kafaka, Elasticsearch 等等。他们做了一个 Federation Connector，充当数据 Connector 的门面，查询进来之后，这个 Federation Connector 会根据实际的数据类型对数据进行路由。
LinkedIn 还开发了一个叫做 Dali View 的东西， 这个 Dali View 就像数据库里面的视图一样，通过在数据之上封装一层，让整个公司里面所有的数据看起来像是在一个同构的数据库里面一样。用户可以通过各种客户端来对这些数据进行查询。如果访问到的是一个 Presto 的表，那么直接路由到底层的 Presto，如果是一个 Hive View，那么先把请求转给 Hive 的 Analyzer，再通过 Calcite 生成 Presto 的 SQL，再丢给 Presto 去执行，这样可以把所有的计算收到 Presto 这一个地方，运维团队几种精力优化 Presto 这一个系统就好了。
统一了 SQL 查询之后，LinkedIn 还对 UDF 进行了统一，因为每个平台都有自己的 UDF API，他们搞了一个通用的抽象，使得用户只要写一份 UDF，就可以在各个平台上运行。
Lyft
最后一个想聊一下的是 Lyft，他们的 PPT 是最长的，其它人 PPT 只有20来页，而他们的 PPT 是70多页(其实很多是PPT是为了页面过度效果)。Lyft 的数仓在 2013 年的时候是完全基于 Redshift的，到了2018年 Redshift(以及Hive) 只管批量计算，而用户的交互式查询完全交给了 Presto 和 Druid。他们的数据量级在 10 PB以上，保存在S3上面，使用的 Parquet 格式，通过日期对数据进行分区，表的总数在50000以上。
他们使用 Presto 主要还是用来交互式的数据查询以及每天定时的报表生成，不进行数据清洗，使用高峰时间是在白天上班时间。
他们开发的一个比较有意思的特性是 Presto Gateway，这个 Gateway 的来由是这样的：上面提到过，在 Lyft 用户对 Presto 的使用模式分两种: 交互式查询以及定时报表生成，这两种使用模式对于服务响应速度的需求是不一样的，为了他们不要相互影响而把 Presto 分成了多个集群，但是他们不想让用户知道这种底层细节。因此他们开发了一个 Gateway，所有的请求都提交到这个 Gateway，然后这个 Gateway 会根据一些路由规则把请求自动路由到正确的集群。
这个架构图画的确实有点朴素...
他们还做了一个很有意思的查询保护机制，保护整个集群不至于被某些慢查询拖垮，这里使用的也是 Presto 的插件机制，对用户的查询进行分析，分析完成之后应用一些预先定义的规则对查询进行阻止，比如查表的时候不带分区，一些预先知道的很差的Query。
总结
Presto 界目前有两大玩家: Facebook 和 Starburst，Facebook 是 Presto 的缔造者，地位自不用说；Starburst 则是由 Presto 的一些 Committer 组建的一个公司，目前在 Presto 商业版本的一些事情, 一些很关键的特性比如 Presto 的 Cost Base Optimizer 就是由他们贡献的。其实阿里在 Presto 上面也有很大的研发投入，只是我们在开源方面发声不多，有点可惜。
Presto 虽然已经有了6年的历史，但是社区还不是很大，Summit 也是才开第一次。但是这种网络带宽越来越大，计算跟存储逐渐分离，这种可以对各种不同格式的、保存在各种不同存储里面的数据进行分析的计算引擎应该会越来越受欢迎。
