国外海量数据离线存储产品应用[最终定稿]

第一篇：国外海量数据离线存储产品应用

国外海量数据离线存储产品应用

在当先信息技术高速发展的情况下，不同类型的信息、数据爆发式的产生。同时，当今社会及经济发展中需要将从前工作、生活、经济活动所产生的非数字化信息及数据进行数字化处理以方便今后对此类数据进行查询、分拣、处理及备份。此数字化过程同样会产生大量的重要数据。这就需要有相应的系统对此大量的重要数据进行备份及保存。

此种数据的特点是信息重要，数据量大。为了保证数据的安全及完备性，需要对数据进行存储，并与相应的处理设备进行分离。这样做既保证了数据的安全又保证备份数据不会受到处理设备的干扰。尤其在911事件后，对数据安全及数据完整性要求较高的企业及机构意识到需要将相应的数据进行周期性的离线备份并将此离线备份数据与原始数据进行分离保管。所以就需要一种专门快速的可以对大量数据进行离线备份的设备来满足此种功能需要。

国内外许多公司及商业、教育机构都采用离线存储设备解决海量重要数据的备份问题。

1、美国华盛顿大学采用此类设备对自身运作产生的大量实验数据和图书数据进行备份和存储。

2、美国国家图书馆采用此类设备对图书馆中的数字化图书进行备份和保存，从而有效的保存了历史文化遗产。

3、招商银行驻纽约办事处使用此类设备对敏感的客户资料和数据进行有效的保管和存储，从而保证了业务准确和快速的运作与发展。

由国家档案局档案科研所、浙江省档案局和北京汉龙思琪数码科技有限公司共同研发的海量数据离线存储柜，基于24V弱电库房安全保存保管情况，采用高科技集成技术，将多个大容量硬盘进行级联管理，采用离线保存管理系统，对电子数据进行安全、节能、便捷、利用性高的大容量数据离线科学管理。

专业的离线存储系统不仅在档案行业有广泛的市场应用前景，同时在图书、医疗、民政、广播电视、文化、军事等行业也有广泛的应用。它可以作为重要数

据在线存储的安全备份和应急服务，为在线存储的灾后数据恢复等提供安全、稳妥的数据保障。

海量数据离线存储系统可以对不同电子介质的海量数据进行统一的管理，以及对存储介质进行登记接收、备份存储、定期检测、长期保管和利用。

第二篇：数据存储主要优点建议

数据存储采购建议

随着集团网络的数据量不断增加，网络数据的安全性是极为重要的，一旦重要的数据被破坏或丢失，就会对企业造成重大的影响，甚至是难以弥补的损失。数据存储备份除了拷贝外，还包括更重要的内容即管理。备份管理包括备份的可计划性，磁盘的自动化操作、历史记录的保存以及日志记录等。所有的硬件备份都不能代替数据存储备份，硬件备份（双机热备份、磁盘阵列备份以及磁盘镜象备份等硬件备份）只是拿一个系统、一个设备等作牺牲来换取另一台系统或设备在短暂时间内的安全。若发生人为的错误、自然灾害、电源故障、病毒黑客侵袭等，引起的后果就不堪设想，如造成系统瘫痪，所有设备将无法运行，由此引起的数据丢失也就无法恢复了。只有数据存储备份才能为我们提供万无一失的数据安全保护。

我们早先采用数据存储为“DAS（Direct Attached Storage，直接外挂存储）”的存储方式。这种数据存储的服务器结构如同PC机架构，外部数据存储设备都直接挂接在服务器内部总线上，数据存储设备是整个服务器结构的一部分，同样服务器也担负着整个网络的数据存储职责。DAS这种直连方式，只能够解决单台服务器的存储空间扩展、传输需求，无法满足多台服务器备份的需要。为了满足现在多台服务器所需要的网络存储必须采取支持以下两种方式的存储设备：

一、NAS（Network Attached Storage，网络附加存储）方式则全面改进了以前低效的DAS数据存储方案，它是采用独立于PC服务器，单独为网络数据存储而开发的一种文件服务器。NAS服务器中集中连接了所有的网络数据存储设备（如各种磁盘阵列、磁带、光盘机等），存储容量可以较好地扩展，同时由于这种网络存储方式是NAS服务器独立承担的，所以，对原来的网络服务器性能基本上没什么影响，以确保整个网络性能不受影响。它提供了一个简单、高性价比、高可用性、高扩展性和低总拥有成本（TCO）的数据存储方案。

