躺在库里的时空大数据，我该拿你怎么办？(二)

面对着数据的体量越来越大、种类越来越多、格式越来越多样化、产生的速度也越来越快、以及因为协助共享从其他渠道获取的数据来源也越来越多等问题的发生，导致了数据在体量上相比过去有了指数级的增长，而且还在不断的增长。体量大了之后，如何存储、如何管理、如何保障数据不丢失，就成了我们要面临的第一重要课题。面对这个课题，信息技术支持部门需要迎接这个挑战，如何解决？原来使用的方法工具还能帮助到我们吗？这始终困扰着我。
在思考解决这个问题之前，有必要先回顾下之前是如何管理这些数据的。到目前为止，我们很多的数据是存储在关系型数据库中，以表的来存储，数据越来越多，表的记录也越来越多，这个表也越来越臃肿，作为数据库管理员就需要不断的优化再优化。对于有经验的数据库管理员而言，可能会把访问频次不高的数据导出放在冷库中或者是直接放在文件中，就像被打入冷库的妃子，不知道什么时候才会得到皇上传召。但很多的小单位面临的情况是，大部分的数据还是放在原库中，这些数据不管用还是不用，都先放在数据库里再说。而这时候数据库管理员就头疼了，因为他经常会收到业务部门的埋怨：数据查询怎么变慢了？原来很快的啊？或许，这个时候有经验的数据库管理员可能会把关注点放在关系型数据库的优化和扩展上，但是也会遇到两个很现实的问题：1.优化扩展的成本多大?能不能花较少的钱/精力来解决这个问题；2.随着数据的指数级增长，未来几年还得在关系型数据库上一再的优化扩展吗？关系型数据库会不会有瓶颈？其实，问题终归就一句话：还是希望用更少的成本/精力来来解决当前的问题。
从成本的角度考虑，如果单位不差钱，那么选择像Oracle、SQL Server这样的成熟商用数据库应该是首要的解决方案，很简单，数据库领域发展这么多年已经很成熟，有问题找厂商。但是不差钱的单位还是比较少的，所以这时候可能大家会把目光放在开源社区。庆幸的是，在开源社区，有一些非常优秀的大数据存储和管理方案，包括名声大噪的HDFS（分布式文件系统）。HDFS免费、稳定、可靠、有大批的开发者在维护，是大名鼎鼎的Apache的一级项目，听着都诱人，不是吗？那是不是就只选HDFS来管理所有的数据？这种方案可以满足现有所有业务系统的需要吗？原来的数据如何迁移到HDFS？原来的业务系统的SQL如何在HDFS上执行？数据的查询统计分析效率如何，能够达到目前业务系统的性能要求吗？