我们早已步入大数据与云计算的时代，什么数据分析、公有云、私有云、混合云听起来感觉很复杂，让人受不了，但是，若你细心观察，你就会发现“存储”很重要，所谓大数据，就是数据越来越多了，怎么把数据存留下来？那自然是需要存储了，今天就来看看了解下存储，及其中的奥妙吧。

数据压缩

首先，是数据压缩，数据压缩是能够影响存储密度的存在，简而言之就是这种空间节省技术可以识别重复样式或者说是冗余数据并将其清除。数据压缩的特点就是可以缩减数据量减少存储空间，你不用担心有用信息会丢失，这样既可以提高其传输、存储和处理效率。数据压缩宝包括有损压缩以及无损压缩，但是这种压缩方式也是需要处理器的消耗的，所以，很多存储需求者和企业级存储供应商考量的重点就是——数据压缩的平衡点在哪里有必要去研究下。

空间高效快照和克隆

由于在网盘和NAS比较普遍的时代，快照和克隆都是经常会出现的，就算没有看过企业级应用场景的快照和克隆，相信大家也是见过“百度快照”吧。

这两种技术不是像数据压缩那样，是一种空间节省技术，他们是一种对数据的保护功能。快照是在线存储设备防范数据丢失的有效方法，快照成为磁盘阵列、卷管理器、文件系统及独立磁盘冗余阵列控制器的标准配置功能，已不是什么稀奇的事情了。有一些节后中，快照的使用是有一些性能隐忧；还有一些架构师要求有保留空间来用于快照池的，还有一些平台是没有限制的。

还有很多技术名词，像是重复数据删除、精简配置、零页回收、内联、后处理与数据hush等。都需要我们去了解，我们才能明白真正含义。

很多大数据都具有空间位置信息，这些空间大数据可以通过大数据GIS技术进行高效存储、索引、处理和分析。另一方面，经典GIS所需面对和处理的数据规模也在快速膨胀，对于经典GIS中超大规模数据的处理与分析，同样需要大数据GIS技术作为支撑。经典GIS中常用的缓冲区分析、叠加分析、空间查询等算法都可以通过大数据GIS技术进行分布式重构，用以面向不断膨胀的超大规模数据。

一、经典GIS数据存储方案

在各种GIS项目应用当中，首要设计的就是数据存储方案。在经典GIS当中，典型数据类型包括矢量的点线面数据、影像和栅格数据、地图缓存瓦片数据等类型。在存储引擎类型方面，使用较多的类型包括以PostgreSQL为代表的SQL数据库型存储，以及众多NoSQL型数据库，包括以MongoDB为代表的文档型数据库，以HBase为代表的列存储数据库，以Redis为代表的key-value型数据库等。随着互联网应用的深入，各种NoSQL型数据库得到了快速发展，并具有支持分布式可扩展部署，高性能读写等特征，因此在大数据GIS技术中，有必要对其进行吸收和融合。

在大数据应用中，由于涉及的数据体量巨大，存储和计算环境的部署强调二者的一体化，或者通过计算向数据靠拢来实现高效的数据读写。在海量空间数据场景下，需要通过空间索引技术将节点内的数据尽可能的保持完整性和独立性，尽量避免节点间的数据交换，从而实现高效的分布式计算。

1、PostgreSQL

PostgreSQL是一个功能强大的开源关系型数据库系统。可以支持各种主流操作系统，它完全兼容ACID，完全支持外键，连接，视图，触发器和存储过程（使用多种语言）。在GIS应用当中，可以使用它进行矢量点线面数据，栅格数据的高效存储和查询，由于它完全支持ANSI-SQL：2008标准，因此可以基于其上定制各种业务化的查询和存储过程。另一方面，基于其上的PostGIS数据库可以直接进行空间对象的存储和索引，并支持高效的查询，以OpenStreetMap为代表的很多GIS应用直接基于PostgreSQL引擎之上构建存储层。

2、MongoDB

