关于javascript:基于JindoFSOSS构建高效数据湖

为什么要构建数据湖

大数据时代晚期，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 不便数据湖上减速机器学习训练。

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