保存的文件的注意事项

结论

现在说明一下，不管是hadoop还是spark，他们保存到文件之后，都会按照你制定的路径生成一个文件夹，然后里面会是一大堆东西，每个都是一个输出，并不是原来想象的那种，他把输出汇总到00000文件中了。

---

2018/04/07
在spark中，如果要保存文件，使用他的API只能保存RDD类型的。
刚刚也就保存了一个东西，比较尴尬的是，他保存之后，并不是我想象中的那样。
使用的命令是xx.saveAsTextFile("xxx")
首先他保存的路径是hdfs中/user/root（当前用户），然后他保存的是一个文件夹，里面文件的分布类似于hadoop的那种分布。
但是不一样的是，原来hadoop的00000文件一般就是reduce的最终产物，也就是所有的文件都拼接在一起了，而且是排序好的。（并不是，自己好好看看吧）
但是spark好像是没做这个事情。他的每个文件及本都是一样大小的。
毕竟他们的mapreduce底层用的都是一样的。

image.png

这一点，就先不说了。但是我感觉，可能就是不太一样。

---

可能需要到一个地方进行求证。找些书上的内容去看。

---

2018/04/08
↑上面都错了。。。
不仅从书上看到，而且是一个网站上。
https://stackoverflow.com/questions/10666488/what-are-success-and-part-r-00000-files-in-hadoop
我本来一直以为他最后会合成一个文件。。。
其实并不然。
也就是说我，原来的时候弄得都是尼玛的错的。。

---

2018/04/10
使用saveAsTextFile命令将数据导出到hdfs上，但是由于本身数据是元组的形式，而且是保存为文本文件，
结果导致保存的文件里面是带u前缀的。也就是python 的unicode。
后面保存文件的时候，需要小心一下了，可能需要先对这个东西进行下处理。
原来的时候保存的文件都是元祖的，如果你把整个东西都组合成一个字符串，就不会带‘u'了
（现在先进行下处理得到结果把）
反正就是吧unicode，转化成str。

---

2018/04/11
**关于‘u’ 可能有了更好的办法。当然，这里没有用到unicode，所以以后可以去掉。

image.png

2018/04/17
之前都是针对RDD进行文件保存。
2018/04/18
昨天试着把DataFrame进行了保存，但是保存的内容是带有那种，
Row(xxxxx)这种，这种的话，后期再对文件进行处理的时候，肯定会更加困难。

DataFrame有一个write的属性，他可以用作保存的作用。但是使用text只能包含一列，这个就被否定了。

发现可以用csv，但是现在发现这个比较麻烦的就是col的顺序跟我原来的顺序不太一样。
看了一些网站，有说用select方式的，但是我感觉这个就比较耗时了，特别是特征多了以后，那就没有办法了。
对啊，卧槽，他们数据列多了时候，都是怎么去制定列的？？？？？？

scala好像有这个库，python没有找到。
反正以后也是这样去查找数据，那就把这个数据直接写到hdfs，然后把header加上。
而且，后续再读的时候，还是要指定这个列，所以header其实加不加都可以。
不过一个比较关键的问题就是，我觉得比较有用的。
就是直接用DataFrame的读写方法去读写，就不用rdd的了。
http://spark.apache.org/docs/latest/api/python/pyspark.sql.html#pyspark.sql.DataFrameReader
而且我看了一下，他虽然保存了非常多的文件，
但是这个文件名不像原来保存的那样part-00000，他的很乱，最后带一个csv后缀。
part-00186-e3e5e263-08dc-4a3d-85ca-b448507ffe05-c000.csv

但是我发现，这个保存出来的文件，并不均匀。有的多于128M，感觉比较尴尬。不知道会不会导致后续读取的时候减慢速度。

---

2018/04/19
今天把所有的数据文件读写都转移到了DF上来，现在使用的是CSV方式。
还是说，重新分片的时候，还是比较慢的。