23年总结6月总结

一、知识点汇总

6.1-6.9

这周的内容 ：综合指标推荐算法清洗整合缺失值预测 spark代码服务器运行 spark转py清洗数据
难点： py清洗数据随机森林对字段预测

个人理解:

这周很糟糕啊，新的数据一出来，就有很多困难一下子摆在自己面前，但是时间已经要来不及了，首先是我将spark清洗进数据库，花费了40分钟一次，虽说是只用一次，但是有很多地方是需要调教的。而且spark并不是导入一次就算了，一些预测和推荐算法是要使用python的。原本自己spark清洗就用了java处理io，spark处理其他，效率是相当慢，推荐接口又需要用py写。更夸张的是新数据一给，web端大致看了一下数据，50w条，而且跟之前的结构有很大的区别，这样不知道spark的代码要清洗到什么时候，就打算全部转python了，清洗和接口都用py。相当于之前一个月清洗的代码基本报废，只有思路是在的。我先试了一下pyspark写，发现也很慢，后面直接没有用spark，单独用python处理数据的pandas，发现比spark快了几十倍啊。搜索发现小数据还是python占优，但是数据一大，内存会顶不住。因为是使用内存处理数据的，所以会快很多。因为之前使用过pandas帮别人做过很多作业，花了一天就上手了，先把hdfs的数据下载下来，一个文件夹下两三个，后面读文件的部分替换成hdfs就好了。大致三种文件四种数据格式，一天能解决一种。
随机森林是一种机器学习算法吧，它基于多棵决策树的集成。每个决策树都会用一部分数据进行训练，并为每个样本生成一个预测结果。然后，通过多个决策树的预测结果的投票或平均值来得出最终的预测结果。在进行预测时，如果输入样本存在缺失值，随机森林会根据已有的决策树模型进行预测。对于有缺失特征的样本，在每棵决策树中对应的特征都会被设置为缺失值，然后根据已有模型进行预测。最后，通过汇总所有决策树的预测结果，得到最终的预测结果。说白了就是根据没有缺失值的行，推测出有缺失值的行的缺失值的值，这种算法比线性回归会科学人性化很多，然而在我的数据集比较少的情况下，缺失值hot会趋向于平均值，然而这里是使用的sparkMl，我已经打算弃用spark了，所以这部分的预测算法白学了，又要去使用新的，感觉线性回归应该对于景区hot预测是没什么问题的。

6.12-6.20

这周的学习内容 ：读取hdfs文件优化pandas读取文件效率服务器配置安装数据导入达梦接口修改注释添加
难点：读取hdfs文件修达梦数据库的BUG 线性回归算法

个人理解:

读hdfs文件这边，花费了大量时间使用一种无线BUG的方法，hdfs3模块真不知道为什么会说一直找不到这个找不到那个，但是在python包下面都是有的，使用sys指定都没用。后面使用hdfs，也会报错，但是报错信息不一样，一直是连接不到web什么的，hdfs3修好以后也是这样，考虑到服务器可能还要重装几次，就弃用hdfs3这个模块了，使用hdfs，刚开始比赛方提供的是一个映射域名+9000端口，我去平台开了台虚拟机，ping他提供的这个映射域名，会返回一个IP地址的，我自己电脑ping了一下竟然能ping通，那这个就是公网了，根本不用平台的机子也能拿到，但是还是一直报conncat，web之类的，反正就是连接不到，换成50070其他端口会直接报端口错误，我又去测试自己虚拟机上面的hdfs，发现能取到，搜索说是hadoop的配置文件需要查看，但是数据是比赛方提供的，我们又不能操作他们的机子。问达梦的人给我答非所问，突然无意中换成了9870端口，发现没报错了，list测试竟然有了。花了两天时间，值得注意的是我昨天在群里说了是公网的问题，他说不是，结果第二天就关了，ping不通了，看来之前的确是公网。
这达梦数据库的bug真的很多，莫名其妙的，一模一样的步骤就要看运气，会出现不同的报错，在不同的服务器会出现很多报错。然后就是dmPython和sqlalchemy_dm，这两个安装以后也会出现找不到什么包之类的问题，光解决这些问题，一个服务器搭建就要花费几个小时，关键他平台的速度还贼慢，不让使用中国镜像真没搞懂100kb的速度这样弄来是什么意思。
之前sparkml的随机森林替换成线性回归了，线性回归对训练数据会比较依赖。大致讲一下原理吧。挺好理解的，就比如我用到线性回归的其中一个地方，预测hot字段，景区影响hot的有哪些字段，grade和qty，那我就根据同时有hot grade qty的数据，计算出三者的模糊关系，为什么是模糊的关系呢，因为存在的数据三者关系也不是固定的。打个比方，y=kx+b这样一个一元一次方程(实际并不是),不同的数据会有很多种k和b。线性回归算法的目标是通过求解k和b的最佳组合，使得建立的线性模型与真实的数据尽可能地接近。具体而言，它会通过最小化预测值与真实值之间的误差，来找到最优的斜率和截距。计算原理是这样，设计原理是相关值之间是一个相互的关系，就比如刷抖音，你给某个视频点了赞，视频也会记录你喜欢这个视频，就能通过你点赞的数据推测出你喜欢的视频，也能将某个视频，推荐给经常给该类视频点赞的人。线性回归的模型套起来还是简单的，因为这模型不能训练的，是一次性的，所以偏差值不会很大，准确性只能说中规中矩。

