能够给大家先简略介绍一下 Presto，因为可能很多人是第一次接触这些大数据平台的技术。那 Presto 是什么呢？
其实它就是能查问大量、海量数据的一个 SQL 数据库，SQL 数据库大家曾经见了很多了，MySQL、oracle 这些都是 SQL 数据库。很多人可能也有领会，SQL 是个很不便的查问数据的语言。那为什么要有 Presto 呢？首先如果你应用 MySQL，oracle 的话，你会发现它查一些小规模的数据, 如果能够很容易命中的话，它是很快的。但如果说你要查海量的数据，比如说有几亿条或者几十亿条的时候，性能就一直的降落，而且如果你要做一个全表的扫描的话，这个对它们来说就是个劫难，可能它就会变得十分的慢。那这时候就有了 Presto 分布式的 SQL 大数据查问引擎，这就是 Bin（范斌——Alluxio 开创成员和 VP of Open Source）之前提到的计算和存储拆散的计算引擎，它就不再像咱们传统的数据库那样治理存储，Presto 不治理存储，它把存储交给了第三方平台，能够是 HDFS 也能够是 GCS 也能够是 S3，什么都能够。Presto 只管计算，那这样的一个状况下，咱们能够离开的 scale up&down，而后达到解决海量数据的目标。
那当初是一个什么状况？我口说无凭, 大家能够看网上的一些材料，互联网巨头的数据都是海量的，都是几十亿人的应用，这些互联网公司都是广泛采纳 Presto 来进行数据的查问，那这个大略是一个什么量呢？一个根本的 Presto 集群，可能是 200~400 的服务器的 Presto 集群，它一秒钟能够解决几十个 B, 也就是几百亿行的数据，如果看这种生产环境的 Presto，咱们能够看到 Presto 一秒钟能够解决几百亿行的数据，这真的非常适合有海量数据的状况下来运行 SQL 的查问。
方才也提到了, Presto 是计算和存储拆散，大家都晓得互联网，尽管上网感觉如同到哪都很快，但其实是有间隔的。比如说明天咱们这个直播，大家可能看到，咱们两个人的视频就没有那么晦涩，为什么？因为咱们间隔有点远，从美国的硅谷到中国传输间隔很长，有很多的网关路由器，延时就在增长，而 Presto 没有本人的数据，要查问任何货色，都要把要查的数据集给读出来，都要给 load 进来，一行一行地扫描一遍，那速度就很依赖于网络传输的速度，其实这也是 Presto 的瓶颈之一。咱们能够把 Alluxio 和 Presto 或者其余的计算引擎部署到一起，它起到一个中间层的作用, 就是说计算引擎只从 Alluxio 拿数据，而后 Alluxio 负责从理论的存储来拿数据。比如说咱们最右边的这个例子，这个是当初很多新兴的互联网公司或者新的守业公司最罕用的一个架构，它从守业第一天或者公司建设第一天起，数据就是齐全的上云，本人不必建数据中心了，这是当初十分常见的一个模式。那数据都在云上，计算怎么办？从云上拿数据其实一方面是费用高，另外一方面是速度可能会慢，那怎么办？咱们就通过 Alluxio 做一层缓存机制，如果数据在 Alluxio 集群里边，那咱们从 Alluxio 能够拿到，如果说没在，咱们的计算引擎也不必关怀，让 Alluxio 去云上把数据拿回来，起到一个提速的作用。
那有些敌人说咱们公司没上云，就是有一些数据中心。但很多公司的数据中心一个中央也放不下，很多公司可能是在北京有数据中心，西安有数据中心，杭州有数据中心，比如说西安的共事想跑一条计算，想跑一个 SQL 的查问，那怎么办？这个数据可能在杭州是吧？这又是一个异地的过程。它也是能够用 Alluxio，Alluxio 跟计算部署到一起，比如说计算 Presto 集群，500 台服务器在西安，那咱们同样把 Alluxio 跟它部署到一起。计算引擎到 Alluxio 来拿数据，Alluxio 负责到异地的数据中心来拿数据，而且有了这个架构之后，能够反对多个异地的数据中心，反正就是到 Alluxio 找数据，Alluxio 负责帮你把数据给拿回来。这是两头的一个状况。那最左边这个状况其实是我亲身经历的一种状况。这个公司原本数据都是在本人数据中心里的 Hadoop 上，然而可能是机器不够用了，公司想上云那怎么办？因为云上的机器可能会更便宜，而且要新机器会更容易。其实很多公司会想是不是要把数据往云上 copy 一份，或者比如说计算是在云上的，那我是不是把数据往云上 copy，然而这个费用或者说老本、耗时都会很大那怎么办？咱们云上的计算集群能够部署一个 Alluxio，同样的情理做到提速。这个图就解决了长距离的，间隔增大了或者说异地的这种状况。当然咱们前面也会有一些具体的例子和数据，能够看到 Alluxio 会有减速，而且也不便拜访的这么一个过程。
咱们上云也好，或者应用第三方的存储服务也好，对咱们的计算引擎也是一个挑战。其实对 Presto 和 Spark 还好，因为各种的 object store 基本上都还反对，然而如果说贵公司要是有很多种存储技术的话，那这个问题就有点麻烦了，能够通过 Alluxio 来做一个形象层，帮你集中管理、集中应用各种存储形式。因为当初很多公司也是有价格上的策略，可能不违心只局限于一种云的服务，对吧？或者它这个数据可能 S3 也放一点，GCP 上也放一点，对吧？那其实就存在 Bin 方才提到的数据孤岛的问题，数据哪里都有，怎么办？真正的数据的使用者，不是那么关怀数据在哪，他只关怀这种逻辑层面上的数据的查问和拜访，并不关怀数据底层是一种什么模式存在的。所以说通过 Alluxio 来做一层形象，做一个隔离，这也加重计算引擎方面的累赘。
那咱们搞这么一个形象层, 一个 layer 在两头, 有什么益处？那第一个益处就是快，为什么会快？因为后面提到了互联网也是有间隔的，网络有间隔，那咱们的 Alluxio 作为一个缓存层，它离计算引擎更近，甚至能够部署在一台机器上，数据的拜访读取的延时就会变得很低。其实快就解决了很多问题，如果有保护过大数据计算引擎的敌人就会晓得，速度一快整个零碎的吞吐量也会回升，稳定性也会回升，各方面都会有进步。其实快也不是速度这么简略，它还提供速度的稳定性。不晓得大家有没有遇到过，你用 Presto 的时候，同一条查问，可能明天须要 5 分钟，今天再运行一下两小时，它不稳固，为什么不稳固？一部分是网络延时的起因，一部分也是因为 Presto 有调度的问题，其余用户比拟多，或者你的优先级被调低了，所以不稳固。那这个不稳固带来很多劫难，咱们管它叫 SLA。如果说你的用户是集体，他可能是个数据工程师或者是数据分析师，他原本一天要运行比如说 10 条 SQL 的查问，因为他要出报表，那他这个数不稳固，两小时没进去，可能要重试一下或怎么样，当天工作实现不了。如果说客户端是一个服务，如果延时不稳固，超过下限的话，那这个问题就更重大了。因为任何客户端都会有一个超时的设定，它间接就失败了。而且方才也提到了网络 I / O 是一个瓶颈，如果有 Alluxio，它能帮你挡掉一些网络的传输，加重网络的累赘，带宽腾出来又能够干很多事，对 Presto 来说各种 SQL 的各种 join 的连贯，会变得更快。而且咱们不单是有这个看起来像是缓存的服务，而且咱们还有一些元数据的服务，叫 catalog service，而后咱们还有一些数据转换的服务。因为其实有的时候有些数据格式并不是那么利于查问，那能够做一些转换，比如说把 csv 转换成 parquet，就更加利于计算引擎来做查问和剖析。
这个图就是在讲 Presto 和 Alluxio 怎么工作，先看一下 Presto 没有 Alluxio 之前本人怎么工作。其实任何一个 Presto 查问分两步走，第一步先去 Hive Metastore 拿元数据。你不是给我一个 table 吗？那我就要看看这个 table 存在哪，这个元数据会给它一系列的地位，一个很长的列表，可能几百个，几千个甚至几万个几十万个都有可能，其实就是一些文件或者门路。Presto 拿到这一系列门路之后，这里也没有什么黑魔法，就是 Presto 把这些数据给读出来，做计算看哪些数据合乎你的要求。
当咱们有了 Alluxio 之后，咱们会让元数据返回一个 Alluxio 地址，因为原本你可能是 S3,HDFS, 当初就是 Alluxio 了，咱们前面有个真正的黑魔法，待会再讲。那它给咱们一个 Alluxio 的 table 的门路，而后 Presto 就会拿这个门路去找 Alluxio。你之前会把 S3 也好，HDFS 也好，把它给挂载到了 Alluxio，Alluxio 晓得你要的是这个货色，因为咱们有元数据服务，而后咱们就晓得你是要这个文件，那 Alluxio 就会看，如果说我有，我就给你，我没有我去找底下的存储，把你要的数据给拿到。这里咱们其实有两个改变，一个就是元数据这里会有 URL 的变动，而后另外一个工作就是咱们须要挂载实在的存储，可能当初有些人会感觉这个如同有点麻烦，那么等下还会有个黑魔法。
咱们也是在最近的这一两个版本中，退出了一个叫 Transparent URI 和主动挂载的性能，当初咱们不麻烦这个元数据和 Hive Metastore 给咱们一个更新了的地址，原来你是 S3 还是 HDFS, 你还是给我这个，所以说对于 Hive Metastore 来说，它齐全能够对 Alluxio 无感知。那等于说 Presto 还是拿到了 S3 的地址，咱们不必批改代码，咱们批改一下 Presto 的配置，把 FS 的默认实现换成 Alluxio 本人实现。就是当他看到这个是 S3 的，他会去 Alluxio 找, 它会有一个主动挂载的机制，当时也会有一些配置，然而就一两行的配置加上之后，他本人到对应的 S3 bucket 上，把这个数据给挂载好。但对于咱们的 Hive Metastore 也好，对于咱们的这个 Presto 用户也好，都是无感知，因为它看起来这个表如同还在 S3 上或者在 HDFS 上，但实际上是到 Alluxio 这边走了一遭，如果说咱们这个缓存有命中，Alluxio 有这个数据了，它就会有十分好的提速成果。
那咱们从用户角度会看到什么？
因为我后面讲了，Presto 是存储和计算拆散的，它并不太治理存储空间，你在 Presto 建表的时候，建这种 external table 时，那其实在干嘛？它就是指定一个门路，通知 Presto 或者通知 Hive Metastore，咱们这里建个表，这个表就是在某一个地位。那如果说你有了 Alluxio 的话，其实你在建表的时候就通知 Presto，这个表是在这个中央，咱们是一个 Alluxio 打头的就好了。前面的这些工作全是其实都是由 Presto 和 Alluxio 来做的，用户的批改就曾经是非常少了。那有了 Transparent URI 后，其实批改能够更少，咱们都不必改原来的建表脚本，如果你原来有表，你是建在这个 S3 上，就不必动了，但如果你没建，你能够用这个命令，跟以前那个一般的 S3 也好还是 HDFS 也好都是截然不同的。而后你就在里边查问就好，你写任何一个 SQL 查问，你都不必管它的门路在哪，表一旦建好，对于一般的数据工程师或者数据设计师也好，他们晓得这个 table 内容其实就够用了，就能够从 table 拿到数据。
那咱们再来就是略微介绍一下咱们的一些实在案例，让大家对咱们的提速过程有一个直观的意识。因为我也是亲自经营保护 Presto 好些年，我感觉我收到的最大的埋怨也好，投诉也好，就是你们怎么这么慢？这个查问我一天都没跑完，我一天工作都被你耽搁了。那怎么办？如果你也是在保护 Presto，或者你们公司有 Presto 的话，试一试咱们的 Alluxio caching, 在进行一些简略的配置和优化之后，你会看到几倍的提速。这里顺便写是 I / O 密集型的查问，但如果说你真的经营 Presto 的话，你会发现大多数 query 都是 I / O 密集型拜访。咱们以前做了一个统计，90% 的工夫都是花在扫表下面的，那应用 Alluxio 会给这些查问一个十分丑陋的提速。
而后你看这里特意强调小文件，这个小文件其实咱们前面还会有另外的直播，会讲这个元数据方面。它为什么会强调小文件，其实小文件的瓶颈, 就有一部分从扫表变成了元数据的获取，因为后面讲了元数据给你一个文件列表，如果文件特地小，同样的数据量外面文件就会特地多，那它这个中央工夫就会耗费比拟长。对于这个案例，如果咱们没有开元数据缓存的话，其实提速没有 5 点几倍，如同是 1 点几倍还是多少倍，咱们开了这个元数据缓存之后，提速 5.9 倍。有趣味的敌人能够关注咱们的后续直播，咱们会有一个 catalog service 的直播。
那么这个是怎么实现的呢? 能够看咱们的左边的这个图，数据还是在这个 S3 上没有变动，对吧？这个图走漏很多信息，能够看到 Alluxio 和 Presto 有一个一一对应的关系。其实咱们就是这么部署的，咱们把每一个 Presto worker 和每一个 Alluxio worker 部署到一起，为什么部署到一起？这里我要提一下，这两个货色真的是天作之合，因为它资源的应用是错位的，Presto 会比拟强调对 CPU 的应用，它要很多的 CPU，它要很多的内存，然而 Alluxio 对 CPU 要的不多，对内存也没要多少，但它对磁盘要的很多。那你想一个物理机器，正好把它俩放一起。有敌人说这两个货色如同都要网络, 怎么办？他俩在一起的话，如果能命中缓存，就不须要从里面拿，如果说没命中，那它俩也只有进来拿一份就好了，其实这个总量上还是没有晋升，如果缓存命中率高，其实网络的压力是大幅降落的，所以它俩单干就能够达到查问提速的成果。
这个我的项目是咱们跟 Facebook 脸书的单干，这也是 BIN 跟我始终在跟的一个我的项目。其实这个数据有点激进，从他们最近一次跟咱们的讲座来看，他们是取得了 10 倍以上的晋升。那这个技术跟后面略有不同，后面是一个分布式的缓存的设计，那这里咱们管它叫 Presto worker 的 local cache，略有不同，能够了解为一二级的缓存。那这个也是一样的逻辑，咱们如果命中了，咱们就本地拿给它，如果没命中就到近程去拿。这个我的项目在脸书曾经失去十分宽泛的应用，数以万计的服务器都在应用，具体的数字我可能不不便走漏，这些服务器都是应用咱们的 local cache 来做提速，而且咱们还会有不少的后续工作，其实咱们还有很大的后劲。
它的特点是，在图上也能看到 local cache 是运行在和 Presto worker 雷同的 JVM 外面。Presto 读文件，无论从 HDFS 读也好，从 S3 读也好，你都读一个文件，那咱们有这个 cache file system，就能够从咱们这边来读这个文件，也会有一个十分好的成果。从这个数据也能看到咱们进步了查问工夫的稳定性，咱们对 p50，就是这个中位数进步 33%，对 p95，就是说 95% 的工夫的查问是 48。慢的查问可能会有更好的成果，而且咱们还加重了很多网络的累赘，这个其实是很胜利的一个标记。他们的服务的稳定性和速度都失去很好的晋升。
咱们还有更多的例子都在这里，十分多的公司都在跟咱们单干，他们都获得了称心的成果，这只是一部分，很多公司也还在跟咱们继续的单干，大家能够看底下这两个链接取得更多的信息，谢谢大家。