阿里云EMR数据湖文件系统: 面向开源和云打造下一代 HDFS

2022-11-01 01:11

前言

最近，阿里云EMR重磅推出新版数据湖Datalake，100%兼容社区大数据开源组件，具备极强的弹性能力，支持数据湖构建DLF、对象存储OSS和OSS-HDFS，支持 Delta Lake、Hudi、Iceberg 三种湖格式。结合阿里云DataWorks，可以为用户提供从入湖、建模、开发、调度、治理、安全等全链路数据湖开发治理能力，帮助客户提升数据的应用效率。同时，也是满分通过中国信通院评测的数据湖产品。

众所周知，EMR的数据湖文件存储、加速等依托数据湖文件系统JindoFS来实现的。本文主要分享下，阿里云EMR数据湖文件系统JindoFS:是如何面向开源和云打造下一代 HDFS的。

当前问题与挑战

了解数据湖文件系统JindoFS (后文简称：JindoFS）的同学可能知道它的一体两面，cache 模式和 block 模式，block 模式提供自己的文件元数据服务，解决对象存储不支持文件、目录语义的问题，同时重用了 cache 模式的缓存服务引擎，支持数据访问加速，整体上大幅优化了用户使用 OSS 的体验。JindoFS 一个系统两个模式部署使用简单，简单到可以退化成客户端模式直接读写 OSS，用户根据场景切换非常方便，目前已成为业内大数据和 AI 场景使用阿里云 OSS 最好的访问方式，除了现有阿里云 EMR 的客户，在阿里云上和 IDC 也有大量的用户在使用。作为 JindoFS 的系统核心，block 模式在使用过程中我们也积攒了不少经验教训，同时伴随存/算分离的深入人心和数据湖架构的流行，新的问题和挑战也在出现，主要表现在以下几个方面。

原生支持文件、目录语义还不够，开源大数据领域常用的 HDFS 能力成为刚需。Block 模式提供了文件元数据管理，解决了 HDFS 重度用户使用 OSS 的痛点，同时这部分用户对 HDFS 重要功能也有越来越多的期待，这样迁移过来的时候可以继续使用原来在 HDFS 上的投入和资产。因此 JindoFS 开发了大量的 HDFS 功能，比如数据加密，Ranger 鉴权，和日志审计。
存储和缓存做成一套系统对中小用户确实很友好，但设计上很难满足大规模部署和更加碎片化的计算场景。JindoFS 在存储部分表现得越来越像 HDFS，越来越复杂；在缓存部分涌现的需求主要是在更多的计算场景支持更好的策略来做数据访问加速，Hadoop 不再是唯一。前者要求存储功能强大和完善，满足大规模部署；后者要求保持存储功能兼容和不变，在业务透明的情况下选择各种缓存策略进行加速。这两部分功能其实是正交的，co-design 做在一起确实对文件读写更加高效，只需要访问 JindoFS master 一次，不需要往分开的两个系统跑两趟分别拿文件元信息和缓存信息。
半托管部署性能最好，云原生和跨产品访问的诉求日益迫切。原来 Hadoop 平台比较强势，大数据上云本质上就是把线下的 Hadoop 一整套搬到云上来，现在则不一样，阿里云上有非常丰富的计算产品支持，大数据上云不再只是上 Hadoop，因此 JindoFS 除了半托管部署，我们需要支持全托管服务化，构建统一的数据湖存储，方便更多的计算产品在存储方案上拉通对齐。所谓数据湖架构，就是存储统一用一套，支持计算开放百家争鸣。

为了解决这些问题和应对挑战，我们首先对数据湖文件系统 JindoFS 做了架构升级，将两个模式加以拆分，一分为二，JindoFS 存储系统和 JindoData 加速系统，新的 JindoFS 专注打造下一代数据湖存储系统，缓存加速的功能则交给 JindoData 加速系统，两者松耦合同时也紧密协作。新的 JindoFS 将 HDFS 兼容和功能对齐作为核心目标，把 HDFS 重度用户和IDC用户的上云平迁作为核心考虑要素，并着重解决云原生数据湖场景跨产品打通访问的痛点。目前新版本 JindoFS 已经完成服务化部署嵌入到 OSS 产品，推出全托管 OSS-HDFS 服务，并上线开服使用。关于 JindoFS 我们会有多篇文章从多个方面对它展开介绍，本文着重把它和开源 HDFS 加以对比，系统阐述我们为什么把 JindoFS 打造成为 HDFS，而且是云时代更好的 HDFS。

解决方案：将数据湖文件系统JindoFS 打造成为HDFS

一、JindoFS 和 HDFS 系统对比分析

首先，我们来看下 JindoFS 的系统架构，如下图示。

整个系统利用阿里云 OSS 云产品构建，除了 OSS，主要包括元数据服务 NamespaceService 和 JindoFS 客户端，非常简洁。我们把它和开源 HDFS 做个对比，HDFS 架构如下：

作为对比，我们看到 JindoFS 和 HDFS 在系统整体上还是比较类似的，除了数据存储不一样，都含有一个核心的元数据服务。JindoFS 之所以也采取了这种方式，关键考虑就是要跟 HDFS 对齐，保证元数据管理上的强一致性和严格事务语义支持，缺乏中心化服务这个角色，很多存储功能难以单纯在客户端协调实现，甚至需要依赖分布式事务保证严格语义，过于复杂。另一方面，受益于云原生设计理念和云平台产品支持，JindoFS 在架构上比 HDFS 做了大幅简化，去除了 DataNode 节点，JindoFS 只有客户端和元数据服务。在部署和使用上简便了很多，在许多个 Worker 机器上只需部署客户端就可以了。

在数据存储上，JindoFS 使用的阿里云 OSS 和 DataNode 一样使用数据的冗余机制，保证了数据的安全性，高可用性。区别在于阿里云 OSS 帮助我们解决了副本复制、弹性、线性扩展和运维等问题。而 DataNode 服务需要人工维护，处理坏盘坏节点，处理节点 Decomission 相对复杂，对技术人员要求较高，操作不当容易导致数据丢失风险，在使用体验上经常让人头痛不已。

二、元数据服务

HDFS NameNode 的元数据全量放置在内存当中提供服务，元数据持久化包含 NameNode 保存的 FsImage，和3个 JournlaNode 保存的 EditLog。为了实现服务高可用，需要2个 Zkfc 服务对 NameNode 进行探活，并用3个 Zookeeper 节点进行服务选主。整体架构看起来相对复杂，运维成本也高很多。

JindoFS 元数据服务的部署模式相对简单很多，只需1个 Leader 节点和2个 Follower 节点。目前默认的元数据存储方式，采用了 Raft 协议+RocksDB 存储引擎的组合方式。利用 Raft 实现3个节点之间的元数据复制，保障了文件元数据的安全性。三个节点由1个 Leader 和2个 Follower 构成。Leader 节点主要提供服务。在 Leader 节点出现问题时，会立马切换到另外一个 Follower 节点担任 Leader 角色。这个操作是毫秒级的，用户基本无感知。在未来，JindoFS 还将探索跨集群、跨AZ的元数据复制。

JindoFS 的 MetaService 是系统的核心，它负责存储文件系统整个目录树的元数据，并服务于 API 调用过来的元数据查询、修改请求。系统中包含了多了 MetaWorker 用于处理一些异步任务，比如元数据分析统计、归档任务处理、异步删除等等。MetaService 负责调度和分配这些任务给多个 MetaWorker ，从而分摊 MetaService 的压力。目前JindoFS使用的元数据存储默认为 RocksDB+Raft 的方式。我们定义并抽象了一层 MetaStore 接口，后面我们还将探索将元数据存储放在 OTS、ArkDB、TiKV 等其它新型的存储引擎上。

作为比较， HDFS 的 NameNode 负责存储整个系统元数据。它的数据只支持保存在本地磁盘，序列化的方式存储在 FsImage 文件上，真正提供服务的是全量 load 到内存中的数据。受限于内存大小，它能承载的文件数有限，实践中最大很难超过4亿。它只支持2个 NameNode ，虽然社区最新版支持多个 Standby 节点，但是会给 DataNode blockReport 造成更大压力。JindoFS 支持2个 Follower 节点和多个 Learner 节点，增加的 Learner 节点不会给集群带来额外负担。

使用 RocksDB 存储引擎可以解决元数据规模问题。文件元数据规模，一直是文件系统的难题之一。HDFS NameNode 将所有文件元数据加载到内存的方式，极大限制了其所能支持的文件数。一般认为，HDFS NameNode 所能支撑的文件元数据在4亿左右，即使增加更多的内存硬件，也难以支撑更大规模。JindoFS 的元数据存储，采用了内存+磁盘的组合方式，并且极大提高了元数据存储规模的上限。RocksDB 基于 LSM 数据结构，写入性能出众，而查询性能相对一般，尤其是对list目录操作涉及的 Range Query。JindoFS 采用了精心设计的内存 Cache 层，大幅提高了查询性能，在查询性能上实现超越 HDFS。

我们还对写入性能进行精心优化。RocksDB 的写入性能出众，尤其是当采取 batch 写入之后，我们发现写入瓶颈并没有发生在 RocksDB 以及磁盘上，而是在于内存互斥锁。NameNode 采取全局一把读写锁的方式相对简单，虽然读性能不受影响，但是写入受互斥锁的影响，存在瓶颈。JindoFS 使用了细粒度锁的方式，将写锁细化到子目录（文件）上，这样在同时写入多个不同的文件时，并不会产生互斥，提高了写入并发。

经测试，JindoFS 服务单个 Bucket 在存储达到100亿文件数时，依然能保持在峰值性能的90%以上，并且持续稳定。

10亿文件数性能测试

NNBench测试

测试环境使用core节点 8 * ecs.g6e.8xlarge 我们使用8台32core的机器，目的是可以加大同时启动的Mapper个数，使得Mapper任务可以在同一时刻执行，从而测试出元数据服务的性能。结果如下：

从测试结果可以看出，JindoFS在元数据创建、查询两个场景下的性能不输于HDFS。

OSS 除了存储 JindoFS 文件 Block 之外，JindoFS 的元数据服务可以充分利用 OSS 的海量存储空间，来增强 JindoFS 的元数据能力。首先，JindoFS 的 auditlog 是存储在 OSS 上的，避免了本地写入 auditlog 造成额外的 IO 压力。JindoFS 利用 OSS 存储任务清单，所有的 MetaWorker 节点从 OSS 获取任务清单，避免直连了 MetaService。MetaWork可以处理分析统计、块清理、归档任务等异步任务。

三、元数据统计分析

上文中提到，JindoFS 系统中包含了多了 MetaWorker 用于处理一些异步任务，其中一个关键人物是对元数据进行统计分析。

我们知道，HDFS对元数据进行统计分析，最常用的是用 du/count 命令发送到 NameNode，由NameNode在内存中计算得到目录树、文件数、文件大小统计结果。如果要查询更深子目录的分布，还要进行多次的查询操作，使用起来相对比较繁琐。如果对一个超大目录进行统计，因为是内存中临时计算，往往还要拿读锁比较长的时间，导致服务无法处理写请求。

JindoFS 将元数据统计分析任务下放到 MetaWorker，由 MetaWorker 进行处理，因此降低了 MetaService 的压力。JindoFS 采用全量 + 增量的计算方式，既保证了高效的计算，也保证了数据的实时准确性。JindoFS 除了提供基本的 du/count 支持，还支持额外的命令查询一个目录下所有文件的大小分布情况，可以直观地看出大文件、小文件的占比。对于 ETL 作业可以提供参考，及时地对小文件进行合并，大文件进行拆解，优化作业执行效率。JindoFS还计划支持文件访问的热度统计，方便用户直观地看到文件的冷热情况，可以及时地对冷文件进行归档处理。

du/count 性能测试

测试方式上，我们分别往 JindoFS 和 HDFS写入1亿个文件，文件的目录层次模拟一个普通用户常用的场景。主要的文件集中在/user和/hive/warehouse等目录下。然后对根目录执行一次 count 命令，然后统计耗时。测试结果如下：

从测试结果中我们可以看出，JindoFS 由于采用了预计算和全量+增量的策略，极大地提高了 du/count 的查询速度。而 HDFS 一次 count 命令需要花费较长时间，而这段时间将很大地影响到正常的作业。

四、数据存储

JindoFS 的文件组织方式是，一个文件会切分成变长的 Block，Block 数据存储在 OSS 上。OSS（Object Storage Service）是阿里云提供的海量、安全、低成本、高持久的云存储服务，单个存储空间的容量不限制。OSS 底层将文件按 Key 进行打散，可以水平线性扩展。这也是 JindoFS 服务采用 OSS 存储 Block 的主要原因。由此我们可以摆脱传统 HDFS 集群的扩容瓶颈。通过 OSS，我们可以存储百PB甚至更多的数据。如果采取将文件按原始方式直接写入 OSS 的方式，可能造成 OSS 的 Key 存在倾斜。比如说 warehouse 目录可能路径较深，并且在不同的 DB 目录，不同的 partition 之间存在数据大小不平衡的问题。JindoFS 服务则很好地解决了这个问题。JindoFS 将目录层次结构保存在元数据服务里，在 OSS 上则保存的是扁平结构的 Block 文件。这些 Block 文件采用了打散的 Key，从而避免了 OSS 可能存在单一prefix热点问题。打散了 OSS Key，JindoFS 服务可以更好地发挥 OSS 带宽的优势。得益于阿里云高效的网络基础设施，OSS 的带宽可以充分得到利用。HDFS 的带宽取决于磁盘规格和数量，一般的用户很难花大量金钱购买高规格的磁盘。通过使用OSS 带宽，省去了用户购买高规格磁盘的费用，可以利用更低的成本达到更大的带宽和性能优势。

HDFS 同样也是将文件拆分成 128MB 的 Block 打散到各个 DataNode 上，DataNode 也可以很好地扩展到上千台。有一个问题是 DataNode 并不能无限地增加，当 DataNode 达到上千台时，大量的 blockReport 对 NameNode 造成了很大压力，而且首先于 NameNode 内存瓶颈，一个集群中的 block 数量受到了限制。DataNode 在弹性缩容上也相对复杂，缩容一台 DataNode 前要先做Decomission，这个过程要等待在其他 DataNode 重新构建出副本，才能使得这台 DataNode 安全下线，这个过程可能持续几个小时左右，所以弹性上小很多。

TestDFSIO测试

测试环境，HDFS集群使用 8 * ecs.d2s.10xlarge， JindoFS集群使用 10* ecs.g5.8xlarge 使得两个集群的 CPU 个数是相等的。由于 HDFS 需要使用本地盘，因此每台机器配备了 7300 Gib * 15块HDD磁盘。

测试结果（单位MB/sec）

通过上述测试成绩，我们可以发现 JindoFS 的文件读写IO性能好于 HDFS 。JindoFS 的存算分离架构发挥了优势，充分利用了网络带宽。而 HDFS 由于需要写3副本，因此同时消耗了磁盘和网络带宽，使得整体的吞吐率低于 JindoFS。

五、HDFS 兼容

数据兼容

JindoFS 保存的元数据内容，包含了 HDFS 的元数据的所有关键字段。HDFS 的元数据保存在 FSImage，主要包含 INode 定义、Block 定义以及文件 Lease、Snapshot 信息等。拿 INode 定义举例，下图中的 INode 定义， HDFS 使用 Protobuf 序列化，JindoFS 使用更加高效的 Flatbuffer 序列化方式。JindoFS 的 INode 定义包含了 HDFS 的 INode 的所有字段，这样的话，客户的云下HDFS 集群平迁到 JindoFS 时，元数据部分可以快速批量导入，因为 JindoFS 包含了所有 HDFS 字段，因此迁移后元数据不会有差异，就可以做到元数据的兼容性。INode 定义中，例如文件权限，JindoFS 同样支持0777的posix 文件权限，并且支持 sticky bit 位。JindoFS 支持文件 atime 和mtime，也具有 Xattr 字段和 acl 字段，都兼容 HDFS 原有的 Xattr 和 acl 信息。

除此之外，Block 定义以及文件 Lease、Snapshot 信息也都可以完整地从 HDFS 迁移到JindoFS，而不会有信息的丢失。JindoFS 的元数据定义可以认为是 HDFS 的超集，除了兼容 HDFS的元数据之外，JindoFS 还增加了一些扩展信息，用于支持 JindoFS 的增强功能。

接口兼容

JindoFS 的一大特色是对 HDFS 接口的全面兼容。传统的对象存储系统，追求极致的扩展性，文件操作接口上相对简单。而 JindoFS 在两者之间实现了平衡。JindoFS 服务不单单是实现了 HCFS 协议的所有接口，而是从底层的 ClientNamenodeProtocol 协议实现了高度兼容。

ClientNamenoeProtocol 协议是客户端和服务端元数据服务的通信协议，包含文件基础操作、文件 Lease、Snapshot 相关、安全相关以及其它等一些操作。这些接口比抽象公共类HCFS接口更加详细、复杂。对象存储系统对一些高级文件操作，比如flush、append，显得力不从心，而这些接口对 HBase 这类事务型系统是必要的，JindoFS 从设计上原生支持flush、append操作。另外，recoverLease 并没有在HCFS中暴露，但是对上层业务至关重要，像 HBase、Flink 等一些分布式系统，在分区迁移后，需要调用 recoverLease 来关闭老节点未写完的文件，新节点才可以继续写入该文件，从而实现 failover 逻辑。JindoFS 服务完全遵照HDFS底层协议，实现了 Lease 相关以及其它大部分接口。上层业务可以无缝从 HDFS 迁移至 JindoFS 服务，而不用担心兼容新问题。

上述表格统计了 JindoFS 在客户端 Protocol 上的覆盖率，可以看到对于文件的基础操作，比如open、create以及append、flush等，JindoFS做到了100%的覆盖率。对于文件 Lease、Snapshot 相关接口也做到了100%覆盖。JindoFS 在安全功能上虽然做到了66%的覆盖率，但是特别支持了Ranger、Kerberos，满足了大部分的业务场景。总体上对 HDFS 接口的覆盖率达到了90%。

二进制协议兼容

JindoFS 服务的协议接口，是二进制兼容 HDFS 的。这主要体现在接口的方法、请求、返回值完全遵照 HDFS 的设计。

JindoFS 的接口在请求、返回值的字段、类型上跟 HDFS 保持基本一致，因此可以实现业务逻辑高度兼容。比如 getFileInfo 接口，HDFS 客户端传递 Request 的参数是字符串 path，JindoFS 同样支持参数path。HDFS 服务端返回的 Response 的内容包含一个 FileStatus 结构体，里面包含fileId、length、path、permission 等几个字段，JindoFS 返回的 Response 结构体包含了 HDFS 的所有字段，以达到完全兼容，避免了业务系统依赖某个字段而找不到的情况。除此之外，JindoFS 额外返回了一些字段，用于支持高级功能。

Jindo SDK 使用 Rest 方式跟服务端通信，如果上层业务使用 Protobuf 封装的 Rpc Request/Response，或者使用 WebHDFS，那么可以将参数原原本本转为 JindoFS 的 Rest 协议的方式，即可快速实现对 JindoFS服务的调用。

JindoFS 实现接口层的二进制兼容，最大的益处是可以兼容开源的 HDFS 客户端直连 JindoFS 服务，实现平滑迁移。根据以往经验，迁移存储系统数据比较容易，而如何做到线上业务系统极短时间停服，甚至不停服是一个大难题。而如果要替换业务系统的客户端 library，必然会造成系统停服重启。而且往往客户的 gateway 集群有多个，涉及到多个团队，很难一次性地替换所有客户端library。JindoFS 的二进制兼容可以做到兼容 HDFS 的客户端，业务系统只需要在适当的时候切换一下连接地址到 JindoFS，无需替换 HDFS 客户端，即可切换到 JindoFS。

HDFS 快照

JindoFS 服务实现了对 Snapshot 功能的支持。并且实现了创建 Snapshot、删除 Snapshot、比较 Snapshot Diff 等接口，在接口上跟 HDFS 保持了一致。

JindoFS 的 Snapshot 实现是基于 Copy on Write 机制，仅当一个 INode 或一个 Block 发生了修改，才会拷贝 INode 元数据或者 Block 数据。因此，在对一个超大目录做 Snapshot 时，可以做到非常轻量和快速。

Snapshot 功能有许多应用场景：1. 用于对历史数据进行定期备份，以防因为误操作而删除数据，或者用于法务合规、安全审计等用途。2.用于确保数据的原子性。有些作业会持续往一个目录写文件，如果我们要对这个目录做 DistCp，那么可能会拷贝一些不完整的数据。此时使用提前创建 Snapshot 的方式，对 Snapshot 做 DistCp，可以保证在设个视图下的数据的原子性。

如图所示，是 JindoFS 的 Snapshot 的实现原理。例如，图中对目录/a创建了一个 Snapshot "s1"，目录当前的状态和s1的状态的差集，保存在目录的 Snapshottable Feature 属性当中。JindoFS 的 snapshot 实现参考了 HDFS，是基于论文《Making Data Structures Persistent》实现的一种高效的 Snapshot 机制。它可以针对单个目录做 Snapshot。查询、删除、插入 Snapshot 的 INode 节点只需要 O(logn) 的时间复杂度。创建一个 Snapshot 仅需要 O(1) 的空间复杂度。因此理论上可以创建大量的 Snapshot，而不用担心性能受到影响。

HDFS 分层存储

JindoFS 分层主要解决客户冷热数据存储成本问题。对于大多数用户数据可以简单的分为冷数据和热数据，根据经验，一般客户60%到80%的数据为冷数据。JindoFS 分层存储中冷数据存放主要依赖 OSS 提供存储类型来提供，OSS 可以提供存储类型分为三种类型：标准存储类型，低频访问存储类型，归档存储类型。JindoFS 分层存储支持存储数据在上述各种数据类型之间进行转换，用户可以根据自己业务的数据类型来确定数据的存储类型，为数据的存储提供一种最优的存储方案，从而达到节省存储成本的目的。

HDFS 支持 setStoragePolicy 来改变数据 Block 在 DataNode 的存储介质是 SSD、HDD或磁带。而在实际场景中，大多数用户的集群只拥有一种介质，要么全部是 SSD，要么全部是 HDD。这种情况下设置文件的 StoragePolicy 为热数据或者归档，不会产生实质性的效果。

JindoFS 的分层存储基于 OSS，并且做了增强。JindoFS 的目录（文件）有 mtime 属性，可以给用户做分层存储决策提供参考。OSS 不支持对一个目录做批量的存储类型转换。JindoFS 允许用户通过命令行工具，将一个标准存储的目录转为低频或归档类型。JindoFS 会自动将这个目录下的所有文件，均转为相应的存储类型。

六、POSIX 支持

传统 HDFS 对 POSIX 的支持相对有限，主要原因是 HDFS 在架构设计上对已经写入的 Block 不支持做修改操作，只能做追加操作。如果想要修改中间某一部分的数据，必须先 truncate 这个 Block 然后重新做追加操作。HDFS 的锁级别为文件锁，属于粗粒度的，而 POSIX 语义支持对文件的部分内容进行加锁，属于细粒度锁。除此之外，HDFS 还不支持 fallocate。

JindoFS 对 POSIX 语义的支持做了大幅增强，通过多版本的机制支持了随机写，并且采用了全新设计的 Lease 管理机制。以下表格总结了 JindoFS 和 HDFS 在 POSIX 语义支持上的差异：

通过支持几乎完整的 POSIX 语义，我们就可以将 ClickHouse、DataNode 等其它存储系统的数据通过 Fuse 形式存储到 JindoFS 上，从而利用 JindoFS 存算分离的特性，将数据存放到对象存储系统上，获得无限存储、弹性伸缩等红利。

总结和展望：全新架构的数据湖文件系统JindoFS将成为云时代最好的HDFS

JindoFS 经过多年的多年的淬炼，吸取总结了丰富经验，从而正式推出了全新架构的 JindoFS 4.x版本，实现了 HDFS 高度兼容。它适用于大数据分析、机器学习训练、实时计算、OLTP 系统等等，涵盖了许多甚至传统数据湖存储覆盖不到的场景。它的出现解决了数据孤岛，简化了业务的架构，同时保证了高效的性能，实现了让数据发挥出更大的商业价值，为企业实现降本增效的效果。

JindoFS 近期还将推出从 HDFS 等存储到 JindoFS 的平滑迁移服务，做到存储系统不停服，业务系统滚动升级，作业无感知的效果，大幅缩减用户过渡到 JindoFS 的使用成本。

JindoFS 也在持续不断优化核心技术竞争力，包括与 JindoData 加速系统相结合，进一步优化底层能，将高性能、高可用、降成本做到极致。我们后续将继续更多文章，讲解 JindoFS 服务底层技术原理。

JindoFS 提供文件系统能力，加上 OSS 提供海量存储能力，JindoFS 与 OSS 相辅相成，深度融合，正式推出了OSS-HDFS全托管服务，只需在创建 OSS Bucket 时勾选“HDFS服务”即可，无需手动部署，方便使用。

OSS-HDFS全托管服务：https://help.aliyun.com/document_detail/405089.htm

往期推荐

1.深入理解virtual关键字

2.《领域驱动设计》：从领域视角深入仓储（Repository）的设计和实现

《Java工程师必读手册》

工匠追求“术”到极致，其实就是在寻“道”，且离悟“道”也就不远了，亦或是已经得道，这就是“工匠精神”——一种追求“以术得道”的精神。如果一个工匠只满足于“术”，不能追求“术”到极致去悟“道”，那只是一个靠“术”养家糊口的工匠而已。作者根据多年来的实践探索，总结了大量的Java编码之“术”，试图阐述出心中的Java编码之“道”。

点击阅读原文查看详情。

微信扫码关注该文公众号作者

戳这里提交新闻线索和高质量文章给我们。

来源: qq

点击查看作者最近其他文章