分布式-查询MySQL类算法-思路梳理

今天刚来的问题是思路很懵，就找学长老杨帮忙理理思路，说着说着，想起十一假期看到的一个知乎关于规模达到多大的数据才值得用大数据的方式处理（当时是为了查MySQL的容量还有为啥用MySQL分布式什么，还顺便得知Facebook用的还是MySQL）https://www.zhihu.com/question/21975289 贺勇的回答，想起来就豁然开朗，“总结得好”。（也就是在大数据上查询慢，但是在小数据集上快啊，那分成几个小的并行就好，正好数据之间彼此没有联系，直接切割即可）

所以就做了个实验，把我的SQL改变不同的起止范围，果然范围大的时间长一些（40M的数据，多出0.5s），那就说明我现在这么写理论上是可以的，比较减小了查询时间，在确定这点之前，我消极地觉得改成分布式的唯一可能就是TB级的数据单机可能存不下，所以要放集群上，现在看来，分布式处理也算减小了查询数据集即查询时间，但是由于每个mapper实际上并不是完美地并行，而且还要加上mr-job启动开销还有网络延迟等等时间成本，其实放在集群上跑可能更慢，也就相当于单机版的开了几个线程，只不过数据量大单机可能存不下而已，那么数据放在集群上……我现在仅仅是放在一个节点的MySQL上，用Mapreduce并行其实没什么必要，在用线程并行可能更快呢……所以分成小SQL（小数据集并行）没问题，但是实现方式有问题，现在试的数据是200M，集群上比直接查慢8s，算上启动时间了，如果数据量更大还是慢，那这就是条死路了。

集群上跑的结果和SQL查询不一样，但是数据量差不多，应该是数据分割时的问题，代码要处理一下，要注意结果准确性。

-----------------出现的小问题和小技巧--------------------

1.一个是误会了partitionor的定义，把它当成分mapper的了，其实它是指定分到哪个reduce的。默认的dfs.block.size是64M，每个split执行一个mapper，所以我准备了大于64*5M小于64*6M的文件，这样就能生成6个mapper啦。但是这样的问题是我不知道每个mapper的顺序，因为我要按顺序切割SQL的。

另一个好方法，直接input文件夹里放六个小文件，每个小文件只有一个数字也就是1-6，这样不仅分成6个mapper，还能标记mapper的顺序。

2.Java处理字符串空格http://www.cnblogs.com/LiuChunfu/p/5661810.html

3.MySQL导入CSV文件的命令，字段名不用引号

4.另外昨天发现集群上的同样的文件比我本地要小，本来我以为数据丢失了，其实正常，应该是不同系统文件组织不同，压缩方式什么的不同的吧

5.另外我发现我这个数据是sensor采集的，100HZ每秒100条记录，但是没关系，时间我用123主键自增代替了嘻嘻 PK primary-key NN not null AI auto-incerment

-----------------数据量1G时速度有明显提升--------------------

嘻嘻，在MySQL上对整个数据集进行查询，耗时7min19s，在集群上跑（代码写死起止时间，否则每个mapper有两个SQL，写死之后每个mapper只有一个SQL）耗时4min19s，代码不写死也就是有两个SQL耗时6min40s，就一条SQL这差的也是很多。

查看结果输出时，发现MySQL上的输出和我写的代码输出大致一致，但是细节不一样，为什么不一样呢，看了半天我发现我根本没看懂这个算法，自己拿数据推演了一遍，我发现我这SQL写的不对啊，打开论文重新看了下变量定义，确实变量定义搞错了，修改一处代码，在集群上重新跑起来debug版，这下就和MySQL上的查询一模一样啦~

还有个问题是，reducer输出的结果文件没排序，系统集成时要注意。