湖加速指的是数据湖加速，指的是为数据湖存储提供适配支持、优化和缓存加速的中间层技术，以统一支持数据湖架构中的各种计算。那么为什么需要湖泊加速呢？数据湖如何实现“加速”？本文将从三个方面介绍湖加速背后的原因，分享阿里云在湖加速方面的实践经验和技术方案。在开源大数据领域，存储/计算分离已经成为共识和标准做法，数据湖架构成为大数据平台的首选。基于这种范式，大数据架构师需要考虑三件事：第一，选择什么样的存储系统作为数据湖（lakestorage）？二、计算和存储分离后，出现性能瓶颈，如何加速计算和优化（lakeacceleration）？第三，对于需要的计算场景，我们应该选择什么样的计算引擎（湖计算）？湖存储可以基于大家熟悉的HDFS，对象存储也可以选择公有云上的，比如阿里云OSS。在公有云上，基于对象存储构建数据湖是目前业界最主流的做法。这里我们重点关注第二个问题，结合阿里云上EMRJindoFS的优化实践，看看数据湖如何“加速”。湖加速在数据湖架构中，湖存储（HDFS、阿里云OSS）和湖计算（Spark、Presto）比较明确。那么什么是湖泊加速呢？你不妨搜索一下……（基本没有直接的答案）。Lake加速是阿里云EMR同学内部提出的。顾名思义，湖加速就是数据湖加速。用于缓存加速的中间层技术。这里比较早的社区解决方案应该是Alluxio，Hadoop社区有S3AGuard，AWS有EMRFS，都适配支持AWSS3，Snowflake在计算端有SSD缓存，Databricks有DBIO/DBFS，阿里云有EMRJindoFS，一般都可以归类为此类技术。那么为什么需要湖泊加速呢？这与数据湖架构的分层和相关技术的演进有很大关系。接下来，我们从三个方面的介绍中寻找答案。它们是：基础版，需要适配；标准版，需要缓存；高端版本，需要深度定制。JindoFS同时覆盖这三个层面，实现了数据湖加速场景的全覆盖。基础版：自适应对象存储基于Hadoop的大数据和以AWS上的EC2/S3为代表的云计算在发展初期更像是两个平行世界。EMR产品出现后，如何将大数据计算（最初主要是MapReduce）接入S3成为一个真正的技术命题。大数据要对接S3和OSS对象存储，首先要适配对象接口。Hadoop生态的开源大数据引擎，如Hive、Spark，过去主要支持HDFS，适配HadoopCompatibleFileSystem（HCFS）接口，同时支持其他存储系统。机器学习生态系统(Python)由POSIX接口和本地文件系统主导。TensorFlow等深度学习框架也支持直接使用HDFS接口。对象存储产品以主要开发语言提供RESTAPI和封装的SDK，但它们都具有对象存储语义。因此，要使用这些流行的计算框架，必须将它们适配并转换为HCFS接口或支持POSIX。这也是为什么随着云计算的普及，适配和支持云端的对象存储产品成为了Hadoop社区发展的热点，比如S3AFileSytem。阿里云EMR团队正在大力打造JindoFS，全面支持阿里云OSS，提供加速优化。如何高效适配，并不是在设计模式中加一层接口转换那么简单。要想做好，您需要了解这两个系统（对象存储和文件系统）背后的重要区别。让我们扩大一点：首先，大规模。对象存储提供海量低成本存储。与文件系统（如HDFS）相比，阿里云OSS被用户认为是可以无限扩展的。同时，随着各种BI技术和AI技术的流行和普及，挖掘数据的价值变得可行，用户倾向于在数据湖（阿里云OSS）中存储越来越多不同类型的数据，例如如图像和声音。、日志等。这在适配层面带来的挑战是需要处理比传统文件系统大得多的数据和文件。包含数千万个文件的超大目录并不少见，甚至包含大量小文件。面对这种目录，一般的适配操作都会失败，要么OOM，要么挂在那里，根本无法使用。JindoFS一路走来积累了很多经验。我们在内存占用和全并发方面深度优化了大目录的listing操作和du/count的统计操作。目前的效果是listing操作有一个大目录，里面有几千万个文件。比社区版快一倍，du/count快21%，整体性能更稳定可靠。二、文件与对象的映射关系。对象存储提供从键到blob对象的映射。这个key的命名空间是扁平的，不具备文件系统本身的层次性。因此，文件/目录的层次结构只能在适配层模拟。正是因为需要依赖模拟，而不是原生支持，所以一些关键的文件/目录操作代价高昂，最广为人知的就是rename。文件重命名或mv操作，在文件系统中，只需要将文件的inode移动到目录树的下一个位置，一个原子操作；但在对象存储中，往往受限于内部实现方式和提供的标准接口和适配器，一般需要先将对象复制到新位置，然后删除旧对象，使用两个独立的步骤和API调用。对目录的重命名操作比较复杂，涉及到目录下所有文件的重命名，每一个都是上述的copy+delete；如果目录层级很深，这个重命名操作还需要递归嵌套，涉及到的客户端调用数量巨大。对象的副本通常与其大小有关。在很多产品中还是比较慢的，可以说是雪上加霜。阿里云OSS在这方面做了很多优化，提供了FastCopy能力。JindoFS充分利用了这些优化支持，结合客户端并发，在百万大目录的重命名操作上比社区版快近3倍。第三，一致性。为了追求超大并发，很多对象存储产品提供了最终一致性（S3），而不是文件系统常见的强一致性语义。这样做的影响是，比如程序刚刚把10个文件写入了一个目录，但是去列表之后，可能只有部分文件是可见的。这不是性能问题，而是正确性问题。因此，为了在适配层满足大数据计算的需求，Hadoop社区在S3A适配上花了不少功夫来应对这个问题。AWS本身也提供了EMRFS。支持ConsistentView。阿里云OSS提供强一致性。基于这个特性，JindoFS得到了极大的简化，用户和计算框架无需担心类似的一致性和正确性问题。第四，原子性。对象存储本身没有目录概念，目录是通过适配层模拟出来的。对一个目录的操作转化为对该目录下所有子目录和文件对客户端的多次调用，所以即使每次对象调用操作都是原子的，对于用户来说，对这个目录的操作不可能是真正原子的。例如，删除目录时，任何一个子目录或文件的删除操作失败（包括重试），即使其他文件删除成功，整个目录删除操作仍然失败。在这种情况下该怎么办？通常只留下一个目录处于中间失败状态。在适配这些目录操作（重命名、复制、删除等）时，JindoFS结合阿里云OSS的扩展和优化支持，尽可能在客户端进行重试或回滚，可以很好的对接数据湖的各种计算，保证管道上下游之间的正确处理。第五，突破极限。对象存储产品独立演化发展，必然有自己独特的秘密。要想充分利用这个特性，可能需要突破HCFS抽象接口的限制。在这里，我们重点介绍ConcurrentMultiPartUpload(CMPU)，这是对象存储的一项高级功能。该特性允许程序以片段并发上传部分的方式高效地编写大对象。使用它有两个好处。一是可以按照并发甚至分布式的方式写一个大对象，实现高吞吐量，充分发挥对象存储的优势；另一种是先将所有部分写入暂存区，直到完成后，整个对象才会出现在目标位置。利用阿里云OSS的先进特性，JindoFS开发了MapReduce模型的JobCommitter，用于Hadoop、Spark等框架。实现机制是每个task先把计算结果按照part写到临时位置，然后jobcommitter再把这些resultobjects补全到最终位置，达到不用rename的效果。在Flinkfilesinkconnector的支持中，我们也将这个额外的接口暴露给了计算层，利用这个特性来支持Exactly-Once的语义。标准版：缓存加速数据湖架构对大数据计算的另一个影响是存储/计算分离。存储和计算分离使得存储和计算在架构上解耦。存储以大容量、低成本的规模提供，计算向弹性伸缩、丰富化、多样化发展，有利于整体专业化、分工化。大家把技术深化，客户价值也能最大化。然而，这种分离架构带来的一个重要问题是，在某些情况下，存储带宽的供应可能与存储带宽的计算需求不兼容。计算需要跨网络访问存储，数据局部性消失，访问带宽将受到整个网络的限制；更重要的是，在数据湖的概念下，多重计算，越来越多的计算需要同时访问数据，会争夺这个带宽，最终会导致带宽供需失衡。我们在很多实践中发现，同一个OSSbucket，Hive/Spark数仓需要做ETL，Presto需要交互分析，机器学习需要抽取训练数据。这在数据湖时代之前是不可想象的。那个时候，也许最多的就是MapReduce作业了。这些多样化的计算对数据访问性能和吞吐量有着相同甚至更高的要求。驻留集群希望完成更多的计算；可弹性伸缩的集群希望尽快完成作业，释放大量节点以节约成本；像Presto这样的交互式分析业务方希望越快越好，稳定性是亚秒级的，返回不受任何其他计算的影响；而GPU训练程序期望与数据完全本地化相同的极端吞吐量。如何打破这种局面？无限地提高存储端的吞吐量是不现实的，因为它一般只限于计算集群之间的网络。为了有效保障富计算的存储带宽需求，业界早就给出了计算侧缓存的答案。Alluxio一直在这样做。JindoFS的核心定位是数据湖加速层，其思路也是一样的。下面是它在缓存场景的架构图。JindoFS在适配和优化阿里云OSS的同时，提供分布式缓存和计算加速。刚刚写入和重复访问的数据可以缓存在本地设备上，包括我们专门优化的HDD、SSD和内存。这种缓存加速对用户是透明的，不需要额外的计算感知和作业修改。使用时，只需要打开一个基于OSS适配的配置开关，即可开启数据缓存。通过我们在适配方面的优化，与业界开源的缓存方案相比，我们在多种计算场景下都有明显的性能领先。基于磁盘缓存，得益于我们更好地平衡多磁盘负载和高效细粒度的缓存块管理，我们使用TPC-DS1TB进行对比测试，SparkSQL性能提升27%；Presto明显领先93%；在HiveETL场景下性能方面，性能领先42%。JindoFS的FUSE支持完全原生代码开发，没有JVM的负担。基于SSD缓存，我们使用TensorFlow程序通过JindoFuse读取缓存在JindoFS上的OSS数据进行训练，比开源方案快40%。在数据湖架构下，在计算侧部署缓存设备引入缓存可以实现计算加速的好处，计算效率的提升意味着更少的弹性计算资源使用和成本支出，但另一方面不可否认的是它还将为用户带来好处。以增加缓存成本和负担。如何衡量成本和收益，决定是否引入缓存，需要结合实际计算场景进行测试和评估，不能一概而论。高配版：深度定制，文件元数据自主管理我们优化了JindoFS上的OSS适配，最大限度地发挥Jindo分布式缓存的性能，可以满足大部分的大规模分析和机器学习训练计算。现有JindoFS的广泛部署和使用表明，无论是Hive/Spark/Impala等数据仓库操作，Presto交互分析，还是TensorFlow训练，我们都可以利用阿里云在计算端缓存自定义模型，实现各种计算吞吐量有效访问OSS数据湖的要求。但故事还没有结束。数据湖的架构决定了计算的开放性和多样性。以上计算可能是最重要的，但不是全部。JindoFS希望在设计之初就实现一套部署，即涵盖各种主要场景。一个典型的情况是，很多用户希望JindoFS能够完全替代HDFS，而不仅仅是Hive/Spark就足够了，用户不希望在数据湖架构下混用其他存储系统。梳理一下，大概有以下几种情况需要我们进一步思考。首先，在上面讨论对象存储适配的时候，我们提到了一些文件/目录操作的原子性需求是无法从本质上解决的，比如文件重命名、目录复制、重命名和删除。要彻底解决这些问题，充分满足文件系统的语义，根本上还是需要自己实现文件元数据管理，比如HDFSNameNode。其次，HDFS有很多更高级的特性和接口，比如支持truncate、append、concat、hsync、snapshot和Xattributes。就像HBase依赖hsync/snapshot，Flink依赖truncate。数据湖架构的开放性也决定了会接入更多的引擎，对这些高级接口的需求也会更多。第三，HDFS的重度用户希望能够迁移到云端，或者在存储方案的选择上进行微调。原有基于HDFS的应用、运维和治理仍然可以使用。在功能上，它提供了Xattributes支持、文件权限支持、Ranger集成支持，甚至还有auditlog支持；性能方面，预计不低于HDFS，最好优于HDFS，无需调优NameNode。为了享受数据湖架构带来的各种好处，如何帮助这类用户升级基于OSS的架构？第四，为突破S3等对象存储产品的局限性，大数据行业也在针对数据湖深度定制新的数据存储格式，如Delta、Hudi、Iceberg。如何支持和有效优化这些格式需要进一步考虑。基于这些因素，我们进一步研发推出了JindoFS块模式，在OSS对象存储的基础上，为大数据计算深度定制，依然提供标准的HCFS接口，因为我们坚信，即使我们也拿深度定制路线，沿用现有标准，更容易推广和使用用户和计算引擎的使用习惯，也更符合湖加速的定位和使命。JindoFS块模式与HDFS相比，不同的是它采用了云原生架构。依托云平台，我们做了很多简化，使整个系统具有弹性、轻量、易运维等特点和优势。如上图，是JindoFSblock模式的系统架构，整体复用了JindoFS的缓存系统。该模式下，文件数据以块的形式存储在OSS上，保证可靠性和可用性；同时，借助本地集群的缓存备份，可以实现缓存加速。文件元数据异步写入阿里云OTS数据库，防止本地误操作，同时方便JindoFS集群重构和恢复；元数据在正常读写时存储在本地RocksDB中，内存用作LRU缓存，因此支持的文件数在亿级别；数据服务的文件/目录级细粒度锁实现，JindoFS在大规模高并发作业高峰时比HDFS更稳定，吞吐量也更高。我们使用HDFSNNBench进行并发测试。对于最关键的open和create操作，JindoFS的IOPS比HDFS高出60%。在千万级大目录测试中，文件列表操作比HDFS快130%；文件统计du/count操作比HDFS快1倍。借助分布式Raft协议，JindoFS支持HA和多命名空间，整体部署和维护比HDFS简单很多。在IO吞吐量方面，除了本地磁盘，OSS带宽也可以同时用于读取。因此，在使用DFSIO的相同集群配置下，JindoFS的读取吞吐量比HDFS快33%。JindoFS在整体湖加速方案中进一步支持块模式，这为我们拓宽数据湖的使用场景，支持更多的引擎带来了更多的想象空间。目前，我们已经支持了很多客户使用HBase。为了受益于这种存储/计算分离架构，使用本地管理的存储设备进行缓存加速，我们也在探索对接更多的开源引擎。比如像Kafka、Kudu甚至是OLAP新贵ClickHouse，这些引擎能不能专注于他们的场景，把他们从处理坏盘和如何扩容中完全解放出来。一些原本坚持使用HDFS的客户，也被块模式的轻运维、灵活、低成本、高性能等优势所吸引，也通过这种方式转移到了数据湖架构上。与OSS适配支持和缓存模式一样，新的JindoFS模式依然提供完全兼容的HCFS和FUSE支持，大量数据湖引擎的使用不需要额外的负担。结语至此，我们有了一个回顾和总结。基于数据湖的大数据平台架构升级是业界的一个重要趋势。数据湖架构包括湖存储、湖加速和湖分析。在阿里云上，我们通过JindoFS为各种场景提供多种数据湖加速方案。阿里云的DataLakeFormation，支持数据湖管理，可以全面支持数据湖。【本文为专栏作者《阿里巴巴官方技术》原创稿件，转载请联系原作者】点此查看作者更多好文
