作者简介
**陈寿纬：**Alluxio软件工程师，在Alluxio首要担任数据湖计划结合、结构化数据与高可用性优化等相关工作。陈寿纬博士结业于罗格斯大学电子与核算机工程系，专业方向是大规模分布式体系的功用与稳定性优化。
**王北南：**Alluxio软件工程师，也是PrestoDB的committer。参加Alluxio之前，北南博士是Twitter Presto团队的技能担任人，并为Twitter的数据渠道构建了大规模分布式SQL体系。他在功用优化、分布式缓存和大数据方面有12年的工作经验。王北南博士结业于雪城大学核算机工程专业，专业方向是对分布式体系进行信号模型检测和运转验证。
活动回顾
Iceberg是数据湖计划中常用的大规模数据剖析元数据存储格局，用以供给优异的功用与ACID支撑。
Alluxio作为开源的数据编列体系，能够协助各种核算引擎进行更好的数据办理与加快数据拜访，提高整体事务的效率与稳定性。
在【Iceberg + Alluxio 助力加快数据通道】系列活动中，本次主题演讲将同享开源分布式存储体系Alluxio与Iceberg的基本概念、集成计划与未来的结合方向。
本次活动中咱们还同享了咱们近期在Presto社区中Iceberg的一些工作与未来的计划。
（以下为本次活动的演讲实录）
Alluxio概览
Alluxio是2014年在伯克利 AMPLab孵化的一个项目，那时分名叫Tachyon，是跟Spark同一期孵化的分布式存储项目。截止到今天为止，咱们这个社区里现已有超过1000名的contributor参加建立了社区代码和各种活动，在Slack committee里边现已有5000以上的 member进行互动，咱们也把技能广泛应用在各种开源场景里边。在去年的时分，咱们也被谷歌评选为最具影响力的十大 Java-based的开源社区项目，假如咱们对这个项目感兴趣的话，欢迎扫描二维码参加咱们 slack社区，跟咱们进行评论。
现在Alluxio项目现已广泛地应用在各种不同的大厂和小厂里边，包含互联网企业，云核算的供给商，也包含银行、不同的通讯行业的企业，假如咱们感兴趣的话，咱们也会进行更多的同享，邀请咱们来一同做技能同享，建立根据Alluxio的技能渠道。Alluxio是一个数据编列层，它不只服务于数据analytics，也服务于AI，咱们最首要的场景也是根据cloud的场景。
Alluxio第一个功用是能够运用Alluxio去衔接一切的核算引擎和存储体系，假如你上面的体系搭载了 Presto、Spark、 MapReduce、Hive这一类的体系，你能够经过Alluxio去拜访下面一切的存储引擎，包含但不只限于我在这里列的HDFS，S3、GCS、Azure和NFS等，咱们有更全面的支撑，包含上层的核算引擎和下层的存储体系。
咱们的方针是把数据从远端的存储带回到近端的核算里边，由于特别是在云核算、混合核算或许是多数据中心的场景下，存储许多时分都不是跟传统的核算在一同的，所以这时分拜访数据就会有许多的问题。在这种场景下，咱们需求把数据重新从远端的存储带回到近端的核算上面达到更高效的拜访。
最首要的应用用例有三个：
- 第一个用例是云核算的场景，云核算场景一般都是用云核算存储，所以它的功用和稳定性并不是十分的好, 把Alluxio加上去今后，能够达到更好的 SLA一致性，更好的功用，而且能够省去流量，比方说公有云存储的流量运用需求花钱，但咱们能够经过caching solution去缓解流量的开支。
- 第二个场景是混合云核算，比方说咱们有一部分的数据是放在公有云里边，有一部分数据还放在传统的私有云里边，假如私有云的数据想去拜访公有云，它的带宽是十分受限的，这个时分能够把Alluxio加进去，成为一个缓存层，来缓解这个问题，这便是混合云布置。
- 第三个场景是一个多核算中心解决计划，比方你在北京、上海，兰州都有一个数据中心，能够在这种场景下布置Alluxio去加快应用场景。
咱们的开展首要有下面三个方向，咱们一向着重Alluxio虽然是一个缓存层的组件，但它不只仅是一个缓存层。
第一个组件便是unify data lake，能够理解为支撑不同的API向上层的核算引擎，也能够向下支撑不同的存储体系，你只需办理好 Alluxio的一套 API，就能够办理好整套的data lake solution。
第二个是能够更有效地获取数据并办理数据，这也是缓存层首要的功用，首要是给事务进行加快。咱们也供给data policy引擎，比方说你想把数据从一个HDFS集群移动到另一个HDFS集群，能够经过policy engine守时而且定量地进行数据移动，然后更好地办理数据集群。
第三个是多云布置。拿美国这边打个比方，比方说你需求用AWS的 S3, 一起要用GCP的BigQuery引擎，你能够进行混合云的布置，也便是说你能够在 GCP里边布置Alluxio集群去query S3的数据，这样就能够更好地建立混合云。
举例
在国内比较常见的场景是从私有云的HDFS到混合云的目标存储，其中咱们供给几个功用，第一个叫unified name space，你能够把 HDFS集群和目标存储的集群都mount到一个一致的Alluxio cluster里边进行办理，供给完好的根据目标存储的一套剖析解决计划。在这种场景下，比较常见到的是混合云布置，便是说既有公有云也有私有云。
咱们来看一下布置的架构，在这个场景里，有两个不同的公有云供给商，一个是AWS，一个是Google Cloud。在AWS和Google Cloud里边咱们都布置了Alluxio集群。其中第三个集群是一个private cluster，便是私有云的集群，咱们也一起布置了Alluxio，它的底层其实是一个MINIO集群，也便是说MINIO的集群一起供给了数据服务给两个公有云和一个私有云，而在这种场景下，你能够用Alluxio作为缓存加快供给给不同的上层核算引擎，包含在AWS上的 EMR Google cloud dataproc和包含在私有云下面自己建立的Hive， Spark和Presto场景，你能够达到一个完好的循环，不需求用私有云里边的MINIO供给十分低的功用，去给不同的公有云和私有云核算引擎。
混合云到多个云的场景
咱们能够看到，同样是两个公有云供给商，左面是Microsoft Azure，右边是AWS，能够看到下面ETL job和Ingestion都会直接写到Alluxio里边，在这种场景下，你能够挑选写入Alluxio的方法，把这个数据写回到底层的 HDFS上面去， 然后Alluxio会把这个数据同享给不同的数据中心，包含右边的HDFS集群和上面的几个公有云的Alluxio集群。在这种建立下，只需求一个Alluxio集群，就能够完成数据同享，不需求建立 ETL数据通道，再去把一切的数据写回到不同的HDFS 集群和另外的Alluxio或许是云核算的目标存储里边。
Iceberg概览
Iceberg是一种开放式的table format，它首要是作为对标 Hive的一种文件，是一种表格存储的格局，首要的应对场景是比较大型的数据剖析场景。它供给几种不同的功用，首要有 Schema evolution，hidden partitioning，partition layout evolution 和time travel，还供给version rollback的功用，许多功用是专门为了满意美国关于数据隐私法案的需求，供给事务性的支撑。相对于Hive很难完成事务性的支撑，Apache Iceberg供给了更好的支撑。
Iceberg的schema evolution都是根据元数据操作的，没有任何的数据操作，能够添加column，drop column，能够rename column，也能够更新 column struct field，map key，map value或许 list element，甚至能够reorder，change the order of column or field in a nested struct。其实他们现在也支撑z-ordering这种格局，为了让数据能得到更好的加快作用。
那么它是怎样完成事务性支撑呢？它用了比较传统的数据库的理念，便是snapshot，它的不同的表格版别，是用snapshot来维护的，snapshot下面有一系列的manifest file来表征这个表在某一个特殊的时刻点，比方说在11月27号，它是一个 snapshot，有或许过比方说一个小时或许是一天，它就更新一个snapshot，所以每个表格是经过snapshot去确保它的不同的版别的数据的一致性。
接下来咱们来看一下为什么 Iceberg提出了这种计划。
在大数据数据库的领域，咱们原来都是用 Hive table，可是咱们发现Hive table有许多问题，它就变成了一个table format。首要问题有我认为有两种，第一个是Hive table不支撑事务性的，所以要支撑 ACID十分困难。第二个是Hive table 是directory-based mechanism，所以每次去获取这个表格的全貌，都要经过底层的存储体系去list directory。在表格小的情况下，这不是一个十分重的开支，但假如是一个十分大的表格，比方说有上万个或许是上百万个partition的表格，开支会十分的昂贵，所以他们就提出一个概念叫encoding partitioning Information in manifest file，等于说它不需求经过 directory-based的概念去做这个工作了，而是把一切的数据都include到 table format里边去，直接去解析这个文件，来获取一切的文件位置。
然后咱们能够看一下，比方说在右边manifest list里边，它会标注 manifest file在哪里，比方说manifest-1.avro这个file，它有一个partition的概念，event time是2021年10月11号到2021年10月15号，有一个最小的event date和最大的event date，然后对应到左面就能够找到 manifest file，这个 manifest file会对应一切的 Parquet文件，由于咱们知道Parquet文件是经过最小值和最大值去做 predicate pushdown，等于说在这个概念里边，它就把一切的最小值和最大值都include到Iceberg的metadata里边去了，就不需求去list directory，去fetch parquet header获取做 predicate pushdown的元数据，而是能够一次性把一切的数据都拉过来，进行indexing的操作。咱们假如对Iceberg的indexing比较感兴趣的话，我引荐咱们去看下面的 tabular log，这是Ryan最新写的关于Iceberg如何做indexing的十分具体的blog，咱们假如感兴趣能够看一下。
Alluxio＋Iceberg 集成计划
咱们发现Alluxio供给的是数据层面的东西，而 Iceberg供给的是表格层面的东西，它们两个关系十分远，可是为什么咱们要把Alluxio的计划和 Iceberg的计划进行集成，我想来答复一下咱们的问题。
首要咱们发现，现在构筑一个大数据计划，是期望得到一个完好的计划，而不是只用一个Iceberg或Alluxio就能够完成一个数据湖的建立，事实上自上而下需求许多不同的组件去组成一个数据湖的计划。比方说，假如是根据Iceberg，很有或许上面需求有元数据的办理层，下面是Iceberg这样的元数据format底层，再下面有或许是使用Presto或许Spark等不同技能建立了 ETL或许OLAP的核算引擎层，然后再下面有或许是Alluxio这样的缓存层，最下面有或许是你自己的一些云核算存储或许HDFS存储。所以咱们看到许多用户十分关心整个事务逻辑的建立，认为Alluxio计划需求跟Iceberg进行集成。
那么现阶段Alluxio给Iceberg供给了哪些优势?
**1.**不论Iceberg放在私有云、公有云仍是多云环境下面，Alluxio都能够给整个数据通道进行加快，给事务逻辑供给更好的数据本地性。
**2.**由于Iceberg比较Hive, 没有自己的服务去办理这些 file format，假如你要进行数据搬迁，会比较费事，特别是比方说现在 Iceberg支撑最好的是Hadoop，也便是根据HDFS那套接口，假如你要把这个计划搬迁到比方说S3或许Azure上面，就会有一些问题，在这种场景下，假如用Alluxio，你只需用一套计划就能够解决一切的问题，不需求将不同的存储计划一个个地跟Iceberg进行适配，这其实在许多场景下是一件十分费事的工作。
**3.**许多公司的底层存储并不确保read-after-write strong consistent，那么你想要完成Iceberg的计划就十分困难，可是Alluxio能够避免这一点，你能够把这个文件写到Alluxio里边，Alluxio能够确保strong consistent的操作，你能够用Alluxio直接根据现在已有的 eventual consistent的体系来建立数据湖。
咱们下面来说一下，在已有的场景下，怎样将Iceberg的计划和Alluxio的计划进行集成。
为什么说集成需求比较当心，其实作为一个缓存层，咱们不是在一切场景下完全的支撑强一致性的，由于咱们的写入有许多种方法，第一种是MUST_CACHE，在这种方法下，咱们会把数据直接写入Alluxio，不写入底层的 HDFS集群或许S3集群。第二种方法叫THROUGH，一般不太关心写入的数据，后面要再被重复应用，所以不想把这个数据写回缓存层，直接写回底层的分布式存储。第三种是CACHE_THROUGH，便是一起写入Alluxio体系和底层的 S3或许HDFS。第四种方法是Eventual consistent的形式，写回Alluxio是strong consistent，但最后写回底层的存储，是一个Eventual consistent的形式。许多人会采用这种形式，由于比方说 object store s3的rename特别的昂贵，这种情况下，咱们引荐经过ASYNC_THROUGH的方法写入，但有时分这个方法，对不同的根据Iceberg的数据湖计划就会有一些不同的影响。
架构引荐
第一种架构比较简单，咱们拿 Spark和AWS举个比如，左面 Spark是在私有云的场景，右边Spark是在公有云的场景，在这两个场景里都一起会写入Alluxio集群。所以在这种场景下，读写这两条线都没有太大的问题。由于这一端的强一致性是在Alluxio这层维护的，所以数据对Iceberg的事务性支撑就能够得到十分好的控制。
第二个场景比较复杂，也是许多用户常用的一种形式。比方在私有云场景里，我是写回Alluxio里边的，但在公有云里边我不期望经过Alluxio写回，由于我现已在AWS里边Run EMR job，所以我期望直接写回S3就能够得到一个比较好的功用。
在这种场景下，当你写入数据的时分，咱们引荐的是用THROUGH和CACHE_THROUGH的形式写回去，这样就确保私有云这一端写回S3时能够保持强一致性。
就算Spark job在AWS上面运转时拉取Iceberg的表格，它也能够拉取到最新的表格，而不是说经过ASYNC_THROUGH的方法，有或许你写进去过了几分钟或许是几十秒，你才发现这个表格更新了，此时你没有办法去update Iceberg的表格，也就没有办法确保数据的一致性。像AWS这种体系，它不供给 push机制奉告更新，所以这种场景下咱们一般会有一个周期性的查看，查看AWS是否更新，在这种场景下，咱们引荐你在读Iceberg文件之前，总是进行元数据的同步操作，确保你每次拉取的数据都是最新的数据。
想要获取更多有趣有料的【活动信息】【技能文章】【大咖观念】，请关注[Alluxio智库]：
