j*n
2 楼
白羊座 --- 火爆脾气是出了名的，不过来得快去得也快
天蝎座 --- 和白羊一样被火星主宰，爆发力和战斗力很强，但比白羊能忍
狮子座 --- 一哭二闹三上吊，狮大小姐最能闹
射手座 --- 我感觉射手女的脾气不错，但火象星座都很难幸免于潜在的暴力性质
双子座 --- 好像闹起来也很歇斯底里阿。。哈哈
金牛座 --- 固执起来可以3天不吃饭
处女座，摩羯座 --- 我们不热暴力，但我们可以冷暴力，冷你冷到你结冰为之
天蝎座 --- 和白羊一样被火星主宰，爆发力和战斗力很强，但比白羊能忍
狮子座 --- 一哭二闹三上吊，狮大小姐最能闹
射手座 --- 我感觉射手女的脾气不错，但火象星座都很难幸免于潜在的暴力性质
双子座 --- 好像闹起来也很歇斯底里阿。。哈哈
金牛座 --- 固执起来可以3天不吃饭
处女座，摩羯座 --- 我们不热暴力，但我们可以冷暴力，冷你冷到你结冰为之
k*n
3 楼
章一 心殇之月 上
类别：历史军事 作者：烟雨江南 书名：罪恶之城
看小说“就爱读书”www.92to.com 卷七 那时浮华染流年
苍蓝之月升起，天青之月隐去，日子在悄然中流走，诺兰德告别了春天，进入初夏。
这一个月，浮世德很平静，神圣同盟很平静，整个诺兰德都很平静。仿佛整个位面
都进入平静的日子，每个人都懒洋洋地失去了斗志。
來自卡兰多的殿下占据了浮岛城堡顶层靠窗边的位置，天天蜷在那里，晒着太阳睡
觉，披着月光睡觉，沐浴着星辉睡觉。一天二十四个小时，这位殿下要睡二十个小时以
上，有时连吃饭都会忘记。
绯色去了法罗，不知找母巢做什么强化去了，提拉米苏倒是天天呆在浮岛上，有些
无所事事，又重新捡起了烹制美食的爱好，或者就是干脆找块空地，一屁股坐下，然后
就是发呆。就是这样，提拉米苏的体形也还在渐渐变大。食人魔这个种族，实力的表现
一向很直观，越是体形庞大，就越是强大。
珞琪依然素面朝天，天天埋头在魔法工坊里，和无数的构装拼件战斗着，浑然忘了
自己曾经门萨之星的身份。可是私下里，在那些年轻法师悄然的窃窃私语中，她依然是
他们一生中见过的最美女人。
黑暗神术师已远赴异国，去往沃尔德的家乡。
其它的追随者都在忙碌着自己的事，每个人现在都有了一个半独立的小世界。
李察则日日坐在城堡顶部占据了整整一层的修炼室中，日日面对浮世德的日落月升
，枯坐不动。这是歌顿曾经坐过的位置，也是歌顿每逢大战之前必然会到的一个地方。
在前往珞琪位面之前，歌顿就曾在这里静静坐过一整天。每当坐在这里，李察总会不由
自主地想一下，那个男人坐在这里时，会想些什么。
修炼室十分空旷，原本对着外面有整幅的落地窗，看出去就象看到了世界，而上次
装修后，李察让人把窗户连同框架全部拆除，于是坐在边缘处，就有孤坐绝壁，临崖悬
空的感觉，好象坐在世界的怀抱里。
整整一个月，李察始终在冥想。不过环境并不算清静，因为耳边总有山与海那小狮
子般的呼噜声。这并沒有打扰到他，反而让他的心境更加宁定平和。他的生活再次规律
如钟摆，每七天他会活动一次，接收一下來自各个附属位面的报告，这段时间，连位面
都风平浪静。
李察已经计算出了第四条轨道，因此这些日子始终在尝试着捕捉第四个星体。他发
现低级位面的冥想效果还是不如诺兰德，而诺兰德其它地方的冥想效果不如浮世德。
在浮世德时，李察时时会感知到许多特殊形态的星体，而其它地方就要少得多。对
于李察來说，光是这一点，浮世德的优势就不是其它地方能比，更不是其它力量层次还
要低于诺兰德的位面所能相比。
偶尔，李察也会沉思为什么浮世德会如此特殊，却找不到答案。浮世德并不是人类
修建的，好象在人类历史开始之前，这座奇迹之城就已经存在了。直到今日，浮世德还
是有许多不解之谜等待着人们去发掘。
一个月的冥想，李察不知失败了多少次。将星体推入计算出的轨道，并且顺利稳定
下來是一件非常困难的事，变数实在是太多了，多到李察的智慧天赋都感觉到无法掌控
的地步。不知多少次，总是差了最后一点距离，那些星体就脱离了轨道，远远飞走。
连续失败了一个月，李察不但不着急，反而越來越沉静。越是艰难，李察明白，也
就意味着收获越大。
转眼之间，就是李察冥想的第三十一天了。这个晚上，不知为什么李察总有些心绪
不宁的感觉，许多往事不由自主地浮上心头。其中大多数是鲁瑟兰村的童年时光。这时
李察才蓦然惊醒，原來已是这么多年过去了。可是熊熊烈火中的故居，还依然在眼前，
真实得宛如刚刚发生。
这么多年了，李察还是沒能完成伊兰妮的心愿。虽然他现在已经是阿克蒙德的族长
，大权在握，整体军力已经正式超越了歌顿时代，可是李察觉得在自己和阿克蒙德火山
墓地之间还有最后一个障碍，那就是歌顿。直到现在，李察还是认为自己沒有达到那个
男人曾经的高度。
直到有那么一天，李察要将歌顿的尸骸从世界的最深处找回來，安葬在家族墓地顶
层，并且将伊兰妮的墓碑立在一旁。在李察心中，这才算是真正完成了妈妈的心愿。
一想到往事，李察忽然心神一动，抬头望去，毫无阻隔的视野里满满是流动的宝蓝
。天穹上不知何时竟然出现了一轮极为巨大的蓝色星体。但是它散发的气息又让李察极
为熟悉，竟然和第四弦苍蓝之月的月力十分相似，一时让李察错以为看到的不是代表着
力量的星体，而是苍蓝之月。
仍处于冥想状态的李察似乎完全沒有去想眼前的是真实还是虚幻。星体散发出的熟
悉感，让他一如这些日子做习惯了的，尝试着开始牵引这颗蓝色星体，但并沒有想着会
成功。
可是沒想到一牵之下，蓝色星体竟然开始向着李察的血脉移动。这颗蓝色星体极为
巨大，堪堪把那条轨道填满，几乎一点余量都沒留。但是李察这一次捕获出乎意料的顺
利，由始至终心如止水，诸般意外变化全都化解，终将那颗蓝色星体的送入轨道。
当蓝色星体自己开始在轨道上运行的一刻，李察忽然明白，那不是星力，而是纯正
的苍蓝之月的月力。在精灵秘剑中，歌顿惟有将第四弦苍蓝之月的破灭教得形神俱备。
因为，那是当初伊兰妮用以刺入歌顿心脏的一剑。
心殇之痛，所以清晰。
因此这一剑也是李察最强的一剑，在七弦弦月之力中，李察对苍蓝之月月力的使用
最为纯熟。
苍蓝月力构成的星体环绕着轨道飞行一周后，从中释放出一股浓浓的月力，飞向李
察的血脉核心。这股月力并沒有融入月力生命树，反正想着暗红的深流沉落下去，与阿
克蒙德血脉融为一体。
刹那间，李察全身剧震，只感觉一种无法形容的冰冷、寂寥和苍凉流过心底，一时
竟是心灰若死。
然而李察心中立时升起明悟，这何尝不是另一种毁灭？
就在这时，迪斯马森的真名从熔岩中浮出，在毁灭之后，原本灰暗的虚空中又亮起
了长长一段真名。仍然是毁灭，更加强大、也更加完整的毁灭。
每一个神文符号中都有无穷可以让李察回味无穷的东西，每个新的神文，都象在李
察面前展开了一个全新的世界，里面有无穷多的奥秘可供探索。这些世界中，同类或者
不同类的规则都拼搭在一起，有些形如光带，有些则有若虚雾，看似杂乱无章，实际上
紧密契合，就象一架精密机器的无数个细小零部件。
每个神文都代表着一种规则，一种力量，一个元素。在另一个层面上，它们又是构
成规则的基本单位。而那些规则有可能再度构成一个新的神文，如是往复，整个世界就
象是一座螺旋型的旋梯，往上往下都沒有尽头。往上探索，则是用已知的神文拼出新的
规则，往下，则是分析神文内部的构成规则。无论上下，都能够掌握更多的全新神文，
也在某种程度上，意味着挣脱了这个世界的束缚。
李察，就恰好出现在旋梯中的某一段上。
他逐渐明白，不论向上还是向下，都是同样的通向规则，通向冲破世界的道路。哪
怕只是踏出一小步，力量都会带來翻天覆地的变化。
毁灭真名的变化还沒有结束，一长串的神文符号正聚向一处，然后如水波般荡漾着
，开始互相融合。在融合的过程中，苍蓝月力构成的星体又释放出一缕月力，再次沉入
阿克蒙德的血脉，然后真名中的几个神文突然变亮了一些，原本很顺利的融合过程又起
了一些波澜，开始重新组合。
每个神文都是一个世界，大世界中又包含着无数的小世界。当神文融合的时候，里
面的规则都会释放出來，然后在某种神秘力量的牵引下重新组合在一起，共同搭建出一
个新的世界。
看样子，这些神文是想重组成一个全新意义的神文。李察立刻明白，这是无以伦比
的机会，甚至比生命树晋阶时还要珍贵。透过这一过程，能够看到规则和神文是如何构
架和转化的。于是李察调动了全部的智慧与真实天赋，开始纪录整个演化的过程。
可是衍化过程实在是太复杂了，每个神文会释放出数百甚至是上万条规则，当规则
重构时，有些规则会湮灭，有些规则则会凭空产生。变化每时每刻都在出现，每个新的
变化，都意味着复杂程度的大幅提升。李察根本來不及分析，就连记忆也只能记住其中
的一小部分，他已经心无旁骛，全力记忆着神文衍变的每一个过程。至于最后能够记下
多少，就只能看运气。
衍变的过程复杂且漫长。李察已经全心投入到神文与规则的世界内，切断了所有对
外界的关注。
然而，浮世德的平静却被打破了。
类别：历史军事 作者：烟雨江南 书名：罪恶之城
看小说“就爱读书”www.92to.com 卷七 那时浮华染流年
苍蓝之月升起，天青之月隐去，日子在悄然中流走，诺兰德告别了春天，进入初夏。
这一个月，浮世德很平静，神圣同盟很平静，整个诺兰德都很平静。仿佛整个位面
都进入平静的日子，每个人都懒洋洋地失去了斗志。
來自卡兰多的殿下占据了浮岛城堡顶层靠窗边的位置，天天蜷在那里，晒着太阳睡
觉，披着月光睡觉，沐浴着星辉睡觉。一天二十四个小时，这位殿下要睡二十个小时以
上，有时连吃饭都会忘记。
绯色去了法罗，不知找母巢做什么强化去了，提拉米苏倒是天天呆在浮岛上，有些
无所事事，又重新捡起了烹制美食的爱好，或者就是干脆找块空地，一屁股坐下，然后
就是发呆。就是这样，提拉米苏的体形也还在渐渐变大。食人魔这个种族，实力的表现
一向很直观，越是体形庞大，就越是强大。
珞琪依然素面朝天，天天埋头在魔法工坊里，和无数的构装拼件战斗着，浑然忘了
自己曾经门萨之星的身份。可是私下里，在那些年轻法师悄然的窃窃私语中，她依然是
他们一生中见过的最美女人。
黑暗神术师已远赴异国，去往沃尔德的家乡。
其它的追随者都在忙碌着自己的事，每个人现在都有了一个半独立的小世界。
李察则日日坐在城堡顶部占据了整整一层的修炼室中，日日面对浮世德的日落月升
，枯坐不动。这是歌顿曾经坐过的位置，也是歌顿每逢大战之前必然会到的一个地方。
在前往珞琪位面之前，歌顿就曾在这里静静坐过一整天。每当坐在这里，李察总会不由
自主地想一下，那个男人坐在这里时，会想些什么。
修炼室十分空旷，原本对着外面有整幅的落地窗，看出去就象看到了世界，而上次
装修后，李察让人把窗户连同框架全部拆除，于是坐在边缘处，就有孤坐绝壁，临崖悬
空的感觉，好象坐在世界的怀抱里。
整整一个月，李察始终在冥想。不过环境并不算清静，因为耳边总有山与海那小狮
子般的呼噜声。这并沒有打扰到他，反而让他的心境更加宁定平和。他的生活再次规律
如钟摆，每七天他会活动一次，接收一下來自各个附属位面的报告，这段时间，连位面
都风平浪静。
李察已经计算出了第四条轨道，因此这些日子始终在尝试着捕捉第四个星体。他发
现低级位面的冥想效果还是不如诺兰德，而诺兰德其它地方的冥想效果不如浮世德。
在浮世德时，李察时时会感知到许多特殊形态的星体，而其它地方就要少得多。对
于李察來说，光是这一点，浮世德的优势就不是其它地方能比，更不是其它力量层次还
要低于诺兰德的位面所能相比。
偶尔，李察也会沉思为什么浮世德会如此特殊，却找不到答案。浮世德并不是人类
修建的，好象在人类历史开始之前，这座奇迹之城就已经存在了。直到今日，浮世德还
是有许多不解之谜等待着人们去发掘。
一个月的冥想，李察不知失败了多少次。将星体推入计算出的轨道，并且顺利稳定
下來是一件非常困难的事，变数实在是太多了，多到李察的智慧天赋都感觉到无法掌控
的地步。不知多少次，总是差了最后一点距离，那些星体就脱离了轨道，远远飞走。
连续失败了一个月，李察不但不着急，反而越來越沉静。越是艰难，李察明白，也
就意味着收获越大。
转眼之间，就是李察冥想的第三十一天了。这个晚上，不知为什么李察总有些心绪
不宁的感觉，许多往事不由自主地浮上心头。其中大多数是鲁瑟兰村的童年时光。这时
李察才蓦然惊醒，原來已是这么多年过去了。可是熊熊烈火中的故居，还依然在眼前，
真实得宛如刚刚发生。
这么多年了，李察还是沒能完成伊兰妮的心愿。虽然他现在已经是阿克蒙德的族长
，大权在握，整体军力已经正式超越了歌顿时代，可是李察觉得在自己和阿克蒙德火山
墓地之间还有最后一个障碍，那就是歌顿。直到现在，李察还是认为自己沒有达到那个
男人曾经的高度。
直到有那么一天，李察要将歌顿的尸骸从世界的最深处找回來，安葬在家族墓地顶
层，并且将伊兰妮的墓碑立在一旁。在李察心中，这才算是真正完成了妈妈的心愿。
一想到往事，李察忽然心神一动，抬头望去，毫无阻隔的视野里满满是流动的宝蓝
。天穹上不知何时竟然出现了一轮极为巨大的蓝色星体。但是它散发的气息又让李察极
为熟悉，竟然和第四弦苍蓝之月的月力十分相似，一时让李察错以为看到的不是代表着
力量的星体，而是苍蓝之月。
仍处于冥想状态的李察似乎完全沒有去想眼前的是真实还是虚幻。星体散发出的熟
悉感，让他一如这些日子做习惯了的，尝试着开始牵引这颗蓝色星体，但并沒有想着会
成功。
可是沒想到一牵之下，蓝色星体竟然开始向着李察的血脉移动。这颗蓝色星体极为
巨大，堪堪把那条轨道填满，几乎一点余量都沒留。但是李察这一次捕获出乎意料的顺
利，由始至终心如止水，诸般意外变化全都化解，终将那颗蓝色星体的送入轨道。
当蓝色星体自己开始在轨道上运行的一刻，李察忽然明白，那不是星力，而是纯正
的苍蓝之月的月力。在精灵秘剑中，歌顿惟有将第四弦苍蓝之月的破灭教得形神俱备。
因为，那是当初伊兰妮用以刺入歌顿心脏的一剑。
心殇之痛，所以清晰。
因此这一剑也是李察最强的一剑，在七弦弦月之力中，李察对苍蓝之月月力的使用
最为纯熟。
苍蓝月力构成的星体环绕着轨道飞行一周后，从中释放出一股浓浓的月力，飞向李
察的血脉核心。这股月力并沒有融入月力生命树，反正想着暗红的深流沉落下去，与阿
克蒙德血脉融为一体。
刹那间，李察全身剧震，只感觉一种无法形容的冰冷、寂寥和苍凉流过心底，一时
竟是心灰若死。
然而李察心中立时升起明悟，这何尝不是另一种毁灭？
就在这时，迪斯马森的真名从熔岩中浮出，在毁灭之后，原本灰暗的虚空中又亮起
了长长一段真名。仍然是毁灭，更加强大、也更加完整的毁灭。
每一个神文符号中都有无穷可以让李察回味无穷的东西，每个新的神文，都象在李
察面前展开了一个全新的世界，里面有无穷多的奥秘可供探索。这些世界中，同类或者
不同类的规则都拼搭在一起，有些形如光带，有些则有若虚雾，看似杂乱无章，实际上
紧密契合，就象一架精密机器的无数个细小零部件。
每个神文都代表着一种规则，一种力量，一个元素。在另一个层面上，它们又是构
成规则的基本单位。而那些规则有可能再度构成一个新的神文，如是往复，整个世界就
象是一座螺旋型的旋梯，往上往下都沒有尽头。往上探索，则是用已知的神文拼出新的
规则，往下，则是分析神文内部的构成规则。无论上下，都能够掌握更多的全新神文，
也在某种程度上，意味着挣脱了这个世界的束缚。
李察，就恰好出现在旋梯中的某一段上。
他逐渐明白，不论向上还是向下，都是同样的通向规则，通向冲破世界的道路。哪
怕只是踏出一小步，力量都会带來翻天覆地的变化。
毁灭真名的变化还沒有结束，一长串的神文符号正聚向一处，然后如水波般荡漾着
，开始互相融合。在融合的过程中，苍蓝月力构成的星体又释放出一缕月力，再次沉入
阿克蒙德的血脉，然后真名中的几个神文突然变亮了一些，原本很顺利的融合过程又起
了一些波澜，开始重新组合。
每个神文都是一个世界，大世界中又包含着无数的小世界。当神文融合的时候，里
面的规则都会释放出來，然后在某种神秘力量的牵引下重新组合在一起，共同搭建出一
个新的世界。
看样子，这些神文是想重组成一个全新意义的神文。李察立刻明白，这是无以伦比
的机会，甚至比生命树晋阶时还要珍贵。透过这一过程，能够看到规则和神文是如何构
架和转化的。于是李察调动了全部的智慧与真实天赋，开始纪录整个演化的过程。
可是衍化过程实在是太复杂了，每个神文会释放出数百甚至是上万条规则，当规则
重构时，有些规则会湮灭，有些规则则会凭空产生。变化每时每刻都在出现，每个新的
变化，都意味着复杂程度的大幅提升。李察根本來不及分析，就连记忆也只能记住其中
的一小部分，他已经心无旁骛，全力记忆着神文衍变的每一个过程。至于最后能够记下
多少，就只能看运气。
衍变的过程复杂且漫长。李察已经全心投入到神文与规则的世界内，切断了所有对
外界的关注。
然而，浮世德的平静却被打破了。
d*a
4 楼
看来没必要花钱扩内存了
现在内存也忒贵了
现在内存也忒贵了
C*r
5 楼
最近刚开始学Spark，因为没有看过源代码，麻烦大家想请教几个问题。
1. RDD在创建的时候是lazy的，并且有narrow和wide两种类型，例如map，filter是
narrow类型的所以不需要额外的shuffle。但是groupbykey之类的就需要shuffle了。并
且每个RDD会保存有自己所对应的partition信息。我的理解是每个action或者
transformation都会被Spark internally翻译成map reduce job来执行。
我的问题是翻译之后的map reduce job的并行度是和哪些因素有关系呢？partition的
数量还有executor的数量还有executor-core的数量之间是什么样的关系呢？例如
parition越多并行的task也会越多么？
2. 当我groupbykey的时候RDD会记录下我当前的RDD中有多少个key value么？并且这些
key value和上面说的partition有什么样的联系呢，还是完全不想关的两个概念？
3. 一个RDD的action或者transformation会被转换成多少map reduce task是由什么决
定的呢？
4. task，executor，executor-core之间的关系是怎么样的呢？
谢谢！
1. RDD在创建的时候是lazy的，并且有narrow和wide两种类型，例如map，filter是
narrow类型的所以不需要额外的shuffle。但是groupbykey之类的就需要shuffle了。并
且每个RDD会保存有自己所对应的partition信息。我的理解是每个action或者
transformation都会被Spark internally翻译成map reduce job来执行。
我的问题是翻译之后的map reduce job的并行度是和哪些因素有关系呢？partition的
数量还有executor的数量还有executor-core的数量之间是什么样的关系呢？例如
parition越多并行的task也会越多么？
2. 当我groupbykey的时候RDD会记录下我当前的RDD中有多少个key value么？并且这些
key value和上面说的partition有什么样的联系呢，还是完全不想关的两个概念？
3. 一个RDD的action或者transformation会被转换成多少map reduce task是由什么决
定的呢？
4. task，executor，executor-core之间的关系是怎么样的呢？
谢谢！
z*l
6 楼
http://www.savingsbond.gov/
【在 y****n 的大作中提到】
: 请问什么叫savings bond,是类似支票可以随时到银行兑换的吗？
: 看字面好像是一种债券，哪位知道的能解释一下吗？谢谢
【在 y****n 的大作中提到】
: 请问什么叫savings bond,是类似支票可以随时到银行兑换的吗？
: 看字面好像是一种债券，哪位知道的能解释一下吗？谢谢
E*T
7 楼
我打人～～我吃饭。。。不吃饭对不起自己……
T*s
8 楼
一转眼就4颗星星了
第三颗是啥
第三颗是啥
t*t
9 楼
4G当然飕飕的。
【在 d******a 的大作中提到】
: 看来没必要花钱扩内存了
: 现在内存也忒贵了
【在 d******a 的大作中提到】
: 看来没必要花钱扩内存了
: 现在内存也忒贵了
J*R
10 楼
高手啊，这几个问题还真没怎么想过。
【在 C*********r 的大作中提到】
: 最近刚开始学Spark，因为没有看过源代码，麻烦大家想请教几个问题。
: 1. RDD在创建的时候是lazy的，并且有narrow和wide两种类型，例如map，filter是
: narrow类型的所以不需要额外的shuffle。但是groupbykey之类的就需要shuffle了。并
: 且每个RDD会保存有自己所对应的partition信息。我的理解是每个action或者
: transformation都会被Spark internally翻译成map reduce job来执行。
: 我的问题是翻译之后的map reduce job的并行度是和哪些因素有关系呢？partition的
: 数量还有executor的数量还有executor-core的数量之间是什么样的关系呢？例如
: parition越多并行的task也会越多么？
: 2. 当我groupbykey的时候RDD会记录下我当前的RDD中有多少个key value么？并且这些
: key value和上面说的partition有什么样的联系呢，还是完全不想关的两个概念？
【在 C*********r 的大作中提到】
: 最近刚开始学Spark，因为没有看过源代码，麻烦大家想请教几个问题。
: 1. RDD在创建的时候是lazy的，并且有narrow和wide两种类型，例如map，filter是
: narrow类型的所以不需要额外的shuffle。但是groupbykey之类的就需要shuffle了。并
: 且每个RDD会保存有自己所对应的partition信息。我的理解是每个action或者
: transformation都会被Spark internally翻译成map reduce job来执行。
: 我的问题是翻译之后的map reduce job的并行度是和哪些因素有关系呢？partition的
: 数量还有executor的数量还有executor-core的数量之间是什么样的关系呢？例如
: parition越多并行的task也会越多么？
: 2. 当我groupbykey的时候RDD会记录下我当前的RDD中有多少个key value么？并且这些
: key value和上面说的partition有什么样的联系呢，还是完全不想关的两个概念？
l*3
11 楼
吃。。。
c*a
12 楼
李察很快就会是“五星上将詹姆士下士”了
a*o
13 楼
你要是不跑大程序，2GB都嗖嗖的，你开个video converter，8G都不嗖嗖的，呵呵。
【在 t**t 的大作中提到】
: 4G当然飕飕的。
【在 t**t 的大作中提到】
: 4G当然飕飕的。
c*n
14 楼
rdd 跟 hadoop MR 的 input split 概念有点像
但是 spark 的独特是， rdd 上带了 transformer, master 可以把不同的 rdd merge
到一起 给 executor. 具体怎么弄我也不清楚， 你只能看 SRC code, 可以 先看 第
一个 release local executor, 很简单
【在 C*********r 的大作中提到】
: 最近刚开始学Spark，因为没有看过源代码，麻烦大家想请教几个问题。
: 1. RDD在创建的时候是lazy的，并且有narrow和wide两种类型，例如map，filter是
: narrow类型的所以不需要额外的shuffle。但是groupbykey之类的就需要shuffle了。并
: 且每个RDD会保存有自己所对应的partition信息。我的理解是每个action或者
: transformation都会被Spark internally翻译成map reduce job来执行。
: 我的问题是翻译之后的map reduce job的并行度是和哪些因素有关系呢？partition的
: 数量还有executor的数量还有executor-core的数量之间是什么样的关系呢？例如
: parition越多并行的task也会越多么？
: 2. 当我groupbykey的时候RDD会记录下我当前的RDD中有多少个key value么？并且这些
: key value和上面说的partition有什么样的联系呢，还是完全不想关的两个概念？
但是 spark 的独特是， rdd 上带了 transformer, master 可以把不同的 rdd merge
到一起 给 executor. 具体怎么弄我也不清楚， 你只能看 SRC code, 可以 先看 第
一个 release local executor, 很简单
【在 C*********r 的大作中提到】
: 最近刚开始学Spark，因为没有看过源代码，麻烦大家想请教几个问题。
: 1. RDD在创建的时候是lazy的，并且有narrow和wide两种类型，例如map，filter是
: narrow类型的所以不需要额外的shuffle。但是groupbykey之类的就需要shuffle了。并
: 且每个RDD会保存有自己所对应的partition信息。我的理解是每个action或者
: transformation都会被Spark internally翻译成map reduce job来执行。
: 我的问题是翻译之后的map reduce job的并行度是和哪些因素有关系呢？partition的
: 数量还有executor的数量还有executor-core的数量之间是什么样的关系呢？例如
: parition越多并行的task也会越多么？
: 2. 当我groupbykey的时候RDD会记录下我当前的RDD中有多少个key value么？并且这些
: key value和上面说的partition有什么样的联系呢，还是完全不想关的两个概念？
w*w
15 楼
估计没人记得，好象很早就有两颗星和一个大晶石啥的。
真实的智慧竟然还没算出来只要不超过第三宇宙速度就可以被俘获。
【在 T*********s 的大作中提到】
: 一转眼就4颗星星了
: 第三颗是啥
真实的智慧竟然还没算出来只要不超过第三宇宙速度就可以被俘获。
【在 T*********s 的大作中提到】
: 一转眼就4颗星星了
: 第三颗是啥
w*6
16 楼
for normal operations, my current 6GB runs just as the same as my previous
2GB
2GB
f*r
17 楼
并行数量取决于你的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时间太长然后driver和exeuctor time out。
通常建议每个exeuctor不多余5个core， 不超过64g内存。因为hdfs系统对并行写文件
的支持是有限制的。groupbykey一般不推荐使用。因为它在mapper阶段不做local
reduce会导致shuffle write的量增多，也就是reducer的shuffle read增加。推荐
reducebykey
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时间太长然后driver和exeuctor time out。
通常建议每个exeuctor不多余5个core， 不超过64g内存。因为hdfs系统对并行写文件
的支持是有限制的。groupbykey一般不推荐使用。因为它在mapper阶段不做local
reduce会导致shuffle write的量增多，也就是reducer的shuffle read增加。推荐
reducebykey
d*a
18 楼
我当初用Vista Ultimate 32-bit里边自带的movie maker转电视卡录的节目到wmv格式
，比较慢
现在升级到Win 7 Ultimate 64-bit, 没有movie maker了，只好下载了个windows live
movie maker, 转起格式来嗖嗖的
也不知道是因为64位，还是live movie maker功力深厚
【在 a*o 的大作中提到】
: 你要是不跑大程序，2GB都嗖嗖的，你开个video converter，8G都不嗖嗖的，呵呵。
，比较慢
现在升级到Win 7 Ultimate 64-bit, 没有movie maker了，只好下载了个windows live
movie maker, 转起格式来嗖嗖的
也不知道是因为64位，还是live movie maker功力深厚
【在 a*o 的大作中提到】
: 你要是不跑大程序，2GB都嗖嗖的，你开个video converter，8G都不嗖嗖的，呵呵。
C*r
19 楼
many thanks for the clarification!
比如说我有一个两个column的table (name, money). 我想以name为key对money做一些
data mining（或者一些复杂的计算）。所以我会做以下的步骤
step1 -> 把table map 成一个file RDD
step2 -> file RDD recudeByKey(name) 或者groupByKey(name)
step3 -> 在第二步产生的RDD上面apply一些其他的运算
那么step2中的reduceByKey加入我设置partition number为100，但是我其实是有200个
distinct names，所以其实平均下来每个partiton里面会有两个（name， list
) pair么？然后每个partition会被分配给一个task进行执行。假如我的配置是(5,4,16
)，所以每个partiton里面即使有两个pair，但还会顺序的进行执行，对么？这里是我
一直非常confuse的地方。。
如果这种情况下的化，我的partition数量是不是越接近不同name的数量越好，因为这
样并行度最大？
core
【在 f********r 的大作中提到】
: 并行数量取决于你的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很少会导致
比如说我有一个两个column的table (name, money). 我想以name为key对money做一些
data mining（或者一些复杂的计算）。所以我会做以下的步骤
step1 -> 把table map 成一个file RDD
step2 -> file RDD recudeByKey(name) 或者groupByKey(name)
step3 -> 在第二步产生的RDD上面apply一些其他的运算
那么step2中的reduceByKey加入我设置partition number为100，但是我其实是有200个
distinct names，所以其实平均下来每个partiton里面会有两个（name， list
) pair么？然后每个partition会被分配给一个task进行执行。假如我的配置是(5,4,16
)，所以每个partiton里面即使有两个pair，但还会顺序的进行执行，对么？这里是我
一直非常confuse的地方。。
如果这种情况下的化，我的partition数量是不是越接近不同name的数量越好，因为这
样并行度最大？
core
【在 f********r 的大作中提到】
: 并行数量取决于你的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很少会导致
D*i
20 楼
这个是因为原来远景旗舰版自带的视频制作器太烂
live
【在 d******a 的大作中提到】
: 我当初用Vista Ultimate 32-bit里边自带的movie maker转电视卡录的节目到wmv格式
: ，比较慢
: 现在升级到Win 7 Ultimate 64-bit, 没有movie maker了，只好下载了个windows live
: movie maker, 转起格式来嗖嗖的
: 也不知道是因为64位，还是live movie maker功力深厚
live
【在 d******a 的大作中提到】
: 我当初用Vista Ultimate 32-bit里边自带的movie maker转电视卡录的节目到wmv格式
: ，比较慢
: 现在升级到Win 7 Ultimate 64-bit, 没有movie maker了，只好下载了个windows live
: movie maker, 转起格式来嗖嗖的
: 也不知道是因为64位，还是live movie maker功力深厚
s*3
21 楼
【在 C*********r 的大作中提到】
: 最近刚开始学Spark，因为没有看过源代码，麻烦大家想请教几个问题。
: 1. RDD在创建的时候是lazy的，并且有narrow和wide两种类型，例如map，filter是
: narrow类型的所以不需要额外的shuffle。但是groupbykey之类的就需要shuffle了。并
: 且每个RDD会保存有自己所对应的partition信息。我的理解是每个action或者
: transformation都会被Spark internally翻译成map reduce job来执行。
: 我的问题是翻译之后的map reduce job的并行度是和哪些因素有关系呢？partition的
: 数量还有executor的数量还有executor-core的数量之间是什么样的关系呢？例如
: parition越多并行的task也会越多么？
: 2. 当我groupbykey的时候RDD会记录下我当前的RDD中有多少个key value么？并且这些
: key value和上面说的partition有什么样的联系呢，还是完全不想关的两个概念？
a*m
22 楼
vista本身就烂，慢的要死。
【在 D**i 的大作中提到】
: 这个是因为原来远景旗舰版自带的视频制作器太烂
:
: live
【在 D**i 的大作中提到】
: 这个是因为原来远景旗舰版自带的视频制作器太烂
:
: live
f*r
23 楼
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。
【在 C*********r 的大作中提到】
: many thanks for the clarification!
: 比如说我有一个两个column的table (name, money). 我想以name为key对money做一些
: data mining（或者一些复杂的计算）。所以我会做以下的步骤
: step1 -> 把table map 成一个file RDD
: step2 -> file RDD recudeByKey(name) 或者groupByKey(name)
: step3 -> 在第二步产生的RDD上面apply一些其他的运算
: 那么step2中的reduceByKey加入我设置partition number为100，但是我其实是有200个
: distinct names，所以其实平均下来每个partiton里面会有两个（name， list
: ) pair么？然后每个partition会被分配给一个task进行执行。假如我的配置是(5,4,16
: )，所以每个partiton里面即使有两个pair，但还会顺序的进行执行，对么？这里是我
t*t
24 楼
视频转换不耗内存，耗CPU而已。
【在 a*o 的大作中提到】
: 你要是不跑大程序，2GB都嗖嗖的，你开个video converter，8G都不嗖嗖的，呵呵。
【在 a*o 的大作中提到】
: 你要是不跑大程序，2GB都嗖嗖的，你开个video converter，8G都不嗖嗖的，呵呵。
f*r
25 楼
我建议初学者不需要太刻意手动设置partition的数目，spark framework一般会帮你选
择合适的数目。如果你的cluster有上一千个节点，每个cpu都是8core的情况，那你理
论上可以同时运行8k个task。这种情况下你增加partition数目或许可能会有帮助。但
前提条件也是真正的运算dominate主要task时间，不是seriliazation/
deserialization或者network的overhead。如果task都是ms level说明你的partition
数目太多了。整个spark tuning是个很tricky的过程，我不建议花太多时间在这个上面
。大部分情况你的改进空间是很有限的。应该多花时间考虑你的算法逻辑，balance你
的dataset。
择合适的数目。如果你的cluster有上一千个节点，每个cpu都是8core的情况，那你理
论上可以同时运行8k个task。这种情况下你增加partition数目或许可能会有帮助。但
前提条件也是真正的运算dominate主要task时间，不是seriliazation/
deserialization或者network的overhead。如果task都是ms level说明你的partition
数目太多了。整个spark tuning是个很tricky的过程，我不建议花太多时间在这个上面
。大部分情况你的改进空间是很有限的。应该多花时间考虑你的算法逻辑，balance你
的dataset。
a*o
26 楼
嗯，是不耗，光耗CPU就行。我错了，我羞愧得无地自容。。。。。。
【在 t**t 的大作中提到】
: 视频转换不耗内存，耗CPU而已。
【在 t**t 的大作中提到】
: 视频转换不耗内存，耗CPU而已。
C*r
27 楼
谢谢！感觉现在RDD的action还有operation的数量太少，有很多很复杂的逻辑如果全部
用RDD拼凑起来会变得很难维护，而且要花很多时间去migrate。所以一个折中的方法就
是把复杂的逻辑用java api wrap起来，然后pass给RDD进行执行。这样可以很快的搭起
来一个系统，但是只是利用了几个基本的RDD，真正复杂的逻辑其实和Spark没有太多关
系。所以才会直接跳到performance tuning的阶段。不知道这样使用Spark会有什么潜
在的问题么？
partition
【在 f********r 的大作中提到】
: 我建议初学者不需要太刻意手动设置partition的数目，spark framework一般会帮你选
: 择合适的数目。如果你的cluster有上一千个节点，每个cpu都是8core的情况，那你理
: 论上可以同时运行8k个task。这种情况下你增加partition数目或许可能会有帮助。但
: 前提条件也是真正的运算dominate主要task时间，不是seriliazation/
: deserialization或者network的overhead。如果task都是ms level说明你的partition
: 数目太多了。整个spark tuning是个很tricky的过程，我不建议花太多时间在这个上面
: 。大部分情况你的改进空间是很有限的。应该多花时间考虑你的算法逻辑，balance你
: 的dataset。
用RDD拼凑起来会变得很难维护，而且要花很多时间去migrate。所以一个折中的方法就
是把复杂的逻辑用java api wrap起来，然后pass给RDD进行执行。这样可以很快的搭起
来一个系统，但是只是利用了几个基本的RDD，真正复杂的逻辑其实和Spark没有太多关
系。所以才会直接跳到performance tuning的阶段。不知道这样使用Spark会有什么潜
在的问题么？
partition
【在 f********r 的大作中提到】
: 我建议初学者不需要太刻意手动设置partition的数目，spark framework一般会帮你选
: 择合适的数目。如果你的cluster有上一千个节点，每个cpu都是8core的情况，那你理
: 论上可以同时运行8k个task。这种情况下你增加partition数目或许可能会有帮助。但
: 前提条件也是真正的运算dominate主要task时间，不是seriliazation/
: deserialization或者network的overhead。如果task都是ms level说明你的partition
: 数目太多了。整个spark tuning是个很tricky的过程，我不建议花太多时间在这个上面
: 。大部分情况你的改进空间是很有限的。应该多花时间考虑你的算法逻辑，balance你
: 的dataset。
t*t
28 楼
说这些就没意思了。
我用i7 920压片，8个线程同时开，也就耗多耗2G内存。不存在什么4G不够用的。
【在 a*o 的大作中提到】
: 嗯，是不耗，光耗CPU就行。我错了，我羞愧得无地自容。。。。。。
我用i7 920压片，8个线程同时开，也就耗多耗2G内存。不存在什么4G不够用的。
【在 a*o 的大作中提到】
: 嗯，是不耗，光耗CPU就行。我错了，我羞愧得无地自容。。。。。。
f*r
29 楼
不知道你的复杂逻辑是什么。RDD就是Vector，你把RDD operation 想象成vector
operation就行了。并行设计主要还是考量怎么把运算逻辑并行化，选出data
independent的processing。你如果感兴趣，可以看看他们mlib的源码，有一些标准ml
的算法实现。
还有一个办法是你可以用scala重写一下你们现有的运算逻辑，尽量用fp的design
pattern。然后把涉及到的装data的collection全部改成RDD就可以用spark加速了。
operation就行了。并行设计主要还是考量怎么把运算逻辑并行化，选出data
independent的processing。你如果感兴趣，可以看看他们mlib的源码，有一些标准ml
的算法实现。
还有一个办法是你可以用scala重写一下你们现有的运算逻辑，尽量用fp的design
pattern。然后把涉及到的装data的collection全部改成RDD就可以用spark加速了。
a*o
30 楼
什么软件？或许跟软件，硬盘，编码方式，片源大小都有关系。
大概我们都盲人摸象了。
【在 t**t 的大作中提到】
: 说这些就没意思了。
: 我用i7 920压片，8个线程同时开，也就耗多耗2G内存。不存在什么4G不够用的。
大概我们都盲人摸象了。
【在 t**t 的大作中提到】
: 说这些就没意思了。
: 我用i7 920压片，8个线程同时开，也就耗多耗2G内存。不存在什么4G不够用的。
c*e
31 楼
linkedin都放弃scala了，你們还在用啊？scala和c++,都是曲高和寡的冬冬，最终结果
很难说啊。
ml
【在 f********r 的大作中提到】
: 不知道你的复杂逻辑是什么。RDD就是Vector，你把RDD operation 想象成vector
: operation就行了。并行设计主要还是考量怎么把运算逻辑并行化，选出data
: independent的processing。你如果感兴趣，可以看看他们mlib的源码，有一些标准ml
: 的算法实现。
: 还有一个办法是你可以用scala重写一下你们现有的运算逻辑，尽量用fp的design
: pattern。然后把涉及到的装data的collection全部改成RDD就可以用spark加速了。
很难说啊。
ml
【在 f********r 的大作中提到】
: 不知道你的复杂逻辑是什么。RDD就是Vector，你把RDD operation 想象成vector
: operation就行了。并行设计主要还是考量怎么把运算逻辑并行化，选出data
: independent的processing。你如果感兴趣，可以看看他们mlib的源码，有一些标准ml
: 的算法实现。
: 还有一个办法是你可以用scala重写一下你们现有的运算逻辑，尽量用fp的design
: pattern。然后把涉及到的装data的collection全部改成RDD就可以用spark加速了。
f*r
32 楼
就是个编程语言而已，用scala只不过因为spark是scala native 而已。他们自己都说
了，RDD level的话，scala比python还是要快一倍的。语言这玩意学着够用就行，将来
真不行了久换呗
【在 c*********e 的大作中提到】
: linkedin都放弃scala了，你們还在用啊？scala和c++,都是曲高和寡的冬冬，最终结果
: 很难说啊。
:
: ml
c*e
33 楼
python和php一个级别的，好多公司都不屑于使用。php做multi-threading那叫一个累
，c#的multi-threading和java的完全不一样。
【在 f********r 的大作中提到】
:
: 就是个编程语言而已，用scala只不过因为spark是scala native 而已。他们自己都说
: 了，RDD level的话，scala比python还是要快一倍的。语言这玩意学着够用就行，将来
: 真不行了久换呗
，c#的multi-threading和java的完全不一样。
【在 f********r 的大作中提到】
:
: 就是个编程语言而已，用scala只不过因为spark是scala native 而已。他们自己都说
: 了，RDD level的话，scala比python还是要快一倍的。语言这玩意学着够用就行，将来
: 真不行了久换呗
相关阅读
builder pattern是一次性还是可复用好？昨天看slides,腾讯用go lang做LDA微软最近听说又准备雷人了有人用clj刷lc么1gb的csv传服务器以api的方式给app使用推荐一个Clojure Web微框架为何人DNA里那么多无用代码？ (转载)java concurrency时，你们用的callable还是runnable?请问：中学里学习Python，都用什么IDE？请推荐一个小巧的，谢谢！想从稳定大公司去Series A Startup求建议有人用过netty么本来技术和管理就是两条路线有从全美or全球范围测试latency的service么?关于spark的cache问题一直没想清楚请教思路 数据同步有关Infinispan vs Hazelcast 哪个做distributed cache更合适Oculus有人关注吗请教个bitarray distance的问题go做得越来越好了啊，已经有人开始用go实现jvm了如何提高C#开发server程序的效率