二、SAN（Storage Area Network，存储域网络）与NAS则是完全不同，它不是把所有的存储设备集中安装在一个专门的NAS服务器中，而是将这些存储设备单独通过光纤交换机连接起来，形成一个光纤通道的网络，然后这个网络再与企业现有局域网进行连接，在这种数据存储方案中，起着核心作用的当然就是光纤交换机了，它的支撑技术就是Fibre Channel（FC，光纤通道）协议，这是ANSI为网络和通道I/O接口建立的一个标准集成，支持HIPPI、IPI、SCSI、IP、ATM等多种高级协议。在SAN中，数据以集中的方式进行存储，加强了数据的可管理性，同时适应于多操作系统下的数据共享同一存储池，降低了总拥有成本。

目前在数据存储方面几大主要品牌：EMC、IBM、HP、DELL等，与其他公司相比中EMC是专业从事数据方面的公司，在数据存储方面有其专业的优势。

利用 EMC 恢复管理解决方案，可以从任何中断或事件中快速、轻松、可靠地恢复业务数据。利用 EMC 恢复管理，您可采用一种全方位的做法，即利用集成式软件的备份、复制、连续数据保护(CDP)、分析和报告来保护数据。它结合了简化的管理，以提供关键业务信息的更高级别的可靠性和恢复能力。

主要优点

一、集中化备份管理 — 跨不同操作系统保护您的关键应用程序和数据库，同时集中执行管理并加快总体备份速度。

二、集中化复制管理 — 以实时或接近于实时的方式将电子数据拷贝移动到本地或远程信息存储库。

三、连续数据保护 — 自动为每一次数据更改保存一个拷贝，以便您能够将数据恢复到任一时间点。

四、分析和报告 — 收集、关联备份操作相关信息并发出警报，包括对备份失败执行根本原因分析。

五、简化管理 — 使用管理控制台查看保护和恢复活动，并确定向何处分配更多资源

EMC 同时有针对 Microsoft SQL Server 的数据保护可满足 SQL Server 的可用性和可恢复性要求。利用 EMC 针对 Microsoft SQL Server 的数据保护，并可利用 SQL Server 中的本机功能实现数据恢复和保护。利用 EMC 行之有效的专业技能满足备份和恢复、SLA 遵守能力、人员职责和基础架构规划等方面的要求。

主要优点

一、提高了数据库可用性 — 使用数据库镜像直接在服务器之间传输事务日志记录，并可快速故障切换到备用服务器。

二、增加了应用程序正常运行时间 — 减少备份窗口以减少对应用程序和系统可用性的影响。

三、减少了业务风险 — 通过内置的硬件冗余、RAID 保护和高可用性确保数据能够快速而准确地恢复。

我们通过对存储方式、存储空间、存储性能的比较，推荐选择的数据存储型号为：

EMC Celerra NX4 磁盘阵列柜 包含1个NAS控制器、2个存贮控制器、7个1TB 7200转SATA系统盘、服务器端工具包、管理软件、三年服务。同时支持光纤SAN、IPSAN、NAS功能。（注：7个1TB硬盘作RAID 5，实际可用存贮空间为5TB。）

第三篇：大数据量,海量数据 处理方法总结

大数据量，海量数据 处理方法总结 大数据量的问题是很多面试笔试中经常出现的问题，比如baidu google 腾讯 这样的一些涉及到海量数据的公司经常会问到。

下面的方法是我对海量数据的处理方法进行了一个一般性的总结，当然这些方法可能并不能完全覆盖所有的问题，但是这样的一些方法也基本可以处理绝大多数遇到的问题。下面的一些问题基本直接来源于公司的面试笔试题目，方法不一定最优，如果你有更好的处理方法，欢迎与我讨论。1.Bloom filter 适用范围：可以用来实现数据字典，进行数据的判重，或者集合求交集

基本原理及要点：

