大数据技术栈通常包括数据采集、存储计算、分析可视化、开放共享、业务应用等几个关键分层，在这些能力引擎中，数据存储是一个关键的能力域。在海量数据聚集整合后，首先就是要将数据存放起来，所以存储引擎的技术选型会直接影响后续的数据用途和分析效果。
存储引擎的选型要考虑一些关键因子，比如数据源类型（结构化/非结构化）、数据规模（GB/TB/PB）、数据增长系数（每年都会增长20%？）、数据加工分析的方式（长期存储？SQL查询？交互式访问？），这些因子必将决定存储引擎的选型方法。
传统关系型数据库（RDB），是企业生产经营中最为普遍的IT存储系统，大多存放业务系统的结构化数据集。在初期往往单节点服务器就能驾驭存储需求，后续随着存储容量逐渐增加大多采用集群的方式去扩展支撑，而且RDB能够支持数据的操作与更新，对增删改查来说绝对是好手，完全遵循了ACID的特性，而且支持标准的SQL语法。因此RDB应用场景非常广泛，技术也非常成熟。但即便如此，似乎RDB没有能在今天大数据时代有所作为。首先今天有很多半结构化/非结构化数据集需要存储并处理，传统关系型数据库并不支持，就更别谈数据规模了。而且RDB主要采用行存储的方式保存数据，从后期查询的支持来讲很难于随机访问，而且系统的扩展性并不出色，不论MqSQL还是PostgreSQL，原生版本的扩展性能需要大量的调优。
对于传统RDB的特点，其实Hadoop生态圈的HDFS具有较多特性差异。比如大规模文件存储支持了海量非结构化数据，什么视频音频、文本日志、社交物联网统统不是问题，而且可以根据节点数量大规模扩展，以提升系统整体的存储容量。HDFS可以承载Hive任务作业，依托于M/R机制实现大规模数据的加载和分析。但Hive只适用于一次写入、多次读取的场景，对于频繁更新和随机访问而言并非长项，因为些都受限于M/R机制和对标准SQL的支持。在大数据早期，HDFS+Hive长期支撑了很多客户的系统，比如电信运营商的详单数据存储和预处理、互联网公司的网络日志采集和分析等，直至今日仍然有很多企业在持续使用，正可谓大数据的关键技术组件。
除了传统SQL结构化数据外，在大数据领域还有NoSQL数据库。当时随着互联网web2.0的兴起，传统的关系数据库在应对大规模和高并发的SNS纯动态网站显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库（NoSQL）则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。NoSQL数据库主要有四大分类：键值（Key-Value）存储数据库、列存储数据库、文档型数据库和图形数据库，所以是典型的支持非结构化数据，这里面由于时间关系暂不展开。在NoSQL四种类型中，以Hbase为代表的列存储数据库是非常有代表性的。由于存储方式的特点使其对海量数据的随即访问支持非常好，而且底层也支持HDFS存储，其系统扩展性也不是问题，列存储大大提高了存储压缩率。现在Hbase不仅支持一级索引，还可以通过功能开发实现二级索引的支持，所以技术成熟度也是不错的。
上述介绍中，你会发现海量数据的大规模分析与高效低延迟访问有较大差别，两者各有优势不可兼得。在现实情况中会经常发现两套存储引擎的交替使用，分别用于实时读写与海量数据分析，可以先将数据写入HBase中，再定期通过ETL到Parquet进行数据同步。但是这样做有很多缺点，比如第一：用户需要在两套系统间编写和维护复杂的ETL逻辑；第二，时效性差，因为ETL通常是一个小时、几个小时甚至是一天一次，那么可供分析的数据就需要一个小时至一天的时间后才进入到可用状态；第三，更新需求难以满足。在实际情况中可能会有一些对已经写入的数据的更新需求，这种情况往往需要对历史数据进行更新，代价太大；第四，存储资源浪费。两套存储系统意味着占用的磁盘资源翻倍了，造成了成本的提升。所以Cloudera开发了Kudu存储引擎，解决了前面种应用场景的问题。但是新技术需要磨合才能实际生产运用，否则会带来风险。
通过上述介绍，如果你需要常规结构化数据集的存储管理和查询分析，那么你需要RDB存储引擎；如果系统将承载海量非结构化数据集，那么存储和分析就需要用到HDFS+Hive的存储引擎；如果你需要海量非结构化数据集的低延迟随机读写场景，那么你需要使用类似于Hbase这样的存储引擎；如果你需要支持结构化数据，而且支持行级的插入、更新、删除，并尝试新技术去应对海量数据分析和低延迟随机访问，那么Kudu也可以选择。
大数据存储引擎是一个既复杂而又关键的领域，一个好的存储技术架构有助于后续业务的“生根发芽”。
| 欢迎光临 168大数据 (http://www.bi168.cn/) | Powered by Discuz! X3.2 |