共计 5816 个字符，预计需要花费 15 分钟才能阅读完成。
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 是一种开放式的 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，大家如果感兴趣能够看一下。
首先咱们发现，当初构筑一个大数据计划，是心愿失去一个残缺的计划，而不是只用一个 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 文件之前，总是进行元数据的同步操作，保障你每次拉取的数据都是最新的数据。