对 于原理来说很简单，位数组+k个独立hash函数。将hash函数对应的值的位数组置1，查找时如果发现所有hash函数对应位都是1说明存在，很明显这 个过程并不保证查找的结果是100%正确的。同时也不支持删除一个已经插入的关键字，因为该关键字对应的位会牵动到其他的关键字。所以一个简单的改进就是 counting Bloom filter，用一个counter数组代替位数组，就可以支持删除了。还有一个比较重要的问题，如 何根据输入元素个数n，确定位数组m的大小及hash函数个数。当hash函数个数k=(ln2)*(m/n)时错误率最小。在错误率不大于E的情况 下，m至少要等于n*lg(1/E)才能表示任意n个元素的集合。但m还应该更大些，因为还要保证bit数组里至少一半为0，则m应 该>=nlg(1/E)*lge 大概就是nlg(1/E)1.44倍(lg表示以2为底的对数)。举个例子我们假设错误率为0.01，则此时m应大概是n的13倍。这样k大概是8个。

注意这里m与n的单位不同，m是bit为单位，而n则是以元素个数为单位(准确的说是不同元素的个数)。通常单个元素的长度都是有很多bit的。所以使用bloom filter内存上通常都是节省的。

扩展：

Bloom filter将集合中的元素映射到位数组中，用k（k为哈希函数个数）个映射位是否全1表示元素在不在这个集合中。Counting bloom filter（CBF）将位数组中的每一位扩展为一个counter，从而支持了元素的删除操作。Spectral Bloom Filter（SBF）将其与集合元素的出现次数关联。SBF采用counter中的最小值来近似表示元素的出现频率。问题实例：给你A,B两个文件，各存放50亿条URL，每条URL占用64字节，内存限制是4G，让你找出A,B文件共同的URL。如果是三个乃至n个文件呢？ 根 据这个问题我们来计算下内存的占用，4G=2^32大概是40亿*8大概是340亿，n=50亿，如果

按出错率0.01算需要的大概是650亿个bit。现在可用的是340亿，相差并不多，这样可能会使出错率上升些。另外如果这些urlip是一一对应的，就可以转换成ip，则大大简单了。2.Hashing 适用范围：快速查找，删除的基本数据结构，通常需要总数据量可以放入内存

基本原理及要点：

hash函数选择，针对字符串，整数，排列，具体相应的hash方法。

碰撞处理，一种是open hashing，也称为拉链法；另一种就是closed hashing，也称开地址法，opened addressing。

扩展：

d-left hashing中的d是多个的意思，我们先简化这个问题，看一看2-left hashing。2-left hashing指的是将一个哈希表分成长度相等的两半，分别叫做T1和T2，给T1和T2分别配备一个哈希函数，h1和h2。在存储一个新的key时，同 时用两个哈希函数进行计算，得出两个地址h1[key]和h2[key]。这时需要检查T1中的h1[key]位置和T2中的h2[key]位置，哪一个 位置已经存储的（有碰撞的）key比较多，然后将新key存储在负载少的位置。如果两边一样多，比如两个位置都为空或者都存储了一个key，就把新key 存储在左边的T1子表中，2-left也由此而来。在查找一个key时，必须进行两次hash，同时查找两个位置。问题实例： 1).海量日志数据，提取出某日访问百度次数最多的那个IP。

IP的数目还是有限的，最多2^32个，所以可以考虑使用hash将ip直接存入内存，然后进行统计。3.bit-map 适用范围：可进行数据的快速查找，判重，删除，一般来说数据范围是int的10倍以下 基本原理及要点：使用bit数组来表示某些元素是否存在，比如8位电话号码

扩展：bloom filter可以看做是对bit-map的扩展 问题实例： 1)已知某个文件内包含一些电话号码，每个号码为8位数字，统计不同号码的个数。

8位最多99 999 999，大概需要99m个bit，大概10几m字节的内存即可。

2)2.5亿个整数中找出不重复的整数的个数，内存空间不足以容纳这2.5亿个整数。将bit-map扩展一下，用2bit表示一个数即可，0表示未出现，1表示出现一次，2表示出现2次及以上。或者我们不用2bit来进行表示，我们用两个bit-map即可模拟实现这个2bit-map。

4.堆 适用范围：海量数据前n大，并且n比较小，堆可以放入内存 基 本原理及要点：最大堆求前n小，最小堆求前n大。方法，比如求前n小，我们比较当前元素与最大堆里的最大元素，如果它小于最大元素，则应该替换那个最大元 素。这样最后得到的n个元素就是最小的n个。适合大数据量，求前n小，n的大小比较小的情况，这样可以扫描一遍即可得到所有的前n元素，效率很高。

