数据湖架构，为什么需要“湖加速”？

 湖加速即为数据湖加速，是指在数据湖架构中，为了统一支持各种计算，对数据湖存储提供适配支持，进行优化和缓存加速的中间层技术。那么为什么需要湖加速?数据湖如何实现“加速”?本文将从三个方面来介绍湖加速背后的原因，分享阿里云在湖加速上的实践经验和技术方案。

在开源大数据领域，存储/计算分离已经成为共识和标准做法，数据湖架构成为大数据平台的首要选择。基于这一范式，大数据架构师需要考虑三件事情：

第一，选择什么样的存储系统做数据湖(湖存储)? 第二，计算和存储分离后，出现了性能瓶颈，计算如何加速和优化(湖加速)? 第三，针对需要的计算场景，选择什么样的计算引擎(湖计算)? 

湖存储可以基于我们熟悉的HDFS，在公共云上也可以选择对象存储，例如阿里云OSS。在公共云上，基于对象存储构建数据湖是目前业界最主流的做法，我们这里重点探讨第二个问题，结合阿里云上的EMR JindoFS优化和实践，看看数据湖怎么玩“加速”。

湖加速

在数据湖架构里，湖存储(HDFS，阿里云OSS)和湖计算(Spark，Presto)都比较清楚。那么什么是湖加速?大家不妨搜索一下…(基本没有直接的答案)。湖加速是阿里云EMR同学在内部提出来的，顾名思义，湖加速即为数据湖加速，是指在数据湖架构中，为了统一支持各种计算，对数据湖存储提供适配支持，进行优化和缓存加速的中间层技术。这里面出现较早的社区方案应该是Alluxio，Hadoop社区有S3A Guard，AWS有EMRFS，都适配和支持AWS S3，Snowflake在计算侧有SSD缓存，Databricks有DBIO/DBFS，阿里云有EMR JindoFS，大体都可以归为此类技术。

那么为什么需要湖加速呢?这和数据湖架构分层，以及相关技术演进具有很大关系。接下来，我们从三个方面的介绍来寻找答案。分别是：基础版，要适配;标配版，做缓存;高配版，深度定制。JindoFS同时涵盖这三个层次，实现数据湖加速场景全覆盖。

基础版：适配对象存储

以Hadoop为基础的大数据和在AWS上以EC2/S3为代表的云计算，在它们发展的早期，更像是在平行的两个世界。等到EMR产品出现后，怎么让大数据计算(最初主要是MapReduce)对接S3，才成为一个真实的技术命题。对接S3、OSS对象存储，大数据首先就要适配对象接口。Hadoop生态的开源大数据引擎，比如Hive和Spark，过去主要是支持HDFS，以Hadoop Compatible File System(HCFS)接口适配、并支持其他存储系统。机器学习生态(Python)以POSIX接口和本地文件系统为主，像TensorFlow这种深度学习框架当然也支持直接使用HDFS 接口。对象存储产品提供REST API，在主要开发语言上提供封装好的SDK，但都是对象存储语义的，因此上述这些流行的计算框架要用，必须加以适配，转换成HCFS接口或者支持POSIX。这也是为什么随着云计算的流行，适配和支持云上对象存储产品成为Hadoop社区开发的一个热点，比如S3A FileSytem。阿里云EMR团队则大力打造JindoFS，全面支持阿里云OSS并提供加速优化。如何高效地适配，并不是设计模式上增加一层接口转换那么简单，做好的话需要理解两种系统(对象存储和文件系统)背后的重要差异。我们稍微展开一下：

第一，海量规模。

对象存储提供海量低成本存储，相比文件系统(比如HDFS)，阿里云OSS更被用户认为可无限扩展。同时随着各种BI技术和AI技术的流行和普及，挖掘数据的价值变得切实可行，用户便倾向于往数据湖(阿里云OSS)储存越来越多不同类型的数据，如图像、语音、日志等等。这在适配层面带来的挑战就是，需要处理比传统文件系统要大许多的数据量和文件数量。千万级文件数的超大目录屡见不鲜，甚至包含大量的小文件，面对这种目录，一般的适配操作就失灵了，不是OOM就是hang在那儿，根本就不可用。JindoFS一路走来积累了很多经验，我们对大目录的listing操作和du/count这种统计操作从内存使用和充分并发进行了深度优化，目前达到的效果是，千万文件数超大目录，listing操作比社区版本快1倍，du/count快21%，整体表现更为稳定可靠。

第二，文件和对象的映射关系。

对象存储提供key到blob对象的映射，这个key的名字空间是扁平的，本身并不具备文件系统那样的层次性，因此只能在适配层模拟文件/目录这种层次结构。正是因为要靠模拟，而不是原生支持，一些关键的文件/目录操作代价昂贵，这里面最为知名的就是rename了。文件rename或者mv操作，在文件系统里面只是需要把该文件的inode在目录树上挪动下位置即可，一个原子操作;但是在对象存储上，往往受限于内部的实现方式和提供出来的标准接口，适配器一般需要先copy该对象到新位置，然后再把老对象delete掉，用两个独立的步骤和API调用。对目录进行rename操作则更为复杂，涉及到该目录下的所有文件的rename，而每一个都是上述的copy+delete;如果目录层次很深，这个rename操作还需要递归嵌套，涉及到数量巨大的客户端调用次数。对象的copy通常跟它的size相关，在很多产品上还是个慢活，可以说是雪上加霜。阿里云OSS在这方面做了很多优化，提供Fast Copy能力，JindoFS充分利用这些优化支持，结合客户端并发，在百万级大目录rename操作上，性能比社区版本接近快3X。

第三，一致性。

为了追求超大并发，不少对象存储产品提供的是最终一致性(S3)，而不是文件系统常见的强一致性语义。这带来的影响就是，举个栗子，程序明明往一个目录里面刚刚写好了10个文件，结果随后去list，可能只是部分文件可见。这个不是性能问题，而是正确性了，因此在适配层为了满足大数据计算的需求，Hadoop社区在S3A适配上花了很大力气处理应对这种问题，AWS自己也类似提供了EMRFS，支持ConsistentView。阿里云OSS提供了强一致性，JindoFS基于这一特性大大简化，用户和计算框架使用起来也无须担心类似的一致性和正确性问题。

第四，原子性。

对象存储自身没有目录概念，目录是通过适配层模拟出来的。对一个目录的操作就转化为对该目录下所有子目录和文件的客户端多次调用操作，因此即使是每次对象调用操作是原子的，但对于用户来说，对这个目录的操作并不能真正做到原子性。举个例子，删除目录，对其中任何一个子目录或文件的删除操作失败(包含重试)，哪怕其他文件删除都成功了，这个目录删除操作整体上还是失败。这种情况下该怎么办?通常只能留下一个处于中间失败状态的目录。JindoFS在适配这些目录操作(rename，copy，delete and etc)的时候，结合阿里云 OSS 的扩展和优化支持，在客户端尽可能重试或者回滚，能够很好地衔接数据湖各种计算，在pipeline 上下游之间保证正确处理。

第五，突破限制。

（编辑：应用网_阳江站长网）

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