p*****2
发帖数: 21240 | 1
多谢大牛。有没有design doc，主要是讲述如何把RDD分配到actors进行计算的，包括
数据的传送。 |
|
w********m
发帖数: 1137 | 2 不是hadoop和spark的committer，没兴趣关心jvm。用轮子的真不觉得轮子怎么做很重
要。
测试过scala和python在spark上的表现，没觉得你说的后者比前者慢几十倍。主要瓶颈
是RDD到hdfs的IO，这跟语言有什么关系。
另外，spark上怎么用groovy。 |
|
w********m
发帖数: 1137 | 3 不是hadoop和spark的committer，没兴趣关心jvm。用轮子的真不觉得轮子怎么做很重
要。
测试过scala和python在spark上的表现，没觉得你说的后者比前者慢几十倍。主要瓶颈
是RDD到hdfs的IO，这跟语言有什么关系。
另外，spark上怎么用groovy。 |
|
z****e
发帖数: 54598 | 4 你的瓶颈居然不在computing上，而在io上
那你根本无法测试语言之间的差异
还谈什么比较？
话说做ml之类的，感觉数据操作是大头
而且spark不就是把数据读入内存么？
你怎么还会有频繁的rdd和hadoop上的io操作，那这样的话，跟hadoop有啥区别？
你确定你用对了spark？
这个优化了之后，你的重点应该是ml那些算法上
那个都是吃资源的大户，做个word count就可以很明显感觉出来了
不过这个不仅跟语言有关，跟复杂度也有关系
我们当时做word count，同样是java，有些人用了4秒，有些人算了一整天
python同样算法更慢，尤其是涉及dictionary的时候
我大概用同样算法跑python要用半个小时，java的话，2分钟差不多
只有spark上怎么用groovy，这个问你，跟python用c库一样用
你要是不知道我没办法 |
|
|
w******g
发帖数: 189 | 6 看见这里有scala 和spark的大牛，问问一个困扰多时的问题。Spark上怎么join avro
format的数据？
如果是plain text，用TAB分割开的数据，做join操作很容易就是把A和B表弄成(key,
value)格式的rdd再调用A.join(B)就可以了。但是我现在要join avro格式的数据，还
是A和B，格式都是(STRING, GenericRecord)。读是可以都的，因为可以执行first和
count的action，但是join貌似要shuffle，shuffle的话要serialize 临时数据。已经
用了kyro的serializer register A和B类了，还是不行。大牛谁有经验或者可以run的
例子吗？ |
|
p***o
发帖数: 1252 | 7 storm里有个叫trident的东西，要不你直接上spark。至于原理你可以看看RDD的paper，
说白了就是只要你保证源是干净的，中间状态都可以重算出来。 |
|
z****e
发帖数: 54598 | 8 nosql问题还多多，还处于发展阶段，newsql说的是分布式db
我觉得nosql现在还发展不到transaction和脚本就能用的地步
还有一段距离要走，比如rdd这种类似以前db的cache
spark才刚开始做 |
|
B********r
发帖数: 397 | 9 是真的，自己在DO开个32G 12cpu 的instance 试试就知道了
如果persist rdd，10-15 秒 1 million row join 1 million
filter, map, reduce 更快
如果要load 基本看你硬盘速度 |
|
|
j*****n
发帖数: 1545 | 11 spark 本身确实没啥，RDD 变来变去 记住那些 operator 就好了。难的是 如果一个新
的ML算法怎么能用 spark 实现. |
|
c*****a
发帖数: 1638 | 12 写很简单。我没看懂你有啥困难的？在function里面直接写就行了，只是要注意控制
provision
通俗点就像在MR里面在mapper里面开连接写就是了。
读会相对比较麻烦。如果你是说scan的话，2种做法吧，数据量不大就在driver里面读
。数据量大的话就分片到每个tasks里面，然后返回RDD。
dynamo用起来不便宜，如果你们确定数据量很大，其实Cassandra可能更好。但是如果
你们现在没有已有的Cassandra，那么可能TCO Cassandra更贵就是了，因为dynamo你们
可以不用Admin。
connector |
|
M*****R
发帖数: 650 | 13 大牛怎么看Spark Streaming？这个和Storm，Samza哪个更有前途一些？
RDD基于coarse-grained memory access pattern，这个好像和streaming应用不合拍啊。
com/
忽略
loop |
|
g*******o
发帖数: 156 | 14 看一下rdd的paper，然后跑几个简单的应用。
会scala上手比较快，只会java问题也不大。 |
|
p****a
发帖数: 38 | 15 rdd的paper, which paper? |
|
c******o
发帖数: 1277 | 16 mostly is not about scala, it is more about the whole rdd implementation.
major work are all about how to design your work flow, and optimize it. |
|
x***4
发帖数: 1815 | 17 谁讲讲flink和spark有什么本质区别？我很表面的理解，spark也支持streaming（rdd
based mini batch），这个和flink的streaming有什么不同？ |
|
f********x
发帖数: 99 | 18 Spark采用batch engine来处理数据; Flink采用stream engine处理数据。
Spark的streaming process = micro batch; Flink的batch process = streaming
process的特殊情况。
在现实世界里，大数据平台处理数据的过程就好比油罐车拉原油的过程。你可以调用油
罐车队批量拉油（spark micro batch)，也修建石油管道直接输送原油（Flink
streaming）。
在计算机领域里，两个大数据平台的本质其是源于对Unix Pipes在分布式环境下的演化
。 下面用Linux自带的工具举个例子，来比较一下Spark和Flink的不同点。假设我们想
统计FileA里面的关键字China的总数：
Spark的处理模式可以等效为: cat FileA > /dev/shm/RDD1; grep China /dev/shm/
RDD1 > /dev/shm/RDD2; wc -l /dev/shm/RDD2 > /dev/shm/FileB
Flink的处理模式可以等效为: cat File... 阅读全帖 |
|
z****e
发帖数: 54598 | 19
rdd
stream就是那种连续的，不间断过来的数据
batch就是那种已知边界的数据
spark的streaming只是mincro batch
本质上还是bacth，不是streaming
streaming要求过来一个就处理一个，而且一次就处理一个
这种就是真streaming，如果达不到这种要求，就是伪streaming
microbatch顾名思义，不是这种搞法
streaming的好处显而易见，时效性强，可以很快作出反应
但是坏处也很明显，需要资源比较多
而且从长时间上看，比如处理chunk，总体算下来
还是batch用时比较节省
其实streaming我个人认为并不适合用来做persistance的处理
尤其是file system, db上的数据，我觉得用batch就足够了
streaming用在对付需要短时间处理并反馈的数据
主要是用来处理web上过来的数据，比如video这些
还有tweets，还比如用一个udp socket直接监听一个port就好了
这些用streaming api就非常合理，可以增强客户体验
他们还有第三种api，就是table api，这个... 阅读全帖 |
|
z****e
发帖数: 54598 | 20 这么做是不是因为依赖了akka的缘故？
immutable真是一个十分无聊的设计
对这个feature实在是无爱
flink只要能改掉这个设计，俺们就换flink
要不然一下storm一下spark的，有些蛋疼 |
|
|
z****e
发帖数: 54598 | 22 那把spark绑死在batch processing上是什么考虑？ |
|
w***g
发帖数: 5958 | 23 不是batch的做不出来。要能做出来干嘛要batch。BLAS的性能要发挥出来矩阵得足够大
才行。 |
|
n*****3
发帖数: 1584 | 24 我猜是因为要 尽量reuse 现有的 code base，
大多 user case spa RK steaming 够用的。
瓶颈应该不在这。
IM MU table 在 concurrency 方面 优势还是很大的。clojure same approach |
|
z****e
发帖数: 54598 | 25 这说的是dataset吧
streaming不就是为了能够real time process而消耗一部分性能么？
硬件开销和响应时间本来就是一个trade off
micro batch最大问题是不能即时反应
目前比较理想的方案就是kafka+storm
spark因为固定在batch上，所以不太行的样子
这一块好新啊，感觉在摸着石头过河，有谁是做streaming的？
古德霸他们弄视频的是不是用这个比较多？ |
|
z****e
发帖数: 54598 | 26 看了下flink
streaming部分的数据结构就是DataStream
不是dataset，这个貌似不错的样子
然后batch的部分数据结构是DataSet
这两个分开比较好，目前streaming部分flink只支持java和scala
dataset两个都有python api
底层都用了akka
然后后面就是map, flatmap, reduce, filter这些 |
|
|
d******e
发帖数: 2265 | 28 不是有pyhton for j嘛
一点都不蛋疼 |
|
|
|
z****e
发帖数: 54598 | 31 不开源，会被lockin在gce上
算了吧，这种lockin一般都不怎么用，除非对这个平台特别有信心 |
|
j********x
发帖数: 2330 | 32 还好吧
反正依赖google不算大问题
这个内部外部都在用
除非google死了
这个才会完蛋
能活过google的早已经是成功了反正 |
|
|
|
e***i
发帖数: 231 | 35 呵呵
A Resilient Distributed Dataset (RDD), the basic abstraction in Spark. |
|
d******e
发帖数: 2265 | 36 Flink flips this on its head. Whereas Spark is a batch processing framework
that can approximate stream processing, Flink is primarily a stream
processing framework that can look like a batch processor. Immediately you
get the benefit of being able to use the same algorithms in both streaming
and batch modes (exactly as you do in Spark), but you no longer have to turn
to a technology like Apache Storm if you require low-latency responsiveness
. You get all you need in one framework, without the ... 阅读全帖 |
|
c******n
发帖数: 4965 | 37 你后面说 pig 串 一系列 job 很对， 现在 Tez 也是。
我觉得这些基本是一个思想。没有本质区别。
spark 做得火， 很大一个原因是 它号称 in memory, 实际上这个并不重要，因为它
还说， 即使 on disk 它也比 hadoop MR 快10倍。 这个它说是少了 serialization
的时间， 但我觉得这个挺扯的， 因为它即使用 memory, 上下级之间 data splits(
rdd) 传输， 也一样会要 serialization.
它们反正是 王婆卖瓜， 你知道数据是可以有选择性 present 的。 真要搞明白， 得
你自己去跑一些实际的 benchmark, 是个不小的 project
它们搞这么火， 还是有 一定 hype 的因素 |
|
|
f********r
发帖数: 304 | 39 并行数量取决于你的executor数目乘以executor core。这两个数值要根据你的yarn
slave node的数量和配置决定。比如你的cluster有5个node， 每个node 4 core 16G。
那么你的（num_executor，executor_core， executor_memory）可以设为（5， 4，
16）或者（10，2， 8）或者（20， 1，4）
当然exeuctor memory要注意留出一部分overhead大概是0.1，所以实际设置不能直接用
上述例子。每个executor是一个独立jvm process，core的数目是线程并发数。所以一
般core的数目对应cpu的vcore数目。partition的数目就是具体的task 数目，每个core
并行执行一个task。所以，按照上面的例子，如果你有100个partition，你可以同时运
算20个。如果同样你把partition数目增加，每个task理论计算时间会变小，但并行度
还是取决于你的launch config。要注意的是如果数据量很大然后partition很少会导致
内存溢出或GC... 阅读全帖 |
|
|
f********r
发帖数: 304 | 41
money>
16
你还是没有细读我上面的回文啊。并发数目和你的partition数目无关。并发数目之取
决于你的exeuctor数目和executor core数目。如果你的配置是5node4core那么并发数
目就是20，也就是20条thread并行执行20task。假如说你的cpu只有2core，你却设置成
4，那么没两条thread要share一个core，实际并发只有10。这就是为什么total
executor core的数目和你的cluster total 物理core的数目要对应。当然一般情况还
应该留一个core给其他service比如node manager，history server etc。
如果你在reducebykey阶段设置100个partition但是实际有200个不同的名字，那每个
task理论上会处理2个名字。但这不是一定保证的，因为你的data可能是skew的。比如
有的名字对应上千个money，有的只对应一两个。每个task上的任务必须是顺序执行的
，应为只有一条thread。 |
|
f********r
发帖数: 304 | 42 我建议初学者不需要太刻意手动设置partition的数目，spark framework一般会帮你选
择合适的数目。如果你的cluster有上一千个节点，每个cpu都是8core的情况，那你理
论上可以同时运行8k个task。这种情况下你增加partition数目或许可能会有帮助。但
前提条件也是真正的运算dominate主要task时间，不是seriliazation/
deserialization或者network的overhead。如果task都是ms level说明你的partition
数目太多了。整个spark tuning是个很tricky的过程，我不建议花太多时间在这个上面
。大部分情况你的改进空间是很有限的。应该多花时间考虑你的算法逻辑，balance你
的dataset。 |
|
c*********e
发帖数: 16335 | 43 linkedin都放弃scala了，你們还在用啊？scala和c++,都是曲高和寡的冬冬，最终结果
很难说啊。
ml |
|
c*********e
发帖数: 16335 | 44 python和php一个级别的，好多公司都不屑于使用。php做multi-threading那叫一个累
，c#的multi-threading和java的完全不一样。 |
|
x***4
发帖数: 1815 | 45 randomSplit 是lazy的，会马上返回。真正的sample的操作会在你call rdd action的
时候才会执行。
)) |
|
b********1
发帖数: 291 | 46 你们都是聪明人，谁能帮忙写个例子。 就算是1对多的join.
a的变量假设是var1, var2,var3
b的变量假设是var4,var5,var6
假设var1,var4是primary key, foreign key的关系。
不管是用scala, python 还是rdd spark.
我打算先看懂哪个就学哪个.
本人编程零基础, 只会写query.
说穿了，我就是想要 create table c as
select a.*, b.var5, b.var6
from a
join b
on a.var1=b.var4
然后把c下载到excel里面看看.
网上看了半天教程， 都是天马行空的东西。
我就奇了怪了， 这么简单的事情，hadoop上怎么就这么难实现？ |
|
d******e
发帖数: 2265 | 47 Spark:
Java, C++ 没有repl,出局。
python性能差，出局。
底层分布式计算没有AKKA的出局。没有AKKA搞毛RDD
你还能上什么，scala唯一选则。
scala虽然烂也主要集成了java的下水。
你们这些老古董，不懂数据工程的需求，就死报java C++高电传统的东西得了。
Perl |
|
a****f
发帖数: 17 | 48 in pyspark
def add_line(lines):
yield 'from spark'
for line in lines:
yield line
rdd. mapPartition(add_line)
10 |
|
w****w
发帖数: 521 | 49 问题很简单，需要从几十万个pdf文件中抓点东西。java的程序已经有了，一个pdf输入
，产生一个csv文件。
我的基本思路是，做一个RDD,第一列是读进来的pdf binary,第二列是根据输入文件名
产生的输出文件名，然后就可以送到各个node上去抓了，最后根据输出名把结果合并成
1000个左右的输出文件。
熟悉spark的朋友能否给个框架？ |
|
n*****3
发帖数: 1584 | 50 RDD is dead, use dataframe instead. |
|
