剖析大数据平台的数据存储

企业动态
数据作为一种资产,若少了存储,就成了无根之木,失去了后续挖掘的价值。在小数据时代,受存储容量与CPU处理能力限制,在现在看来相当小的数据,在当时其实也可以认为是“大数据”了。那么,为何在当时没人提出Big Data概念,得到业界关注并催生出一波数据浪潮呢?

数据作为一种资产,若少了存储,就成了无根之木,失去了后续挖掘的价值。在小数据时代,受存储容量与CPU处理能力限制,在现在看来相当小的数据,在当时其实也可以认为是“大数据”了。正如在蒸汽机时代,创造了时速126英里(203公里)纪录的Mallard蒸汽火车就可以被视为极速火车了。那么,为何在当时没人提出Big Data概念,得到业界关注并催生出一波数据浪潮呢?

Big Data概念是1998年由SGI***科学家John Masey在USENIX大会上提出的。他当时发表了一篇名为Big Data and the Next Wave of Infrastress的论文,使用了Big Data来描述数据爆炸的现象。但大数据真正得到业界关注,则是其后多年的事情了。其中大数据最重要的发酵素则是2003-2006年Google发布的GFS、MapReduce和BigTable三篇论文。

在我看来,小数据时代的数据量虽然在逐年增加,但是当时突破存储容量的解决办法依旧是垂直伸缩,即通过寻求更大容量的存储介质来解决这个问题。由于互联网业务不够流行,Web 2.0还未开始(更谈不上移动应用与物联网),当时IT系统要处理的数据结构相当单一,都是相对规整的关系型数据(结构数据)。因而在小数据时代,存储世界是关系数据库一统天下的时代。

当存储技术的发展变得步履蹒跚,赶不上数据发展的速度时,分布式存储成为了必然选择,非结构型数据也对存储格式提出了新的要求。层出不穷的数据源也使得数据量产生了井喷似的迅猛增长。

此时,分布式存储与NoSQL的诞生回应了这样的需求,解决了大数据存储的根本难题。

数据存储工具如百花盛开,一时仿佛来到了数据存储的盛世。然而,乱花渐欲迷人眼,我们反而不知道该怎么选择合适的数据存储技术了。正如设计需要结合业务场景,对数据存储的技术决策同样需要结合具体的场景。决定的因素包括:

  • 数据源的类型与数据的采集方式
  • 采集后数据的格式与规模
  • 分析数据的应用场景

如果数据的采集是针对业务历史数据的同步与备份,那么HDFS可能就是***的存储选择;如果数据的格式为文档型结构,那么诸如MongoDB之类的文档型数据库就可能是我们首要考虑的目标;如果存储的数据是要应对全文本搜索的应用场景,那么ElasticSearch可能才是我们的心头所爱。

倘若存在某种业务场景,使得这几种决定因素互相冲突,例如既需要分布式的文档数据库,又需要支持高性能的统计分析,该怎么应对呢?这就引出了大数据平台数据存储的一个重要特征:

  • 相同的业务数据会以多种不同的表现形式,存储在不同类型的数据库中,形成polyglot-db这种产生数据冗余的生态环境。

没有哪一款存储工具擅长应对所有的数据处理场景。

在对数据存储进行技术决策时,我们需要充分了解各种存储工具的优缺点,然后结合业务场景对其进行选择。就像足球教练那样,要对各个球员的技术特点了如指掌,才能将他们安排在合适的位置上。

[[196847]]

在大数据存储领域,HDFS或许就是我们最放心的守门员,全量的历史数据都可以交给他。你几乎不用害怕他会“丢球”,而他守门的技巧是可以横向扩展的,再多再猛烈的射门他都能挡得住。

PostgreSQL是保守型的后场选手,他技术全面,在保持数据一致性方面他能做到近乎***的万无一失。性格稳重,以符合大多数教练对后防需求的思维方式来踢球。

HBase属于后腰型选手,既能在防守上给PostgreSQL以协助,又不时通过列式存储的技术特点传出让人拍案叫绝的好球。

Redis是中场提速器,他不仅能够加快球队的传球效率为球队提速,而且还以极高的传球***率著称,偶尔传出的致命一击更能帮助球队攻城拔寨。Redis还是***的团队成员,可以与各种类型的球员打出漂亮配合,他还不抢风头,只在自己最擅长的领域默默地展现自己的才华。

ElasticSearch或许可以称得上是“中场大师”,因为他能为各种类型的前锋提供传球支持,并能保证球权处理的高效性。他的各种盘球技法(支持各式各样的查询)让人眼花缭乱。兴之所至时,他的盘带与传球真如水银泻地一般,No look pass的传球总是出人意料的精彩。

诸如Parquet、Neo4j、Pilosa之类的数据库都可以称得上是剑走偏锋的前锋球员.他们不善于应对阵地战靠着稳扎稳打通过硬实力硬吃对手,而是像刺客一般伺机而动,对手稍有不慎,迎接他的就是一剑封喉的绝杀。

对于polyglot-db这种解决方案,我们还需要细心处理好数据一致性问题,即当数据源的数据发生变化时,我们如何将这些数据变化反应到各种存储工具中。如果数据是以immutable形式存储,满足数据的一致就变得容易多了。因此在polyglot-db的场景下,我们倾向于数据保持不变。如果业务场景确实不支持,同步就会变得更复杂。在前面讲解数据采集时,我已经给出了不够***的解决方案,庶几能解决数据同步问题。

数据存储就是数据平台工程师手中的工具百宝箱,你需要熟悉各种工具的利弊,他们擅长处理的场景,然后再将好钢用在刀刃上,以求***性的发挥工具的潜力。记住,在大数据平台中,不是数据驱动而是业务场景驱动你对数据存储的技术决策。

【本文为51CTO专栏作者“张逸”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2017-07-21 14:22:17

大数据大数据平台数据处理

2017-06-14 23:42:27

大数据数据源架构

2017-07-22 00:41:27

大数据数据存储

2013-09-12 14:28:44

大数据存储

2018-06-07 16:33:31

大数据冷热数据存储平台

2013-05-06 10:22:28

大数据Hadoop

2018-04-11 06:31:24

大数据架构数据分析Hadoop

2019-08-23 15:55:27

架构大数据BI系统

2013-08-08 10:07:43

大数据存储结构化数据

2011-08-11 14:04:17

大数据

2018-10-29 13:07:15

HBase存储迁移

2021-02-22 10:55:59

大数据大数据平台数据平台建设

2014-05-21 16:24:47

大数据存储大数据分析

2017-03-28 18:25:59

华为

2022-09-01 23:34:18

大数据数据分析工具

2018-03-20 10:37:33

存储大数据管理

2020-12-17 19:15:48

大数据大数据平台架构数据平台建设

2012-10-09 10:51:51

大数据数据中心大数据应用

2018-01-24 10:33:18

存储

2017-02-05 17:27:43

点赞
收藏

51CTO技术栈公众号