Presto+Alluxio 加速 Iceberg 数据湖访问_互联网资讯__分享互联网新鲜有趣好玩的事物-云易优站长平台

导读本文将分享 Alluxio 社区和 PResto 社区在数据湖方面的一些工做，次要聚焦 Iceberg。

文章包罗以下几个部门：

1. Presto & Alluxio

2. Alluxio & Iceberg

3. 更佳理论

4. 将来的工做

分享嘉宾｜王北南博士 Alluxio 软件工程师

编纂整理｜唐洪超敏捷云

出品社区｜DataFun

Presto & Alluxio

1. Presto Overview

Presto 是一个里程碑式的产物，它可以让我们很简单的不需要数据的导入和导出，就能够利用尺度的 SQL 来查询数据湖仓上的数据。早先是数据仓库 data warehouse 即 Hive 数据仓库，之后呈现了 Hudi 和 Iceberg，有一些公司用 Presto 查询 Kafka ，还有 Druid 等等。Druid 很快，但是可能对 Join 撑持欠好，能够用 Presto 间接查询 Druid 一步到位，然后通过一些计算的 pushdown，可以让 Druid 中有些跑得比力困难的使命得到很好的运行。

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 开展的汗青。

2. 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 次要的数据来源可能 95% 以至 99% 是来自 Hive 。当然如今也有些变革了，因为数据湖的兴起，可能越来越多流量会转向数据湖 Iceberg 和 Hudi。

3. Presto + Alluxio Overview

Presto 拜候数据源就是通过曲连的体例，好比要拜候 HDFS 就连到 HDFS 上。有的公司可能数据源太多，可能有十几个 HDFS 的集群，那时候 presto 需要一个同一的定名空间，此时 Presto 能够供给一个结合，在物理的数据层上面供给一个笼统层，看起来就像是一个 cluster，然后在 Presto 中呈现出来的就是一个同一的定名空间，那个功用仍是挺便利的。

4. Presto 与 Alluxio 连系

Presto 查数据并非把数据给吃进来，而是拜候数据的原始的存储，数据存储在 HDFS 就拜候 HDFS，当 SQL 查询进来后翻译完，去到那个 Hive Metastore 中拿到元数据，通过元数据找到表数据存储在哪个目次中，将该目次分隔，然后让每个 worker 读取若干的文件去计算成果。在连系 Alluxio 的工做时，改动了缓存途径。

其其实商用版本有更好的一个功用。能够不改动那个途径，仍是那个 S3 途径，但它其实利用了当地的 Alluxio，当然那在我们数据库中碰到一些费事，因为数据库中 expert 文件里边是 hard code 而不是死的途径，为缓存带来了一些费事，我们通过转换，让原来是拜候原始数据的存储，通过 election 酿成拜候当地的数据源，得到提速的效果。

5. Co-located deployment

我们提出供给了别的一种摆设的体例。我们把 Presto worker 和 Alluxio worker 摆设在统一台物理机上。如许包管了数据的当地性。确保数据加载到了 Presto worker 的当地。那里 Presto DB 上有更精简的实现体例，在 to local cache 项目中，有 local cache 实现数据的当地化，通过数据当地化免却收集传输。关于 Alluxio 就是 Co-located 的摆设体例。它跟 HDFS 比拟也免却了一次收集的传输。

6. Disaggregated deployment

国内良多公司利用数据一体机，将 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 的摆设体例。

Alluxio & Iceberg

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 连系形成了必然的费事。

1. Alluxio + Iceberg Architecture 计划

计划一：

所有的操做都通过 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 的目次。

2. Iceberg Local Cache

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 是不开的，翻开的话可能会有数据一致性的问题。

3. 数据加密

早先 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 就能够满够数据加密的要求了。

4. 谓词下推

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 的开销，让系统变得愈加的不变。

今天的分享就到那里，谢谢各人。

｜分享嘉宾｜