Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/eedalong/ds-lab1
https://github.com/eedalong/ds-lab1
Last synced: about 20 hours ago
JSON representation
- Host: GitHub
- URL: https://github.com/eedalong/ds-lab1
- Owner: eedalong
- Created: 2020-03-03T02:55:45.000Z (over 4 years ago)
- Default Branch: master
- Last Pushed: 2020-04-10T15:01:56.000Z (over 4 years ago)
- Last Synced: 2024-06-20T23:58:26.596Z (5 months ago)
- Language: Go
- Size: 74.1 MB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# DS-Lab1
Project for class DS
本次实验尽可能地对着MR地论文实现，其实就对Lab1作业来讲，远远不用写这么多。由于在Lab1中的设定，通信只能由WORKER发起，Master节点只能被动响应，所以有些地方可能设计的比较诡异看起来。如下几点还未实现：
1. TaskID的生成。目前判断两个task是根据任务文件是不是一样进行判断的，但是显然这样比较愚蠢。之前之所以这么做，是因为这样的机制可以使得backup的task更新同一个task的状态数据。
2. Struggle task的识别与backup task的启动。struggle task的识别相对来说比较好解决。相对比较麻烦的就是backup task的标识。如何能区分开backup task与原本的task，同时又能够让他们更新同一个task的数据。其实问题2与问题1是同一个问题。
3. 垃圾清理问题。垃圾清理主要是指中间文件清理。第一版实现的时候垃圾清理实际上是放在master节点来做。在这个实验中，这么做从结果上看没有问题。但是这显然与实际不符合。所以后来把垃圾清理放在了worker端。但是目前面临的问题就是，go没有try catch机制，如果程序被kill，或者某个步骤出错导致程序运行失败，在只能此修改worker的情况下，目前我还没找到一个优雅的方法进行垃圾清除。这样导致的结果是测试crash的时候，会有一部分中间文件残留下来。
4. 任务进度报告特性没有实现。因为任务实在太小了。正常来说，Map阶段的进度报告是由文件内容读取比例算出来的。在这个实验中map的task_file是直接一下读完的。reduce的任务报告倒是可以做，按照一个个文件算就行。但是在这个任务中意义不大。所以就没写了
======更新=============
5. 读了一下Hadoop的源码。发现解决1、2问题的好办法。实际上在我原来的实现中，之所以1、2变得困难是因为Task本身和一个executive unit混为一谈了。Hadoop用了AttemptTask来解决这个问题。这就意味着一个task可以对应多个attemptTask。很好的解决了1、2问题
6. 完成了任务进度报告。但是并不是从worker端统计，是从master端统计。
垃圾清理问题目前还未解决。要是能捕获异常，这就不事儿了。
7. 垃圾清理实际上是一定要借助Master节点的。即Master告诉机器上的Worker应该清理哪些垃圾。所以此时应该再把Node和Worker分开。Node里面保存所有中间的文件信息，如果一个worker没来得及清理就crash了，Master应该把该垃圾清理任务交给同一个Node上的其他Worker。
==更新
Lab2A写的我很生气，本来半天就能搞定的事情，整整Debug了一天，我真的是醉了。真的不能在疲劳的时候写代码， 最后找来找去是个前面调试被注释掉的语句忘记注释回来了。 下次写代码前一定先设计好， 不能直接上来就写。 设计要比代码实现重要，只要设计合理了， 代码正常实现不会出现什么大问题。 这个经验要一定有积累。得学学Go了，写代码的很多时间花费在了查各种语法中。
=更新=
Lab2B写的还行，整整写了24小时，除了中间睡觉睡了6小时之外， 连吃饭的时候都在想问题。甚至睡觉的时候都他娘的和别人在讨论这个问题。前面在并发写入的地方出现了顺序问题。 早晨起来灵光乍现，想到用生产者消费者模式来解决并发写入时可能带来的顺序错误问题。 最终结果还不错。数据总量过大问题待解决
==更新
目前Lab2B全部能过，之前的数据总量问题也解决了。前面过度设计了很多内容。给自己带来了很多的麻烦。后来简化了设计就好了很多。
==更新
Lab2C写完。 Lab2C比较简单，只需要实现持久化函数即可。 目前采用的持久化策略是定时持久化， 所以可能有的时候会出问题。接下来改进的思路就是在一些状态更改的地方加入持久化步骤应该就没问题了。
==更新
在极个别的情况下还是会有死锁的情况发生。 会出现Leader节点Commit了数据之后Followers不去commit数据。但暂时还没有分析清楚为什么会导致死锁