对大数据处理的存储,排序和计算的一点思考

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

1)大数据的最基本难题

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

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

 

PS：题外话，在数据库检索中，用Like并不代表低效率，对于现在的Oracle来说，在索引字段上用like（前缀匹配）数据其实很快的，我估计Oralce的索引采用的是类似B+结构，索引叶子节点上是连续有序的，用一点小技巧，就可以很快获得检索结果，比如 like AB%,先可以直接定位到AB,然后定位到AC（不含AC),中间一段就是索引结果。这只是推断,不过我在亿级的记录上进行测试,结果令人惊讶,性能非常不错(具体的测试可参见我前面的薄文http://blog.csdn.net/hawksoft/article/details/7418897).

人往往很容易形成思维定势,其实在早些年时,做查询用like都是尽量要避免的,后面很久没有深搞Oracle,直到今年做底层架构测试Oracle SQL语句性能时才从知道Like也不一定低效率.同时也有些感慨,因此记下这些,以提醒自己要避免思维和知识的刻舟求剑.你在进步,别人也在进步,需要时常更新知识,特别是一些经验性的常识.

 

--思考随笔，有点简单，为记。