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文件之前，总是进行元数据的同步操作，保障你每次拉取的数据都是最新的数据。