大数据处理的存储,排序和计算

大数据处理现在比较火热,在信息爆炸的信息社会,这其实也是必然的.特别是云计算时代,对于云应用,这是一个无法绕开的课题.相对处理能力来讲,"大数据"处理其实从有计算机开始就已经存在.我做ERP系统的时候(2001),为了性能,就用了数据的分开存储,以下是我的一些看法:

1)大数据的最基本难题
    在数据量海量的情况下,需求的不确定性、计算能力和内存空间的瓶颈、外围存储的非随机访问是大数据处理非常困难的基本原因。由于计算能力和内存空间的限制,海量数据不可能全驻内存处理,而外围的IO能力又使得数据移动的代价非常大,一种确定的存储方案能满足的外部需求非常有限,存储方案一旦确定,有利的业务范围和能提高的计算效率的也基本确定,要满足额外的业务或需求就变得非常困难,比如数据如果按时间分布存储,但业务需求如果要按地点进行检索,要得到准确的结果,你就不得不遍历所有的存储点,而如果要进一步按类别(类别属性在各存储点无规律)排序,这就是一个噩梦。

2)大数据处理的基本矛盾
    用户的需求多样性和大数据应对方案的单一性,比较典型的例子就是大数据排序,假设一类数据有26个属性A-Z,存储可以分布,查询也可以分布,但你存储方案一旦确定,比如按,A,K,X三个属性分布存储,那么对A K X属性检索和排序都会比较快,但如果用户要对O、P、Q属性进行检索,按K排序就非常麻烦了,你得先从各个点获取检索结果,然后集中进行排序。理论上来讲,我们可以针对用户的每一种可能需求各自建立自己的存储方案,但实际上很难行得通(对于一些不需要修改和同步的数据,应对难度就低很多,比如网页搜索,可以采用索引索引的技术),特别是对于企业级应用。所以:
    3)大数据处理的基本方法
    分治,针对业务设计,索引技术。大数据处理首先要根据业务的特点选定存储方案,因为存储方案确定后,数据处理的性能空间就大致确定了。这也是数据挖掘需要建立主题仓库的根本原因,其目的就是缩小目标范围(需求),使得数据存储有利于挖掘计算(业务).而一个万能的解决方案是不存在的。从另外一个方面来说,这也是为什么我们不提倡过度设计的原因,因为一个设计能解决80%的问题就已经非常不错,如果你非得找一个解决100%问题的方案,反而会使得整体上的效率变低.分治其实就是人海战术,属于分布式计算范畴.由于分布式计算一般要求对计算节点的添加与移除要尽量简单,这其实就限制了计算节点的个性化,因此,对节点间的协同作业规则就要尽量简单,可靠和有效(一般工程化的东西要求基本如此).针对业务设计,主要目的就是让目标点减少,提高解决问题的聚焦度,从而提高方案的对业务的最大限度的效率支持,比如,在架构选型上,首选的都不是那些开源框架或者像微软提供的哪些企业应用框架,原因非常简单,就是这些框架的假定用户范围都非常大,都是想放之四海而皆准,当然这不是在说这些框架的不是,因为他们的立场必须这样.由于考虑的东西太多,其效率,特别是与公司的业务的契合度而言,往往就不会很好.在力所能及的范围内,我喜欢开发适合于自己业务的框架,不仅轻量级,更主要的是可以与公司业务紧密结合(PS:这是从GFS学来的,所谓针对业务的访问接口(大意));索引技术就很多了,大家可以看看相关资料.
    4) 试验和模拟是学习大数据处理成功的关键
    犯错不怕,就怕不会犯错,做为程序员,有想法,就应该敲码实现,用代码验证想法,用想法指导敲码,虽然对国人而言,写代码很掉价,但如果喜欢,又何必在乎呢.因为只有经过试验,才敢真正的去应用.不是每个人都可以有淘宝,百度等那样真实的海量数据让你去练手的.