MongoDB是一个基于分布式存储的NoSQL文档型数据库，它是一个介于关系型数据库和非关系型数据库之间的产品。大多数NoSQL都提供较少的关系型数据库特征，但MongoDB是个例外，其对于SQL查询支持较为丰富。其BSON形式的数据结构非常适合进行缓存瓦片的存储，而缓存瓦片的使用往往也不要求过多的SQL查询语法支持。另一方面，它也同样可以进行矢量点线面的存储，并且内置了Spatial扩展可以支持空间索引和空间查询。

3、HDFS

HDFS是一种分布式文件系统，它虽然不是一种数据库产品，但由于其是Hadoop生态体系的基石，且与Spark技术无缝结合，因此在大数据实施时，经常被用来作为一种通用型存储方案。在大数据GIS当中，其使用方式主要有两类，一种是直接作为文件系统，将csv、json格式的大文件放置其上进行直接存储，另一种是作为Spark计算引擎的存储方案，使用自定义的二进制格式存储空间数据，并进行空间二级索引设计和实现，以高效对接Spark分布式计算。

二、经典GIS数据处理方案

由于各种存储引擎特点不一，因此在项目实施中，如何选择最适合的存储和计算方案，需要与项目的具体使用背景相结合。我们建议从数据规模（千万级、亿级、十亿级还是更大）、数据更新频率（年、月、日还是更小）、数据处理复杂性（SQL查询、空间查询还是复杂空间运算）等几个维度进行综合考量。我们选择了几个较为典型的应用场景，进行具体说明。

1、千万级实时更新

该应用的典型客户为政府各单位的分中心，虽然全国范围内的汇总数据规模庞大，但省市分中心单位维护的子库数据规模在千万级左右。虽然数据规模不大，但是具有业务逻辑复杂，要求实时更新的特点，因此推荐根据业务场景，灵活使用Oracle或UDB数据库型引擎。可以进行实时更新，也可以根据复杂业务进行较复杂的SQL查询检索。并且可以对接Spark计算引擎，进行大规模数据的复杂计算。

2、亿级准实时更新

该应用的典型客户是部委的全国级主中心，从各省市分中心汇总的数据规模可以达到亿级到十亿级规模，更新频率低于分中心的实时业务系统，但也需要具备一些SQL查询能力。此时推荐使用PostgreSQL或MongoDB进行分布式存储，一方面可以支持数据的动态扩展，另一方面也可以支持一定的SQL查询。当然也可以对接Spark计算引擎，进行业务计算。

3、十亿级低频更新

该应用的典型客户也是部委的全国级主中心，可能需要对汇总的多年份历史数据进行时间序列分析或者综合性分析。此时的数据更新频率较低，可能是以年为单位，但总体的数据规模非常庞大，可能达到十亿甚至百亿规模。此时推荐使用HDFS进行数据存储，再对接Spark技术进行分布式计算，对这种超大规模的空间数据进行处理和综合分析。

三、经典GIS应用案例

矢量数据的空间叠加赋值算法，是国土测绘领域这样的大规模矢量数据分析常用功能。SuperMapiObjectsjavaforSpark以该算法为例，讲解大数据技术如何提升经典GIS数据处理和分析性能。矢量数据分析的基础是高效的空间索引，而分布式矢量分析同样需要基于空间索引进行加速。

1、分布式构建空间索引

分布式构建空间索引根据整体流程，又可以细分为索引对象构建，数据集重分区，索引后数据缓存等几个子过程。较常使用的索引类型有均匀格网索引和四叉树索引两种。索引对象构建后可以广播到集群各节点，数据集重分区过程各节点可以获取该对象进行空间对象处理。由于后续的叠加赋值计算需要基于索引后数据进行，所以SuperMapiObjectsjavaforSpark需要把重分区后的数据缓存下来，以kryo序列化的方式将数据缓存到HDFS上。

2、分布式叠加赋值计算

