※ 引述《azai2008 (阿宅)》之铭言： : 刚刚去逛了一下比赛的部落格 : 发现里面有更新一个实作范例，是利用Apache hadoop进行google的mapreduce : 这样就可以把程式进行切割，在丢到每台电脑进行运算 : 还蛮有趣的范例 : 跟之前把资料丢到大型主机进行运算的方式完全相反~ : http://www.wretch.cc/blog/trendnop09/21085442 这个之前有玩过了， 不过它对 Java 的支援比较完善， C++ 虽然有 API 但是一堆 Java 能用的 C++ 都没得用， 譬如存取 HDFS 的部分都没有文件， 只有内部隐藏的 API， 你想直接用 fopen() 或 ifstream 读档是读不到东西的； 最重要的是它的 HDFS 慢到炸掉， 可是 process 之间并没有类似 IPC 的东西， 如果你想让 process 之间能互传资料， 目前除了写进慢到不行的 HDFS 里再读出来外没有其它方法。 还有程式运算本身的性质是否适合 MapReduce 也很重要， 一般来说 map 的 process 数跟你写入 input path 的档案数量一致， input file 的格式是 key/value values， 产生 input file 的方法可以用纯文字档， 或是它们提供的 SequenceFile.Writer， 它的运算结果也是 key/value pairs， map class 会被呼叫到的 method 大概就长这样： public void map(InputKeyType key, InputValueType value, OutputCollector<OutputKeyType, OutputValueType> out, Reporter reporter) throws IOException { ... out.collect(new OutputKeyType(...), new OutputValueType(...)); } 这是被动呼叫的 method， 你用来当作 input 的档案会被分解成很多 key/value pairs， 然後一组一组的被传进来跑你自订的 code， key 和 value 的 types 可以自己决定 (非基础型别的话会比较复杂要用它们的 serialization 模型自己定义一份)， input 和 output 的 key/value types 可以不同； reduce 就像是把分散出去算的东西合并收集起来 (通常 task 数远少於 map)， 有相同 key 的 values 会被 reduce task 并成一项， 比方说不同的 map tasks 丢出来的结果有 ("a", 1), ("a", 2), ("a", 3) 你可以设计 reduce task 把它们的 value 用加法合并成 ("a", 6)， reduce class 被呼叫到的 method 大概长这样： public void reduce(InputKeyType key, Iterator<InputValueType> values, OutputCollector<OutputKeyType, OutputValueType> out, Reporter reporter) throws IOException { while(values.hasNext()) { ... } out.collect(new OutputKeyType(...), new OutputValueType(...)); } 看参数列应该就知道， 当资料传进 reduce tasks 时， 背後已经有一个机制把具相同 key 的 values 收集起来了， 要单纯把 values 加起来就是在上面的 while loop 写个累加运算， reduce tasks 输出的 key/value pairs 会变成档案存在 HDFS， 档案的数量跟 reduce tasks 的数量一样多， 要 parse 它们的话用它们提供的 SequenceFile.Reader 就可以了。 简单来说这是没有 global variable 的世界， process 之间传递资料完全靠传 function arguments 沟通 (仅限於 map 对 reduce，像 map 跟 map 之间只能靠读写 HDFS)， arguments 的形式只能是 key/value pairs， 如果这样无法满足你的需求或是你想不到如何把程式模型转成这样 (转换的方式通常是以完全不同角度思考，常让人跌破眼镜)， 一定要用到全域资料的话， 你写出来的程式一定是用 100 台运算比用 1 台算还慢 100 倍以上， 因为全域资料只能透过读写 HDFS 来进行， 这种东西的 I/O 速度是用秒来当单位的， 人多的时候可能还要用分钟当单位。 被拿来当范例用的 word count 刚好就适合这种设计模式， 搜寻引擎大部分的 algorithm 也是跟这种模式相契合， 但是否世界上所有的问题都适合以这种模式实作， 我个人觉得答案是否定的， 虽然一直看到很多人在推这东西， 不过实际上写过用过就会发现没有那麽好。 虽然讲是这样讲， 不过应用范围也没想像中的窄就是了， 只是看范例学这东西很容易产生一种误解， 就是把 reduce tasks 当成收破烂的阿嬷， 以为它单纯只是被拿来收集和汇整结果用的东西， 结果把所有工作都设计成由 map tasks 处理 (这种问题的典型案例就是 reduce task 数永远只有 1)； 其实 reduce tasks 可以跟 map tasks 同时进行， 要是没办法善用 reduce tasks 的话， 你程式的 critical path 就很难再缩短， 光是想到把运算责任全部塞在 map task 上， 结果跑出来的效能很烂的话， 先怪 MapReduce 的模型不适合也是有问题的。 -- Ling-hua Tseng ([email protected]) Department of Computer Science, National Tsing-Hua University Interesting: C++, Compiler, PL/PD, OS, VM, Large-scale software design Researching: Software pipelining for VLIW architectures Homepage: https://www.tinlans.org --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 118.160.104.178 ※ 编辑: tinlans 来自: 118.160.104.178 (04/12 03:54)