扩展：双堆，一个最大堆与一个最小堆结合，可以用来维护中位数。问题实例： 1)100w个数中找最大的前100个数。

用一个100个元素大小的最小堆即可。

5.双层桶划分 适用范围：第k大，中位数，不重复或重复的数字

基本原理及要点：因为元素范围很大，不能利用直接寻址表，所以通过多次划分，逐步确定范围，然后最后在一个可以接受的范围内进行。可以通过多次缩小，双层只是一个例子。扩展： 问题实例： 1).2.5亿个整数中找出不重复的整数的个数，内存空间不足以容纳这2.5亿个整数。有点像鸽巢原理，整数个数为2^32,也就是，我们可以将这2^32个数，划分为2^8个区域(比如用单个文件代表一个区域)，然后将数据分离到不同的区域，然后不同的区域在利用bitmap就可以直接解决了。也就是说只要有足够的磁盘空间，就可以很方便的解决。

2).5亿个int找它们的中位数。这个例子比上面那个更明显。首先我们将int划分为2^16个区域，然后读取数据统计落到各个区域里的数的个数，之后我们根据统计结果就可以判断中位数落到那个区域，同时知道这个区域中的第几大数刚好是中位数。然后第二次扫描我们只统计落在这个区域中的那些数就可以了。

实 际上，如果不是int是int64，我们可以经过3次这样的划分即可降低到可以接受的程度。即可以先将int64分成2^24个区域，然后确定区域的第几 大数，在将该区域分成2^20个子区域，然后确定是子区域的第几大数，然后子区域里的数的个数只有2^20，就可以直接利用direct addr table进行统计了。6.数据库索引 适用范围：大数据量的增删改查 基本原理及要点：利用数据的设计实现方法，对海量数据的增删改查进行处理。扩展： 问题实例： 7.倒排索引(Inverted index)适用范围：搜索引擎，关键字查询 基本原理及要点：为何叫倒排索引？一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。

以英文为例，下面是要被索引的文本： T0 = “it is what it is” T1 = “what is it” T2 = “it is a banana” 我们就能得到下面的反向文件索引： “a”: {2} “banana”: {2} “is”: {0, 1, 2} “it”: {0, 1, 2} “what”: {0, 1}

检索的条件“what”, “is” 和 “it” 将对应集合的交集。正 向索引开发出来用来存储每个文档的单词的列表。正向索引的查询往往满足每个文档有序频繁的全文查询和每个单词在校验文档中的验证这样的查询。在正向索引 中，文档占据了中心的位置，每个文档指向了一个它所包含的索引项的序列。也就是说文档指向了它包含的那些单词，而反向索引则是单词指向了包含它的文档，很 容易看到这个反向的关系。扩展： 问题实例：文档检索系统，查询那些文件包含了某单词，比如常见的学术论文的关键字搜索。8.外排序 适用范围：大数据的排序，去重 基本原理及要点：外排序的归并方法，置换选择 败者树原理，最优归并树

扩展：

问题实例： 1).有一个1G大小的一个文件，里面每一行是一个词，词的大小不超过16个字节，内存限制大小是1M。返回频数最高的100个词。这个数据具有很明显的特点，词的大小为16个字节，但是内存只有1m做hash有些不够，所以可以用来排序。内存可以当输入缓冲区使用。9.trie树 适用范围：数据量大，重复多，但是数据种类小可以放入内存 基本原理及要点：实现方式，节点孩子的表示方式 扩展：压缩实现。问题实例： 1).有10个文件，每个文件1G，每个文件的每一行都存放的是用户的query，每个文件的query都可能重复。要你按照query的频度排序。

2).1000万字符串，其中有些是相同的(重复),需要把重复的全部去掉，保留没有重复的字符串。请问怎么设计和实现？

3).寻找热门查询：查询串的重复度比较高，虽然总数是1千万，但如果除去重复后，不超过3百万个，每个不超过255字节。10.分布式处理 mapreduce 适用范围：数据量大，但是数据种类小可以放入内存

基本原理及要点：将数据交给不同的机器去处理，数据划分，结果归约。

扩展：

问题实例： 1).The canonical example application of MapReduce is a process to count the appearances of

each different word in a set of documents:

