结论
现在说明一下,不管是hadoop还是spark,他们保存到文件之后,都会按照你制定的路径生成一个文件夹,然后里面会是一大堆东西,每个都是一个输出,并不是原来想象的那种,他把输出汇总到00000文件中了。
2018/04/07
在spark中,如果要保存文件,使用他的API只能保存RDD类型的。
刚刚也就保存了一个东西,比较尴尬的是,他保存之后,并不是我想象中的那样。
使用的命令是xx.saveAsTextFile("xxx")
首先他保存的路径是hdfs中/user/root(当前用户),然后他保存的是一个文件夹,里面文件的分布类似于hadoop的那种分布。
但是不一样的是,原来hadoop的00000文件一般就是reduce的最终产物,也就是所有的文件都拼接在一起了,而且是排序好的。(并不是,自己好好看看吧)
但是spark好像是没做这个事情。他的每个文件及本都是一样大小的。
毕竟他们的mapreduce底层用的都是一样的。
![](https://i-blog.csdnimg.cn/blog_migrate/937c594a3dba4a02112f691979131849.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,所以以后可以去掉。
![](https://i-blog.csdnimg.cn/blog_migrate/66c289216166c357188559fc1daba0c9.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方式。
还是说,重新分片的时候,还是比较慢的。