E7

理由
举报 取消

如果给你10台这样的服务器,在做大数据方面你会怎么用?比如6台hadoop,4台spark等等,你会怎么用?

2017年11月17日 2 条回复 653 次浏览

回复 ( 2 )

  1. 王威扬
    理由
    举报 取消

    泻药。先问一下题主,我脸上写着架构师几个字吗?(开玩笑的。)

    正好最近做了个高性能数据平台+大数据平台的PPT方案,还是想稍微分享一下其中的内容以及几张图,也希望更有经验的工程师指正。我觉得,很多对技术架构很熟悉的人刚刚面对硬件的时候会有一定几率lost在硬件的技术参数里,而“到底什么硬件是合适的” 不仅仅是一个技术问题,其实也是一个经济问题。因为不了解“你手头有多少硬件资源可以用”,所以我只能从“我怎么用”或者“我即将怎么用”这个角度来回答。

    ================================================================

    先来梳理一下思路:做得最好的云服务有哪些?这些公司具备哪些特征?

    • 合理的基础架构:不是越牛越好,而是紧密结合着上面跑着的服务以及最终应用场景而来
    • 完善的上层建筑:开发者使用云服务的痛点在于本地复杂的架构希望在云端井井有条。

    基于此,我会拿两家公司的产品来做参考:Amazon的AWS基础设施以及QingCloud的服务。

    ================================================================

    1 从Amazon的AWS理解硬件

    AWS将预留节点的配置大致分为4类以便更好的满足不同的需求:

    • 计算密集型:一般是多路Xeon(甚至北美还有可以使用GPU资源的节点)。
    • 内存密集型:在一些特定的应用(ElasticSearch,Redis)上,内存会消耗的特别快
    • IO密集型:一般用在对数据库I/O性能(无论是RDBMS还是NoSQL)有比较强烈的需求的时候。
    • IO存储型:大数据时代,很多数据价值密度极低,比较鸡肋,使用存储节点比较合适。

    结合我以及一些朋友、同事的经验,如果需要本地部署这几种节点的话,每一种都需要合理搭配(除非你想1个节点搭着各种杂七杂八的数据库服务,这样有可能引起不必要的混乱)

    计算密集型节点

    倾向于做成并行任务提交的集群,作为高性能计算使用。做成Fat Node比较好,我的建议是有条件上4路甚至还带着GPU,内存够用就好,也就是主力计算资源尽量往一起堆,数据不需要频繁走网线,否则有些人就会上Infiniband这种解决方案来解决网速或者直连PCIE上面GPU/显存的问题。这种节点明显适合Spark集群,等着别人来提交繁重的计算任务。往往他们访问的数据资源并不多,但是计算量却非常大,比如给定原始参数做蒙特卡罗模拟,那真的是输入几个参数,一跑一下午。再比如,采样后进行随机森林算法,你的目标可能是训练几千个森林,一个森林里面几十颗树,完全的暴力Ensemble。并行的跑也不会对收敛速度有什么太大的帮助了。(如果你还要做一些图像识别、语音识别的工作,更多要借助GPU的功能,就不在此处展开,避免班门弄斧。)

    推荐配置:4路Xeon E5/7-4xxx,128GB内存,SSD,GPU(可选),Infiniband(可选)

    内存密集型节点

    需要你明确自己到底把什么往上放。

    比如一个大规模社交网络的挖掘(PageRank啊,最短寻路啊,环路搜索啊,Louvain什么的),数据要反复迭代,所以内存是越大越好,而不同节点间的数据交换是越小越好。

    比如Redis,如果你要给计算密集型的节点提供数据,每次都走I/O再走网线就有点蠢,你可以把几十上百G的东西先完全缓存住一下。只要你的内存够大,而且命中缓存在50%以上节省下这次I/O的时间,都会让你觉得这选择太棒了。

    再比如你要搞ElasticSearch替代MongoDB作为主力NoSQL,在上面有些分析的查询是特别吃内存+吃一部分计算资源的(还有人在ES上跑NLP,吓死宝宝了)

    再比如你要搞消息队列,如果是拿Java开发的话(Samza,Kafka一类),我有一种认为它们贼能吃内存的偏见。大神们请打我脸。

    推荐配置:双路Xeon E5-2xxx,512GB内存,2×SSD,IB(可选)

    I/O密集型节点

    我觉得一个稍微大一些的内存是必要的,这种内存消耗主要来自于你有多少空间是预留给RDBMS和MongoDB的索引以及热数据。也许你的索引也就是不到1G,绰绰有余,可是又远远不足以放下热数据,这种情况我的建议是没有必要特地为I/O密集型节点配置过高的内存,让他的热数据有施展空间即可,反正你也分不出足够大的内存启动一个Redis了,如果真的要进行大量数据缓存的话不如另找一台内存密集型节点如何?

    推荐配置:单路Xeon E5-2xxx,128G内存,2×SSD+N*SAS

    I/O存储型节点

    Hadoop基础平台,包括1台稳定的本地Yum源啦(超级低配就行,233),HDFS集群以及跑在上面的Hive啦,各种各样的Raw!Data!还有实习生特别喜欢玩的各种小工具(让他们有个自己学习提高以及作妖的机会)等等。基础配置就行,作为原始数据源、数据清洗、备份归档、批量加工ETL、个人数据研究的节点还挺合适的。主要是,数据价值如果真的不大(注意,反正你的事务性数据都在I/O密集型节点对不对),日志这种的,用普通硬盘绰绰有余了,2T那种最便宜的就行!

    推荐配置:单路Xeon E3 -1xxx,32-64G内存,12×2TB

    哦,还有一件事

    我刚才好像很多次提到SSD……

    在2015年11月这个时间节点,集群用的SSD性价比最高没有之一的方案是Intel 750 PCI-E SSD,1.2T容量 2.4GB/s读 1.2GB/s写,海淘6800RMB。

    作为从09年开始用Intel X25-E,玩过Intel 三星 Marvell SandForce主控,三星 镁光 东芝NAND芯片,还有一堆莫名其妙牌子的SSD用户,请感受一下,我不是托。(深情的凝望)

    =================================================================

    2 从QingCloud的服务理解不同业务场景中对于数据平台的需求。

    抛开很多人喜欢讲的工单响应时间啊、稳定性不谈,QingCloud的服务吸引力对我而言还是挺大的。我需要他基于几种考虑:

    • PostgreSQL:一个强力的RDBMS来替代MySQL存储事务性、半结构化、地理、JSON数据,还能各种玩耍OLAP功能,支持对象化,二次开发版本还支持GPU加速等等(跑题了)
    • MongoDB:一个强力的NoSQL,来处理客户视角下剧烈变化的业务数据
    • Zookeeper+Spark:一个强力的并行计算引擎。Let’s (Py)Spark!

    这字里行间写满了两个字:好玩。也许更多的玩具我在本地部署的时候还会用到,不过这些工具在云端的自动化部署和运维已经足够让人兴奋,也足够能解决一大批痛点了。

    ==================================================================

    3 回到题主的问题:

    我有办法告诉题主的是,你的节点计算、内存性能都很棒,很奢侈!I/O略显不足,而混在一起的时候我觉得可能适合另外找1台临时的低配机器放本地源,最终从逻辑上来讲你的集群应该是这张图的一个子集:除了1-2台边边角角的数据库、消息队列服务,剩下的就是一个全模块的CDH集群(性能尽量不浪费,但运维压力大,抢I/O资源会很明显)或者刻意拆成2个集群,一个主要Spark,一个主要是Hadoop基础服务。(转图还是尽量带着作者,谢谢,这样拍砖能拍对地方。)

    将CDH5部署在集群上,并且将争夺同类型资源的服务尽量分开

    但是!我不了解你的需求,比如

    • 你的原始数据预估存量是多少?增量多少?存什么结构的数据?需要哪些Hadoop组件干什么?
    • 你的团队里面写Scala的有几个?写Py的有几个?做什么算法?随机森林,SVM or 图模型?
    • 你的集群是否大量输入数据?对内提供缓存?对外提供服务?记录日志?性能要求?
    • 资源浪费会不会导致你的方案不被信任?I/O不足怎么解决?有强力运维吗?

    你提到的6*Hadoop基础平台+4*Spark貌似是很合理的……然而我认为Scala和Py写的多的人更容易直接上手做算法,如果全员都是算法岗,和基础数据岗分开了,10个节点全做Spark有什么不可以?如果这个集群还肩负着沉重的跑批任务,最好不要玩太多花样,老实搞1台数据库,大部分跑Hive,1-2台Spark出政绩亮点。

    所以我好像并没有解决你的问题。(被殴打)

  2. Vinny
    理由
    举报 取消

    Spark 没必要跟 Hadoop(HDFS)分开建集群啊,资源浪费了啊

我来回答

Captcha 点击图片更换验证码