void map(String name, String document):

// name: document name

// document: document contents

for each word w in document: EmitIntermediate(w, 1);void reduce(String word, Iterator partialCounts): // key: a word // values: a list of aggregated partial counts int result = 0;for each v in partialCounts: result += ParseInt(v);Emit(result);Here, each document is split in words, and each word is counted initially with a “1” value by

the Map function, using the word as the result key.The framework puts together all the pairs

with the same key and feeds them to the same call to Reduce, thus this function just needs to

sum all of its input values to find the total appearances of that word.2).海量数据分布在100台电脑中，想个办法高效统计出这批数据的TOP10。

3).一共有N个机器，每个机器上有N个数。每个机器最多存O(N)个数并对它们操作。如何找到N^2个数的中数(median)？ 经典问题分析 上千万or亿数据（有重复），统计其中出现次数最多的前N个数据,分两种情况：可一次读入内存，不可一次读入。

可用思路：trie树+堆，数据库索引，划分子集分别统计，hash，分布式计算，近似统计，外排序

所 谓的是否能一次读入内存，实际上应该指去除重复后的数据量。如果去重后数据可以放入内存，我们可以为数据建立字典，比如通过 map，hashmap，trie，然后直接进行统计即可。当然在更新每条数据的出现次数的时候，我们可以利用一个堆来维护出现次数最多的前N个数据，当 然这样导致维护次数增加，不如完全统计后在求前N大效率高。

如果数据无法放入内存。一方面我们可以考虑上面的字典方法能否被改进以适应这种情形，可以做的改变就是将字典存放到硬盘上，而不是内存，这可以参考数据库的存储方法。

当 然还有更好的方法，就是可以采用分布式计算，基本上就是map-reduce过程，首先可以根据数据值或者把数据hash(md5)后的值，将数据按照范 围划分到不同的机子，最好可以让数据划分后可以一次读入内存，这样不同的机子负责处理各种的数值范围，实际上就是map。得到结果后，各个机子只需拿出各 自的出现次数最多的前N个数据，然后汇总，选出所有的数据中出现次数最多的前N个数据，这实际上就是reduce过程。实际上可能想直 接将数据均分到不同的机子上进行处理，这样是无法得到正确的解的。因为一个数据可能被均分到不同的机子上，而另一个则可能完全聚集到一个机子上，同时还可 能存在具有相同数目的数据。比如我们要找出现次数最多的前100个，我们将1000万的数据分布到10台机器上，找到每台出现次数最多的前 100个，归并之后这样不能保证找到真正的第100个，因为比如出现次数最多的第100个可能有1万个，但是它被分到了10台机子，这样在每台上只有1千 个，假设这些机子排名在

1000个之前的那些都是单独分布在一台机子上的，比如有1001个，这样本来具有1万个的这个就会被淘汰，即使我们让每台机子选 出出现次数最多的1000个再归并，仍然会出错，因为可能存在大量个数为1001个的发生聚集。因此不能将数据随便均分到不同机子上，而是要根据hash 后的值将它们映射到不同的机子上处理，让不同的机器处理一个数值范围。

而外排序的方法会消耗大量的IO，效率不会很高。而上面的分布式方法，也可以用于单机版本，也就是将总的数据根据值的范围，划分成多个不同的子文件，然后逐个处理。处理完毕之后再对这些单词的及其出现频率进行一个归并。实际上就可以利用一个外排序的归并过程。

另外还可以考虑近似计算，也就是我们可以通过结合自然语言属性，只将那些真正实际中出现最多的那些词作为一个字典，使得这个规模可以放入内存。

第四篇：银行海量交易数据是怎么存储的？海量流水数据如何开放给客户查甚至导出？

银行海量交易数据是怎么存储的？海量流水数据如何开放

给客户查甚至导出？

