今日算法已经以standlone模式在本机上跑通了，结果也和之前的那版（数据读入内存采样）一致。期间为了达到一致的效果，改了一是无放回采样，二是采样SQL随机程度问题，因为我忘记了每组的id不是从0开始的，之前只是实现了用id分组，所以每组第一个值也就是最小值就有较大的概率被取到，改完之后，很随机了。在昨晚的思考后，根据公式我发现最后采样总会停止，最大的迭代次数就是每组最大的记录数，因为此时置信区间宽度变为0，所有组必定没有overlap，算法停止，而实验表明最后确实在迭代了300次之后停了，但这也说明尽了最大能力采样，这种各组平均值都相差较小的极端情况，进行了很多次的迭代，可以说是非常慢了。实验结果standlone模式下跑了10min+，切换成本机yarn模式30min+妥妥的，yarn模式反而更慢了（无论是本机还是大集群），应该这是真实的分布式环境，存在真实的网络等开销，所以一个真实的job运行时间是慢的，用Mapreduce仅仅为了采样实在是小题大做了。
想法：1.增大step，即每轮迭代每个map采样的数量；2.其它办法，使得算法更适合分布式。
算法正确性问题还需要考虑，因为现在分布式实现的效果已经和之前把文件读到内存中采样完全一样了，但是两版的结果并不是完全正确，正确性还是有出入的。
今天只遇到一个bug：java中split()特殊符号"." "|" "*" "\" "]" 实习时候好像也碰到过，但是还是忘了
http://blog.csdn.net/myfmyfmyfmyf/article/details/37592711