Presto+Alluxio 快速 Iceberg 数据湖访问

发布时间：2023-02-27 12:45:13 所属栏目：大数据来源：

导读：Presto+Alluxio 加速 Iceberg 数据湖访问
一、Presto & Alluxio
1 、 Presto Overview
Presto 是一个里程碑式的产品，它能够让我们很简单的不需要数据的导入和导出，就可以使用标准的 SQL 来查询数据湖仓上

Presto+Alluxio 加速 Iceberg 数据湖访问
一、Presto & Alluxio
1 、 Presto Overview
Presto 是一个里程碑式的产品，它能够让我们很简单的不需要数据的导入和导出，就可以使用标准的 SQL 来查询数据湖仓上的数据。早先是数据仓库 data warehouse 即 Hive 数据仓库，之后出现了 Hudi 和 Iceberg，有一些公司用 Presto 查询 Kafka ，还有 Druid 等等。Druid 很快，但是可能对 Join 支持不好，可以用 Presto 直接查询 Druid 一步到位，然后通过一些计算的 pushdown，它可以很好地运行 Druid中一些较难跑的任务。

另一个社区是 trinodb，prestodb 分出去之后，新建的开源社区更加的活跃。此社区背后的商用公司叫 starburst，这个社区更加活跃，用户会更多一些，但是 prestodb 背后的大厂多一些。

Presto 系统目前的具体使用场景应该会有很多，很多数据科学家和数据工程师通过 SQL 查询想要的数据；一些公司决策使用的 BI 工具，比如 tableau 和 zeppelin；公司决策需要报表和 dashboard，这些 query 可能需要在几秒钟快速地完成，将数据展示出来，比如广告的转化率和活跃用户，这些数据需要实时或准实时的反馈出来；还有一个场景就是 A/B testing，因为它的好处就是很快，结果能够很快的反馈回来；最后一个是 ETL，ETL 是很多公司的数据仓库或者数据平台的基石，非常重要，但是 Presto 并不是特别适合在这个领域，虽然很多人使用 Presto 来处理一些 ETL 的 job，但是 Presto 并不是一个很容错的系统，如果计算过程中坏掉，整个查询可能就要从头开始了。

2、Presto 主体架构

由于 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 的工作时，改变了缓存路径。

5、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，这种方式会导致拓展的时候可能出现问题。

Hive 数据仓库已经有十几年的历史了，但是一直存在着一些问题，对于一个表的 Schema 经常有多人的改动，且改动往往不按规律改，原来是简单类型，改成了复杂类型，导致无法保证数据的一致性，如果一条 SQL 查询两年的数据，这个表很可能两年中改了好几次，可能很多列的类型也改了，名字也改了，甚至可能删掉或者又加回来，这就会导致 Presto 报错，即使 Spark 也很难在数据 Schema 修改的过程中做到完全兼容。这是各个计算引擎的通病。

其实最早我们讨论 Iceberg 这个方案的时候，最想解决的就是 Schema 的升级变化问题，另外想解决的就是数据版本的一致性问题。众所周知，数据可能中间会出错，此时需要数据回滚从而查看上一个版本的数据，也可能要做一些 time travel 查指定时间版本的数据。有些数据是追加的，可以通过 partition 按时间来分区，通过 partition 查询指定时间分区数据。有的数据集是快照数据集，数据后一天覆盖前一天，历史数据无法保留，而 Iceberg 能解决这个问题。

其实 Iceberg 并没有提供一个新的数据存储，它更多的是提供一个数据的组织方式。数据的存储还是像 Hive 的数仓一样，存在 parquet 或者 ORC 中，Iceberg 支持这两种数据格式。

关于 Schema 的 evolution 是一个痛点，Presto 支持读和写，但是目前用 Presto 写 Iceberg 的不多，主要还是用 Presto 读，用 Spark 来写，这给我们的 Alluxio to Iceberg 结合造成了一定的麻烦。结合造成了一定的麻烦。为了解决这个问题，我们开发了一个基于presto的文件管理系统，可以实现文件的快速备份和恢复。

（编辑：驾考网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!