【CaesarChan的回答(6票)】:其实我想说下，仅“流水数据查询”这个功能还用不到“大数据”的概念。看下百度百科里面“大数据”的概念大数据技术(big data)，或称巨量资料，指的是所涉及的资料量规模巨大到无法通过目前主流软件工具，在合理时间内达到撷取、管理、处理、并整理成为帮助企业经营决策更积极目的的资讯。在维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》中大数据指不用随机分析法（抽样调查）这样的捷径，而采用所有数据进行分析处理。大数据的4V特点：Volume（大量）、Velocity（高速）、Variety（多样）、value（价值）。“合理时间内达到撷取、管理、处理、并整理成为帮助企业经营决策更积极目的的资讯。”分析和决策这才是银行引入“大数据”处理的关键因素。仅仅对于“海量流水数据提供给客户查询”而言，只是满足了客户的某个功能性需求而已。一般来说，银行的数据都是结构化的、持久性存储的（非结构化的数据一般指电子影像，如客户办理业务的回单扫描图片等），以数据库以及文件方式存储为主。按照交易数据性质，我们可以分为“原始流水数据”和“加工后数据”两种。“原始流水数据”一般最开始生成于交易处理的应用程序（这些应用可以理解为前线部队）处理交易的过程，几乎记录了交易的所有内容：交易日期、交易时间、卡号、账号、地区号、网点号、地点、终端编号、柜员编号、交易凭证（如Transaction Certification）、交易渠道等等等等乱七八糟你想得到想不到的字段。曾经见过一张表，多达数百个字段，一条记录长度多达数千字节。这类数据的特点是，信息全面，占用空间大。“加工后数据”产生于“原始流水数据”，一般情况下，“前线部队”会把“原始流水数据”提供给其他应用程序（可以理解为后勤部队），“后勤部队”会根据自身应用的需求将数据进行裁剪而不是照单全收。简单举个例子，假设用户拿到的信用卡对账单是由一个叫做“客户账单”（Customer Statement，下面简称CS）的应用生成。CS会根据业界的标准从交易流水中获取仅需的数据，比如交易日期，商户名称、卡号、交易币种、交易金额等。其他并不需要的数据就会被舍弃，这样也就保证了数据存储的经济性。好了，经过上面的理论准备，我们来设计一个“历史数据查询”（Historical Data Inquiry,下面简称HDI）的应用，首先看下它的功能和特点：1.需要支持对客户历史流水数据的查询；2.需要很大的存储空间；3.交易以查询为主；4.数据插入的时效性不高，没有数据删除操作；可以看出，HDI应用的设计难点主要在存储空间、查询速度、数据更新方式方面。让我们以银行卡历史流水数据查询交易为例，一个个分析这些难点应该如何解决：1.存储空间。我们之前举了“原始流水数据”的特点：信息全面，占用空间大。为了解决这个问题，我们首先可以来一次数据的裁剪，HDI本来也是个“后勤部队”，抄起大砍刀一阵猛砍，只留下交易渠道、交易日期，商户名称/网点名称、卡号、交易币种、交易金额几个字段。几千个字节一下减为200个字节。但这样就结束了吗？还没有！积少成多的道理大家都知道，一条记录多50个字节，100条记录就多5000字节！还怎么砍？二八原则，让我们从商户名称来想办法！举个例子（请勿对号入座）：“内蒙古自治区锡林郭勒盟东乌珠穆沁旗满都胡宝拉格镇满都宝拉格苏木小学小卖部”，整整36个字，72个字节，每做一笔交易HDI就要给一份存储的钱啊！咋办？加个设备档案参数表，再多也不过超过百万级的数据，每个商户只存一次，流水表里面只存个10位的端机编号，查询的时候展示出来，存储空间立马就节省出来了。解决办法：数据裁剪、档案参数表。2.查询速度。首先需要分析下，这类交易的量大不大？数据变动多不多？查询条件复不复杂？分析一下我们就可以知道，大多数此类业务的场景都是“拿流水办证明”，交易频度并不高；作为历史数据，“What's done is done”,不存在太大对已插入数据变更的概率；查询条件也一般为卡号+时间区间。在大海里面捞针很困难，但在水杯里面找颗茶叶还是很容易的。我们的策略就是：对数据库进行分库、分区、分表，简单的理解：把长袜子和短袜子放在不同的抽屉里面，想找的时候就拉对应的抽屉即可！具体可以把数据库按时间区分，按卡号区间区分，在进行数据查询的时候就事前指定方向，这样跟从大堆数据里面捞东西相比就快了很多了。解决办法：数据库分库、分区、分表，限定查询的灵活性。3.数据更新方式。既然说是历史数据查询，那么也就没有实时性的需求，HDI可以通过后台批量的方式将数据慢慢进行裁剪、插入，每天/每周/每月加载都可以，数据量再大都有充足的处理时间。解决办法：后台批量更新。总结：单纯就“海量流水数据如何开放给客户查甚至导出”这个功能来说，还用不到“大数据”这样高大上的概念，使用传统的技术加上设计的一些构思就完全能够实现。而对数据的分析和处理，以便获得可供决策的关键数据，这才是“大数据”概念的关键所在。毕竟，无论你查或不查，历史明细就在那里，不增不减；市场才是瞬息万变，大数据分析的准确性、时效性才是赢得市场的关键砝码。就数据“银行海量交易数据是怎么存储的”这个问题，@du不知道已经答复比较清楚了，这里就不赘述了。PS:多谢 @detail lee指导，补充下表达下：1.开放提供给客户查询的数据只是银行海量数据的一小部分，这部分数据是可以通过传统的方式截取、存储手段展现的;2.大数据的存储、处理，目前银行业多使用数据仓库，TeraData技术来实现,主要作为内部数据分析处理使用；3.存量“原始流水数据”银行还是主要使用磁带备份方式。4.银行IT的现状是对新技术的使用还是比较慢比较谨慎，特别是对已有系统的升级改造更是慢，真需要跟业界（特别是金融界的其他IT）取经多学习。【du不知道的回答(4票)】:个人了解：

