基于JindoFS+OSS构建高效数据湖

为何要构建数据湖

大数据时代早期，Apache HDFS 是构建具备海量存储能力数据仓库的首选方案。随着云计算、大数据、AI 等技术的发展，全部云厂商都在不断完善自家的对象存储，来更好地适配 Apache Hadoop/Spark 大数据以及各类 AI 生态。因为对象存储有海量、安全、低成本、高可靠、易集成等优点，各类 IoT 设备、网站数据都把各类形式的原始文件存储在对象存储上，利用对象存储加强和拓展大数据 AI 也成为了业界共识，Apache Hadoop 社区也推出了原生的对象存储“Ozone”。从 HDFS 到对象存储，从数据仓库到数据湖，把全部的数据都放在一个统一的存储中，也能够更加高效地进行分析和处理。

对于云上的客户来讲，如何构建本身的数据湖，早期的技术选型很是重要，随着数据量的不断增长，后续进行架构升级和数据迁移的成本也会增长。在云上使用 HDFS 构建大规模存储系统，已经暴露出来很多问题。HDFS 是 Hadoop 原生的存储系统，通过 10 年来的发展，HDFS 已经成为大数据生态的存储标准，但咱们也看到 HDFS 虽然不断优化，可是 NameNode 单点瓶颈，JVM 瓶颈仍然影响着集群的扩展，从 1 PB到 100+ PB，须要不断的进行调优、集群拆分来，HDFS 能够支持到 EB 级别，可是投入很高的运维成本，来解决慢启动，心跳风暴，节点扩容、节点迁移，数据平衡等问题。

云原生的大数据存储方案，基于阿里云 OSS 构建数据湖是最合适的选择。OSS 是阿里云上的对象存储服务，有着高性能、无限容量、高安全、高可用、低成本等优点，JindoFS 针对大数据生态对 OSS 进行了适配，缓存加速，甚至提供专门的文件元数据服务，知足上云客户的各类分析计算需求。所以在阿里云上，JindoFS + OSS 成为客户采起数据湖架构迁移上云的最佳实践。

JindoFS 介绍

Jindo 是阿里云基于 Apache Spark / Apache Hadoop 在云上定制的分布式计算和存储引擎。Jindo 原是阿里云 开源大数据团队的内部研发代号，取自筋斗(云)的谐音，Jindo 在开源基础上作了大量优化和扩展，深度集成和链接了众多阿里云基础服务。

JindoFS 是阿里云针对云上存储自研的大数据缓存加速服务，JindoFS 的设计理念是云原生：弹性、高效、稳定和低成本。JindoFS 彻底兼容 Hadoop 文件系统接口，给客户带来更加灵活、高效的数据湖加速方案，彻底兼容阿里云 EMR 中全部的计算服务和引擎：Spark、Flink、Hive、MapReduce、Presto、Impala 等。JindoFS 有两种使用模式，块存储模式(BLOCK)和缓存模式(CACHE)。下面咱们介绍下如何在 EMR 中配置和使用 JindoFS 以及不一样模式对应的场景。

JindoFS 架构

JindoFS 主要包含两个服务组件：元数据服务(NamespaceService) 和存储服务 (StorageService)：

• NamespaceService 主要负责元数据管理以及管理 StorageService。
• StorageService 主要负责管理节点的本地数据和 OSS 上的缓存数据。

下图是 JindoFS 架构图：元数据服务 NamespaceService 部署在独立的节点，对于生产环境推荐部署三台(Raft)来实现服务高可用；存储服务 StorageService 部署在集群的计算节点，管理节点上的闲置存储资源（本地盘/SSD/内存等），为JindoFS 提供分布式缓存能力。

JindoFS 元数据服务

JindoFS 的元数据服务叫 JindoNamespaceService，内部基于 K-V 结构存储元数据，相对于传统的内存结构有着操做高效，易管理，易恢复等优点。

