Presto 是一个里程碑式的产品，它能够让咱们很繁难的不须要数据的导入和导出，就可以经常使用规范的 SQL 来查问数据湖仓上的数据。早先是数据仓库>Presto 中有一个概念叫做交互式的查问，即在几秒种最多几分钟前往一个结果。事实中很多人用 Presto 来做秒级查问，即 subsecond 的查问，一秒钟前往结果，得出一些很快很高效的 dashboard。也有人用 Presto 来处置一些几小时的 job，甚至用 Presto 来局部取代 ETL，经过 SQL 语句就能间接处置数据，繁难易用。Presto 处置的数据量为 PB 级，在日常的经常使用中，普通一个 Presto 集群，一天处置几十个 PB 的数据，还是很容易的。当然，集群越多，处置的数据量也越大。
目前 Presto 有两个开源的社区，一个是prestodb，此社区关键是由 Facebook 指导的社区，包含 uber、Twitter，以及国际公司 TikTok，腾讯都有介入。
另一个社区是trinodb，prestodb 分出去之后，新建的开源社区愈加的生动。此社区面前的商用公司叫 starburst，这个社区愈加生动，用户会更多一些，但是 prestodb 面前的大厂多一些。
Presto 目前的经常使用场景有很多，很少数据迷信家和数据工程师经过 SQL 查问想要的数据；一些公司决策经常使用的 BI 工具，比如 tableau 和 zeppelin；公司决策须要报表和 dashboard，这些 query 或许须要在几秒钟极速地成功，将数据展现进去，比如广告的转化率和生动用户，这些数据须要实时或准实时的反应进去；还有一个场景就是A/B testing，由于它的好处就是很快，结果能够很快的反应回来；最后一个是ETL，ETL 是很多公司的数据仓库或许数据平台的基石，十分关键，但是 Presto 并不是特意适宜在这个畛域，只管很多人经常使用 Presto 来处置一些 ETL 的 job，但是 Presto 并不是一个很容错的系统，假设计算环节两边坏掉，整个查问或许就要从头开局了。
下图
上图 是 Presto 的主体架构，coordinator 似乎一个 master，担任调度，当有一个查问出去时，把 SQL 解析生成查问的 plan，而后依据 plan 散发给若干个 worker 口头。依据不同的运算性质，每个 worker 去查对应的数据源，数据源或许是 Hive 数仓，也或许是数据湖 Iceberg 或许 Hudi，不同的数据源对应不同的 connector。connector 在经常使用的时刻，其真实 Presto 里就像一个 catalog 一个 namespace。比如在 SQL 中查问 Hive 数据仓库中的部门表，经过 hive.ADS.tablename 就可以把这个 table 找到。
由于 Presto 有着多个 connector 和 catalog，天生能够提供数据的 federation，即联结。可以在 Presto 中联结不同的数据源，可以来自 Hive 、Iceberg 、Kafka 、Druid、mysql 等各式各样的数据源，并把来自多个数据源的数据 join 到一同。Presto很灵敏，如很多人还把 Hive 的表跟 Google 的 spreadsheet 表格 join 到一同。
Presto 访问数据源就是经过直连的模式，比如要访问 HDFS 就连到 HDFS 上。有的公司或许数据源太多，或许有十几个 HDFS 的集群，这时刻 presto 须要一个一致的命名空间，此时 Presto 可以提供一个联结，在物理的数据层上方提供一个形象层，看起来就像是一个 cluster，而后在 Presto 中出现进去的就是一个一致的命名空间，这特性能还是挺繁难的。
Presto 查数据 并不是把数据给吃出去，而是访问数据的原始的存储，数据存储在 HDFS 就访问 HDFS，当 SQL 查问出去后翻译完，去到这个 Hive Metastore 中拿到元数据，经过元数据找到表数据存储在哪个目录中，将该目录分开，而后让每个 worker 读取若干的文件去计算结果。在结合 Alluxio 的上班时，扭转了缓存门路。
其真实商用版本有更好的一特性能。可以不扭转这个门路，还是这个 S3 门路，但它其实经常使用了本地的 Alluxio，当然这在咱们数据库中遇到一些费事，由于数据库中 expert 文件里边是 hard code 而不是死的门路，为缓存带来了一些费事，咱们经过转换，让原本是访问原始数据的存储，经过 election 变成访问本地的数据源，失掉提速的成果。
咱们提出提供了另外一种部署的模式。咱们把 Presto worker 和 Alluxio worker 部署在同一台物理机上。这样保障了数据的本地性。确保数据加载到了 Presto worker 的本地。这里 Presto DB 上有更精简的成功模式 ，在 to local cache 名目中，有 local cache 成功数据的本地化，经过数据本地化省掉网络传输。关于 Alluxio 就是 Co-located 的部署模式。它跟 HDFS 相比也省掉了一次性网络的传输。
国际很多公司经常使用数据一体机，将 Presto、Spark、HDFS、 ClickHouse 等都放到一同。针对这种状况，介绍的成功就是用 in memory 的 Lark show 的 local cache，会有十分好的提速，即 local cache 结合 Alluxio worker ，能有百分之四五十的提速。 缺陷 在于这种成功须要经常使用很多的内存，数据缓存在内存中，经过 SSD 或许内存来给 HDD 或许慢速的 SSD 做一个提速。这种模式即 Alluxio worker 跟 Presto worker 捆绑到了一同，200 个 Presto worker节点，就须要 200 个 Alluxio worker，这种模式会造成拓展的时刻或许产生疑问。
所以当数据量特意渺小，且跨数据核心访问的时刻，更介绍分别式 disaggregated 的部署模式。
Hive 数据仓库 曾经有十几年的历史了 ，但是不时存在着一些疑问，关于一个表的 Schema 经常有多人的改动，且改动往往不按法令改，原来是繁难类型，改成了复杂类型，造成不可保障数据的分歧性，假设一条 SQL 查问两年的数据，这个表很或许两年中改了好几次，或许很多列的类型也改了，名字也改了，甚至或许删掉或许又加回来，这就会造成 Presto 报错，即使 Spark 也很难在数据 Schema 修正的环节中做到齐全兼容。这是各个计算引擎的通病。
其实最早咱们探讨 Iceberg 这个方案的时刻，最想处置的就是 Schema 的更新变动疑问，另外想处置的就是数据版本的分歧性疑问。妇孺皆知，数据或许两边会出错，此时须要数据回滚从而检查上一个版本的数据，也或许要做一些 time travel 查指定期间版本的数据。有些数据是追加的，可以经过 partition 按期间来分区，经过 partition 查问指定期间分区数据。有的数据集是快照数据集，数据后一天笼罩前一天，历史数据不可保管，而 Iceberg 能处置这个疑问。
其实 Iceberg 并没有提供一个新的数据存储，它更多的是提供一个数据的组织模式。数 据的存储还是像 Hive 的数仓一样，存在 parquet 或许 ORC 中，Iceberg 允许这两种数据格局。
当然很多时刻为了能经常使用 export table，咱们会把一些原始的数据 CSV 或许其余格局导出去变成一个 expert table，依据分区从新组织写入 parquet 或许 ORC 文件。
关于 Schema 的 evolution 是一个痛点，Presto 允许读和写，但是目前用 Presto 写 Iceberg 的不多，关键还是用 Presto 读，用 Spark 来写，这给咱们的 Alluxio to Iceberg 结合形成了必定的费事。
一切的操作都经过 Alluxio 写，Spark 和 Presto 将 Alluxio 作为一个底层存储，从而充沛保障数据的分歧性。
弊病是，实施该方案的公司稍微大了之后，数据间接往 S3 或 HDFS 写，不经过 Alluxio。
读写都经过 Alluxio，经过智能同步元数据，保障拿到最新数据，此方案基本可用，不过还需 Spark 社区、Iceberg 社区以及 Presto 社区继续协作来把数据分歧性做得更好。
1、Iceberg Native Catalog
目前，与 cache 结合比拟好的是经常使用 Iceberg native catalog，在 Iceberg 叫 Hadoop catalog，在 Presto 中叫 native catalog，假设经常使用最原始的 Hive catalog，则 table 的元数据，即 table 位置的数据是放在 Hive-Metastore 中，Presto 或许 Spark 访问表的时刻先去查问 Hive-Metastore 失掉表的存储门路，而后经过 Iceberg 将数据文件加载出去，但是实践上，table 会有变卦，此时须要将 Hive-Metastore 上锁，这种方案在只要一个 Hive-Metastore 的时刻才有效，假设面临多个 Hive-Metastore 会产生锁失效的疑问。
更好的一个方案是 Iceberg native catalog，即齐全放弃 Hive-Metastore，经常使用一个目录来存储这个 table 的列表，这个目录可以在 HDFS 上或许 S3 上，咱们愈加介绍 HDFS，由于 HDFS 成果好一些，分歧性也强一些。这一方案防止了 Hive-Metastore service 自身的很多疑问，如 scalability 、延时。此方案对 cache 也比拟友好，不须要做一个 metadata 的 cache，而是间接 cache 寄存 metadata 的目录。
Local Cache 的成功是 Presto DB 的 RaptorX 名目，是给 Hive connector 做 Local Cache，很容易就可以给 Iceberg connector 也来关上这个 Local Cache。相当于是 cache 了 parquet 的文件到 local 的 SSD 上，Prestoworker，worker 上的 SSD 其实原本是闲置的，经过它来缓存数据成果还是挺好的。它可以提速，但咱们目前还没有特意好的官网 benchmark。
目前只是对 worker 启动 cache，metadata coordinator 是不开的，关上的话或许会有数据分歧性的疑问。
早先 parquet 文件是不加密的，cache 了 parquet 文件，只管不是明文，但只需你知道怎样读取这个 parquet 文件格局就能把一切数据读取进去。其 magic number 原来是 pare 1 就代表第一个版本，如今参与了一个 magic number 即 pare 加密的版本，这个加密版本把一些加密的信和 metadata 存在 footer 里边，它可以选用对一些 column 和性能启动加密。加密好后，数据便不再是明文的了，假设没有对应的 key，就不可读取出数据。
经过对 parquet 加密，咱们不再须要第三方的加密，也不须要对整个文件加密，可以只对须要加密的一些数据启动加密，这个方案也处置了另外一个关键的疑问，就是有的公司其实是整个文件来加密寄存在 HDFS，而后 Presto 读之前把它解密好，很多文件存储系统就是存的时刻是加密的。读取的时刻确实拿到的解密好的数据，当 Presto 再经过 Local Cache 缓存数据的时刻，cache 里存储还是明文数据，这破坏了数据加密的治理。但是驳回 parquet 外部加密，local cache 就可以满足数据加密的要求了。
Iceberg 经过谓词下推（Predicate Pushdown）可以缩小查问的数据量。
原来 Presto 的暴力查问，依据条件把合乎条件的一条条数据挑进去，但是两边有优化。其实很多查问条件可以间接 push 到 Iceberg，Iceberg 读取文件的范围就小了。
上方 是一个 benchmark，可以看到没有谓词下推前扫到了 200 万条记载，CPU time 是 62 毫秒。谓词下推后，扫到了一条记载，查问期间极大的缩短，这也是对缓存的一个优化。开谓词下推（Predicate Pushdown）性能后，咱们发现，缓存档次够用，扫的文件少了很多，这象征着咱们都可以缓存的下了，命中率有一个提高。
在前面的上班中咱们发现系统的瓶颈在 CPU。此瓶体如今很多中央，其中很大一局部是对 parquet 文件的解析，parquet 文件解析义务太重了。由于 parquet 很浪费资源，很难将 parquet 转换为更好的格局。此时，一种处置方案是将数据分为冷热数据，将较热的数据转换为愈加轻量，序列化低的格局存到缓存中，经过试验，将 parquet 文件反序列好的数据间接放到内存中，效率优化 8% 到 10% 。
但这有一个疑问，此方案对 Java 的 GC 压力十分大，由于缓存长期间存在。咱们发现此方案并不是那么好实施，所以咱们愈加想用 off heap 的模式，将数据存在 heap 之外。此时不能 cache object 自身，须要 cache Arrow 或许 flat buffer 格局，这两种格局反序列老本极低，又是二进制的流存在内存中，经过 off heap 把它装出去，而后在 Java 中再反序列化，这样可以到达一个很好的提速成果。
另外咱们也可以把一些算子 pushdown 到 native 成功存储。比如说 Alluxio 再参与一些成功 native 的 worker 和客户端的 cache 成功，咱们将算子间接 pushdown 过去，就像前面 Iceberg pushdown 一样，有些计算 push 到存储，存储前往来的结果特意少，它帮你计算，而且格局更好，它是 Arrow 并可以有 native 的成功，也可以向量化的计算。
Java 也能向量化计算。但疑问在于 Java 的版本要求比拟高，须要 Java16 或 17，而如今 Presto DB 还在 Java 11，trainer 倒是可以了，但是这个成果也不是特意好，由于 Presto 和 trainer 内存中的格局对性能化计算不友好，而且这个格局基本上是不能动的，假设要动，基本上全都要从新成功，这也是为什么会有这个 vlogs 在那里的要素。
或许这个 Presto 会有格局转换，但是不在眼前，但是咱们可以 off heap 的缓存，可以把这个 Arrow 缓存到 off heap 上，而后在那里边须要的时刻把它拿进去。而后反序列化成 page，而后给 Presto 进后退一步的计算。这个开发正在启动，或许在未来会给大家展现一局部的上班。其实就是为了降落 CPU 的经常使用和系统的延时，降落 GC 的开支，让系统变得愈加的稳固。
当天的分享就到这里，谢谢大家。