并行计算

多进程 在 python 中使用 multiprocessing 时， multiprocessing.Pool 必须写在 if __name__ == '__main__': 下，否则会报错。不是很实用。 import multiprocessing def fun ( p ) : print ( p ) return p [ 0 ] , p [ 1 ] def do_something ( x ) : v = pow ( x , 2 ) return v if __name__ == '__main__' : t_dir = "C:/Users/user/Desktop/u" dir_list = os . listdir ( t_dir ) lst = [ ] for i in range ( len ( dir_list ) ) : lst . append ( ( dir_list [ i ] , i ) ) p = multiprocessing . Pool ( 4 ) # items = [x for x in range(1, 100000000)] dis = p . map ( fun , lst ) p . close ( ) p . join ( ) 来源： https://blog.csdn.net/qq_40250862/article/details

from: https://www.cnblogs.com/wuyudong/p/mapreduce-principle.html 简单解释 MapReduce 算法 一个有趣的例子 你想数出一摞牌中有多少张黑桃。直观方式是一张一张检查并且数出有多少张是黑桃？ MapReduce方法则是： 给在座的所有玩家中分配这摞牌 让每个玩家数自己手中的牌有几张是黑桃，然后把这个数目汇报给你 你把所有玩家告诉你的数字加起来，得到最后的结论 拆分 MapReduce合并了两种经典函数： 映射（Mapping） 对集合里的每个目标应用同一个操作。即，如果你想把表单里每个单元格乘以二，那么把这个函数单独地应用在每个单元格上的操作就属于mapping。 化简（Reducing ） 遍历集合中的元素来返回一个综合的结果。即，输出表单里一列数字的和这个任务属于reducing。 重新审视上面的例子 重新审视我们原来那个分散纸牌的例子，我们有MapReduce数据分析的基本方法。友情提示：这不是个严谨的例子。在这个例子里，人代表计算机，因为他们同时工作，所以他们是个 集群 。在大多数实际应用中，我们假设数据已经在每台计算机上了 – 也就是说把牌分发出去并不是MapReduce的一步。（事实上，在计算机集群中如何存储文件是Hadoop的真正核心。） 通过把牌分给多个玩家并且让他们各自数数，你就在 并行

863高性能计算机评测中心 http://hpctest.cs.tsinghua.edu.cn/programs.html 主页 评测程序 发表论文 人员组织 English 自主研发 Micro-Benchmark Kernel-Benchmark Applications 自主研发 SIM-MPI 一款模拟并行程序通信行为的trace-driven模拟器. HPC_Net_Checker 该测试程序用来检查大规模集群系统中网络链接通信性能存在故障的节点. PBB 一款面向生物信息学领域的基准测试程序集，该程序包括7个用OpenMP并行的生物信息学测试程序，BLAST, PLSA, MUSCLE, Rosetta, Semphy, ModuleNet, SNP. TPC-C 我们按照TPC-C最新标准5.11设计并实现了一套TPC-C评测程序，并对国产高端服务器进行了性能评测。 Micro-Benchmark OSU MPI Benchmarks 下载地址： http://mvapich.cse.ohio-state.edu/benchmarks/ 简介：由Ohio State University提供，程序生成不同规模的数据并执行各种不同模式的MPI通信，测试 各种通信模式的带宽和延迟。分为点对点通信和组通信两种形式，其中点对点通信重点关注拓扑结构中非 等价节点之间的通信性能。

---恢复内容开始--- 一、大数据时代的现状 据统计，YouTube上每分钟就会增加500多小时的视频，面对如此海量的数据，如何高效的存储与处理它们就成了当前最大的挑战。 但在这个对硬件要求越来越高的时代，CPU却似乎并不这么给力了。自2013年以来，处理器频率的增长速度逐渐放缓了，目前CPU的频率主要分布在3~4GHz。实际上CPU与频率是于能耗密切相关的，我们之前可以通过加电压来提升频率，但当能耗太大，散热问题就无法解决了，所以频率就逐渐稳定下来了，而Intel与AMD等大制造商也将目标转向了多核芯片，目前普通桌面PC也达到了4~8核。 随着集成电路上的晶体管数据量越来越多，功耗的增加以及过热问题，使得在集成电路上增加更多的晶体管变得更加困难，摩尔定律所预言的指数增长必定放缓。因此，摩尔定律失效。 当前和未来五年，微处理器技术朝着多核方向发展，充分利用摩尔定律带来的芯片面积，放置多个微处理器内核，以及采用更加先进的技术降低功耗。 当然，多核并行计算不仅仅可以使用 CPU ，而且还可以使用 GPU （图形处理器），一个 GPU 有多大上千个核心，可以同时运行上千个线程。那怎么利用 GPU 做并行计算呢？可以使用英伟达的 CUDA 库。 什么时候用并行计算? 多核CPU——计算密集型任务: 尽量使用并行计算，可以提高任务执行效率。计算密集型任务会持续地将CPU占满