• 高效元数据操做。JindoFS NamespaceService 基于内存 + 磁盘管理和存储元数据，可是性能上比使用内存的 HDFS NameNode 还要好，一方面是 JindoFS 使用 C++ 开发，没有 GC 等问题，响应更快；另外一方面是因为 Namespace Service 内部有更好的设计，好比文件元数据上更细粒度的锁，更高效的数据块副本管理机制。
• 秒级启动。有大规模 HDFS 集群维护经验的同窗比较清楚，当 HDFS 元数据存储量过亿之后，NameNode 启动初始化要先加载 Fsimage ，再合并 edit log，而后等待所有 DataNode 上报 Block，这一系列流程完成要花费一个小时甚至更长的时间， 因为 NameNode 是双机高可用（Active/Standby），若是 standby 节点重启时 active 节点出现异常 ，或两台 NameNode 节点同时出现故障，HDFS 将出现停服一小时以上的损失。JindoFS 的元数据服务基于 Raft 实现高可用，支持 2N+1 的部署方式，容许同时挂掉 N 台；元数据服务 (NamespaceService) 在元数据内部存储上进行了设计和优化，进程启动后便可提供服务，能够作到了快速响应。因为 NamespaceService 近实时写入 OTS 的特色，元数据节点更换，甚至集群总体迁移也很是容易。
• 低资源消耗。HDFS NameNode 采用内存形式来存储文件元数据。在必定规模下，这种作法性能上是比较不错的，可是这样的作法也使 HDFS 元数据的规模受限于节点的内存，通过推算，1亿文件 HDFS 文件大约须要分配 60 GB Java Heap 给 NameNode，因此一台 256 GB的机器最多能够管理 4 亿左右的元数据，同时还须要不断调优 JVM GC。JindoFS 的元数据采用 Rocksdb 存储元数据，能够轻松支持到 10 亿规模，对于节点的内存需求也很是小，资源开销不到 NameNode 的十分之一。

JindoFS 缓存服务

JindoFS 的数据缓存服务叫 JindoStorageService，本地 StorageService 主要提供高性能缓存加速，因此运维上能够基于这样的设定大大简化。

• 弹性运维。HDFS 使用 DataNode 在存储节点上来管理节点存储，所有数据块都存储在节点的磁盘上，依靠 DataNode 按期检查和心跳把存储状态上报给 NameNode，NameNode 经过汇总和计算，动态地保证文件的数据块达到设定的副本数（通常 3 副本）。对于大规模集群（节点 1000+），常常须要进行集群节点扩容，节点迁移，节点下线，节点数据平衡这样的操做，大量的数据块的副本计算增长了 NameNode 负载，同时，节点相关操做要等待 NameNode 内部的副本调度完成才能进行，一般一个存储节点的下线须要小时级别的等待才能完成。JindoFS 使用 StorageService 来管理节点上的存储，因为 JindoFS 保证了数据在 OSS 上有一副本，因此本地的副本主要用来进行缓存加速。对于节点迁移、节点下线等场景，JindoFS 无需复杂副本计算，经过快速的“标记”便可完成下线。
• 高性能存储。StorageService 采用 C++ 语言开发，在对接最新高性能存储硬件上也有着自然优点。StorageService 的存储后端不只能够同时对接SSD、本磁盘、OSS 知足 Hadoop/Spark 大数据框架各类海量、高性能的存储访问需求，能够对接内存、AEP 这样的高性能设备知足 AI/机器学习的低延时、高吞吐的存储使用需求。

JindoFS 适用场景

JindoFS 的元数据存储在 Master 节点的 NamespaceService （高可用部署）上，性能和体验上对标 HDFS；Core节点的 StorageService 将一份数据块存储在 OSS 上，本地数据块能够随着节点资源进行快速的弹性伸缩。多集群之间也能够相互打通。

为了支持数据湖多种使用场景，一套 JindoFS 部署同时提供两种 OSS 使用方式，存储模式（Block）和缓存模式（Cache）。

