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

标签 | 大数据 架构

作者 | 张逸

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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