云时代的数据储存技术详解

　　数据存储对象包括数据流在加工过程中产生的临时文件或加工过程中需要查找的信息。数据以某种格式记录在计算机内部或外部存储介质上。数据存储要命名，这种命名要反映信息特征的组成含义。数据流反映了系统中流动的数据，表现出动态数据的特征；数据存储反映系统中静止的数据，表现出静态数据的特征。

　　纵观数据库发展的几十年，从网状数据库、层次数据库到RDBMS数据库，在最近几年的NewSQL的兴起，加上开源的运动，再加上云的特性，可以说是日新月异。在20世纪80年代后，大部分的业务确定了使用RDBMS数据为存储基础。新世纪开始，随着互联网的发展，数据量的增大，慢慢RDBMS数据库撑不住了，就出现了读写分离策略。随着压力增加，Master撑不住了，这时就要分库了，把关联不大的数据分开部署，一些join查询不能用了，需要借助中间层。随着数据量的进一步增加，一个表的记录越来越大，查询就变得很慢，于是又得搞分表，比如按ID取模分成多个表以减少单个表的记录数。经历过这些事的人都知道过程是多么的折腾。在不同的场景下，就出现各自优秀的分布式数据库，比如在文档型存储下的MongoDB，KV类型的Redis，再比如今天讲的列族类型的HBase。

　　大数据时代数据存储的特点为：基础量大、增长快、计算与存储的实时性要求迫切、支持时效性短、易发散、易产生脏数据，这些HBase自出生起，就满足这些需求。在大数据时代，我们认为HBase是公认的大数据存储。HBase的原型出自Google的BigTable，这个跟大数据的GFS及MapReduce齐名的三篇论文，由此开创了大数据时代。目前在阿里，已经有上万台的HBase集群，在各个场景下有广泛的应用。

　　为什么要上云，需要了解到HBase本身比较复杂，这涉及到分布式、数据存储、响应延迟，索引等一些分布式、数据库的知识，对于运维好这个复杂系统还是有一定的难度;要有很好的使用姿势，虽然API比较简单，但是各种组合情况下，畅玩好HBase还是需要一定的功力;上云是趋势，自己去基于ECS建设又不太了解云环境下，怎么正确部署HBase，怎么跟OSS等云上组件配合。

　　为此，我们提供云HBase加上专家服务解决以上3个问题

　　最后，HBase在阿里集团使用了6年之久，已经在HBase的性能、运维等积累了大量的经验，我们希望把这些回馈给客户，例如：我们仅仅单条低字节高频写入情况就比社区版本高出30%+的性能。

　　目前提供的价值点有，以下几点：

　　高可靠：数据备份，数据可靠性9个9

　　高可用：Master节点强制HA机制，出现问题后直接切换

　　易运维：一键构建、配置修改、一键扩容、自动备份、数据流入

　　高性能：比如开源性能大幅度提升30%+

　　低成本：后续本地盘、云盘、OSS分级别存储

　　技术架构

　　从技术架构层面看，大致如下：

　　基础资源层：我们底层使用了ECS及本地磁盘的架构，保证在低成本的同时又具备高性能

　　基础软件层，我们使用了ALi-JDK及ALi-Liunx，这两个都有专门的团队在维护，对云HBase的贡献，比如：改进gc算法减少毛刺，改进linux中断提升性能。

　　HBase内核层，目前使用是跟阿里集团内部一致的版本，也就是说内部所有的性能优化、功能增强在公有云的客户都可以享受到。这些包括但不限于：提升读写性能、增强稳定性、降低磁盘、网络抖动引起的毛刺等等。-另外就是运维平台，逐步完善，后续会包括监控报警、配置管理、健康诊断等等易于运维的功能。

　　目前支持两种访问网络类型，第一种是经典网络、第二种是VPC网络。区别就是VPC再加了一层网络隔离。

　　经典网络：

　　VPC网络：

　　使用场景

　　HBase作为默认的大数据时代的存储，基本解决以下三大类的场景：

　　平台类，基本存放是平台的产品，就是其它软件的存储，比如目前很就行的kylin，阿里内部的日志同步工具TT，图组件Titan等。此类存放的往往平台的数据，有时候往往是无业务含义的。作为平台的底层存储使用。

　　用户行为类，此类主要是面向各个业务系统。这里的用户不仅仅指的人，也包括物，比如物联网。在阿里主要还是人产生的数据，比如：淘宝收藏夹、交易数据、旺旺聊天记录等等。这里使用比较直接，就直接存放HBase，再读取。难度就是需要支持千万级别的并发写访问及读取，需要解决服务质量的问题，比如GC了，就出现大量的毛刺。

　　报表类的需求，比如报表、大屏等，最出名的就是阿里巴巴的天猫双十一大屏。

　　基本上：MySQL支持小数据量，查询较为复杂的数据应用;HBase支持大数据，查询较为简单的数据应用。

　　在服务器与存储的各种连接方式中，DAS曾被认为是一种低效率的结构，而且也不方便进行数据保护。直连存储无法共享，因此经常出现的情况是某台服务器的存储空间不足，而其他一些服务器却有大量的存储空间处于闲置状态却无法利用。如果存储不能共享，也就谈不上容量分配与使用需求之间的平衡。

　　DAS结构下的数据保护流程相对复杂，如果做网络备份，那么每台服务器都必须单独进行备份，而且所有的数据流都要通过网络传输。如果不做网络备份，那么就要为每台服务器都配一套备份软件和磁带设备，所以说备份流程的复杂度会大大增加。

　　想要拥有高可用性的DAS存储，就要首先能够降低解决方案的成本，例如：LSI的12Gb/sSAS，在它有DAS直联存储，通过DAS能够很好的为大型数据中心提供支持。对于大型的数据中心、云计算、存储和大数据，所有这一切都对DAS存储性能提出了更高的要求，云和企业数据中心数据的爆炸性增长也推动了市场对于可支持更高速数据访问的高性能存储接口的需求，因而LSI12Gb/sSAS正好是能够满足这种性能增长的要求，它可以提供更高的IOPS和更高的吞吐能力，12Gb/sSAS提高了更高的写入的性能，并且提高了RAID的整个综合性能。

　　后续计划，一些功能，比如同步等，产品化，直接从rds及离线系统导入数据到云HBase系统中，完善云HBase功能，不断做精细化，提供HBaseonOSS的能力，降低数据存储的成本，提供双集群多写多度的能力，做多区多地域容灾。

　　与直连存储架构相比，共享式的存储架构，比如SAN（storage-areanetwork）或者NAS（network-attachedstorage）都可以较好的解决以上问题。于是乎我们看到DAS被淘汰的进程越来越快了。可是到2012年为止，DAS仍然是服务器与存储连接的一种常用的模式。事实上，DAS不但没有被淘汰，近几年似乎还有回潮的趋势。

　　更多详细内容，尽在课课家教育，我们期待您的咨询！