由于在前面的分布式构建索引过程中，SuperMap iObjects java for Spark把按照索引重分区后的数据缓存到了HDFS上，因此在进行叠加赋值计算之前，SuperMap iObjects java for Spark首先需要将数据从HDFS上读取到Spark的RDD中。在读取之后，就可以基于索引后的FeatureRDD进行两图层间的叠加计算了。由于叠加赋值一般涉及被更新数据和更新数据两个数据集，所以SuperMap iObjects java for Spark使用RDD的zipPartitions接口来将两个RDD进行组合。

四、经典GIS性能提升测试

SuperMap iObjects java for Spark使用的测试环境的单节点操作系统为64位Ubuntu 16.04 Linux系统，CPU为英特尔酷睿i7-6700K，四核处理器，主频为4 GHz，硬盘为1 TB，内存为16 GB。Spark集群配置为一个Master节点，四个Woker节点，即五台同配置的PC机环境。使用的Hadoop版本为2.7.3，Spark版本为2.1.0。

测试数据局部放大图

为了保证测试的有效性，SuperMap iObjects java for Spark设计了规模不等的三组矢量数据进行分析计算。A组数据被 更新图层图斑对象数目为10万，更新图层（即提供属性值的图层） 图斑对象数目为80。

两图层数据分布特征为：更新图层的单个矢量面对象面积显著大于被更新图层对象，但二者的总体图斑覆盖范围相近。B组数据被更新图层图斑对象数目为100万，更新图层图斑对象数目为800，两图层数据分布特征与A组数据类似。C组数据被更新图层图斑对象数目为1000万，更新图层图斑对象数目为1万，两图层数据分布特征与A组数据类似。SuperMap iObjects java for Spark将分布式改进后的方法与传统GIS软件的单节点叠加赋值功能进行了性能对比，结果如表1所示。

表1性能测试结果

从测试结果可以看出，基于大数据技术的矢量数据叠加赋值方法，在不同级别的实验数据下，相比传统GIS单节点功能都有更好的性能表现。在小规模数据量（数据A）场景下性能有约33%的提升，在中等规模数据量（数据B）场景下性能有约71%的提升，在大规模数据量（数据C）场景下性能有约90%的提升，图2使用柱状图来更为直观的进行结果展示。

在对常用的GIS核心算法进行分析之后，我们认为：大多数的经典GIS核心算法都可以进行分布式算法改进，即使用大数据技术进行海量空间数据处理和分析的性能提升。目前SuperMap iObjects java for Spark已经完成的算法包括空间查询、叠加分 析、缓冲区分析、属性更新、矢量裁剪等功能，后面还计划针对矢量数据处理，拓扑检查等经典GIS常用功能进行进一步的升级改进。

内容来源：超图

大数据将给各行各业带来巨大的价值，例如医疗保健、电商零售等行业。大数据涉及IT和营销部门：它不仅是一个技术问题。同时，大数据将可能提供真实的、可操作的决策信息。虽然目前大数据趋势正在迅猛发展，但很多人并不是完全清楚如何管理数据。尽管存在这种不确定性，不过大家越来越多地达成共识：大数据能够带来价值，企业已经开始投资于基础设施系统来实现大规模存储和数据分析。

在企业蔓延的大数据

对于传统基础设施而言，因为太大而无法被有效地和充分地捕捉、管理、存储和分析的数据集被称为大数据。现有的数据存储系统无法分析大数据，限制了大数据的增长。现在企业非常需要新的存储、网络和计算系统来处理大数据。

大数据将可能帮助所有行业的各种规模的企业保持竞争力，帮助企业削减成本、简化工作流程和生产力，提高产品质量和推出新产品或新的服务。分析其客户数据的企业能够更好地分析其客户在使用什么以及需要什么。

为什么大数据需要可扩展的存储解决方案

