精华内容
下载资源
问答
  • 大数据技术原理应用——大数据存储与管理 1.分布式文件系统 (1)计算机集群结构 集群的概念 集群是指将多台服务器整合在一起,每台服务器都实现相同的业务,做相同的事情。 每台服务器并不是缺一不可,它存在的...

    大数据技术原理与应用——大数据存储与管理

    1.分布式文件系统

    (1)计算机集群结构

    集群的概念

    集群是指将多台服务器整合在一起,每台服务器都实现相同的业务,做相同的事情。

    每台服务器并不是缺一不可,它存在的作用主要是:
      缓解并发压力、提升计算性能
      单点故障转移问题

    传统版集群结构示意

    1.传统集群使用多个处理器和专用高级硬件的并行化处理装置
    2.紧密/集中构造
    在这里插入图片描述
    阿姆达尔定律——并行度和可扩展性关系
    在这里插入图片描述

    普通版计算机集群结构

    普及化的计算机集群,都是由普通硬件构成的,硬件成本上低、使用和开发的门槛降低 - 相互之间分散——所以也称分布式
    在这里插入图片描述

    (2)分布式文件系统结构

    分布式计算机系统

    业务分工和总体协调
    在这里插入图片描述

    大数据存储的解决途径

    集中扩展模式
    通过文件系统管理、存储数据
    信息爆炸时代获取的数据成指数倍的增长,单纯通过增加硬盘个数来扩展计算机文件系统的存储容量的方式/以及专用的存储系统
    分散存储组合 - 分布式
    文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点(可简单的理解为一台计算机)相连,通过多节点…

    解决存储和管理难题:

    将固定于某个地点的某个文件系统,扩展到任意多个地点/多个文件系统,众多的节点组成一个文件系统网络
    每个节点可以分布在不同的地点,通过网络进行节点间的通信和数据传输
    人们在使用分布式文件系统时,无需关心数据是存储在哪个节点上、或者是从哪个节点获取的,只需要像使用本地文件系统一样管理和存储文件系统中的数据

    常见的分布式文件系统

    在这里插入图片描述

    HDFS集群系统的文件系统

    总体的文件是通过某一种机制分布在各个计算机上:节点。这些节点分为两类:一类叫“主节点”(Master Node)或者也被称为“名称节点”(NameNode),另一类叫“从节点”(Slave Node)或者也被称为“数据节点”(DataNode)
    在这里插入图片描述

    2.HDFS简介

    在这里插入图片描述
    总体而言,HDFS要实现以下目标
      兼容廉价的硬件设备
      流数据读写
      大数据集
      简单的文件模型
      强大的跨平台兼容性

    HDFS特殊的设计,在实现上述优良特性的同时,也使得自身具有一些应用局限性,主要包括以下几个方面:
      不适合低延迟数据访问
      无法高效率存储大量小文件
      不支持多用户写入及任意修改文件

    3.HDFS的相关概念

    (1)块

    HDFS默认一个块 64MB/128M,一个文件被分成多个块,以块作为存储单位

    块的大小远远大于普通文件系统,可以最小化寻址开销

    在这里插入图片描述

    HDFS采用抽象的块概念可以带来以下几个明显的好处
    1)支持大规模文件存储:文件以块为单位进行存储,一个大规模文件可以被分拆成若干个文件块,不同的文件块可以被分发到不同的节点上,因此,一个文件的大小不会受到单个节点的存储容量的限制,可以远远大于网络中任意节点的存储容量。

    2)简化系统设计:首先,大大简化了存储管理,因为文件块大小是固定的,这样就可以很容易计算出一个节点可以存储多少文件块;其次,方便了元数据的管理,元数据不需要和文件块一起存储,可以由其他系统负责管理元数据。

    3)适合数据备份:每个文件块都可以冗余存储到多个节点上,大大提高了系统的容错性和可用性。

    (2)名称节点和数据节点

    在这里插入图片描述
    在这里插入图片描述

    HDFS主要组件的功能

    在这里插入图片描述

    名称节点的数据结构

    在HDFS中,名称节点(NameNode)负责管理分布式文件系统的命名空间(Namespace),保存了两个核心的数据结构,即 FsImage 和 EditLog
      FsImage 用于维护文件系统树以及文件树中所有的文件和文件夹的元数据
      操作日志文件 EditLog 中记录了所有针对文件的创建、删除、重命名等操作

    名称节点记录了每个文件中各个块所在的数据节点的位置信息
    在这里插入图片描述
    FsImage文件
    在这里插入图片描述
    FsImage 文件包含文件系统中所有目录和文件 inode 的序列化形式。每个 inode 是一个文件或目录的元数据的内部形式,并包含此类信息:文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块。对于目录,则存储修改时间、权限和配额元数据。

    FsImage 文件没有记录文件包含哪些块以及每个块存储在哪个数据节点。而是由名称节点把这些映射信息保留在内存中,当数据节点加入 HDFS 集群时,数据节点会把自己所包含的块列表告知给名称节点,此后会定期执行这种告知操作,以确保名称节点的块映射是最新的。

    名称节点的启动
    在这里插入图片描述
    在名称节点启动的时候,它会将 FsImage 文件中的内容加载到内存中,之后再执行 EditLog 文件中的各项操作,使得内存中的元数据和实际的同步,存在内存中的元数据支持客户端的读操作。

    一旦在内存中成功建立文件系统元数据的映射,则创建一个新的 FsImage 文件和一个空的 EditLog 文件

    名称节点起来之后,HDFS 中的更新操作会重新写到 EditLog 文件中,因为 FsImage 文件一般都很大(GB 级别的很常见),如果所有的更新操作都往 FsImage 文件中添加,这样会导致系统运行的十分缓慢,但是,如果往 EditLog 文件里面写就不会这样,因为 EditLog 要小很多。每次执行操作之后,且在向客户端发送成功代码之前,edits 文件都需要同步更新。

    名称节点运行期间 EditLog 不断变大的问题
    在名称节点运行期间,HDFS 的所有更新操作都是直接写到 EditLog 中,久而久之,EditLog 文件将会变得很大

    虽然这对名称节点运行时候是没有什么明显影响的,但是,当名称节点重启的时候,名称节点需要先将 FsImage 里面的所有内容映像到内存中,然后再一条一条地执行 EditLog 中的记录,当 EditLog 文件非常大的时候,会导致名称节点启动操作非常慢,而在这段时间内 HDFS 系统处于安全模式,一直无法对外提供写操作,影响了用户的使用

    如何解决?
    答案是:SecondaryNameNode 第二名称节点
    在这里插入图片描述
    在这里插入图片描述

    第二名称节点 是 HDFS 架构中的一个组成部分,它是用来保存名称节点中对 HDFS 元数据信息的备份,并减少名称节点重启的时间。SecondaryNameNode 一般是单独运行在一台机器上

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    数据节点(DataNode)

    数据节点是分布式文件系统 HDFS 的工作节点,负责数据的存储和读取,会根据客户端或者是名称节点的调度来进行数据的存储和检索,并且向名称节点定期发送自己所存储的块的列表。

    每个数据节点中的数据会被保存在各自节点的本地 Linux 文件系统中。
    在这里插入图片描述

    4.HDFS 体系结构

    在这里插入图片描述

    (1)HDFS 体系结构概述

    HDFS 采用了主从(Master/Slave)结构模型,一个 HDFS 集群包括一个名称节点(NameNode)和若干个数据节点(DataNode)。名称节点作为中心服务器,负责管理文件系统的命名空间及客户端对文件的访问。集群中的数据节点一般是一个节点运行一个数据节点进程,负责处理文件系统客户端的读/写请求,在名称节点的统一调度下进行数据库块的创建、删除和复制等操作。每个数据节点的数据实际上是保存在本地 Linux 文件系统中的。
    在这里插入图片描述

    (2)HDFS 命名空间管理

    在这里插入图片描述
    HDFS 的命名空间包含 目录、文件和块

    HDFS1.0体系结构中,在整个 HDFS 集群中只有一个命名空间,并且只有唯一一个名称节点,该节点负责对这个命名空间进行管理

    HDFS 使用的是传统的 分级文件体系,因此,用户可以 像使用普通文件系统一样,创建、删除目录和文件,在目录间转移文件,重命名文件等。

    (3)通信协议

    在这里插入图片描述
    HDFS 是一个部署在集群上的分布式文件系统,因此,很多数据需要通过网络进行传输

    所有的 HDFS 通信协议都是构建在 TCP/IP 协议基础之上的

    客户端通过一个可配置的端口向名称节点主动发起 TCP 连接,并使用客户端协议与名称节点进行交互

    名称节点和数据节点之间则使用数据节点协议进行交互

    客户端与数据节点的交互是通过 RPC(Remote Procedure Call)来实现的。在设计上,名称节点不会主动发起 RPC,而是响应来自客户端和数据节点的 RPC 请求。

    (4)客户端

    客户端是用户操作 HDFS 最常用的方式,HDFS 在部署时都提供了客户端

    HDFS客户端是一个库,暴露了 HDFS 文件系统接口,这些接口隐藏了 HDFS 实现中的大部分复杂性

    严格来说,客户端并不算是 HDFS 的一部分

    客户端可以支持打开、读取、写入等常见的操作,并且提供了类似 Shell 的命令行方式来访问 HDFS 中的数据

    此外,HDFS 也提供了 Java API,作为应用程序访问文件系统的客户端编程接口

    (5)HDFS 体系结构的局限性

    HDFS 只设置唯一一个名称节点,这样做虽然大大简化了系统设计,但也带来了一些明显的局限性,具体如下:
    1)**命名空间的限制:**名称节点是保存在内存中的,因此,名称节点能够容纳的对象(文件、块)的个数会受到内存空间大小的限制。
    2)**性能的瓶颈:**整个分布式文件系统的吞吐量,受限于单个名称节点的吞吐量。
    3)**隔离问题:**由于集群中只有一个名称节点,只有一个命名空间,因此,无法对不同应用程序进行隔离。
    4)**集群的可用性:**一旦这个唯一的名称节点发生故障,会导致整个集群变得不可用。
    在这里插入图片描述

    5.HDFS 存储原理

    (1)冗余数据保存

    作为一个分布式文件系统,为了保证系统的容错性和可用性,HDFS 采用了多副本方式对数据进行冗余存储,通常一个数据块的多个副本会被分布到不同的数据节点上,如图所示,数据块 1 被分别存放到数据节点 A 和 C 上,数据块 2 被存放在数据节点 A 和 B 上。这种多副本方式具有以下几个优点
    1)加快数据传输速度
    2)容易检查数据错误
    3)保证数据可靠性
    在这里插入图片描述

    (2)数据存储策略

    数据存放

    第一个副本,放置在上传文件的数据节点;如果是集群外提交,则随机挑选一台磁盘不太满、CPU不太忙的节点
    第二个副本:放置在与第一个副本不同的机架的节点上
    第三个副本:与第一个副本相同机架的其他节点上
    更多副本:随机节点
    在这里插入图片描述

    数据读取

    HDFS 提供了一个 API 可以确定一个数据节点所属的机架 ID,客户端也可以调用 API 获取自己所属的机架 ID

    当客户端读取数据时,从名称节点获得数据块不同副本的存放位置列表,列表中包含了副本所在的数据节点,可以调用 API 来确定客户端和这些数据节点所属的机架 ID,当发现某个数据块副本对应的机架 ID 和客户端对应的机架 ID 相同时,就优先选择该副本读取数据,如果没有发现,就随机选择一个副本读取数据

    (3)数据错误与恢复

    HDFS 具有较高的容错性,可以兼容廉价的硬件,它把硬件出错看作一种常态,而不是异常,并设计了相应的机制检测数据错误和进行自动恢复,主要包括了一下几种情形:名称节点出错、数据节点出错和数据出错。

    名称节点出错

    在这里插入图片描述
    名称节点保存了所有的元数据信息,其中,最核心的两大数据结构是 FsImage 和 Editlog,如果这两个文件发生损坏,那么整个 HDFS 实例将失效。因此,HDFS 设置了备份机制,把这些核心文件同步复制到备份服务器 SecondaryNameNode 上。当名称节点出错时,就可以根据备份服务器 SecondaryNameNode 中的 FsImage 和 Editlog 数据进行恢复。

    数据节点出错

    在这里插入图片描述
    每个数据节点会定期向名称节点发送“心跳”信息,向名称节点报告自己的状态
    当数据节点发生故障,或者网络发生断网时,名称节点就无法收到来自一些数据节点的心跳信息,这时,这些数据节点就会被标记为“宕机”,节点上面的所有数据都会被标记为“不可读”,名称节点不会再给它们发送任何 I/O 请求
    这时,有可能出现一种情况,即由于一些数据节点的不可用,会导致一些数据块的副本数量小于冗余因子
    名称节点会定期检查这种情况,一旦发现某个数据块的副本数量小于冗余因子,就会启动数据冗余复制,为它生成新的副本
    HDFS 和其他分布式文件系统的最大区别就是可以调整冗余数据的位置

    数据出错

    在这里插入图片描述
    网络传输和磁盘错误等因素,都会造成数据错误
    客户端在读取到数据后,会采用 md5 和 sha1 对数据块进行校验,以确定读取到正确的数据
    在文件被创建时,客户端就会对每一个文件块进行信息摘录,并把这些信息写入到同一个路径的隐藏文件里面
    当客户端读取文件的时候,会先读取该信息文件,然后,利用该信息文件对每个读取的数据块进行校验,如果校验出错,客户端就会请求到另外一个数据节点读取该文件块,并且向名称节点报告这个文件块有错误,名称节点会定期检查并且重新复制这个块

    6.HDFS 数据读写过程

    读取文件

    在这里插入图片描述

    写入文件

    在这里插入图片描述

    FileSystem 是一个通用文件系统的抽象基类,可以被分布式文件系统继承,所有可能使用 Hadoop 文件系统的代码,都要使用这个类
    Hadoop 为 FileSystem 这个抽象类提供了多种具体实现
    DistributedFileSystem 就是 FileSystem 在 HDFS 文件系统中的具体实现
    FileSystem 的 open() 方法返回的是一个输入流 FSDataInputStream 对象,在 HDFS 文件系统中,具体的输入流就是 DFSInputStream;FileSystem 中的 create() 方法返回的是一个输出流 FSDataOutputStream 对象,在 HDFS 文件系统中,具体的输出流就是 DFSOutputStream。
    在这里插入图片描述

    (1)读数据的过程

    在这里插入图片描述

    (2)写数据的过程

    在这里插入图片描述

    7.HDFS 编程实践

    Hadoop 提供了关于 HDFS 在 Linux 操作系统上进行文件操作的常用 Shell 命令以及 Java API 。同时还可以利用 Web 界面查看和管理 Hadoop 文件系统

    备注:Hadoop 安装成功后,已经包含 HDFS 和 MapReduce,不需要额外安装。而 HBase 等其他组件,则需要另外下载安装。

    在学习 HDFS 编程实践前,我们需要启动 Hadoop 。执行如下命令:
    在这里插入图片描述

    (1)HDFS 常用命令

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    (2)HDFS 的 Web 界面

    在这里插入图片描述

    (3)HDFS 常用 Java API 及应用实例

    在这里插入图片描述

    本章小结

    在这里插入图片描述

    展开全文
  • 3.2 大数据存储与管理方法 闪存、PCM等新型存储介质的引入使得大数据存储架构有了多种选择。但由于新型存储介质在价格、寿命等方面传统的磁盘相比不具优势,因此目前主流的观点是在大数据存储系统中同时使用新型...

    本节书摘来自华章出版社《大数据管理概论》一书中的第3章,第3.2节,作者 孟小峰,更多章节内容可以访问云栖社区“华章计算机”公众号查看

    3.2 大数据存储与管理方法

    闪存、PCM等新型存储介质的引入使得大数据存储架构有了多种选择。但由于新型存储介质在价格、寿命等方面与传统的磁盘相比不具优势,因此目前主流的观点是在大数据存储系统中同时使用新型存储介质和传统存储介质,由此产生了多种基于新型存储的大数据存储架构,如基于PCM的主存架构、基于闪存的主存扩展架构、基于多存储介质的分层存储架构等。

    3.2.1 基于PCM的主存架构

    由于PCM存储密度高、容量大、耗电低,而且访问速度接近内存,因此工业界和学术界都开展了将PCM作为主存系统的研究。与闪存相比,PCM存取延迟更短,而且可以直接按位存取,因此能够被CPU直接存取,更适合作为DRAM的扩展。与DRAM相比,PCM具有非易失性特点,因此适合存储文件等静态数据。
    在利用PCM替代DRAM方面,目前的研究重点主要集中在利用DRAM减少对PCM的写操作以及负载均衡等项目。对于利用DRAM来减少对PCM写操作的方法,研究者往往借助DRAM缓存来延迟对PCM的写操作从而达到减少PCM写次数的目的[42]。负载均衡思想是通过增加一层地址映射,将PCM的写操作均匀地分配给所有的存储单元,以尽可能地达到PCM的最大使用寿命。
    在针对大数据存储的集群架构中,负载均衡主要通过适合PCM的数据划分算法实现。PCM作为主存系统的思想对于大数据管理与分析有着重要的意义。虽然大数据应用中涉及的原始数据量非常大,但真正有价值的数据以及应用每次需要存取的数据量仍是有限的,因此我们可以利用PCM的高性能、非易失、按位存取等特性,将应用需要实时存取的高价值数据存储在PCM中,将PCM与DRAM混合形成高性能数据处理系统,同时将大规模的原始数据存储在磁盘和SSD中。因此,将PCM引入目前的存储架构中将有望解决大数据管理与分析中的性能问题。

    3.2.2 基于闪存的主存扩展架构

    与PCM相比,目前闪存的应用更为广泛。高速大容量SSD设备的不断出现,使得SSD在存储架构中的地位也得以提升。在大数据管理方面,目前SSD的存储容量还达不到大数据的PB级别存储需求,因此近年来主要的工作集中在利用高端SSD进行主存扩展的研究上。
    普林斯顿大学的研究人员提出了一种利用SSD进行内存扩展的主存管理系统——SSDAlloc。SSDAlloc在存储体系中将SSD提升到一个更高的层次,它把SSD当作一个更大、稍慢的DRAM而不是将它当作磁盘的缓存。为了提高数据库系统的整体性能,研究者以NoSQL数据库系统Redis为基础平台,用SSD代替磁盘作为虚拟内存中的交换设备,扩大虚拟内存的同时帮助NoSQL数据库减少数据读延迟。考虑到当将SSD作为虚拟交换设备时,页面交换的代价依然较大,一种基于DRAM与SSD的混合主存架构被设计出来,其将SSD作为主存,将DRAM作为SSD的高速缓冲,并将这种混合主存结构融入Memcached,大幅提升了Memcached性能。

    3.2.3 基于多存储介质的分层存储架构

    基于不同存储介质的分层存储架构目前主要集中在DRAM、闪存、磁盘的混合存储上。一种观点是将闪存作为内存与磁盘之间的缓存。例如,FlashCache[43]是Facebook为innoDB设计的块缓存应用,它将闪存划分为一个逻辑集合,基于组相联映射的思想将磁盘上的块数据映射到闪存中。当I/O请求到达时,FlashCache会先在闪存中查找该数据是否已被缓存,如果有则直接进行读操作,否则访问磁盘。将闪存作为DRAM与磁盘之间的缓存进行数据预取[44]或者预写[45,46],可以充分发挥闪存读性能好的优点,减少对磁盘的写操作,同时减少系统能耗。另一种观点是将闪存与磁盘一样作为二级存储介质,手动或者自动地将不同类别的数据分配到闪存或磁盘上[47]。由于不同的存储分配策略以及存储介质组合方式对于此类系统的性能有着决定性影响。
    在存储分配方面,已有研究倾向于根据I/O特性和数据的“冷热”程度来进行存储分配,将读倾向负载的数据或者热点数据存放在SSD上,而写倾向负载或非热点数据等则存放在磁盘上。IBM在其企业级存储设备DS8000上增加了EasyTier自动封存存储功能[48],将较大的逻辑卷进行划分,并对划分后的子卷进行热度检测,如果是热点卷,就将其迁移到SSD上,同时把SSD的非热点卷迁移到磁盘上。
    此外,面向分层存储的存储分配方法还应用在大数据文件系统的元数据管理上。在面向大数据管理的分布式文件系统中,利用分层系统存储分配的思想进行元数据管理,可以提升元数据存取性能。其基本思路是采用在元数据服务器上使用SSD作为存储设备的方法来加速文件系统。
    在存储介质用量组合方面,基本思想是将有限的闪存存储资源在复杂的工作负载下进行有效分配,在减少成本的同时满足系统的性能要求。在大数据环境中,存储介质用量组合研究需要考虑复杂的数据负载、系统的可靠性、能耗等多个方面的因素。
    Google设计了一款基于Colossus文件系统的闪存分配推荐系统——Janus[49]。他们通过实验发现大数据存储中I/O访问主要集中于新建文件,故此系统将新建文件存储在闪存层,然后使用FIFO或者LRU算法将文件迁移到磁盘进行存储,他们还设计了缓存性评估方程、经济性评估方程来评估不同的负载需求,进而进行闪存用量推荐。其实验结果表明,经过Janus的优化,闪存层存储了1%的数据,服务了28%的读操作,显著提高了系统的读性能。
    由于目前闪存、PCM等新型存储介质与DRAM、磁盘等传统存储介质处于共存的局面,预计在较长的时间内新型存储介质将与传统介质同时出现在存储系统中。尤其对于大数据存储环境,其数据的使用频率、规模等都不允许将所有数据都统一存储在集中式的存储设备上,因此基于分层存储的多介质混合存储技术将越来越受到研究者们的重视。但由于多种存储介质的分层存储存在着多种组合方式,哪种混合存储策略适合大数据应用、在多介质混合存储系统中如何有效地实现数据分配与迁移等仍有待进一步探索。

    3.2.4 分布式存储与缓存架构

    目前,基于分布式观点的数据管理是大数据存储与管理研究中的一个热点。一种观点是将闪存应用于分布式文件系统中进行元数据存储。元数据对于整个大数据管理系统的性能起着决定性作用,对于大数据解析、大数据统计、大数据操作优化等有着重要作用。基于闪存的分布式文件系统元数据管理的基本思路是在元数据服务器上使用SSD作为存储设备来加速文件系统。例如,在Lustre分布式文件系统架构中的元数据服务器(Metadata Server,MDS)上使用闪存作为存储介质,加速元数据的读写速度[50]。此外,基于Memcached的内存分布式缓存技术也被广泛用来加速大规模数据的访问,而在更为复杂的大数据环境下,其局限性主要体现在:一方面内存分布式缓存受限于集群内存容量,只能服务容量较小的热点数据,会造成性能下降;另一方面,如果采取扩大集群内存容量来满足更多数据缓存需求的话,会带来高额的成本和巨大的能耗。现阶段解决方法是将小容量、高I/O负载的缓存处理与大容量、中低等I/O负载的缓存处理分离,形成“热缓存”与“冷缓存”的缓存策略,其中在“冷缓存”方面主要采用了闪存技术。例如,Facebook设计了基于闪存的McDipper键-值存储系统[51],代替Memcached为大量访问频率较低的图片提供缓存服务,降低成本和能耗,为了减少闪存I/O延迟,将闪存层分成两个区域,一个区域存放数据,另一个区域配置了“散列桶”存放键值数据的指针,并将“散列桶”元数据放入了内存。

    展开全文
  • 以相变存储器为代表的存储级主存技术为切入点,针对大数据存储与管理中的高效存储、实时处理等存在的挑战,讨论了面向新型存储的大数据存储管理研究现状,并对未来基于新型存储的大数据研究进行了展望。
  • 大数据存储管理大趋势
  • 什么是成本管理 大数据成本管理架构 快手存储管理策略(现状及问题、成本分析、成本控制) 快手存储管理实施方法 专项数据治理 自驱式数据管理 全周期成本管理 全范围成本管理
  • 空间大数据存储管理

    2021-04-21 15:52:33
    能满足空间大数据存储管理需求,需要对传统 空间数据引擎进行升级扩展。基于分布式文件 系统、分布式数据库发展的分布式空间数据库,可 以有效提升对空间大数据存储管理能力。代 表 性 的 分 布 式 数 据 ...

    简述

    在空间大数据时代,传统关系型数据库已经不能满足空间大数据的存储和管理需求,需要对传统空间数据引擎进行升级与扩展。基于分布式文件系统、分布式数据库发展的分布式空间数据库,可以有效提升对空间大数据的存储和管理能力。代表 性 的 分 布 式 数 据 存 储 技 术 有 Elasticsearch、HDFS、MongoDB、HBase 等。

    其中,各有擅长:

    1. 基于 Elasticsearch的空间数据引擎可以实现对亿级以上的位置 空间数据的存储支持;
    2. 基于HDFS的空间数据引擎 (分布式空间文件引擎,Distributed Spatial File,
      DSF)则适用于亿级记录的静态空间数据的存储与 分析;
    3. 基于 MongoDB 的空间数据引擎可以实现亿 级记录地图瓦片存储;
    4. 基于HBase的空间数据引擎 可以用于亿级空间数据的存储、管理、分析、可视化 等综合应用。
    展开全文
  • 华为大数据存储教程系列
  • 目前大数据行业也越来越火爆,从而导致国内大数据人才也极度缺乏,下面介绍一下关于Hadoop环境中管理大数据存储技巧。 在现如今,随着IT互联网信息技术的飞速发展和进步。目前大数据行业也越来越火爆,从而导致国内...

    随着IT互联网信息技术的飞速发展和进步。目前大数据行业也越来越火爆,从而导致国内大数据人才也极度缺乏,下面介绍一下关于Hadoop环境中管理大数据存储技巧。

    在现如今,随着IT互联网信息技术的飞速发展和进步。目前大数据行业也越来越火爆,从而导致国内大数据人才也极度缺乏,下面介绍一下关于Hadoop环境中管理大数据存储技巧。

    1、分布式存储

    传统化集中式存储存在已有一段时间。但大数据并非真的适合集中式存储架构。Hadoop设计用于将计算更接近数据节点,同时采用了HDFS文件系统的大规模横向扩展功能。

    虽然,通常解决Hadoop管理自身数据低效性的方案是将Hadoop数据存储在SAN上。但这也造成了它自身性能与规模的瓶颈。现在,如果你把所有的数据都通过集中式SAN处理器进行处理,与Hadoop的分布式和并行化特性相悖。你要么针对不同的数据节点管理多个SAN,要么将所有的数据节点都集中到一个SAN。

    但Hadoop是一个分布式应用,就应该运行在分布式存储上,这样存储就保留了与Hadoop本身同样的灵活性,不过它也要求拥抱一个软件定义存储方案,并在商用服务器上运行,这相比瓶颈化的Hadoop自然更为高效。

     2、超融合VS分布式

    注意,不要混淆超融合与分布式。某些超融合方案是分布式存储,但通常这个术语意味着你的应用和存储都保存在同一计算节点上。这是在试图解决数据本地化的问题,但它会造成太多资源争用。这个Hadoop应用和存储平台会争用相同的内存和CPU。Hadoop运行在专有应用层,分布式存储运行在专有存储层这样会更好。之后,利用缓存和分层来解决数据本地化并补偿网络性能损失。

    3、避免控制器瓶颈(ControllerChokePoint)

    实现目标的一个重要方面就是——避免通过单个点例如一个传统控制器来处理数据。反之,要确保存储平台并行化,性能可以得到显著提升。

    此外,这个方案提供了增量扩展性。为数据湖添加功能跟往里面扔x86服务器一样简单。一个分布式存储平台如有需要将自动添加功能并重新调整数据。想系统学习大数据的话,可以加入大数据技术学习扣扣君羊:522189307

    4、删重和压缩

    掌握大数据的关键是删重和压缩技术。通常大数据集内会有70%到90%的数据简化。以PB容量计,能节约数万美元的磁盘成本。现代平台提供内联(对比后期处理)删重和压缩,大大降低了存储数据所需能力。

     5、合并Hadoop发行版

    很多大型企业拥有多个Hadoop发行版本。可能是开发者需要或是企业部门已经适应了不同版本。无论如何最终往往要对这些集群的维护与运营。一旦海量数据真正开始影响一家企业时,多个Hadoop发行版存储就会导致低效性。我们可以通过创建一个单一,可删重和压缩的数据湖获取数据效率

     6、虚拟化Hadoop

    虚拟化已经席卷企业级市场。很多地区超过80%的物理服务器现在是虚拟化的。但也仍有很多企业因为性能和数据本地化问题对虚拟化Hadoop避而不谈。

    7、创建弹性数据湖

    创建数据湖并不容易,但大数据存储可能会有需求。我们有很多种方法来做这件事,但哪一种是正确的?这个正确的架构应该是一个动态,弹性的数据湖,可以以多种格式(架构化,非结构化,半结构化)存储所有资源的数据。更重要的是,它必须支持应用不在远程资源上而是在本地数据资源上执行。

    不幸的是,传统架构和应用(也就是非分布式)并不尽如人意。随着数据集越来越大,将应用迁移到数据不可避免,而因为延迟太长也无法倒置。

    理想的数据湖基础架构会实现数据单一副本的存储,而且有应用在单一数据资源上执行,无需迁移数据或制作副本。

    8、整合分析

    分析并不是一个新功能,它已经在传统RDBMS环境中存在多年。不同的是基于开源应用的出现,以及数据库表单和社交媒体,非结构化数据资源(比如,维基百科)的整合能力。关键在于将多个数据类型和格式整合成一个标准的能力,有利于更轻松和一致地实现可视化与报告制作。合适的工具也对分析/商业智能项目的成功至关重要。

    展开全文
  • 大数据存储与管理研究首先面临的是存储技术上的挑战。虽然目前有许多存储技术有望用于大数据存储,但它们都存在局限性[36]。例如:目前以NoSQL数据库为代表的大规模分布式数据库系统设计了...
  • 阐述了智能电网面临的挑战以及大数据关键技术对电力行业的可持续...分别从智能电网主数据管理、用电信息统一存储管理、电能质量分析、配网运营能力分析等几个典型大数据系统分析了大数据关键技术在智能电网中的应用。
  • 本标准规定了大数据存储与处理系统的分布式文件存储、分布式结构化数据存储、分布式列式数据存储、分布式图数据存储、批处理框架、流处理框架、图计算框架、内存计算框架和批流融合计算框架等的功能要求。...
  • 大数据存储管理

    千次阅读 2019-02-02 14:15:23
    大数据存储管理
  • conn = pymysql.connect(host="localhost",user="root",passwd="199712",db="hackdata",charset="utf8")

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 159,780
精华内容 63,912
关键字:

大数据存储与管理