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

对象存储产品是独立演化发展的，少不了会有自己的一些独门秘籍，这种特性要充分利用起来可能就得突破HCFS抽象接口的限制。这里重点谈下对象存储的高级特性Concurrent MultiPartUpload (CMPU)，该特性允许程序按照分片并发上传part的方式高效写入一个大对象，使用起来有两个好处，一个是可以按照并发甚至是分布式的方式写入一个大对象，实现高吞吐，充分发挥对象存储的优势;另外一个是，所有parts都是先写入到一个staging区域的，直到complete的时候整个对象才在目标位置出现。利用阿里云OSS这个高级特性，JindoFS开发了一个针对MapReduce模型的Job Committer，用于Hadoop，Spark 和类似框架，其实现机制是各个任务先将计算结果按照part写入到临时位置，然后作业commit的时候再complete这些结果对象到最终位置，实现无须rename的效果。我们在Flinkfile sink connector支持上也同样往计算层透出这方面的额外接口，利用这个特性支持了Exactly-Once的语义。

标配版：缓存加速

数据湖架构对大数据计算的另外一个影响是存/算分离。存储和计算分离，使得存储和计算在架构上解耦，存储朝着大容量低成本规模化供应，计算则向着弹性伸缩，丰富性和多样化向前发展，在整体上有利于专业化分工和大家把技术做深，客户价值也可以实现最大化。但是这种分离架构带来一个重要问题就是，存储带宽的供应在一些情况下可能会跟计算对存储带宽的需求不相适应。计算要跨网络访问存储，数据本地性消失，访问带宽整体上会受限于这个网络;更重要的是，在数据湖理念下，多种计算，越来越多的计算要同时访问数据，会竞争这个带宽，最终使得带宽供需失衡。我们在大量的实践中发现，同一个OSS bucket，Hive/Spark数仓要进行ETL，Presto要交互式分析，机器学习也要抽取训练数据，这个在数据湖时代之前不可想象，那个时候也许最多的就是MapReduce作业了。这些多样化的计算，对数据访问性能和吞吐的需求却不遑多让甚至是变本加厉。常驻的集群希望完成更多的计算;弹性伸缩的集群则希望尽快完成作业，把大量节点给释放掉节省成本;像Presto这种交互式分析业务方希望是越快越好，稳定亚秒级返回不受任何其他计算影响;而GPU训练程序则是期望数据完全本地化一样的极大吞吐。像这种局面该如何破呢?无限地增加存储侧的吞吐是不现实的，因为整体上受限于和计算集群之间的网络。有效地保证丰富的计算对存储带宽的需求，业界早已给出的答案是计算侧的缓存。Alluxio一直在做这方面的事情，JindoFS核心定位是数据湖加速层，其思路也同出一辙。下面是它在缓存场景上的架构图。

JindoFS在对阿里云OSS适配优化的同时，提供分布式缓存和计算加速，刚刚写出去的和重复访问的数据可以缓存在本地设备上，包括HDD，SSD和内存，我们都分别专门优化过。这种缓存加速是对用户透明的，本身并不需要计算额外的感知和作业修改，在使用上只需要在OSS适配的基础上打开一个配置开关，开启数据缓存。叠加我们在适配上的优化，跟业界某开源缓存方案相比，我们在多个计算场景上都具有显著的性能领先优势。基于磁盘缓存，受益于我们能够更好地balance多块磁盘负载和高效精细化的缓存块管理，我们用TPC-DS 1TB进行对比测试，SparkSQL性能快27%;Presto大幅领先93%;在HiveETL场景上，性能领先42%。JindoFS 的 FUSE支持完全采用 native 代码开发而没有 JVM 的负担，基于SSD缓存，我们用TensorFlow程序通过JindoFuse来读取JindoFS上缓存的OSS数据来做训练，相较该开源方案性能快40%。

在数据湖架构下在计算侧部署缓存设备引入缓存，可以实现计算加速的好处，计算效率的提升则意味着更少的弹性计算资源使用和成本支出，但另一方面毋庸讳言也会给用户带来额外的缓存成本和负担。如何衡量这个成本和收益，确定是否引入缓存，需要结合实际的计算场景进行测试评估，不能一概而论。

高配版：深度定制，自己管理文件元数据

我们在JindoFS上优化好OSS适配，把Jindo分布式缓存性能做到效能最大化，能满足绝大多数大规模分析和机器学习训练这些计算。现有的JindoFS大量部署和使用表明，无论Hive/Spark/Impala这种数仓作业，Presto交互式分析，还是TensorFlow训练，我们都可以在计算侧通过使用阿里云缓存定制机型，来达到多种计算高效访问OSS数据湖的吞吐要求。可是故事并没有完，数据湖的架构决定了计算上的开放性和更加多样性，上面这些计算可能是最主要的，但并不是全部，JindoFS在设计之初就希望实现一套部署，即能覆盖各种主要场景。一个典型情况是，有不少用户希望JindoFS能够完全替代HDFS，而不只是Hive/Spark够用就可以了，用户也不希望在数据湖架构下还要混合使用其他存储系统。整理一下大概有下面几种情况需要我们进一步考虑。

第一、上面讨论对象存储适配的时候我们提到，一些文件/目录操作的原子性需求在本质上是解决不了的，比如文件的rename，目录的copy，rename和delete。彻底解决这些问题，完全满足文件系统语义，根本上需要自己实现文件元数据管理，像HDFS NameNode那样。

第二、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。如何兼容支持和有力优化这类格式，也需要进一步考虑。

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

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