1、就存储来说，一般会按照时间维度划分，时间近的存当前库，时间久的存数据仓库。时间近的就是普通库如主机db，时间远得就数据仓库。目前数据仓库国内采用技术几乎全是td，它可谓数据仓库届的老大，但成本较高。

2、按照政策要求，银行是需要保留15年的数据供审计。数据存储也是按照一年，三年，等时间划分。目前几大行建成数据仓库的不多。

3、客户的查询一般简单，银行数据库端行已经是做到了读写分离，支撑查询没有问题。

4、对于处理加工分析一般是在数据仓库处理，如一些报表等。它一般供业务人员查询，并发用户较少。分析可用sas等建模进行分析。

5、由于银行一般是非实时数据的分析处理，目前也可以采用Hadoop平台进行处理，但处理速度远不如td。【杨博的回答(2票)】:不邀自来。题主想单纯了解银行数据存储及查询所涉及到的技术的话，我可能还是能够说点什么的。银行客户群体庞大且数据细致条目众多，这使得银行每天的交易所产生和涉及到的数据量极为庞大。根据人行和银监会的要求，对每个交易账户，银行需要保存长达15年的数据。但实际上我们只能查询近一年的交易数据。这是因为银行所有的用户数据通常都是静态存储的，而近一年的数据是做了数据持久化的。而且通常这些数据都是分布存储在各省分行的。静态存储就是将数据集中存储在数据库集群中，这部分数据不会经常被查询，因此可以直接存在数据库的物理文件中，直接以文件的形式存在于硬盘上。这种存储方式是查询不友好的，也就是说查询一次耗费的时间和性能是比较高的（尽管这种消耗对于我单次查询是可以忍受的，但由于用户量巨大，可能同一时间会有很多次查询，这就会极度占用系统资源），因为每次查询数据都要直接从硬盘读取数据。对于提供给用户经常查阅的近一年的数据肯定不能仅仅通过这种方式存储。所以出现了另一种方式，就是为能够经常被查阅的数据做数据持久化。数据持久化实际上是一种计算机技术，通过这种技术，系统可以将数据库中的一部分数据动态加载到内存中，提供一个更高速性能更好的数据源供系统查询。这就使得用户可以即时查询自己近期的全部交易记录。除此之外，实际上用户每天的交易数据也不是实时记录到数据库文件中的，这些数据都是以天为单位向数据库体提交的。以上是关于一年内可查询数据的存储方式。这些数据用户可以通过终端或者网银随时查询。至于一年以上的用户数据，通常都是直接从静态数据中查阅的，而且也不是任何一个用户都能随时查阅，必然要提交申请获得，有的还需要等待到一个工作日出结果。这就是因为这样大量对静态数据的查询比较耗时，银行会集中查询。银行应该还没有哪家可以提供用户从开户以来但现在的所有数据，而且也没这个必要。除非是开户不超过15年的。存储数据成本非常大。多一个月的不必要数据都会使成本大增。各银行，无论大小，所使用的数据库无非oracle db2等等，而且由于用户数据与交易记录通常联系紧密，因此通常都是关系数据库。之前说过，这些数据库是分布式的，就是为了满足各个省分行对本地区账户的访问。但通常总行都有数据中心来存储最终固化的数据。至于数据的分析，这个由于不需要即时查询，可以集中处理。说了这么些，纯粹是从技术人员的角度说了银行数据的存储及访问。如果有不明确的或者疏漏的，请后来人补充。题主还有疑问可以继续追问。【爻艮兑的回答(1票)】:一般都是分级分档分别存储的。比如当月数据存交易系统实时库里，一年内的存在数据仓库里，三年内的存数据仓库历史库里，三年以上的存带库里。至于你说的交易对账单这样的给客户看的东西一般都是加工好的成品数据，所以可以存很久很久的，那才占多大点空间啊！银行的科技系统其实比绝大多数的互联网科技企业要复杂而庞大得多。【邓昳轶的回答(1票)】:历史数据查询在很长时间内都是国内各大银行的软肋，特别是对客部分。直到大数据技术的出现，那些说大数据炒作的人睁开眼看看，至少大数据技术解决了实际问题不是吗？据我所知，各大行试水大数据都是从历史数据查询开始的，有些行已经建成了。我们行也在启动了，差不多也是HBASE这一套，现在还不敢说效果，等建好了再来答您。不过可以预见的是，性能不是问题，数据治理方面才是真正的难点。【detaillee的回答(0票)】:是不是都在用hbase技术架构？【ltye的回答(0票)】:谢邀，我不负责数据平台和业务系统，了解的不是太多~ 不过我们行的核心系统数据都是结构化、关系型数据库存储的。【知乎用户的回答(0票)】:除个别大的银行的历史数据可能较多，单就某个银行的数据来说，算不上海量。原文地址:知乎