存储基础设施投资将提供一个平台，通过这个平台，企业能够从大数据中提取出有价值的信息。从大数据中能得出的对消费者行为、社交媒体、销售数据和其他指标的分析，这将直接关联到商业价值。随着大数据对企业发展带来积极的影响，越来越多的企业将利用大数据，以及寻求适用于大数据的数据存储解决方案。而传统数据存储解决方案(例如网络附加存储NAS或者存储区域网络SAN)无法扩展或者提供处理大数据所需要的灵活性。

云存储用于大数据

这不只是关于为大数据购买更多的存储：数据需求会无限增长，这会导致更大的存储需要。云计算的可扩展和灵活的性质使其成为大数据管理的理想选择。通过基于云计算的存储系统，数据集可以被复制、迁移和保存在世界的任何地方。通过将基础设施放在云供应商处，这简化了扩展和缩小基础设施的工作。块存储特别适合于大数据，因为它是一种独立的存储解决方案，这种方法允许研究人员和分析师非常迅速地访问、分析和管理数据。因为云计算方案，企业不再需要开发、托管和维护自己的基础设施，显著降低了成本。

问题不在于企业是否会利用大数据，而是合何时利用大数据。目前的数据存储基础设施并不适合有大数据管理，而云计算提供了一种简单的具有成本效益的方式，用来处理、存储和管理大数据。很多云计算供应商提供块存储或对象存储，这都是大数据的理想选择。

大数据的最底层的内容就是存储，只有把数据存在能高效访问的分布式系统下才能提升工作效率。今天小鸟就带大家来盘点一下这些常见的分布式文件系统：

Lustre

Lustre是一个非常安全，规模很大的分布式文件系统，最早由CFS（Cluster File System Inc.）公司研发，最后由CFS、惠普和因特尔三家公司一起与2003年推出第一版发布版，发展到现在已经非常成熟。其存储量通常以PB起步，节点支持数也能打到万级。但是其对设备有特殊要求。

HDFS

HDFS是Hadoop内置的分布式文件系统，之前也有过介绍。HDFS最大的优势就是价格低廉，因此也使用极为广泛。并且其高可靠性，高容错性也让使用者非常信赖。虽然HDFS的存储级别也在PB以上，但是对于小文件过多的情况HDFS不能很好的支持。

QFS

QFS和HDFS类似，都是为了解决高效顺序读写大量数据的问题。但是QFS在性能上优于HDFS，读写效率提升综合越60%。现在QFS还比较小众，没有经过大量的使用测试，因此还不能用于大规模的生产环境。

GlusterFS

GlusterFS也是一个PB级别的集群文件系统，其思想是将集群内所有服务器的存储空间汇到一个大的网络系统上。这样做最大的特点就是无中心，不会有单点故障。

Alluxio

Alluxio是第一个基于内存的分布式文件系统，因此其相应速度也会超出普通的分布式文件系统很多，例如HDFS就比它慢数百倍。并且Alluxio和Spark也有良好的交互。最重要的是Alluxio中国人开发的，文档都是中文的，对于被英文文档困扰很久的小伙伴绝对是福音。

Ceph

Ceph也是一个没有单点故障的分布式文件系统，Ceph的每个节点上都有一小部分资源用于计算节点的数据信息，从而非常优秀的实现负载均衡。

PVFS

PVFS是一个并行虚拟文件系统，他能很好的支持linux上的原声命令和工具，例如rm、dd、cat等。但是PSFS是单管理节点的，因此存在单点故障，并且在启动后无法灵活的修改。

想学习更多大数据知识欢迎关注小鸟，转发评论收藏然后私信小鸟，有机会领取大数据入门教程一份。关注小鸟，福利多多。

489034603

由于大数据的迅猛发展，数据正在呈指数级增长，各种传感器的剧增，高清晰度的图像和视频都是数据爆炸的原因。腾讯、淘宝掌握了大量的用户数据，力图描绘出用户的整体“画像”。面对大数据的汹涌来袭，传统的数据存储和数据库技术已经难以应对，那么，大数据技术如何存储海量数据并提高系统容错性？目前，较为主流的海量文件存储技术有Google的GFS和Hadoop的HDFS，HDFS是GFS的开源实现。它们均采用分布式存储的方式存储数据，用冗余存储的模式保证数据的可靠性。

