共计 6894 个字符，预计需要花费 18 分钟才能阅读完成。
简介： 湖减速即为数据湖减速，是指在数据湖架构中，为了对立反对各种计算，对数据湖存储提供适配反对，进行优化和缓存减速的中间层技术。那么为什么须要湖减速？数据湖如何实现“减速”？本文将从三个方面来介绍湖减速背地的起因，分享阿里云在湖减速上的实践经验和技术计划。
在开源大数据畛域，存储 / 计算拆散曾经成为共识和规范做法，数据湖架构成为大数据平台的首要抉择。基于这一范式，大数据架构师须要思考三件事件：
- 第一，抉择什么样的存储系统做数据湖 (湖存储)？
- 第二，计算和存储拆散后，呈现了性能瓶颈，计算如何减速和优化 (湖减速)？
- 第三，针对须要的计算场景，抉择什么样的计算引擎 (湖计算)？
湖存储能够基于咱们相熟的 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 上下游之间保障正确处理。
第五，冲破限度。
对象存储产品是独立演变倒退的，少不了会有本人的一些独门秘籍，这种个性要充分利用起来可能就得冲破 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。如何兼容反对和无力优化这类格局，也须要进一步思考。
基于这些因素，咱们进一步开发和推出 JindoFS block 模式，在 OSS 对象存储的根底上针对大数据计算进行深度定制，依然提供规范的 HCFS 接口，因为咱们深信，即便同样走深度定制路线，遵循现有规范与应用习惯对用户和计算引擎来说更加容易推广和应用，也更加合乎湖减速的定位和使命。JindoFS block 模式对标 HDFS，不同的是采取云原生的架构，依靠云平台咱们做了大量简化，使得整个零碎具备弹性，轻量和易于运维的特点和劣势。
如上图示，是 JindoFS 在 block 模式下的零碎架构，整体上重用了 JindoFS 缓存零碎。在这种模式下，文件数据是分块寄存在 OSS 上，保障牢靠和可用；同时借助于本地集群上的缓存备份，能够实现缓存减速。文件元数据异步写入到阿里云 OTS 数据库避免本地误操作，同时不便 JindoFS 集群重建复原；元数据在失常读写时走本地 RocksDB，内存做 LRU 缓存，因而撑持的文件数在亿级；联合元数据服务的文件 / 目录级别细粒度锁实现，JindoFS 在大规模高并发作业顶峰的时候体现比 HDFS 更稳固，吞吐也更高。咱们用 HDFS NNBench 做并发测试，对于最要害的 open 和 create 操作，JindoFS 的 IOPS 比 HDFS 高 60%。在千万级超大目录测试上，文件 listing 操作比 HDFS 快 130%；文件统计 du/count 操作比 HDFS 快 1X。借助于分布式 Raft 协定，JindoFS 反对 HA 和多 namespaces，整体上部署和保护比 HDFS 简化太多。在 IO 吞吐上，因为除了本地磁盘，还能够同时应用 OSS 带宽来读，因而在同样的集群配置下用 DFSIO 实测下来，读吞吐 JindoFS 比 HDFS 快 33%。
JindoFS 在湖减速整体解决方案上进一步反对 block 模式，为咱们拓宽数据湖应用场景和反对更多的引擎带来更大的设想空间。目前咱们曾经反对不少客户应用 HBase，为了受害于这种存 / 算拆散的架构同时借助于本地治理的存储设备进行缓存减速，咱们也在摸索将更多的开源引擎对接上来。比方像 Kafka，Kudu 甚至 OLAP 新贵 ClickHouse，能不能让这些引擎专一在它们的场景上，将它们从坏盘解决和如何伸缩这类事件上彻底解放出来。本来一些保持应用 HDFS 的客户也被 block 模式这种轻运维，有弹性，低成本和高性能的劣势吸引，通过这种形式也转到数据湖架构上来。如同对 OSS 的适配反对和缓存模式，JindoFS 这种新模式依然提供齐全兼容的 HCFS 和 FUSE 反对，大量的数据湖引擎在应用上并不需要减少额定的累赘。
总结
行文至此，咱们做个回顾和总结。基于数据湖对大数据平台进行架构降级是业界显著趋势，数据湖架构包含湖存储、湖减速和湖剖析，在阿里云上咱们通过 JindoFS 针对各种场景提供多种数据湖减速解决方案。阿里云推出的专门反对数据湖治理的 Data Lake Formation，可全面反对数据湖。
咱们联合云上数年的实践经验，积淀了 EMR JindoFS 在湖减速上的各种场景、挑战以及对应的技术计划。咱们优化的思路有哪些，相较现有的社区计划，JindoFS 有哪些劣势，心愿通过本文让同学们对阿里云上的数据湖计划有更加全面的意识，同时心愿阿里云数据湖 JindoFS/OSS + DataLake Formation + EMR 能为同学们的大数据探索之旅带来更多价值。