第五篇：NAS存储与数据备份方案

NAS存储与数据备份方案

数据备份部分是整个网络系统的关键点，任何原因造成数据丢失都将带来无法估量的损失，因为这些数据涉及到公司各应用系统（包括缺陷、动态成本、点检、物质仓储、大宗物料、生产运营等系统），为了保证各系统的正常运行，必须保证能随时访问生产数据、查询历史数据。一旦发生意外导致数据丢失（包括系统崩溃、数据的丢失等），造成影响难以估计。

NAS（Network Attached Storage：网络附属存储）是一种将分布、独立的数据整合为大型、集中化管理的数据中心，以便于对不同主机和应用服务器进行访问的技术。按字面简单说就是连接在网络上, 具备资料存储功能的装置，因此也称为“网络存储器”。它是一种专用数据存储服务器。它以数据为中心，将存储设备与服务器彻底分离，集中管理数据，从而释放带宽、提高性能、降低总拥有成本、保护投资。其成本远远低于使用服务器存储，而效率却远远高于后者。

NAS数据存储的优点：

1、NAS适用于那些需要通过网络将文件数据传送到多台客户机上的用户。NAS设备在数据必须长距离传送的环境中可以很好地发挥作用。

2、NAS设备非常易于部署。可以使NAS主机、客户机和其他设备广泛分布在整个企业的网络环境中。NAS可以提供可靠的文件级数据整合，因为文件锁定是由设备自身来处理的。

3、NAS应用于高效的文件共享任务中，例如UNIX中的NFS和Windows NT中的CIFS，其中基于网络的文件级锁定提供了高级并发访问保护的功能。

公司现有存储及备份模式已经无法满足日益强大的信息系统，现急需建立一套先进的存储备份管理系统，以合理利用存储资源为基础，突出以数据为中心，实现高效的存储与数据管理，给诸多宝贵的数据提供安全、稳定的环境。

基于以上NAS系统的种种优点，结合公司实际情况，决定采用NAS系统来升级公司的存储与备份现有模式。

下图为目前的拓扑图，需要操作服务器的数量多，数据的完整性无法得

到很好的验证。

下图为添加NAS存储系统后的拓扑图，在不改变当前网络环境的状态下，直接将NAS存储系统连接至二层交换机，快速投入使用，同时支持基于Web的GUI远程管理，大大提升了备份效率。

以后的建议：可逐渐扩大NAS存储系统的应用，利用双机冗余备份，实现数据同时同步的异地容灾备份，拓扑如下：