下面我们通过几个问题，来让大家更好的了解数据存储应该如何解决？

1、大数据的处理流程包括了哪些环节？每个环节有哪些主要工具？

数据采集： 半结构日志文件可使用flume； 结构化数据可以使用传统的E TL工具如，datastage、kettle 等等

数据存储：hadoop hdfs存储海量数据；也可用传统的oracle、sysbase iq等数据仓库解决方案

数据统计： 使用hive、impala对hadoop进行统计分析；

数据挖掘：可使用mahout进行数据挖掘

2、大数据的数据库相比于传统数据库有何变化？出现了哪些新的大数据的数据管理方式？

量大、结构多样、速度要求高等特点； 出现了以hadoop为代表的分布式存储和nosql等数据存储管理方案

3、大数据工程师应该都知道，现在处理大数据文件的存储，比较典型的有Google的Big Table和Hadoop的HBase，它们有哪些相似点和不同点？

Hadoop的HBase是Google的Big 的开源实现，每个人都可以下载来使用，也可以根据自己需要进行修改和完善

以上都为个人观点，谨供大家参考一下，如果感觉写的可以，即可给自己一个比较准确的定位，为以后的学习找准正确的方向。

另外，如果小伙伴想学习大数据技术，可以加下图片下面的交流群，群里有很多学习视频都可以下载，而且每天大数据架构师马士兵老师都会在群里分享大数据的技术。。

根据IDC研究报告，未来10年全球数据量将以40%多的增长速度呈直线上升趋势，2020年，全球的数据量将达到35ZB（35,000,000PB），是2010年的40倍。换句通俗的话说，也就是每过1分钟，全世界就有1820TB的新数据产生。

数据量的急速膨胀

随着互联网、移动互联网、物联网等技术的发展，一个城市的数据生产在飞速的发展，信息就成了一个企业的战略子站，市场竞争和政策的管制要求越来越多的数据被长期的保存。不仅仅是企业需要保存数据，政府也越来越开始注重各类信息数据的收集、保存和备份，从而进行用户行为分析、市场的研究。

大数据的分析

与传统数据分析相比，用于大数据分析的数据集合主要有2点区别：第一，传统模式大都采用通过采样的方式获得部分数据用于分析，而大数据可以对收集到的所有的数据进行分析，分析用的数据源由采样数据扩展至了全部的数据；第二，传统分析更加关注数据源与分析结果间的因果关系，大数据分析时数据源与分析结果不再只是因果的关系，基于有相关关系的数据源同样可以分析并且预测出正确的结果。

大数据的分析给传统的数据分析和处理技术带来了很多挑战。云计算和开源技术的发展推动大数据落地，分布式存储、非关系型数据库和并行处理技术逐渐成为大数据应用实施过程当中的关键技术。开元Hadoop为大数据提供了各个层面的技术支持，这也是当前形势下应用最广泛、关注度最高的大数据项目。Hadoop几乎已经成为了大数据处理的事实标准。

大数据的存储

谈到大数据的分析，就必不可少的在这之前，需要对大数据进行存储和备份。大数据的存储需要满足海量的存储、安全存储和快读读取的要求，目前应用较广的主要有Hadoop分布式文件系统。据江苏爱科赛尔云数据的责任人表示：“作为数据服务公司，技术是最根本的，而目前首要的就是把重心放在原始数据的高压缩和去重技术上。”另外，针对大数据的存储和备份，一些市场上主要的需求和建议在今年也被大家开始提出：

1、大数据存储和备份系统对备份的文件格式应该采取多样化的设定，即无论何种形式的文件，均可以使用软件进行存储和备份；

2、大数据存储和备份在执行任务的时候，在LAN或WAN时都应该达到最低网速，及时在网速较慢的情况下（256kbps）也能进行快速的备份和上载。

