大数据应用之双色球算奖平台总体设计历史数据存储篇
作者：张子良
版权所有，转载请注明出处
1.1 引子：文件OR数据库
历史期次的双色球选注数据的存储，采用什么样的格式比较好呢？这需要重点从三个方面考虑，一、文件访问方便吗？二、文件服务器空间够用吗？三、软硬件故障环境下，如何保障数据的可用性。基于这几个方面的考虑，到底是采用文件存储还是采用数据库存储呢？本文，从传统和前沿技术两个角度给出了两种相应的解决方案。
1.2 文件存储
1.2.1 三大问题
根据上一篇《大数据应用之双色球算奖平台总体设计数据规模估算篇》分析，双色球单期次数据的存储规模在7G左右，记录数在2亿条左右。可以考虑以文本文件的方式进行存储，这里面面临三大问题，一、单个文件过大的问题，访问不便，文本文件一般来讲超过200M，使用常规文本文件阅读器打开，都会成为问题，各位可以自行尝试。二、历史期次存储空间问题，技术总是在发展的，目前一般的服务器存储空间，单台服务器硬盘配置个NT，从技术和成本角度，都不会成为障碍，双色球每周三期，考虑到节假日的因素，每年约156期，156*7=1092，所需空间约1T。三、数据高可用性问题，传统单点存储方式的缺点，不做说明，考虑一个极端，硬盘坏了，或者服务器宕机，数据怎么访问？
1.2.2 传统方案
问题的存在，不代表没有解决的方法，一切软件问题的技术解决方案，其实都是在各种妥协中寻求平衡点而已。当然总有无法平衡的时候，而这时总会有技术方面的突破，有需求才有动力。传统的方式，针对问题一，可以按照地域或者期次进行文件夹组织，按照投注站进行文件命名，不同投注站的单独期次的文件存放到同一个文件中，这样做的好处是单个文件的大小变小了，读取成为可能，缺点是你要去管理大量的小文件。针对问题二、如果考虑一台主机就能存个三年五载的数据，不妨搞个磁盘阵列，或者多加几块T级的存储硬盘。这么做的好处是空间问题得到解决了，缺点是仍然面临IO读取速度的问题。针对问题三、可以采用磁带机，或者物理隔离的冗余备份，考虑到数据的特点，数据一次写入，不会发生变更，所以即使是刻盘的方式都是能够解决问题的，这么做自然能做到保障数据的可用性，但是同样的存在问题，那就是即时可用性，无论什么原因，我必须停下当前的工作，重新进行数据的导入和加载。
1.2.3 前沿技术
如果双色球历史数据存储的问题，结合最新的分布式存储（HDFS），会得到怎么样的效果呢？我们不妨仔细的考虑一下。如果采用分布式单文件存储，每一期作为一个文件，可以很好的解决存储空间和高可用性的问题，但是分段读取还是一个障碍，除非你一次想使用整个文件。所以还是要妥协，那就是把文件按照上一节中提到的方式进行切分。只是考虑业务分析的需求，粒度可以控制在以地域为单位或者以投注站为单位，粒度过细则会涉及到HDFS文件分块的问题（64M）。
1.3 数据库存储
1.3.1 核心问题
考虑到双色球投注数据的特点，每一个选注为一个独立的数据单元，一条记录。采用关系型数据库进行存储的好处很明显，就是结构清晰，访问方便。但是由于数据规模的问题，单表存储2亿条记录，如果采用传统关系型数据库，面临的核心问题就是单表记录数过大的问题。
1.3.2 传统技术-分区&分表
历史的因素，关系型数据一致面临大数据应用领域的挑战，当然也衍生出来许多的解决办法，比如说分区，比如说分表。分区的核心思想在于增加单表的空间，而分表的核心思想则在于分而治之。但是都无法逃避单点访问受限的问题，再怎么变，也要受控于RDMS服务器的性能。
1.3.3 前沿技术-NoSQL
如果采用No-SQL技术（Hbase）又会是怎么样的情形呢？我们以期次为单位组织表结构，每期一个文件，以投注站编号和流水号为rowkey，以红球为family1，以篮球为family2。根据Hbase的特点，则既可以解决记录数的问题，也可以解决访问并发访问性能的问题（Hbase文件存储采用HDFS）。同时Hbase基础之上有很多分布式并行计算的工具可用，可以很好的协调多服务器的并行计算。
1.4 对比分析
前文已述，很喜欢No-SQL方式的实现，个人认为是目前最为恰当的方式。引玉抛砖，还是多听听各位大牛的意见吧。
