海量数据处理大作业实验报告

海量数据处理实验报告PancakeTycoon煎饼大亨海量数据处理课程实验报告清华大学计54曹正kevin@goog01清华大学计54杨子redeye@goog01一项目内容简介本项目主题是实现一款模拟经营类游戏。使用hadoop大规模数据处理技术，对店铺、顾客进行模拟，并针对店铺信息等提供可供玩家设置的交互性，从而实现最简单的模拟经营效果。游戏对煎饼摊这一校内常见的经营进行模拟。用户可以设置煎饼摊的数量，不同摊位的详细设置（见后，详细设计部分）。软件根据用户的设置，对每个顾客的消费行为作模拟，最后汇总，返回给用户。用户根据返回的结果，适当调整摊位的设置，力争尽可能多的利润。煎饼摊需要投入经营资金，例如面粉等原料的进货。同时销售则会收入资金。利润由此而来。总体上，单个摊位的模型设置如前所述，可以看到和实际中的煎饼摊位是差不多的。在应对多店铺的情况时，模型有所简化，见详细设计部分。二项目详细设计1总论软件需要与用户交互，以输入店铺参数等信息，同时软件还要能够使用分布式系统，进行hadoop数据处理，最后软件要将结果返回给用户。基于以上功能需求的考虑，软件划分为两个部分：与用户交互、接受输入、反馈结果的客户端，和获得运行所需数据、进行hadoop数据处理、最终汇总结果返回的服务器端。客户端运行在用户机器上，服务器端运行在集群上。双方通过Socket进行通信，以协议的形式设定好双方统一的命令、数据格式。2数学模型如项目概述所述，对于每个店铺，使用类似实际的表达。对于店铺见的关系，软件对模型作了高度简化。对于顾客信息，为了运算的需要，产生对应的参数。a店铺信息考察一个实际的煎饼摊位，为了煎饼制作、销售的进行，摊位需要准备如下物资：面粉、果子（薄脆）、葱、酱（这里我们分为甜和咸两种）、鸡蛋。我们对模型作了简化，没有提供榨菜等。这些物资在经营过程中需要玩家给出进货指令来增加。煎饼销售要考虑的问题有售价，以及每套煎饼内使用的面粉、果子（薄脆）、葱、酱、鸡蛋。这里果子（薄脆）和鸡蛋可以按照顾客的需求加入，参见顾客模型。经营过程就是物资的输入输出，收入的获得，成本的支出过程。玩家控制进货，对应的产生指出；经营过程被模拟出来，对应的产生收入。最终的经营效果，包括物资的剩余量和销售收入会提供的玩家，以便作分析进行进货。b顾客信息在店铺信息中已经给出了经营算法。这里考虑每一位顾客是否会购买煎饼。模型被简化，目前每位顾客有买与不买两个选择，但不会买多份。为了考察购买与否，需要给出一个评估函数。该函数以店铺信息中的经营参数，以及顾客信息作为参数。为此，顾客信息模型建立，带有如下参数：喜好的面粉量、葱、酱添加量，加多少果子，加多少鸡蛋。店铺与顾客对应参数相减，取偏差相对喜好的百分比，再相加。使用该值作为评估函数的一部分，另一部分参见顾客调查。定义好评估函数，则每个顾客均参与评估，当达到阈值，如0.5之类，则评估返回为购买，否则即为不购买。将所有顾客遍历，得到汇总信息，归并之后返回给玩家，也就是店铺信息指出的返回值的来源。顾客的数目可以在服务器端的程序中手动进行设置。c多店铺多店铺模型相比开始时的设计有大幅简化。初始设计中，店铺带有坐标信息，对应的顾客也带有坐标信息。取欧氏距离作为计算标准，每位顾客在每一轮经营中会选择最近的一个店铺。后来，取消了坐标的设计。目前的设计是顾客会随意选择一个店铺，然后根据顾客信息中的方式进行评估。店铺的数目和分布可以在客户端的程序中手动进行设置。目前的店铺设置为清华大学地图中的10个店铺位置，如下图所示。其中的数字是服务器端和客户端约定的交流hardcode部分，这些信息替代了原来的坐标信息。d顾客调查软件提供给客户一些额外信息，是对购买的顾客作的调查，包括：是否觉得贵，是否认为等待时间过长，是否认为过咸或者过淡，是否认为过甜。为了模拟这些信息，在顾客信息中添加这些成员，并在每轮模拟中计算这些值。计算方法同顾客信息中指出的评估方法。特别地，由于有了顾客调查这部分信息，故让他们也参与到评估中，方法即为在最终的评估结果基础上加上这些数值。值得注意的是，所加的数值是上一轮计算出来的，对应实际中对一个煎饼摊的印象。而后新的顾客调查数值才会被计算出来并在信息中更新。以上所有的数值都是为了参与模拟经营的计算，要返回给玩家时，再进行如下模拟。在店铺信息中指出的汇总过程中，考察每一个顾客。生成一个随机数，如果随机到调查该顾客，则从顾客调查信息中取出数据，否则跳过、轮询下一位顾客。在取出数据后，按照一定阈值，如0.02，对数据作评估，在对应的问卷结果中加入。该过程类似下面的代码。foreveryguest{getarandomnumber;ifthenumberdostn'tfit,continue;getalldataofthisguest;count_of_transaction++;if(data.feel_expensivemorethan0.02)count_of_feel_expensive++;other3if-clauses}以上代码最终会返回count_of_transactioncount_of_feel_expensiveetc.信息，而这些则最终反馈给玩家。3通信协议从以上模型分析中可以获得以下信息。i客户端需要告知服务器端用户输入的参数；ii客户端需要通知服务器端进行经营的模拟；iii服务器端执行结束后要告诉客户端；iv客户端要求时将结果从服务器端传回；v客户端要告诉服务器端的信息组成的格式规定；vi服务器端要返回给客户端的信息组成的格式规定。以上为协议的概况，详细协议内容参见附录。4服务器端服务器端代码位于gServer.jar，编译单元mainclass.java。服务器端包含六个类。amainclass控制server端全部的控制逻辑。由main创建socket，等待客户段连接，并实现与客户端的交互。针对客户端的不同请求调用相应的方法。同时通过带有不同参数的启动服务器端，实现生成顾客信息等server需要的工具功能。idealParameter接受客户端的信息，这些信息是协议中提到的用户输入的参数，对应数学模型中的（多）店铺信息。iidealExecute包装执行过程，在客户端请求进行经营的模拟时，server的控制逻辑调用该函数。该函数通过一系列Linux本地过程调用实现server所在Linux主机文件系统与hadoop文件系统的信息交换和数据格式转换。该函数通过调用hadoopExecute实现事实上的模拟过程。iiihadoopExecute接受客户端的一些参数，如时间等，并使用模拟经营所用到的所有数据构造ExecuteOnce类，进行mapreduce执行过程。ivdealSendResult包装了发送结果的过程，包括一些命令控制字的发送，并通过调用dealSendResultA完成每一份（如果不止一个店铺）结果的格式转换和发送过程。vdealSendResultA完成事实上的结果发送。vicommandToInteger工具函数。由于使用Socket流传递的命令字为字符格式，使用该函数将之转换为数值格式，以方便server端的控制逻辑。bParameters工具类，用以表征用户输入的参数。提供了String作为参数的构造函数，并重写了toString方法，以实现类数据格式、hadoop字符串快捷参数格式的转换。cResults工具类，用以表征模拟的结果。提供了String作为参数的构造函数，并重写了toString方法，以实现类数据格式、文件内存储格式之间的转换。提供了根据Parameters构造Results的方法，以方便reduce中的结果生成。dPeopleGenerating工具类，提供了顾客信息的对象表示形式。提供了String作为参数的构造函数，并重写了toString方法，以实现类数据格式、文件内存储格式之间的转换。提供静态方法run，通过mainclass::main被调用，以帮助生成足够数量的顾客信息。eMyRandomextendsRandom工具类，继承自Random，以方便实现生成制定范围的Gauss分布随机数。fExecuteOnce负责MapReduce实现的类。内含静态类Map，Reduce，作为MapReduce的实现。在run中负责参数格式化工作，并设置双文件输出模式。iMapmap过程的工作类，其实现基于前述数学模型。iiReducereduce过程的工作类，其实现基于前述数学模型。iiiMyOutputFormatextendsMultipleTextOutputFormat派生类，用以实现多文件输出。重写了generateFileNameForKeyValue方法，根据key的不同，输出像不同的文件。定义特殊的key=-1，表示输出汇总结果，否则为顾客信息的更新后结果。5客户端客户端部分使用Flash（基于ActionScript3.0）进行编写。共使用6个图层，其中包括背景层、图片层、组件层、动作层和隐藏层。而动作部分主要包含组件的动作记录，事件监听和socket连接。整个模型的操作基于Stall类，该类保存于Stall.as中，其中存储了和服务器端类似的Stall数据结构，包括一个店铺的id，坐标信息，最大容量，是否被购买（对于未被购买的店铺，店铺基本信息是存在的），名称，以及各类进货信息，煎饼的配料信息和售价。除此之外，该类还封装了一些组件信息，例如在地图上表示这个类的一个MovieClip组件以及对应的RadioButton，方便后面的调试和操作。而构造函数publicfunctionStall(sid:int,sx:Number,sy:Number,scapacity:int,sname:String)对于上述变量进行了初始化。游戏的执行在目前的版本中并没有很绚丽的界面，主要实现在6个帧内完成。第一帧中包含了欢迎画面和IP以及Port的输入窗体，而在代码部分，主要对于按钮进行监听，一旦发现单击事件，立即触发LoginAction，进行Socket连接。而Socket的定义使用了基本的字节流Socket，并没有使用XMLSocket，定义和对应的事件监听如下：varsocket:Socket=newSocket();socket.addEventListener(Event.CONNECT,onConnect);socket.addEventListener(ProgressEvent.SOCKET_DATA,onSocketData);socket.addEventListener(IOErrorEvent.IO_ERROR,ioError);对于第一个和第三个事件分别表示连接成功和连接失败，在Flash中会分别转向第3帧和第2帧。这一帧的截图如下。第二帧中进行报错处理，同时保持第一帧中的输入和按钮组件，因此可以重复进行尝试，直到成功为止，第二帧执行截图如下所示。一旦进入第三帧，说明Socket已经成功连接，由于在第四帧和第五帧之间会进行不断的循环操作，进行逐日的进货销售过程。因此在第三帧中并没有任何的图片信息，只是在代码部分加入了店铺的初始化信息，店铺数组（10家店铺的指针集合）地建立以及启动资金的初始化，在目前的模型中启动资金为10000元。第四帧是程序执行最核心的部分，代码的前半部分需要处理游戏地图区域的选择事件（触发选中相应的Stall，更新其MovieClip的执行情况），若干按钮的单击事件（触发socket端发出传参操作，以及买卖店铺事件）以及NumericStepper的更改事件（将相应的值保存在Stall类的实例中）。该帧代码的后半部分需要处理socket产生的onSocketData事件，也就是对于socket接收到服务器发来的所有socket数据进行解析，处理，进行相应的应答。对于传参操作，会不断的发送socket数据，而在第5帧进行的接受结果操作，也在同一个函数中进行实现，需要将接收的信息，在窗口中进行显示。考虑到程序编写的方便，在游戏设计之初，服务器端和客户端就分工，将程序中两个需要长时间保存的数据分别保存于两端，各个原料的库存量（这些量将会保留到第二天继续参与）由服务器端维护（因为库存涉及到当日的原料是否可以充足的供应给顾客，这一部分在服务器端实现），而总的金额由服务器端维护（因为这些金额还可以用于店铺规模的扩大，以及购买新的店铺、变卖已有店铺，这些操作直接在客户端上进行）。基本界面如下所示。其中的左侧为地图区域，主要包括一张现有地图，以及上面的位置标示，当鼠标单击其中的标示时，会触发相应判断，如果这是一个已经拥有的店铺（对应的availability属性值为true），那么选中时，会变为旋转彩色边界，对应的数据更新为该店铺的值，并且可以编辑，同时可以进行Sell操作，通过右侧的Sell按钮。一个未选中的已有店铺用黄色显示，而选中和未选中的尚未拥有的店铺均为灰色边界，同时可以进行Buy操作。如果对所有已有店铺进行操作结束后，就可以通过Starttheday按钮进行执行操作。这是进入第5帧，这里并没有什么界面，只是一些代码，可以进行执行指令的socket发送，之所以单独作为一帧是因为在目前的程序中客户端的执行结果是在输入窗体中进行，而且没有太多的结果动画展示，而在以后的改进中，可以再加入更多的内容。同样，如果金钱不足会进入第6帧，在这里目前也没有内容，留作以后扩展。三遇到的问题服务器端使用mapreduce框架计算，其输出默认为单一文件。由于程序模型要求输出两类结果，所以希望输出两个文件。经过努力，成功实现双文件输出。对于客户端，由于未曾写过ActionScript3程序，因此大部分时间用于熟悉该语言，了解其特点。与其他（例如C程序）不同，其它程序在执行的时候主要考虑的是空间的顺序，直接分析程序的流程就可以得到执行顺序。而Flash程序很多需要在不同的帧之间进行操作，特别是一些实例并不是在程序段中定义和声明的，可以直接在界面中的参数段中设置。特别是在进行socket调接的时候，服务