3、针对国内情况，对于虚拟机本身的备份和恢复应该开始重视起来；

4、在软件报错的时候，应该能够进行自我的修复，而不是当软件报错的时候就导致企业无法进行顺利的存储和备份；

5、增加Failover和Failback的失败自动切换和失败自动恢复的模式，这样一来就可以似的操作智能化，在遇到错误的时候能够自动重新选择其它线路，而不是一味的停在原地。

随着互联网发展日趋成熟，常规存储已经满足不了用户的服务需求，而大数据拥有（大量、高速、多样、低价值密度、真实性5V特点。使数据存储领域发生着剧烈的变化，而且这种变化将是长期的一种趋势。而随着数据存储领域的革新变化，必然将催生中一些更新的技术产生，必将改变存储领域的持续发展，未来有哪些存储技术会改变未来呢？

以太网硬盘

　　希捷日前宣布了其以太网连接的动能硬盘，该公司宣称以太网硬盘将提供比现在有可能高达四倍存储应用性能。以太网硬盘的设计思路非常明显，就是要精简数据到硬盘之间的传输环节（即数据无需从服务器到HBA卡再到阵列控制器最后被写到硬盘中，在以太网硬盘的系统中，数据可以直接经网络到硬盘的以太网接口进而存进硬盘中）。

氦气填充磁盘

　　HGST在之前推出了其首款6TB充氦硬盘填充氦气的驱动器，这款产品的好处是，它能够使用更多的旋转盘片驱动器 ，增加产品性能能。而且氦提供更小的阻力，以防止盘片，因为过多摩擦导致更多的热量消耗。

高性能相变存储器/ NAND混合固态存储

　　相变存储器（PCM）是作为固态硬盘（SSD）替代的使用的标准NAND（闪存）内存。相变存储器（PCM）是一种非易失存储设备，它利用材料的可逆转的相变来存储信息。是利用特殊材料在不同相间的电阻差异进行工作的。IBM预计，在此基础上的混合PCM技术的存储产品将在2016年。

IBM 154TB的磁带

　　在2014年5月，IBM与富士胶卷已经公布一款154TB LTO磁带库的演示方案，并将在未来十年内正式投放市场。凭借着自身强大的磁带合作关系网、IBM完全有机会将索尼一举逐出角斗擂台。先进的伺服控制技术能够让磁头实现纳米级别的准确定位。新的信号处理算法使运行状态更为可靠，同时配备极为精密的90纳米磁巨阻磁头（简称GMR）读取机制。

遗传存储

　　哈佛大学研究人员将一本大约有 5.34 万个单词的书籍编码进不到一沙克（亿万分之一克）的DNA微芯片，然后成功利用DNA测序来阅读这本书。这是迄今为止人类使用DNA遗传物质储存数据量最大的一次实验。由于DNA分子是非常致密的存储介质，1克的DNA可以保存2000TB的数据量。

过去 10 年，随着互联网技术的快速发展，数据库呈现井喷式发展，出现了各式各样的产品，如文件存储数据库、列存储数据库、NewSQL 数据库。之所有如此，归结于数据量不断快速膨胀，传统数据库在大数据上的处理性能不能满足需求等。企业和开发者趋于去针对不同应用类型开发不同的数据库，来满足对特定数据处理的需求。

阿里巴巴在多种场景下同样有不同的数据存储技术实践，比如：

海量数据场景下的 OLAP 列式数据库 —— HiStore

HiStore 是一款基于独特的知识网格技术的列式数据库，定位于海量数据高压缩比列式存储，是低存储成本，低维护成本，海量数据 OLAP 存储引擎；有效的解决了海量数据存储的成本问题，以及在百亿数据场景下支持实时高效的多维度自由组合的检索。适用场景：

日志/事件管理系统：调用链路日志跟踪，消息轨迹分析，系统/网络安全审计记录;

