海量数据处理

摘要：对于海量数据的处理，数据存储在后续应用及维护中占据了核心地位。一个良好的存储模型与设计不合理的模型在对资源的消耗上有着天壤之别，而一个针对具体问题设计合理的方案能够在工作中事半功倍。

关键词：数据；处理；存储

中图分类号：TP311.52 文献标识码：A 文章编号：1007-9599 （2012） 16-0000-02

1 引言

在企业竞争日益激烈的今天，第一时间了解公司线上业务运行情况并及时进行调整直接决定了项目能否第一时间占据市场高地。对业务数据的处理涉及到收集，存储，加工三个关键步骤，而根据不同的业务类型，对数据的一致性，准确性，实时性都有不同的要求。能否制定出适合业务类型的数据处理解决方案将决定数据处理系统的成败，从而影响了项目的命运。本文将从介绍数据收集开始，结合不同的业务类型提出相应的解决方案，并权衡各种方案的利弊。

2 数据收集

本文的讨论重点是关系型数据库解决方案及NoSQL解决方案的比较，但在此之前对数据收集进行简要介绍对于理解后续的模型是有必要的。由于企业的业务往往分散在各地的服务器上，要对业务数据进行收集可采取两种方案，服务端主动发送，服务端记录日志并由数据收集系统的客户端进行收集并发送。为减少业务之间的耦合，我们将采取第二种方案，即业务相关服务记录特定格式日志，并由客户端进行收集，在业务相关服务中仅需添加根据特定格式写日志接口。

3 数据存储

对于海量数据的处理，数据存储在后续应用及维护中占据了核心地位。设计良好的存储模型与设计不合理的模型在对资源的消耗上有着天壤之别，而一个针对具体问题设计合理的方案能够在工作中事半功倍。

3.1 关系型数据库模型

当业务规模相对较小并且业务种类单一时（比如一些刚起步的游戏公司）其主要需关注的数据是一些游戏的在线、登入、登出、付费人数等数据，在下文中将称其为关键运营数据。这些数据表现了一个项目的生命特征（当这些特征表现很低靡时，如果不是服务器出问题了，公司管理者就应该为项目的前途担心了）。对于这些数据要求有极高的一致性、准确性以及实时性。当然最好能记录明细（明细往往由相关的提供业务支持的系统进行维护）。对于这种类型的数据，需要为每个业务逻辑制定一个标识，当收集到该数据时，（数据处理）服务端根据该标识对数据进行区分，从而存储于数据库中。对这类数据须保证实时性，但不需要保持时序关系。

3.2 NOSQL思想

“NoSQL这一术语常用于描述网页开发者对非关系型数据库与日俱增的使用”。[3]

随着公司业务种类的多样化，以及业务的深入，越来越多的项目浮出水面，尤其是对于无线项目，由于这类项目往往由用户下载客户端后客户端直接提供服务，限制于发行商对产品的限制，不便因数据收集的需求对产品进行频繁修改。而业务的深入也必定带来更多更细致的数据需求。在这样的背景下，类似于关键运营数据那样为每个业务逻辑制定标识的方法维护性将变得很低（试想对某个游戏的所有道具、所有任务、所有NPC或是一个行为产生的结果进行数据收集，将需要为所有的这些对象制定标识，系统的开发者以及维护者将不堪重负）。此时地数据将成几何级数倍的速度增长，正如[1]中所说，“对于这些数据的读写操作大多基于主键，而并不需要基于RDBMS的复杂功能，而为了维护这些过量的功能企业不得不投入大量的硬件和人力资源，使基于RDBMS的解决方案变得很低效。”，“尽管在RDBMS上近几年取得了许多进步，但要扩展一个数据库仍然不是一件轻松的工作。”所以除了本来就应考虑的一致性准确性等问题外，存储模型的延伸性也应该进行考量。

如[2]中提到的Brewer的CAP理论中陈述的，“在任何一个系统（常为分布式系统）中，一致性，可用性，以及分区容忍性只能三选其二”，对于CAP三者的解释如下，Consistency（一致性）：对所有数据库的查询操作都将获取同样的结果，即使在并发更新的情况下。Availability（可用性）：所有的数据库客户端总能存取数据。Partition Tolerance（分区容忍性）：数据库能被分割开到多台机器上，即使发生网络中断也能继续提供服务。在现有的需求下，较好的实现能够根据配置在这三者间进行调解，如Cassandra[2]。

本文讨论的存储模型的存储策略借鉴了Dynamo，而数据结构类似于Google的Big-table，目前开源社区对该类存储模型较好的实现可以参考Cassandra。同时这类系统一般用于公司内部运营支持，暂不考虑安全性相关问题。

3.3 NOSQL模型

在新项目上线之前，可以根据策划案对可能需要设计的数据需求进行统筹，并制定需求，在与数据处理系统开发人员，产品开发人员沟通后，最终修改需求并不再进行更改。在产品开发之前，为这些需求制定标识字串，这些字串往往是自说明的。在一切都准备好之后，在产品的业务代码中加入相应的数据收集代码。

当用户在产品中产生一个动作时，与该行为相对应的结果将通过数据收集代码写到磁盘中，数据收集客户端将分析磁盘上的文件，将对应的字串发送至服务端。服务端可以通过在框架上使用共享库的方式，加在不同模块以针对不同的数据类型。比如可以专门有一个共享库用来处理放入NoSQL存储的数据。根据Big-table中提出的数据模型思想，可以通过主键定位到具体的数据，故存放之前需要对整个字串进行拆解，根据事先制定的数据模型来组成不同的数据包并写入存储。

由于到达数据处理服务端的字串是自说明的，其中包含了用来定位一个数据所有必要的信息，所以若在最初制定的数据需求是全面的，游戏中所有用户相关行为产生的数值信息都可以使用相同的格式写至磁盘，很大程度上节省了产品开发人员以及，数据处理系统开发及维护人员以及在双方沟通中消耗的沟通成本。

基于Dynamo思想的分布式存储采用了P2P结构，使用该节点的好处在于所有的节点都是对等的，即使其中一个出现问题，如断电、网络中断等，只要采用合理的备份策略，整个集群是可用的。另外采用这样的方法便于维护人员向集群中添加或减少机器，因为所有节点是对等的。

由此可见，妥善使用NoSQL并设计良好的话，可以极大地降低开发及维护人员的人力成本。

4 总结

无论是关系型数据库还是NoSQL都不可能成为最终的解决方案，正如多年前被的认为关系型数据库可以成为终极的解决方案的思想一样，NoSQL也不可能坐上这一宝座。

所幸的是，现在的工程师们在经历了关系型数据库时代后对这一点已经有了深刻的认识，并以此为动力开发出了多样化的NoSQL产品，每一款都解决了某些特定的问题。对于即将使用NoSQL思想设计自己系统的工程师，应当仔细分析自己的需求，使用最适合自己的NoSQL产品，或者对现有的NoSQL产品进行定制（很多产品如Cassandra都提供了可自定义的接口）。甚至可以根据需求设计并开发自己的数据库系统。

在思考解决方案时，也务必需要考虑是否在该项目中是否真的有必要使用NoSQL产品，因为往往对一家相对成熟的公司（有自己的数据库管理员）在使用关系型数据库进行开发时的效率是最高风险最低的。

参考文献：

[1]Dynamo：Amazon’s Highly Available Key-value Store

[2]Oreilly Cassandra The Definitive Guide

[3]NoSQL Databases

[4]Bigtable：A Distributed Storage System for Structured Data