• 缓存模式。对于已经存在于 OSS 上的数据，可使用缓存模式访问，正如“缓存”自己的含义，经过缓存的方式，在本地集群基于 JindoFS 的存储能力构建了一个分布式缓存服务，把远端数据缓存在本地集群，使远端数据“本地化”。使用上也沿用原来的路径访问，如 oss://bucket1/file1 ，这种模式全量的文件都在 OSS 上面，能够作到集群级别的弹性使用。
• 存储模式。存储模式（Block）适用于高性能数据处理场景，元数据存储在 NamespaceService （支持高可用部署）上，性能和体验上对标 HDFS；StorageService 将一份数据块存储在 OSS 上，本地数据块能够随着节点资源能够进行快速的弹性伸缩。基于 JindoFS Block 模式这样的特性，能够用做构建高性能数仓的核心存储，多个计算集群能够访问 JindoFS 主集群的数据。

JindoFS 方案优点

基于JindoFS + OSS 来构建数据湖相比于其余数据湖方案同时具备性能和成本优点。

• 性能上，JindoFS 针对一些经常使用的场景和 Benchmark 进行了对比测试，如 DFSIO、NNbench、TPCDS、Spark、Presto 等，经过测试咱们能够看到性能上，Block模式彻底领先于 HDFS，Cache模式彻底领先于 Hadoop 社区的 OSS SDK 实现，因为篇幅的缘由，后续咱们会发布详细的测试报告。
• 成本上。成本是也是用户上云的重要考量，JindoFS 的成本优点主要体如今运维成本和存储成本两方面。运维成本指的是集群平常维护，节点上下线、迁移等。如前面分析，当 HDFS 集群增加到必定规模时，好比 10PB+，除了对 HDFS 进行专家级别调优外，还须要业务上的拆分规划，避免达到 HDFS 元数据上的瓶颈。同时，随着集群数据不断增加，一些节点和磁盘也会出现故障，须要进行节点下线和数据平衡，也给大集群的运维带来必定的复杂度。JindoFS 可使用 OSS + OTS 的存储模式，OSS 上保留原始文件和数据块备份，对节点和磁盘出现的问题能够更好兼容；元数据（NamespaceService）采用 C++ 开发加上工程打磨，相比 NameNode + JVM 在容量上和性能上也更有优点。

下面咱们重点来看存储成本。存储成本指的是存放数据后产生的存储费用，使用 OSS 是按量付费的，相比基于本地盘建立的 HDFS 集群有更好的成本优点，下面来计算和对比一下两者成本：

基于 HDFS + 本地盘方案构建大数据存储：

因为本地盘机型为总体价格，须要以下进行换算，预估存储成本以下：

（参考连接：https://www.aliyun.com/price/product#/ecs/detail ）

考虑到实际使用 HDFS 会有3副本以及必定的预留空间，咱们以 HDFS 3 副本、 80% 使用率进行成本计算：

基于 JindoFS 加速方案构建数据湖：

OSS 数据存储（标准型单价）=  0.12元/GB/每个月

（参考连接：https://www.aliyun.com/price/product#/oss/detail ）

咱们能够看到使用 JindoFS 加速方案构建数据湖，要节省 25% 的存储成本。同时 OSS 是按量计费，即计算存储分离，当计算和存储比例存在差别时，好比存储资源高速增加，计算资源增长较小时，成本优点会更加明显。

对 OSS 数据进行缓存加速，须要额外使用计算节点上部分磁盘空间，带来必定成本。这部分红本，通常取决于热数据或者要缓存数据的大小，跟要存储的数据总量关系不大。增长这部分红本，能够换取计算效率的提高和计算资源的节省，总体效果能够根据实际场景进行评估。

JindoFS 生态

数据湖是开放的，须要对接各类计算引擎。目前 JindoFS 已经明确支持 Spark、Flink、Hive、MapReduce、Presto 和 Impala 组件。同时，JindoFS 为了支持更好地使用数据湖，还提供 JindoTable 对结构化数据进行优化和查询加速；提供 JindoDistCp 来支持 HDFS 离线数据往 OSS 迁移；支持 JindoFuse 方便数据湖上加速机器学习训练。

原文连接本文为阿里云原创内容，未经容许不得转载。