MapReduce执行过程
MapReduce存在以下4个独立的实体。1. JobClient：运行于client node，负责将MapReduce程序打成Jar包存储到HDFS，并把Jar包的路径提交到Jobtracker，由Jobtracker进行任务的分配和监控。
2. JobTracker：运行于name node，负责接收JobClient提交的Job，调度Job的每一个子task运行于TaskTracker上，并监控它们，如果发现有失败的task就重新运行它。
3. TaskTracker：运行于data node，负责主动与JobTracker通信，接收作业，并直接执行每一个任务。
4. HDFS：用来与其它实体间共享作业文件。
具体细节如下：
1.JobClient通过RPC协议向JobTracker请求一个新应用的ID，用于MapReduce作业的ID
2.JobTracker检查作业的输出说明。例如，如果没有指定输出目录或目录已存在，作业就不提交，错误抛回给JobClient，否则，返回新的作业ID给JobClient
3.JobClient将作业所需的资源（包括作业JAR文件、配置文件和计算所得得输入分片）复制到以作业ID命名的HDFS文件夹中
4.JobClient通过submitApplication()提交作业
5.JobTracker收到调用它的submitApplication()消息后，进行任务初始化
6.JobTracker读取HDFS上的要处理的文件，开始计算输入分片，每一个分片对应一个TaskTracker
map任务不是随随便便地分配给某个TaskTracker的，这里有个概念叫：数据本地化（Data-Local）。意思是：将map任务分配给含有该map处理的数据块的TaskTracker上，同事将程序jar包复制到该TaskTracker上来运行，这叫“运算移动，数据不移动”。而分配reduce任务时并不考虑数据本地化
7.TaskTracker通过心跳机制领取任务（任务的描述信息）
8.TaskTracker读取HDFS上的作业资源（JAR包、配置文件等）
9.TaskTracker启动一个java child子进程，用来执行具体的任务（MapperTask或ReducerTask）
10.TaskTracker将Reduce结果写入到HDFS当中
注：以HDFS的一个块的大小（默认64M）为一个分片
15年2.7.3版本开始，block size由64 MB变成了128 MB的。
Shuffle分析
Shuffle的中文意思是“洗牌”，如果我们这样看：一个map产生的数据，结果通过hash过程分区缺分配给了不同的reduce任务，是不是一个对数据洗牌的过程呢？
shuffle的概念：
Collections.shuffle(List list)：随机打乱list里的元素顺序。
MapReduce里的Shuffle：描述着数据从map task输出到reduce task输入的这段过程。
Map端流程分析
1 每个输入分片会让一个map任务来处理，默认情况下，以HDFS的一个块的大小（默认64M）为一个分片，当然我们也可以设置块的大小。map输出的结果会暂且放在一个环形内存缓冲区中（该缓冲区的大小默认为100M，由io.sort.mb属性控制），当该缓冲区快要溢出时（默认为缓冲区大小的80%，由io.sort.spill.percent属性控制），会在本地文件系统中创建一个溢出文件，将该缓冲区中的数据写入这个文件。
2 在写入磁盘之前，线程首先根据reduce任务的数目将数据划分为相同数目的分区，也就是一个reduce任务对应一个分区的数据。这样做是为了避免有些reduce任务分配到大量数据，而有些reduce任务却分到很少数据，甚至没有分到数据的尴尬局面。其实分区就是对数据进行hash的过程。然后对每个分区中的数据进行排序，如果此时设置了Combiner，将排序后的结果进行Combianer操作，这样做的目的是让尽可能少的数据写入到磁盘。
3 当map任务输出最后一个记录时，可能会有很多的溢出文件，这时需要将这些文件合并。合并的过程中会不断地进行排序和combiner操作，目的有两个：1、尽量减少每次写入磁盘的数据量；2、尽量减少下一复制阶段网络传输的数据量。最后合并成了一个已分区且已排序的文件。为了减少网络传输的数据量，这里可以将数据压缩，只要将mapred.compress.map.out设置为true就可以。
数据压缩：Gzip、Lzo、snappy。
4 将分区中的数据拷贝给相对应的reduce任务。有人可能会问：分区中的数据怎么知道它对应的reduce是哪个呢？其实map任务一直和其父TaskTracker保持联系，而TaskTracker又一直和obTracker保持心跳。所以JobTracker中保存了整个集群中的宏观信息。只要reduce任务向JobTracker获取对应的map输出位置就OK了。
reduce端流程分析
1 reduce会接收到不同map任务传来的数据，并且每个map传来的数据都是有序的。如果reduce端接收的数据量相当小，则直接存储在内存中（缓冲区大小由mapred.job.shuffle.input.buffer.percent属性控制，表示用作此用途的堆空间百分比），如果数据量超过了该缓冲区大小的一定比例（由mapred.job.shuffle.merg.percent决定），则对数据合并后溢写到磁盘中。
2 随着溢写文件的增多，后台线程会将它们合并成一个更大的有序的文件，这样做是为了给后面的合并节省空间。其实不管在map端还是在reduce端，MapReduce都是反复地执行排序，合并操作，现在终于明白了有些人为什么会说：排序是hadoop的灵魂。
3 合并的过程中会产生许多的中间文件（写入磁盘了），但MapReduce会让写入磁盘的数据尽可能地少，并且最后一次合并的结果并没有写入磁盘，而是直接输入到reduce函数。
4 Reducer的输入文件。不断地merge后，最后会生成一个“最终文件”。为什么加引号？因为这个文件可能存在于磁盘上，也可能存在于内存中。对我们来说，希望它存放于内存中，直接作为Reducer的输入，但默认情况下，这个文件是存放于磁盘中的。当Reducer的输入文件已定，整个Shuffle才最终结束。然后就是Reducer执行，把结果放到HDSF上。
详细过程：
1 每个map task都有一个内存缓冲区，存储着map的输出结果，当缓冲区快满的时候需要将缓冲区的数据以一个临时文件的方式存放到磁盘，当整个map task结束后在对磁盘中这个map task产生的所有临时文件做一个合并，生成最终的正式输出文件，然后等待reduce task来拉数据。
2 在map task执行时，它的输入数据来源于HDFS的block，当然在MapReduce概念中，map task只读取split。split与block对应关系可能是多对一，默认是一对一。在wordcount例子里，假设map的输入数据都是是像“aaa”这样的字符串。
3 在经过mapper的运行后，我们得知mapper的输出是这样一个key/value对：key是“aaa”，value是数值1。因为当前map端只做加1的操作，在reduce task里采取合并结果集。前面我们知道这个job有3个reduce task。那到底当前的“aaa”究竟该丢给哪个reduce去处理呢？是需要现在做决定的。
4 MapReduce提供Partitioner接口，作用就是根据key或value及reduce的数量来决定当前的输出数据最终应该交由哪个reduce task处理。默认对key hash后再以reduce task数据取模（取余）。默认的取模方式只是为了平均reduce的处理能力，如果用户自己对Partitioner有需求，可以定制并设置到job上。
5 在例子中，“aaa”经过Partition后返回0，也就是这对值应当交由第一个reduce来处理。接下来，需要将数据写入内存缓冲区中，缓冲区的作用是批量收集map结果，减少磁盘IO的影响。我们的key/value对以及Partition的结果都会被写入缓冲区。当然，写入之前，key与value值都会被序列化成字节数组。
6 内存缓冲区是有大小限制的，默认是100MB。当map task的输出结果很多时，就可能会撑爆内存，所以需要在一定条件下将缓冲区中的数据临时写入磁盘，然后重新利用这块缓冲区。这个从内存往磁盘写数据的过程被称为spill，中文可理解为溢写。溢写是由单独线程来完成，不影响往缓冲区写map结果的线程。溢写线程启动时不应该阻止map的结果输出，所以整个缓冲区有个溢写的比例spill.percent。比例默认是0.8，也就是当缓冲区的数据值已经达到阈值（buffer size * spill percent = 100MB * 0.8 = 80MB），溢写线程启动，锁定这80MB的内存，执行溢写过程。map task的输出结果还可以往剩下的20MB内存中写，互不影响。
7 当溢写线程启动后，需要对这80MB空间内的key做排序（sort）。排序是MapReduce模型默认的行为，这里的排序也是对序列化的字节做的排序。
8 因为map task的输出是需要发送到不同的reduce端去，而内存缓冲区没有对将发送到相同reduce端的数据做合并，那么这种合并应该是体现在磁盘文件中的。从官方图上也可以看到写到磁盘中的一些文件是对不同的reduce端的数值做过合并。所以溢写过程一个很重要的细节在于，如果有很多个key/value对需要发送到某个reduce端去，那么需要将这些key/value值拼接到一块，减少与partition相关的索引记录。
在针对每个reduce端而合并数据时，有些数据可能像这样：“aaa”/1，“aaa”/1。对于wordcount例子，只是简单地统计单词出现的次数，如果在同一个map task的结果中有很多像“aaa”一样出现多次的key，我们就应该把它们的值合并到一块，这个过程叫reduce也叫combine。但MapReduce的术语中，reduce只值reduce端执行从多个map task取数据做计算的过程。除reduce外，非正式地合并数据只能算作combine了。其实大家知道的，MapReduce中将Combiner等同于Reducer。
如果client设置过Combiner，那么现在就是使用Combiner的时候了。将有相同key的key/value对的value加起来，减少溢写到磁盘的数据量。Combiner会优化MapReduce的中间结果，所以它在整个模型中会多次使用。那哪些场景才能使用Combiner呢？从这里分析，Combiner的输出是Reducer的输入，Combiner绝不能改变最终的计算结果。所以从我的想法来看，Combiner只应该用于那种Reduce的输入key/value与输出key/value类型完全一致，且不影响最终结果的场景。比如累加，最大值等。Combiner的使用一定得慎重，如果用好，它对job执行效率有帮助，反之会影响reduce的最终结果。
9 每次溢写会在磁盘上生成一个溢写文件，如果map的输出结果真的很大，有多次这样的溢写发生，磁盘上相应的就会有多个溢写文件存在。当map task真正完成时，内存缓冲区中的数据也全部溢写到磁盘中形成一个溢写文件。最终磁盘中会至少有一个这样的溢写文件存在（如果map的输出结果很少，当map执行完成时，只会产生一个溢写文件），因为最终的文件只有一个，所以需要将这些溢写文件归并到一起，这个过程就叫Merge。Merge是怎样的？如前面的例子，“aaa”从某个map task读取过来时值是5，从另外一个map读取时值是8，因为他们有相同的key，所以要merge成group。
什么是group：对于“aaa”就是像真阳的：{“aaa”，[5,8,2,...]}，数组中的值就是从不同的溢写文件中读取出来的，然后再把这些值加起来。请注意，因为merge是将多个溢写文件合并到一个文件，所以可能也有相同的key存在，在这个过程中，如果client设置过Combiner，也会使用Combiner来合并相同的key。
至此，map端的所有工作都已经结束，最终生成的这个文件也存放在TaskTracker够得到的某个本地目录中。每个reduce task不断地通过RPC从JobTRacker那获取map task是否完成的信息，如果reduce task得到通知，获知某台TaskTracker上的map task执行完成，Shuffle的后半段过程开始启动。
Reduce端的shuffle过程：
1 copy过程，简单地拉取数据。Reduce进程启动一些数据copy线程（Fetcher），通过http方式请求map task所在的TaskTracker获取map task的输出文件。因为map task早已结束，这些文件就归TaskTracker管理在本地磁盘中。
2 Merge阶段。这里的merge和map端的merge动作相同，只是数组中存放的是不同map端copy来的数值。copy过来的数据会先放入内存缓冲区中，这里的缓冲区大小要比map端更为灵活，它基于JVM的heap size设置，因为Shuffle阶段Reducer不运行，所以应该把绝大部分的内存都给Shuffle使用。
3 Merge有三种形式：1、内存到内存；2、内存到磁盘；3、磁盘到磁盘。默认情况下第一种形式不启用，让人比较困惑。当内存中的数据量到达一定阈值，就启动内存到磁盘的merge。与map端类似，这也是溢写的过程，在这个过程中如果你设置有Combiner，也是会启用的，然后在磁盘中生成了众多溢写文件。第二种merge方式一直在运行，直到没有map端的数据时才结束，然后启动第三种磁盘到磁盘的merge方式生成最终的那个文件。
Map端流程分析
1 每个输入分片会让一个map任务来处理，默认情况下，以HDFS的一个块的大小（默认64M）为一个分片，当然我们也可以设置块的大小。map输出的结果会暂且放在一个环形内存缓冲区中（该缓冲区的大小默认为100M，由io.sort.mb属性控制），当该缓冲区快要溢出时（默认为缓冲区大小的80%，由io.sort.spill.percent属性控制），会在本地文件系统中创建一个溢出文件，将该缓冲区中的数据写入这个文件。
2 在写入磁盘之前，线程首先根据reduce任务的数目将数据划分为相同数目的分区，也就是一个reduce任务对应一个分区的数据。这样做是为了避免有些reduce任务分配到大量数据，而有些reduce任务却分到很少数据，甚至没有分到数据的尴尬局面。其实分区就是对数据进行hash的过程。然后对每个分区中的数据进行排序，如果此时设置了Combiner，将排序后的结果进行Combianer操作，这样做的目的是让尽可能少的数据写入到磁盘。
3 当map任务输出最后一个记录时，可能会有很多的溢出文件，这时需要将这些文件合并。合并的过程中会不断地进行排序和combiner操作，目的有两个：1、尽量减少每次写入磁盘的数据量；2、尽量减少下一复制阶段网络传输的数据量。最后合并成了一个已分区且已排序的文件。为了减少网络传输的数据量，这里可以将数据压缩，只要将mapred.compress.map.out设置为true就可以。
数据压缩：Gzip、Lzo、snappy。
4 将分区中的数据拷贝给相对应的reduce任务。有人可能会问：分区中的数据怎么知道它对应的reduce是哪个呢？其实map任务一直和其父TaskTracker保持联系，而TaskTracker又一直和obTracker保持心跳。所以JobTracker中保存了整个集群中的宏观信息。只要reduce任务向JobTracker获取对应的map输出位置就OK了。
reduce端流程分析
1 reduce会接收到不同map任务传来的数据，并且每个map传来的数据都是有序的。如果reduce端接收的数据量相当小，则直接存储在内存中（缓冲区大小由mapred.job.shuffle.input.buffer.percent属性控制，表示用作此用途的堆空间百分比），如果数据量超过了该缓冲区大小的一定比例（由mapred.job.shuffle.merg.percent决定），则对数据合并后溢写到磁盘中。
2 随着溢写文件的增多，后台线程会将它们合并成一个更大的有序的文件，这样做是为了给后面的合并节省空间。其实不管在map端还是在reduce端，MapReduce都是反复地执行排序，合并操作，现在终于明白了有些人为什么会说：排序是hadoop的灵魂。
3 合并的过程中会产生许多的中间文件（写入磁盘了），但MapReduce会让写入磁盘的数据尽可能地少，并且最后一次合并的结果并没有写入磁盘，而是直接输入到reduce函数。
4 Reducer的输入文件。不断地merge后，最后会生成一个“最终文件”。为什么加引号？因为这个文件可能存在于磁盘上，也可能存在于内存中。对我们来说，希望它存放于内存中，直接作为Reducer的输入，但默认情况下，这个文件是存放于磁盘中的。当Reducer的输入文件已定，整个Shuffle才最终结束。然后就是Reducer执行，把结果放到HDSF上。
注意：对MapReduce的调优在很大程度上就是对MapReduce Shuffle的性能的调优。
三、内存缓冲区：MapOutputBuffer
两级索引结构：
环形缓冲区：
1 kvoffsets缓冲区：也叫偏移量索引数组，用于保存key/value信息在位置索引kvindices中的偏移量。当kvoffsets的使用率超过io.sort.spill.percent（默认为80%）后，便会触发一次SpillThread线程的“溢写”操作，也就是开始一次spill阶段的操作。
2 kvindices缓冲区：也叫位置索引数组，用于保存key/value在数据缓冲区kvbuffer中的起始位置。
3 kvbuffer数据缓冲区：用于保存实际的key/value的值。默认情况下该缓冲区最多可以使用io.sort.mb的95%，当kvbuffer使用率超过io.sort.spill.percent（默认80%）后，便会触发一次SpillThread线程的“溢写”操作，也就是开始一次spill阶段的操作。
绛旓細闄勪簩銆佸緱鍑虹粨璁虹殑娴嬭瘯杩囩▼ 锛堟湭鏈夌┖鐪嬩功锛屽彧鑳介氳繃鎰氱鐨勬祴璇曟柟娉曞緱鍑虹粨璁轰簡锛変竴. 鐩存帴閫氳繃windows涓奅clipse鍙冲嚮main绋嬪簭鐨刯ava鏂囦欢锛岀劧鍚"run as application"鎴栭夋嫨hadoop鎻掍欢"run on hadoop"鏉ヨЕ鍙鎵цMapReduce绋嬪簭鐨勬祴璇曘1锛屽鏋滀笉鎵搄ar鍖呭埌杩涢泦缇や换鎰弆inux鏈哄櫒涓婏紝瀹冩姤閿欏涓嬶細[work] 2012-06-25 ...
绛旓細鍙互鍙敤涓琛屼唬鐮佹潵杩愯MapReduce浣滀笟:JobClient.runJon(conf),Job浣滀笟杩愯鏃跺弬涓庣殑鍥涗釜瀹炰綋: 1.JobClient 鍐欎唬鐮,閰嶇疆浣滀笟,鎻愪氦浣滀笟銆 2.JobTracker:鍒濆鍖栦綔涓,鍒嗛厤浣滀笟,鍗忚皟浣滀笟杩愯銆傝繖鏄竴涓猨ava绋嬪簭,涓荤被鏄疛obTracker銆 3.TaskTracker:杩愯浣滀笟鍒掑垎鍚庣殑浠诲姟,鍗冲垎閰嶆暟鎹垎閰嶄笂鎵цMap鎴朢educe浠诲姟銆 4.HDFS:淇濆瓨...
绛旓細澶ф暟鎹殑鏃朵唬锛 鍒板寮犲槾闂槾閮芥槸Hadoop, MapReduce, 涓嶈窡涓婃椂浠ｆ庝箞琛岋紵 鍙槸瀵逛竴涓猦adoop鐨勬柊鎵嬶紝 鍐欎竴涓睘浜庤嚜宸辩殑MapReduce绋嬪簭杩樻槸灏忔湁鐐归毦搴︾殑锛 闇瑕佸缓绔嬩竴涓猰aven椤圭洰锛 杩樿鎼炴竻妤氬悇绉嶅簱鐨勪緷璧栵紝 鍐嶅姞涓婄紪璇戣繍琛岋紝 鍩烘湰涓婂ご澶т袱鍦堜簡鍚с 杩欎篃浣垮緱寰堝鍙槸鎯崇畝鍗曚簡瑙ｄ竴涓婱apReduce鐨勪汉鏈涜...
绛旓細鍙互鍙敤涓琛屼唬鐮佹潵杩愯MapReduce浣滀笟:JobClient.runJon(conf),Job浣滀笟杩愯鏃跺弬涓庣殑鍥涗釜瀹炰綋: 1.JobClient 鍐欎唬鐮,閰嶇疆浣滀笟,鎻愪氦浣滀笟銆 2.JobTracker:鍒濆鍖栦綔涓,鍒嗛厤浣滀笟,鍗忚皟浣滀笟杩愯銆傝繖鏄竴涓猨ava绋嬪簭,涓荤被鏄疛obTracker銆 3.TaskTracker:杩愯浣滀笟鍒掑垎鍚庣殑浠诲姟,鍗冲垎閰嶆暟鎹垎閰嶄笂鎵цMap鎴朢educe浠诲姟銆 4.HDFS:淇濆瓨...
绛旓細浣跨敤Hadoop杩涜澶ф暟鎹繍绠楋紝褰撴暟鎹噺鏋佸叾澶ф椂锛岄偅涔堝MapReduce鎬ц兘鐨勮皟浼橀噸瑕佹т笉瑷鑰屽柣锛屽挨鍏舵槸Shuffle杩囩▼涓殑鍙傛暟閰嶇疆瀵逛綔涓氱殑鎬绘墽琛屾椂闂村奖鍝嶇壒鍒ぇ銆備笅闈㈡荤粨涓浜涘拰MapReduce鐩稿叧鐨勬ц兘璋冧紭鏂规硶锛屼富瑕佷粠浜斾釜鏂归潰鑰冭檻锛氭暟鎹緭鍏ャ丮ap闃舵銆丷educe闃舵銆丼huffle闃舵鍜屽叾浠栬皟浼樺睘鎬с傚湪鎵цMapReduce浠诲姟鍓嶏紝灏嗗皬...
绛旓細MapReduce鏋佸ぇ鍦版柟渚夸簡缂栫▼浜哄憳鍦ㄤ笉浼氬垎甯冨紡骞惰缂栫▼鐨勬儏鍐典笅锛屽皢鑷繁鐨勭▼搴忚繍琛屽湪鍒嗗竷寮忕郴缁熶笂銆侻apReduce淇濊瘉缁撴灉鏂囦欢涓璳ey鐨勫敮涓鎬х殑鏂规硶涓猴細1銆佹墦寮Hadoop闆嗙兢锛屾墦寮涓绘満master鐨勭粓绔紝杈撳叆銆恑fconfig銆戝懡浠ゆ煡鐪嬩富鏈篒P鍦板潃銆2銆佷娇鐢⊿ecureCRT杞欢杩炴帴鍒癏adoop闆嗙兢鐨勪富鏈恒3銆侀鍏堣繘鍏ュ埌hadoop鐩綍涓嬬殑bin鐩綍...
绛旓細Hadoop鏄敤鏉ュ紑鍙戝垎甯冨紡绋嬪簭鐨勬灦鏋勶紝鏄竴涓敱Apache鍩洪噾浼氭墍寮鍙戠殑鍒嗗竷寮忕郴缁熷熀纭鏋舵瀯銆傜敤鎴峰彲浠ュ湪涓嶄簡瑙ｅ垎甯冨紡搴曞眰缁嗚妭鐨勬儏鍐典笅锛屽紑鍙戝垎甯冨紡绋嬪簭銆MapReduce鏄敤鏉ュ仛澶ц妯″苟琛屾暟鎹鐞嗙殑鏁版嵁妯″瀷銆傛柟渚夸簡缂栫▼浜哄憳鍦ㄤ笉浼氬垎甯冨紡骞惰缂栫▼鐨勬儏鍐典笅锛屽皢鑷繁鐨勭▼搴忚繍琛屽湪鍒嗗竷寮忕郴缁熶笂銆
绛旓細瀹冪殑杩愯鏃剁幆澧冪敱涓ょ被鏈嶅姟缁勬垚锛欽obTracker鍜孴askTracker锛屽叾涓紝JobTracker璐熻矗璧勬簮绠＄悊鍜屾墍鏈変綔涓氱殑鎺у埗锛岃孴askTracker璐熻矗鎺ユ敹鏉ヨ嚜JobTracker鐨勫懡浠ゅ苟鎵ц瀹冦傦紙4锛MapReduce 2.0鎴栬匨Rv2锛圡apReduce version 2锛夋垨鑰匩extGen MapReduc MapReduce 2.0鎴栬匨Rv2鍏锋湁涓嶮Rv1鐩稿悓鐨勭紪绋嬫ā鍨嬶紝鍞竴涓嶅悓鐨勬槸杩愯鏃...
绛旓細鍦ㄥ彜鑰佺殑 Hadoop1.0 涓紝MapReduce 鐨 JobTracker 璐熻矗浜嗗お澶氱殑宸ヤ綔锛屽寘鎷祫婧愯皟搴︼紝绠＄悊浼楀鐨 TaskTracker 绛夊伐浣溿傝繖鑷劧鏄笉鍚堢悊鐨勶紝浜庢槸 Hadoop 鍦 1.0 鍒 2.0 鐨勫崌绾杩囩▼涓紝渚垮皢 JobTracker 鐨勮祫婧愯皟搴﹀伐浣滅嫭绔嬩簡鍑烘潵锛岃岃繖涓鏀瑰姩锛岀洿鎺ヨ Hadoop 鎴愪负澶ф暟鎹腑鏈绋冲浐鐨勯偅涓鍧楀熀鐭炽傦紝鑰岃繖涓...
绛旓細鍏跺疄锛屽皢map澶勭悊鐨勭粨鏋滐紝浼犺緭鍒皉educe涓婄殑杩囩▼锛屽湪MapReduce涓紝鍙互鐪嬪仛shuffle鐨勮繃绋嬨傚湪map绔紝姣忎釜map task閮芥湁涓涓唴瀛樼紦鍐插尯锛屽瓨鍌ㄧ潃map鐨勮緭鍑虹粨鏋滐紝褰撶紦鍐插尯蹇弧鐨勬椂鍊欓渶瑕佸皢缂撳啿鍖虹殑鏁版嵁浠ヤ竴涓复鏃舵枃浠剁殑鏂瑰紡瀛樻斁鍒扮鐩橈紝褰撴暣涓猰ap task缁撴潫鍚庡啀瀵圭鐩樹腑杩欎釜map task浜х敓鐨勬墍鏈変复鏃舵枃浠跺仛鍚堝苟锛...