volatile的使用场景：多个线程同时访问一个变量，CLR为了效率，允许每个线程进行本地缓存，这就导致了变量的不一致性。volatile就是为了解决这个问题，volatile修饰的变量，不允许线程进行本地缓存，每个线程的读写都是直接操作在共享内存上，这就保证了变量始终具有一致性。缺点很明显：牺牲了效率。 lock的使用场景：多个线程同时访问一个代码块，使用lock 修饰该代码块，强制多个线程进行排队，一个接一个的去访问。缺点很明显：排队进行必然导致效率低。 系统中应该尽量减少lock的使用（也就是排队执行的情况），因为根据阿姆达尔定律：S=1/(a+(1-a)/n) ，其中S 为加速比，a 为串行计算部分，n为并行计算节点，该公式意味着：如果具备足够的并行计算节点，要想增加系统的速度，必须减少串行部分。因为串行意味着，一个人做的时候，其他人必须等着。Google 的MapReduce，也就是把串行计算转化为并行计算。 转载于:https://www.cnblogs.com/nzbbody/archive/2011/12/29/2305895.html 来源： https://blog.csdn.net/weixin_30553065/article/details/99234337

郑昀 创建于2015/11/10 最后更新于2015/11/12 关键词：佣金计算、定时任务、数据抽取、数据清洗、数据计算、Java、Redis、MySQL、Zookeeper、azkaban2、oozie、mesos Summoner 是国玺部门推出的基于 MySQL+Redis+Zookeeper 的分布式并行计算调度和管理系统，李红红主设。 0x00，为什么要做“数据”并行计算调度？ 大家都可能做过 基于 MySQL 数据库的，大规模的、有步骤的、步骤与步骤之间有依赖关系的数据计算 。你可能定义了一堆彼此依赖的定时任务，也可能写成一个大进程跑。 举一个实际场景吧，在我们 O2O 业务体系下，我要做人员规模三四千人、有多条业务线、组织结构为大区-区域-城市-销售组的销售团队的昨日佣金和当月佣金，这里的挑战是： 涉及到商户、门店、交易、折扣、核销物料等等，数据量很大，至少每天都要算一次，要算得快， 激励政策和佣金计算公式随着竞争态势变化，一般一两个月变一次， 数据抽取尽可能少影响正常业务， 计算逻辑调整后要能快速部署和运行。 那么，以前可能会定义一些定时任务，每天凌晨从各个业务数据库（毕竟全都拆库分表了）里抽取： 人员组织架构 大区、区域和城市的对照关系 合同以及合同拥有者 商户和门店 门店下的收单交易 佣金计算公式、规则以及各种权重因子 …… 既有全量数据，也有增量数据

GBDT的整体是串行运行的，但在每一轮迭代时，以下是可以并行计算的： 1 计算(更新)每个样本的负梯度。(第m-1轮迭代完毕时，第m轮的每个样本的负梯度就可以全部更新出来了) 2 在拟合残差树时某个节点分类时，求各种可能的分类情况时的增益(基尼系数)是可以并行计算的。(GBDT没有做，xgboost做到了，用一个block结构存储这些特征增益)。但对于拟合一整棵残差树，增益是无法并行计算的，下一个节点的最大增益要在它的父节点生成后才可以求。 3 最后预测过程中，每个样本将之前的所有树的结果累加的时候。因为f(最终) = f(初) + f(残1) + f(残2) + …，一个测试样本最终的预测值等于各个子模型预测结果线性相加。各个子模型对于测试样本的预测是可以同时进行的，最后将各个模型的结果累加就是最终的预测值。 注：能并行的条件是在计算时数据都是已知，不需要得到以往的数据(这里指上一轮迭代得到的数据)才能进行就算。比如，如果求特征2的增益要知道特征1的增益，那这样增益计算就无法并行了。 来源： https://blog.csdn.net/weixin_40363423/article/details/98878459

海量数据处理是基于海量数据上的存储、处理、操作。 所谓海量，就是数据量很大，可能是TB级别甚至是PB级别，导致无法一次性载入内存或者无法在较短时间内处理完成。面对海量数据，我们想到的最简单方法即是分治法，即分开处理，大而化小，小而治之。我们也可以想到集群分布式处理。 1 海量数据的存储：为大数据分析做准备 传统关系型数据库 传统关系型数据库在 数据存储上主要面向结构化数据，聚焦于便捷的数据查询分析能力、按照严格规则快速处理事务（transaction）的能力、多用户并发访问能力以及数据安全性的保证。其结构化的数据组织形式，严格的一致性模型，简单便捷的查询语言，强大的数据分析能力以及较高的程序与数据独立性等优点获得广泛应用。 但是 面向结构化数据存储的关系型数据库已经不能满足当今互联网数据快速访问、大规模数据分析挖掘的需求。 它主要缺点： 1) 对于半结构化、非结构化的海量数据存储效果不理想。像电子邮件、 超文本、标签（Tag）以及图片、音视频等各种非结构化的海量数据。 2）关系模型束缚对海量数据的快速访问能力： 关系模型是一种按内容访问的模型。即在传统的关系型数据库中，根据列的值来定位相应的行。这种访问模型，会在数据访问过程中引入耗时的输入输出，从而影响快速访问的能力。虽然，传统的数据库系统可以通过分区的技术（水平分区和垂直分区） ，来减少查询过程中数据输入输出的次数以缩减响应时间