有一个问题想请教一下大家, 数据有 200G , 18 亿行, 集群的环境内存有 3TB ;
我想对数据进行一些 “过滤”、 “统计”类似的操作, 类似于 mapTopair, reduceByKey 这样的操作,
但是自己写的程序却很慢。
我有疑问,这样的 RDD 操作和 按行读入文件,存储到一个 List 里面有什么区别?
按行读入文件以后也可以 进行判断、符合条件 add 这类的操作呀?
请问 RDD 的优势在哪里,或者说程序进行优化有什么需要注意的吗?
1
anonymoustian OP 我的意思就是说, java RDD 处理的数据, 直接按行读入 放入 List 然后对 List 操作不也一样吗? 貌似 RDD 更慢些, 大家能详细说一下吗
|
2
Galileo 2016-03-24 00:46:49 +08:00
RDD 是分布式的, List , Spark 可不帮你管分布式
|
3
knightdf 2016-03-24 00:47:38 +08:00
RDD 可以分布式处理啊。。。我可以一个集群来处理这个事,再把结果汇总就行了.而且不做 cache 的话读取又不会变快
|
4
lairdnote 2016-03-24 08:02:45 +08:00
哈哈。。 200G 这个指标不行吧。。
200T 的数据 跑 spark 集群那才一个快阿 |
5
ooonme 2016-03-24 08:47:07 +08:00 via iPhone
repartition
|
6
anonymoustian OP @Galileo 那请问我有 200G 的数据,把这 200G 的数据全部读入到 List 中,和用 RDD 处理有什么区别吗?
这个 List 读进来是 怎么存储的呢? 是不是一个单机的内存? |
7
liuzhster 2016-03-24 09:45:36 +08:00
@anonymoustian 我的理解是,只要内存够,读入是没有问题的,但是之后你是没法使用 map,reduce,collect 等方法的。因为你的 list 不是分布式的,所以 Spark 不能帮你做,既然如此为何还要用 Spark ,直接使用 java api 操作 list 就行了。
|
8
anonymoustian OP @liuzhster 是这样的,但是请问如果数据有 200G 的话,全部读入 List, 这个 list 的内存 是不是单机占用的内存? 而不是集群全部的内存? 您说的 内存够的意思是不是 单机内存够的意思??
所以我现在也在思考 对待数据时候 用 spark 的优势以及优点在哪里,也希望能指导一下。 另外如果内存不够的话, 18 亿条数据, 我每次用 Spark SQL limit 出来 几十万条,是不是也可以做,我现在就是这些概念搞得很糊涂,希望能指一条明路,谢谢! |
9
min 2016-03-24 13:13:21 +08:00
你的数据库系统什么情况?
用 jdbc 把数据都读到 Spark 里面是可行的,而且是可以分 partition 的。 然而这些数据的读取速度仍然取决于你的数据库到 spark 之间的网络性能。 spark 的好处是读取完成后的所有操作是分布在 spark cluster 上的,而你自己写的程序是单机的,最多能用多线程利用到机器上所有的 cpu 核。 要决定用 spark 还是都到一个 list 里面自己处理,需要你自己评估、测试,跟数据量、处理逻辑都是有关的。 |
10
Galileo 2016-03-26 04:10:00 +08:00
@anonymoustian 你不会是因为单机内存不够才用的 Spark 吧。。。
你单机一个 List ,然后处理起来也只能用单机处理啊。这样不就慢吗。 用 RDD , spark 就帮你处理掉分布式了,不光是存储的分布式,计算也是分布式啊。 |
11
anonymoustian OP @Galileo 谢谢,但是我能问您一个问题吗? 我单机内存是 32G 的话,如果在 spark 上读入 200G 的数据 到内存 (比如说 是一个 List ) 会出现什么情况呢? 这个 List 是不是因为只能存 32G 然后报错呢? 谢谢 我想问问这个。。。。 我明白 SPark 存储的分布式 和计算分布式
|
12
Galileo 2016-03-28 07:02:41 +08:00
@anonymoustian 我之前用 Spark 遇到过读取数据内存装不下的情况,然后会有异常。
但是那是在 RDD 下的。 但是具体到你这个情况,我没试过。也不好给出答案。或许你可以试试写一个测试程序试试看。 因为有虚拟内存的存在,所以用 list 读取超过物理内存大小的数据之后不一定会爆,但是最好试一下会比较好 |
13
anonymoustian OP @Galileo 好的 谢谢您
|