通信行业：话单分析，用户行为分析等;

大数据量的分析应用：网页/在线分析，移动分析，客户行为分析，营销和广告数据;

数据仓库/数据集市：实时展示统计分析后数据，便于用户根据统计结果做决策;

对数据存储成本敏感，查询有实时性要求的场景应考虑HiStore;

物联网：保存大量物理节点的采集上报，状态等信息，用于后期统计处理;

历史评价数据，历史订单数据等。

高性能时间序列数据库 —— HiTSDB

HiTSDB 是阿里自主研发的面向物联网及相关领域的高性能时间序列数据库产品，支持每秒1000万时序数据点写入；具备PB级别的数据存储能力，提供高效压缩算法，整体存储成本降低90%；提供时序数据插值计算，降精度计算，时间纬度聚合计算，空间纬度聚合计算的能力。主要解决以下问题。

大规模的物联网设备的时序数据高并发写入；

低成本的存储；

灵活高效的数据分析能力。

在线海量数据处理分布式数据库 —— Lindorm

Lindorm 是新一代面向在线海量数据处理的分布式数据库，目前公布的资料不多。在 10 月 11 日- 14 日杭州云栖大会的“互联网新型数据库专场”上，阿里将公布 Lindorm 更多技术详情。届时，阿里的技术专家将通过分享这些多种场景下的数据存储技术实践，帮助企业更好地理解各种数据存储技术的特点，针对自己的业务发展对数据存储技术进行选择和组合。

原文地址：http://linuxprobe/aliyun-databases.html

从“大数据”时代被宣称到来的那一天，至今日，数据量已经几何倍数的翻增，数据，已经渗透到当今每一个行业和业务职能领域，成为重要的生产因素。

大数据的第一个特征是数据量大，大数据的起始计量单位至少是P、E甚至 ZB级别；第二个特征是数据类型繁多，包括网络日志、音频、视频、图片、地理位置信息等等。

同时，海量多类型的数据对数据的处理能力提出了更高的要求，不仅要提供海量的数据存储空间，又要满足多种类文件的高效存储。

目前，解决这种需求最常用的方式就是采用分布式存储系统。

分布式存储存放的数据，包含数据和元数据信息，那么什么是数据和元数据呢？

用户需要存放到存储设备的文件，就是数据

数据有很多种类，日志、音频、视频、图片等，不同的文件大小是不同的。

存储设备为了存放用户文件而生成的数据记录，就是元数据

如果用户数据比喻成一本书，元数据就是这本书的目录。

分布式存储依照存放数据和元数据的方式不同，分为全对称和非对称模式。

全对称：所有的节点都会处理元数据，各个节点间实时同步元数据信息；

非对称：我有元数据节点，元数据节点单独处理元数据信息，所有信息必须通过元数据节点进行管理。

思考一个问题：当不同类型、不同大小的海量数据需要实时存储时，这两种架构会有怎样的情况发生？

全对称：海量文件带来的海量元数据在各个节点间同步，带来了性能和带宽等瓶颈问题；

非对称：元数据采用独立的节点，处理能力有限，不能很好的满足海量小文件的性能问题。

如何解决这种问题呢？我做了一个大胆的设想，提出一种新的逆向思维解决方式，我把它叫做集群元数据后处理架构。

每个存储节点管理一个虚拟磁盘MD，虚拟磁盘MD由多个存储节点的磁盘块按照一定的规律组合而成，几个存储节点形成一个冗余群组，群组内部统一元数据信息，单个节点采用SSD加速缓存，并在自身的存储空间中，保留一份元数据备份。

客户端进行数据写入时，不再经过集群元数据节点，而是直接采用轮询方式写入存储节点，存储节点负责客户端元数据的建立、存储和同步。

根据前面的架构，我们可以并行的高效的进行文件的写入操作，而不需要经过集群元数据节点，下面，我们来解决数据统一命名空间的文件读取问题，我把这种读取分为二种模式：