二:小组项目总结:

在这次比赛项目中，作为队长，我不仅需要完成自己负责的模块部分，更重要的是负责组织和安排小组成员的工作。回顾目前项目制作过程，我认为我在工作安排方面有以下几点反思和改进的地方。首先，我发现有时候我只是简单地告诉他们完成某个任务，而没有具体说明要达到的目标和时间要求。这导致一些情况下前后端配合感到困惑，并且无法高效地完成任务。以后需要更加清晰地传达任务的目标和要求，提供明确的时间表和衡量指标，使每个成员能够清楚地知道他们需要做什么，并在规定的时间内完成。
之前做的任务表其实是有时间安排的，但是计划跟着变化走，那个表也就没什么用了。我觉得我们组的实力在工作室各个领域都还是挺强的，问题最大的地方在于沟通，在平台出来之前，因为我那部分基本都解决了，所以基本每天都会问一下他们的进度，哪些地方需要怎样的接口，然后再跟后端讲，这样的沟通方式其实还是可以的，因为前端可能只知道自己需要实现什么样的功能，我会去询问，然后商量需要什么样的数据，我在告诉后端哪些功能有，要写什么样的接口，sql方面能帮助的还会提供一下帮助。
平台出来以后，因为上个月的努力基本白费了，本来想着数据是差不多了，一天两天时间搞一下就行了，就能帮前后端写写代码，或者写文档了。结果差这么多，那几天又担心来不及，都在自己埋头把数据处理了，数据我也有跟小组成员说过数据结构和变动，有变动其实不多，要改的接口和功能是不多的，即使没有数据也是能进行的，但是他们都是在等我搞好数据，导致工作进度效率变慢了几天，新数据确实加上补充缺失值和rating计算加上了很多功能，之前很多null的值，我都处理掉了，新数据搞了可能一个星期吧。这段时间没有怎么让前后端沟通，确实是有点忙不过来了。然后有很多地方的接口都是还没写的，之前我其实是有注意到的，那部分功能需要新数据才能用，就先让他们将其他地方该能写好的地方写好了，就意识到自己数据搞的越慢项目就快不起来，加了几天班终于把数据搞好了，最近几天的效率是之前没数据的很多倍，可能是没数据接口那边不太好感觉吧，因为没法测试。总的来说，通过反思和总结这次比赛项目中对自己小组工作安排的经验，我知道自己有很多地方还是需要加强改进的，应该督促前后端加强自主沟通，而不是自己当传话筒，能够更好地发挥队长的职责，提升小组的工作效率和质量，取得更好的成绩。
这大半个月是走入项目的末尾了，自己负责的代码部分基本完成了，为什么是基本完成，可能有些地方接口要添加或者要修改一下。但是是小事情的了，接下来的时间就开始主攻文档了，文档方面因为借鉴的不多，所以感觉还是要花费一些功夫的。这个月刚开始来平台和数据的时候真是把我吓一了跳，数据多了这么多，还格式不一样，清洗数据部分之前的时间真都白瞎了。平台也不是整的很明白其实，好在磕磕绊绊的都解决了，项目开发也步入了正轨了。