咨询北京国互网网站建设,wordpress wamp,滁州建设局网站,模仿淘宝网站为什么要构建数据湖
大数据时代早期#xff0c;Apache HDFS 是构建具有海量存储能力数据仓库的首选方案。随着云计算、大数据、AI 等技术的发展#xff0c;所有云厂商都在不断完善自家的对象存储#xff0c;来更好地适配 Apache Hadoop/Spark 大数据以及各种 AI 生态。由于…为什么要构建数据湖
大数据时代早期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 实现高可用支持 2N1 的部署方式允许同时挂掉 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 定期检查和心跳把存储状态上报给 NameNodeNameNode 通过汇总和计算动态地保证文件的数据块达到设定的副本数一般 3 副本。对于大规模集群节点 1000经常需要进行集群节点扩容节点迁移节点下线节点数据平衡这样的操作大量的数据块的副本计算增加了 NameNode 负载同时节点相关操作要等待 NameNode 内部的副本调度完成才能进行通常一个存储节点的下线需要小时级别的等待才能完成。JindoFS 使用 StorageService 来管理节点上的存储由于 JindoFS 保证了数据在 OSS 上有一副本所以本地的副本主要用来进行缓存加速。对于节点迁移、节点下线等场景JindoFS 无需复杂副本计算通过快速的“标记”即可完成下线。高性能存储。StorageService 采用 C 语言开发在对接最新高性能存储硬件上也有着天然优势。StorageService 的存储后端不仅可以同时对接SSD、本磁盘、OSS 满足 Hadoop/Spark 大数据框架各种海量、高性能的存储访问需求可以对接内存、AEP 这样的高性能设备满足 AI/机器学习的低延时、高吞吐的存储使用需求。
JindoFS 适用场景
JindoFS 的元数据存储在 Master 节点的 NamespaceService 高可用部署上性能和体验上对标 HDFSCore节点的 StorageService 将一份数据块存储在 OSS 上本地数据块可以随着节点资源进行快速的弹性伸缩。多集群之间也可以相互打通。
为了支持数据湖多种使用场景一套 JindoFS 部署同时提供两种 OSS 使用方式存储模式Block和缓存模式Cache。
缓存模式。对于已经存在于 OSS 上的数据可以使用缓存模式访问正如“缓存”本身的含义通过缓存的方式在本地集群基于 JindoFS 的存储能力构建了一个分布式缓存服务把远端数据缓存在本地集群使远端数据“本地化”。使用上也沿用原来的路径访问如 oss://bucket1/file1 这种模式全量的文件都在 OSS 上面可以做到集群级别的弹性使用。存储模式。存储模式Block适用于高性能数据处理场景元数据存储在 NamespaceService 支持高可用部署上性能和体验上对标 HDFSStorageService 将一份数据块存储在 OSS 上本地数据块可以随着节点资源可以进行快速的弹性伸缩。基于 JindoFS Block 模式这样的特性可以用作构建高性能数仓的核心存储多个计算集群可以访问 JindoFS 主集群的数据。
JindoFS 方案优势
基于JindoFS OSS 来构建数据湖相比于其他数据湖方案同时具有性能和成本优势。
性能上JindoFS 针对一些常用的场景和 Benchmark 进行了对比测试如 DFSIO、NNbench、TPCDS、Spark、Presto 等通过测试我们可以看到性能上Block模式完全领先于 HDFSCache模式完全领先于 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 方便数据湖上加速机器学习训练。 原文链接 本文为阿里云原创内容未经允许不得转载。
