p*****2
发帖数: 21240 | 1 看到很多设计题，尤其是big data, large scale的，基本上都可以用我们的tech
stack秒杀，就是
kafka + spark + cassandra
其实谈到big data, large scale的话，能用到的技术也就那么几个，尤其是一谈到
performance的话，基本就没啥好选的了。目前industry最明显的趋势就是上边这个
stack，估计dongfei大牛也认可。
如果这些技术不熟悉的话，storm，hbase也可以侃侃。再不行的话，redis，mongo这些
也能将就一下。
如果不要求performance的话，hadoop那套东西可以讲讲。couchbase啥的还是比较小众
，面试谈的话对方也不一定知道。 |
g*********e
发帖数: 14401 | 2 spark不是hdfs上的吗，如何用cassandra |
S*******w
发帖数: 24236 | 3 redis和 cassandra 不是一个category。不能比。 |
p*****2
发帖数: 21240 | 4
这个就错误了。赶紧去google一下。
【在 g*********e 的大作中提到】
: spark不是hdfs上的吗，如何用cassandra
|
p*****2
发帖数: 21240 | 5
redis在系统设计中很重要的一环，尤其是要求low latency的应用。
【在 S*******w 的大作中提到】
: redis和 cassandra 不是一个category。不能比。
|
S*******w
发帖数: 24236 | 6 所以我的意思是
kfaka + spark + C不能解决所有case
有的scenario必须要redis 这一类的东西。
【在 p*****2 的大作中提到】
:
: redis在系统设计中很重要的一环，尤其是要求low latency的应用。
|
p*****2
发帖数: 21240 | 7
看情况。C＊硬件配的好的话，真可能能免了redis。当然真的看需求了，要求太高的，
redis还是要硬上了。不过这属于跟面试官讨论的范畴了，不影响大方向。
【在 S*******w 的大作中提到】
: 所以我的意思是
: kfaka + spark + C不能解决所有case
: 有的scenario必须要redis 这一类的东西。
|
y**********u
发帖数: 6366 | 8 redis主要是替代memcache或者当in-memory queue
【在 S*******w 的大作中提到】
: redis和 cassandra 不是一个category。不能比。
|
M*******a
发帖数: 1633 | 9 我老都不懂，咋办
你们哥鲁胖就是高大上阿，用的东西都很in |
p*****2
发帖数: 21240 | 10
大牛赶快来吧。
【在 M*******a 的大作中提到】
: 我老都不懂，咋办
: 你们哥鲁胖就是高大上阿，用的东西都很in
|
|
|
g*****g
发帖数: 34805 | 11 Cache layer在web session clustering这里基本上是必须的。别的地方就要看use
case.
【在 S*******w 的大作中提到】
: 所以我的意思是
: kfaka + spark + C不能解决所有case
: 有的scenario必须要redis 这一类的东西。
|
p*****2
发帖数: 21240 | 12 这个session cache也有人用c*吧
【在 g*****g 的大作中提到】
: Cache layer在web session clustering这里基本上是必须的。别的地方就要看use
: case.
|
g*****g
发帖数: 34805 | 13 可以这么用，但规模大远不如memcache高效。别忘了memcache是在内存里的，C*只是有
cache的数据库而已。
【在 p*****2 的大作中提到】
: 这个session cache也有人用c*吧
|
p*****2
发帖数: 21240 | 14 你觉得couchbase做这个如何？
貌似dse可以把c* data全放内存里？
【在 g*****g 的大作中提到】
: 可以这么用，但规模大远不如memcache高效。别忘了memcache是在内存里的，C*只是有
: cache的数据库而已。
|
g*****g
发帖数: 34805 | 15 只要能放进内存，memcache和redis算是首选。couchbase我不熟不敢评论。
Session大，内存不足，或者session的数据重新产生的penalty很大，可以考虑C*,
Dynamo. 所有的设计都是取舍，没有一个什么都好的方案，看的是哪个更适合自己的应
用。
【在 p*****2 的大作中提到】
: 你觉得couchbase做这个如何？
: 貌似dse可以把c* data全放内存里？
|
w**n
发帖数: 122 | 16 设计题难道不是谈具体怎么处理，比如load balancer, DB sharding, data replica等等
二爷说的这些技术，没用过基本就是不知道，即使读过，也只是皮毛的皮毛
公司infra用什么技术，其实也没多大的自由度
【在 p*****2 的大作中提到】
: 看到很多设计题，尤其是big data, large scale的，基本上都可以用我们的tech
: stack秒杀，就是
: kafka + spark + cassandra
: 其实谈到big data, large scale的话，能用到的技术也就那么几个，尤其是一谈到
: performance的话，基本就没啥好选的了。目前industry最明显的趋势就是上边这个
: stack，估计dongfei大牛也认可。
: 如果这些技术不熟悉的话，storm，hbase也可以侃侃。再不行的话，redis，mongo这些
: 也能将就一下。
: 如果不要求performance的话，hadoop那套东西可以讲讲。couchbase啥的还是比较小众
: ，面试谈的话对方也不一定知道。
|
p*****2
发帖数: 21240 | 17 同意
【在 g*****g 的大作中提到】
: 只要能放进内存，memcache和redis算是首选。couchbase我不熟不敢评论。
: Session大，内存不足，或者session的数据重新产生的penalty很大，可以考虑C*,
: Dynamo. 所有的设计都是取舍，没有一个什么都好的方案，看的是哪个更适合自己的应
: 用。
|
p*****2
发帖数: 21240 | 18 现在各种design的话还是比较固定的章法
比如你说的这些
但是目前流行的是大数据 这个challenge很大 大数据的design 如果你没做过就很难了
这也是为什么dongfei随便拿offer的原因了
人家是专业大数据 一说话就不一样
等等
【在 w**n 的大作中提到】
: 设计题难道不是谈具体怎么处理，比如load balancer, DB sharding, data replica等等
: 二爷说的这些技术，没用过基本就是不知道，即使读过，也只是皮毛的皮毛
: 公司infra用什么技术，其实也没多大的自由度
|
z*******3
发帖数: 13709 | 19 c*用来做persistence
然后redis用来做cache用
到底怎么用，就看要不要持久化了
不过cassandra用来做cache也不是不可以
想偷懒就直接上cassandra就是了
【在 S*******w 的大作中提到】
: redis和 cassandra 不是一个category。不能比。
|
z*******3
发帖数: 13709 | 20 其实原理都那么一回事
kafka换成其他的message server
比如jms，本质都一样
反正无非找个server，能接收msg，能启动流程就可以了
然后spark套上随便一个rdd，其实都能用
couchbase和mongo就很尴尬了
因为spark之后，对于persistence的要求很低了
只要有一个东西能用来存数据就行了
处理全部交给spark去做，spark上面还有一堆libs
那如果把couch这些接上spark，那就显得多余
因为couch做的很多东西，其实spark就能做
而用了spark，用hdfs或者高级一点，cassandra就足够了
不需要couch这些，couchdb还是凑合，couchbase就显得多余 |
|
|
z*******3
发帖数: 13709 | 21 如果对j2ee比较熟悉的话
kafka - jms，这个其实所有的message server都可以用，只要有接口
只是kafka和jms都是jvm上的东西，所以接口很容易搞，非jvm语言不保证
spark - logic部分，通过kafka来触发
最后cassandra其实就是db+orm
本质上是一样的，原理都那么一回事
但是还是觉得有点问题，难道clustering, classification这些也通过kafka来触发？
嗯，搭配一个spring scheduler应该会比较合理点
big data还是有很多东西需要自启动并处理的 |
p*****2
发帖数: 21240 | 22 基本是这个样子
就怕面试官不动spark 就只能扯扯其他的了
【在 z*******3 的大作中提到】
: 其实原理都那么一回事
: kafka换成其他的message server
: 比如jms，本质都一样
: 反正无非找个server，能接收msg，能启动流程就可以了
: 然后spark套上随便一个rdd，其实都能用
: couchbase和mongo就很尴尬了
: 因为spark之后，对于persistence的要求很低了
: 只要有一个东西能用来存数据就行了
: 处理全部交给spark去做，spark上面还有一堆libs
: 那如果把couch这些接上spark，那就显得多余
|
z*******3
发帖数: 13709 | 23 couch跟mongo一样，都是doc based
cassandra是column-based
session这种是典型的key-value pair
我觉得还是用redis这种比较好，数据结构比较接近
couch用的是json，parse起来应该会比较讨厌
而且couch有些太过于小众了，都是以前用erlang的在用
【在 g*****g 的大作中提到】
: 只要能放进内存，memcache和redis算是首选。couchbase我不熟不敢评论。
: Session大，内存不足，或者session的数据重新产生的penalty很大，可以考虑C*,
: Dynamo. 所有的设计都是取舍，没有一个什么都好的方案，看的是哪个更适合自己的应
: 用。
|
g*****g
发帖数: 34805 | 24 所谓 column base同样是 key value pair. 可行是可行的。
【在 z*******3 的大作中提到】
: couch跟mongo一样，都是doc based
: cassandra是column-based
: session这种是典型的key-value pair
: 我觉得还是用redis这种比较好，数据结构比较接近
: couch用的是json，parse起来应该会比较讨厌
: 而且couch有些太过于小众了，都是以前用erlang的在用
|
z*******3
发帖数: 13709 | 25 理论上可行，但是就是不知道会不会出啥问题
如果等scale了之后，再出点这样那样的问题
尤其是源代码还是erlang这种语言写的
嗯，想想都害怕，还是不要了
persistence的部分还是要谨慎点，其他改起来都相对容易
【在 g*****g 的大作中提到】
: 所谓 column base同样是 key value pair. 可行是可行的。
|
p*****2
发帖数: 21240 | 26 redis scale麻烦
mongo还不错 速度也快
【在 z*******3 的大作中提到】
: 理论上可行，但是就是不知道会不会出啥问题
: 如果等scale了之后，再出点这样那样的问题
: 尤其是源代码还是erlang这种语言写的
: 嗯，想想都害怕，还是不要了
: persistence的部分还是要谨慎点，其他改起来都相对容易
|
z*******3
发帖数: 13709 | 27 做个local cache就好了
深层次的cache交给cassandra去做
【在 p*****2 的大作中提到】
: redis scale麻烦
: mongo还不错 速度也快
|
f*******w
发帖数: 1243 | 28 主要是光拽这些名词，还是没啥底气啊。看这些东西的感觉就是什么都是碎片，连不成
一个完整的体系。 |
p*****2
发帖数: 21240 | 29
多听听zhaoce讲课就可以了。
【在 f*******w 的大作中提到】
: 主要是光拽这些名词，还是没啥底气啊。看这些东西的感觉就是什么都是碎片，连不成
: 一个完整的体系。
|
M*******a
发帖数: 1633 | 30 我不是大牛啊。
【在 p*****2 的大作中提到】
:
: 多听听zhaoce讲课就可以了。
|
|
|
D*********G
发帖数: 193 | 31 这个绝对不是 new graduate level.....
就算大概了解一点，一问细节就露馅了
new graduate 还是老老实实读 FLAG 的 design paper，然后把每个design题都自己做
一遍好了
【在 p*****2 的大作中提到】
: 看到很多设计题，尤其是big data, large scale的，基本上都可以用我们的tech
: stack秒杀，就是
: kafka + spark + cassandra
: 其实谈到big data, large scale的话，能用到的技术也就那么几个，尤其是一谈到
: performance的话，基本就没啥好选的了。目前industry最明显的趋势就是上边这个
: stack，估计dongfei大牛也认可。
: 如果这些技术不熟悉的话，storm，hbase也可以侃侃。再不行的话，redis，mongo这些
: 也能将就一下。
: 如果不要求performance的话，hadoop那套东西可以讲讲。couchbase啥的还是比较小众
: ，面试谈的话对方也不一定知道。
|
T******g
发帖数: 790 | |
g**e
发帖数: 6127 | 33 二爷,少了workflow/pipeline设计啊
【在 p*****2 的大作中提到】
: 看到很多设计题，尤其是big data, large scale的，基本上都可以用我们的tech
: stack秒杀，就是
: kafka + spark + cassandra
: 其实谈到big data, large scale的话，能用到的技术也就那么几个，尤其是一谈到
: performance的话，基本就没啥好选的了。目前industry最明显的趋势就是上边这个
: stack，估计dongfei大牛也认可。
: 如果这些技术不熟悉的话，storm，hbase也可以侃侃。再不行的话，redis，mongo这些
: 也能将就一下。
: 如果不要求performance的话，hadoop那套东西可以讲讲。couchbase啥的还是比较小众
: ，面试谈的话对方也不一定知道。
|
p*****2
发帖数: 21240 | 34 大牛说说？
面试没被人问到过
【在 g**e 的大作中提到】
: 二爷,少了workflow/pipeline设计啊
|
v***o
发帖数: 287 | 35 mongo 速度会遇到瓶颈当到达一定的scale.
【在 p*****2 的大作中提到】
: redis scale麻烦
: mongo还不错 速度也快
|
p*****2
发帖数: 21240 | 36 当kv store应该没问题吧？
【在 v***o 的大作中提到】
: mongo 速度会遇到瓶颈当到达一定的scale.
|
c******f
发帖数: 243 | 37 我们这里design差不多.就是我们不用kafka,用了kinesis....
kinesis有storm, spark接口 |
d********w
发帖数: 363 | 38 这个说的好直接啊，我看过或者面过的startup中，80%都会用到Kafka，20% Spark，有
你说的这种经典组合，这有个学术名称的，叫lambda architecture. 把实时跟批处理
结合,适合做Stats日志统计系统。 Twitter 还有Summingbird也不错，说是能通过一套
框架自动翻译成Stream和batch way的处理。但真正做过的才知道这种Lambda架构的弊
端，一个是online可能有误差，有重复或者数据的丢失可能性，而batch layer延迟太
高，维护两套异构系统复杂度高。有了新的需求，改起来非常麻烦，涉及到两遍
migration。我的建议是
1是以后Stream系统足够强大，takeover一切，spark正往这个方向走
2.pipeline能够独立运行，如果有版本变化，新版本会替代老的pipeline，成为主线，
老的就自然死亡。这有点像git的分支管理，你先独立开发好自己的版本，最后rebase
一下就合并到主线
【在 p*****2 的大作中提到】
: 看到很多设计题，尤其是big data, large scale的，基本上都可以用我们的tech
: stack秒杀，就是
: kafka + spark + cassandra
: 其实谈到big data, large scale的话，能用到的技术也就那么几个，尤其是一谈到
: performance的话，基本就没啥好选的了。目前industry最明显的趋势就是上边这个
: stack，估计dongfei大牛也认可。
: 如果这些技术不熟悉的话，storm，hbase也可以侃侃。再不行的话，redis，mongo这些
: 也能将就一下。
: 如果不要求performance的话，hadoop那套东西可以讲讲。couchbase啥的还是比较小众
: ，面试谈的话对方也不一定知道。
|
p*****2
发帖数: 21240 | 39 大牛说的真好
目前的情况我的理解是要compromise latency 或者 consistency了
我们的应用重复处理问题不大 丢一点数据也可以容忍
rebase
【在 d********w 的大作中提到】
: 这个说的好直接啊，我看过或者面过的startup中，80%都会用到Kafka，20% Spark，有
: 你说的这种经典组合，这有个学术名称的，叫lambda architecture. 把实时跟批处理
: 结合,适合做Stats日志统计系统。 Twitter 还有Summingbird也不错，说是能通过一套
: 框架自动翻译成Stream和batch way的处理。但真正做过的才知道这种Lambda架构的弊
: 端，一个是online可能有误差，有重复或者数据的丢失可能性，而batch layer延迟太
: 高，维护两套异构系统复杂度高。有了新的需求，改起来非常麻烦，涉及到两遍
: migration。我的建议是
: 1是以后Stream系统足够强大，takeover一切，spark正往这个方向走
: 2.pipeline能够独立运行，如果有版本变化，新版本会替代老的pipeline，成为主线，
: 老的就自然死亡。这有点像git的分支管理，你先独立开发好自己的版本，最后rebase
|
v***o
发帖数: 287 | 40 一开始还行，collection复杂了，加上scale后，就明显慢多了。
【在 p*****2 的大作中提到】
: 当kv store应该没问题吧？
|
|
|
p*****2
发帖数: 21240 | 41 主要是什么原因呀
【在 v***o 的大作中提到】
: 一开始还行，collection复杂了，加上scale后，就明显慢多了。
|
v***o
发帖数: 287 | 42 Mongo 的底层设计就决定了，虽然可以通过sharding 来 scale,但是,其根本问题是
document DB,与bigTable/Hbase(key-value) 的distributed 底层设计完全不可比。
mongo scale到一定程度就出现问题了，当然，也与应用有关，比如schema，indexing
不合理。
而且，实际中，ebay是最大的mongo用户了。数据量远比google,facebook差远了。
【在 p*****2 的大作中提到】
: 主要是什么原因呀
|
b********r
发帖数: 620 | 43 牛们，推荐一两个入门的real world design case based upon kafka + spark +
cassandra?
我的理解是
kafka = tibco-like broadcasting/p-p messaging
spark = enhanced hadoop
cassandra = kv storage
不知道对不对。
【在 p*****2 的大作中提到】
: 看到很多设计题，尤其是big data, large scale的，基本上都可以用我们的tech
: stack秒杀，就是
: kafka + spark + cassandra
: 其实谈到big data, large scale的话，能用到的技术也就那么几个，尤其是一谈到
: performance的话，基本就没啥好选的了。目前industry最明显的趋势就是上边这个
: stack，估计dongfei大牛也认可。
: 如果这些技术不熟悉的话，storm，hbase也可以侃侃。再不行的话，redis，mongo这些
: 也能将就一下。
: 如果不要求performance的话，hadoop那套东西可以讲讲。couchbase啥的还是比较小众
: ，面试谈的话对方也不一定知道。
|
p*****2
发帖数: 21240 | 44
cassandra = column based nosql
cassandra = dynamo + hbase
【在 b********r 的大作中提到】
: 牛们，推荐一两个入门的real world design case based upon kafka + spark +
: cassandra?
: 我的理解是
: kafka = tibco-like broadcasting/p-p messaging
: spark = enhanced hadoop
: cassandra = kv storage
: 不知道对不对。
|
m*******g
发帖数: 410 | |