本地用户文件读取：客户端自身存放的文件，可以通过直接访问数据节点的方式，获取数据，避免元数据节点瓶颈和减轻元数据节点压力；

其他用户文件读取：通过元数据集群，获取目录信息后访问数据节点。

图示可以看到，元数据通过这种方式，进行统一模式的集中处理，并可以根据应用需求进行数据索引，提升访问效率。

总结：

我把这种模式称为：分布式存储 – 集群元数据分层处理架构。更多编程知识详询462403503共同学习。

HBase是一个查询极其快速的非关系型数据库，它在实时读写和实时访问上有着巨大的优势，并且非常灵活。今天小鸟就从HBase的存储结构来向大家揭秘其强大之处。

之前小鸟已经介绍过HBase的系统架构了，没有看过的同学欢迎翻阅之前的文章：大数据Hadoop工具，HBase系统架构简介

下面正式进入今天的主题：HBase的存储结构

先来看下面这幅图：

这是一个HBase表的存储结构模型，其中有4个字段。分别为Rowkey（主键）、Time Stamp（时间戳）、CF（列族）、CF：xx（列）。这看上去是一个数据表，但是对于HBase而言，这只是一行数据。看到这大家可能会比较迷惑，这明明就是数据表嘛，我用了这么多年excel，你可别骗我。

为了方便理解，我们先来举个例子，请看下面这幅图：

这是一个普通的数据表，名为legens。其中有5列数据，分别为id、名字，出生日期，外号和出生地。有些小伙伴看到表里的内容应该会很熟悉，但是这并不是重点。假如，现在有些人不止1个外号了。有些人有2个甚至3个外号，这时如果要将数据存入数据表，则需要修改表结构，修改结果如下：

如果接下来还有别的字段要添加，比如性别等。那么这个表结构还需要修改。因此在统计结构不严谨的数据的时候，普通的关系型存储结构并不好用。那么如果使用HBase的话，如何存这些数据呢？请看下图：

这就代表着一行数据，和普通的数据表类似但又不完全像，接下来小鸟就按照前面的过程来讲解。

首先，rowkey是主键，它决定一行数据。rowkey在生成的时候就会排好序，排序规则按照字典顺序。所谓字典顺序就是ABCD、1234。Rowkey只能存储64k的字节数据，如果太长则影响性能。

Timestamp是时间戳，每插入一次数据都会有一个时间戳，其作用是标识本次加入的数据，起到一个版本的作用，HBase在插入数据的时候默认版本号就是时间戳。这个字段可以自己修改定义，但是一般都采用默认的时间戳。

通常获取数据就是获取时间戳最近的一条数据。假如现在加入一条数据。Cf1:name=劫。那此时如果获取rowkey为1的一行下，cf1为name的数据时，获取到的就是劫而非亚索。

因为此时劫是新加入的，HBase在做数据更新的时候就是利用新数据来覆盖旧数据的。

Cf是列族，全称是Colunm Family。HBase表中的每个列都属于一个列族。列族必须作为表模式事先定义完毕。例如create ‘legens’ ‘cf1’ ‘cf2’ ‘cf3’……。一个列族下的所有数据都存于一个目录下，由几个文件保存。

除此之外，权限控制、存储和调优都是在列族层做处理的，因为表在建模的时候并不会考虑有多少列。

列族一般不轻易修改。

name、born、alias等都是列，列名以列作为前缀。例如cf1:name。一个列族有多个列成员，上述cf1就有name、born、alias1、alias2、alias3。并且列在后续可以按需求增加。加入现在要在cf1中加入height，则直接添加cf1:height=xxx。

确定一个列的某个属性的值需要四个值来确定，分别是rowkey、列族、列名、和timestamp。

最后要说明的是，HBase中存储的数据是没有类型的，全部都是以字节码的形式存储。

以上就是本次HBase存储结构的全部内容了，有任何疑问欢迎私信或者评论，小鸟将第一时间解答。另外开黑也可以的。