首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    技术 | 数据仓库分层存储技术揭秘

    据IDC发布的《数据时代2025》报告显示,全球每年产生的数据将从2018年的33ZB增长到2025年的175ZB,平均每天约产生491EB数据。随着数据量的不断增长,数据存储成本成为企业IT预算的重要组成部分。例如1PB数据存储一年,全部放在高性能存储介质和全部放在低成本存储介质两者成本差距在一个量级以上。由于关键业务需高性能访问,因此不能简单的把所有数据存放在低速设备,企业需根据数据的访问频度,使用不同种类的存储介质获得最小化成本和最大化效率。因此,把数据存储在不同层级,并能够自动在层级间迁移数据的分层存储技术成为企业海量数据存储的首选。

    02

    主流大数据存储解决方案评析

    大数据存储不是一类单独的产品,它有很多实现方式。EMC Isilon存储事业部总经理杨兰江概括说,大数据存储应该具有以下一些特性:海量数据存储能力,可轻松管理PB级乃至数十PB的存储容量;具有全局命名空间,所有应用可以看到统一的文件系统视图;支持标准接口,应用无需修改可直接运行,并提供API接口进行面向对象的管理;读写性能优异,聚合带宽高达数GB乃至数十GB;易于管理维护,无需中断业务即可轻松实现动态扩展;基于开放架构,可以运行于任何开放架构的硬件之上;具有多级数据冗余,支持硬件与软件冗余保护,数据具有高可靠性;采用多级存储备份,可灵活支持SSD、SAS、SATA和磁带库的统一管理。 通过与中国用户的接触,杨兰江认为,当前中国用户最迫切需要了解的是大数据存储有哪些分类,而在大数据应用方面面临的最大障碍就是如何在众多平台中找到适合自己的解决方案。 EMC针对不同的应用需求可以提供不同的解决方案:对于能源、媒体、生命科学、医疗影像、GIS、视频监控、HPC应用、某些归档应用等,EMC会首推以Isilon存储为核心的大数据存储解决方案;对于虚拟化以及具有很多小文件的应用,EMC将首推以VNX、XtremIO为核心的大数据存储解决方案;对于大数据分析一类的应用需求,EMC会综合考虑客户的具体需求,推荐Pivotal、Isilon等一体化的解决方案。在此,具体介绍一下EMC用于大数据的横向扩展NAS解决方案——EMC Isilon,其设计目标是简化对大数据存储基础架构的管理,为大数据提供灵活的可扩展平台,进一步提高大数据存储的效率,降低成本。 EMC Isilon存储解决方案主要包括三部分:EMC Isilon平台节点和加速器,可从单个文件系统进行大数据存储,从而服务于 I/O 密集型应用程序、存储和近线归档;EMC Isilon基础架构软件是一个强大的工具,可帮助用户在大数据环境中保护数据、控制成本并优化存储资源和系统性能;EMC Isilon OneFS操作系统可在集群中跨节点智能地整合文件系统、卷管理器和数据保护功能。 杨兰江表示,企业用户选择EMC Isilon的理由可以归纳为以下几点。第一,简化管理,增强易用性。与传统NAS相比,无论未来存储容量、性能增加到何种程度,EMC Isilon的安装、管理和扩展都会保持其简单性。第二,强大的可扩展性。EMC Isilon可以满足非结构化数据的存储和分析需求,单个文件系统和卷中每个集群的容量为18TB~15PB。第三,更高的处理效率,更低的成本。EMC Isilon在单个共享存储池中的利用率超过80%,而EMC Isilon SmartPools软件可进一步优化资源,提供自动存储分层,保证存储的高性能、经济性。第四,灵活的互操作性。EMC Isilon支持众多行业标准,简化工作流。它还提供了API可以向客户和ISV提供OneFS控制接口,提供Isilon集群的自动化、协调和资源调配能力。 EMC Isilon大数据存储解决方案已经在医疗、制造、高校和科研机构中有了许多成功应用。

    03

    每日论文速递 | NLP大佬们联合发文,倡导使用检索增强模型RA-LMs

    摘要:参数化语言模型(LMs)通过在大量网络数据上进行训练,展现出了显著的灵活性和能力。然而,它们仍然面临着诸如幻觉、难以适应新数据分布以及缺乏可验证性等实际挑战。在这篇立场论文中,我们主张将检索增强型LMs作为下一代LMs取代参数化LMs。通过在推理过程中结合大规模数据存储,检索增强型LMs可以更加可靠、适应性强,并且具有可归因性。尽管具有潜力,但检索增强型LMs由于几个障碍尚未被广泛采用:具体来说,当前的检索增强型LMs在超出知识密集型任务(如问答)的文本利用方面遇到困难,检索和LM组件之间的互动有限,缺乏用于扩展的基础设施。为了解决这些问题,我们提出了开发通用检索增强型LMs的路线图。这涉及重新考虑数据存储和检索器,探索具有改进的检索器-LM交互的流水线,并且在高效训练和推理的基础设施上进行重大投资。

    01

    腾讯云 TStor 存储,助力广州银行打造安全可信的文档中台系统

    背景 广州银行成立于1996年9月,自成立以来,依托中国经济腾飞的大好形势,乘广东改革开放先行先试的东风,不断深化改革、强化管理、优化服务,各项业务持续快速发展,竞争实力显著增强,已成为国内具有一定知名度与地方特色的商业银行。 随着银行业务的快速发展,现有的数据中心基础设施的资源已经无法满足业务需求,需要对多个系统进行扩容,包括办公系统、文档中台系统、数据分析系统、数据存储等。新建的系统,除了要满足银行的业务需求外,还要符合自主可控、安全可信等信息技术创新标准。 作为一家国有银行,广州银行积极响应国家政策,

    01

    Hive的基本知识(一)

    Hive 组件 用户接口:包括 CLI、JDBC/ODBC、WebGUI。其中,CLI(command line interface)为shell命令行; Hive中的Thrift服务器允许外部客户端通过网络与Hive进行交互,类似于JDBC或ODBC协议。WebGUI是 通过浏览器访问Hive。 元数据存储:通常是存储在关系数据库如 mysql/derby中。Hive 中的元数据包括表的名字,表的列和分区及其属性,表的属性(是否为外部表等),表的数据所在目录等。 Driver驱动程序,包括语法解析器、计划编译器、优化器、执行器 : 完成 HQL 查询语句从词法分析、语法分析、编译、优化以及查询计划的生成。生成的查询计划存储在 HDFS 中,并在随后有执行引擎调用执行。 执行引擎:Hive本身并不直接处理数据文件。而是通过执行引擎处理。当下Hive支持MapReduce、 Tez、Spark3种执行引擎。 Hive基本使用 链接方式: 1.使用hive本地连接 2.开启hiveserver2远程服务,使用beeline连接 3.使用hive参数执行任务 hive -e ‘执行语句’ hive -f ‘执行脚本文件’

    01

    事务处理的数据存储

    在上篇文章我们讨论了数据模型,今天试着讨论更基础的数据存储和搜索。数据存储根据开发者使用,可以分为一般的事务处理和数据分析,因为这两者面临的情况不一样。事务处理聚焦于快速的存储和搜索少量的数据,但是数据分析需要读取大量的数据去进行聚合,而不怎么考虑读取花费的时间。后者一般称为数据仓库。 首先我们先看看传统数据库和大部分NoSQL的数据存储引擎。这个实际上分为两个流派,一个是基于日志结构,主要使用了LSM树,另一个是基于OS的页的结构,就是所谓的B树。这么说可能比较难懂。让我们想象一下,假设你有一个excel,里面存储了一条数据a,b,如果我们想查询a,我们可以遍历excel找到满足以a开头的数据a,b。这就是一个简单的数据库,存储数据时,只要简单的添加在下一列。查找时进行遍历,找到符合条件的。让我们想想这会有什么问题。对于数据存储,我们只需要简单的添加数据,对于磁盘这样极有效率,当然实际上的数据库还要考虑并行处理、磁盘存储空间不足等等情况。存储数据的file,就是所谓的log。另一方面,对于搜索数据,这个效率就相当慢了,因为每次搜索数据都需要遍历整个文件,时间复杂度是线性的增长,这时候我们就需要索引了。显然索引对于整个数据存储文件而言,是额外的存储结构,维护索引结构会牺牲write的效率。 对于索引结构,首先想到的是key-value结构。例如对于数据a,b c,f,d这种数据,我们可以用一个索引a,0 b,3这种hash map的形式0和3代表着文件的offset,我们查找数据的时候,先去hash map找到对应的key值,获得offset,我们就能获得key值对应的value。这听起来很简单,然而这就是Bitcask的实现方式。这个索引结构是完全存储在内存当中,如果超出内存的话,就会放在磁盘上。如果数据一直在增长,磁盘空间肯定会有不足的那一刻,解决办法就是将数据拆分为固定大小的segment,以及在合适的时候,合并segment,根据时间戳,保留最新的value值,重新写入新的segment,对旧的进行删除。对于实际的工程,我们还需要考虑 1.文件存储的格式,一般而言应该是以bytes存储 2.删除数据时,应该加上一个标签,比如tombstone,在合并segment时,对数据进行删除 3.数据库崩溃重新恢复,Bitcask使用的是快照的方式在磁盘保存索引结构 4.并发的写入数据,这个需要检查点来处理数据写入时数据库崩溃 5.并发控制,因为文件的immutable,所以并发控制相当简单。 但是这个依然存在问题,让我们想想,那就是hash table必须存储在内存中,这个对于大数据时很不友好,即使你是存储在磁盘上。并且对于范围查找很不友好,因为你需要遍历所有key去查找一个范围内的一个key。 为了解决范围查找,人们又提出了在创建索引时,我们可以按照key值进行排序,这样的存储方式叫做SSTable。这样有下面的几个好处,合并segment变得更有效率了,因为你只需要读取开始的key和结束的key就可以了。在保存索引时,也不需要将所有的key存储在内存里,只需要保存每个segment的开始key和结束key。读取数据时,也不需要遍历所有的key值了。那么对于维护索引呢?我们在写入数据时,会先写入memtable(存储在内存的例如红黑树之类的数据结构)。当memtable超过某个阈值时,会将memtable写入到磁盘的segment中。在读取数据时,我们会首先在memtable中查找数据,然后再根据时间逐步读取segment。每隔一段时间,后台进程便会合并segment,清理垃圾数据。这样处理的唯一问题,就是memtable遇到服务器崩溃。我们可以牺牲一部分write的效率,生成一个独立的log去立马保存写入的数据,这个log的唯一用途就是防止memtable的丢失。 上面的就是现在HBase、LevelDB、Lucene这些使用的LSM树结构。对于其的优化,目前可以使用布隆过滤器、size-tiered等方式去优化读取和合并segment。除了LSM树,目前还有一个广泛使用的索引,那就是B树。 B树主要是利用了操作系统的页结构,将数据拆分成一个固定尺寸的block块,使用存储address和location,类似于指针的方式存储数据。具体细节不多说,网上的文章一大堆。我们需要考虑的是负载因子和二叉树的平衡。对于每次的写入和修改数据,我们都需要找到key值在系统里对应的address去修改数据,重新写入,同样为了防止数据崩溃,一般的数据库会使用预写日志(WAL)去保存每一次数据的修改和写入。 除了这些索引,还有所谓的二级索引。这个类似于倒排索引。不仅如此,还有基于列的存储方式,这个大多是为了数据仓库服务的。

    03
    领券