新⼀代USDP开源套件,可替代CDH的免费大数据套件平台及架构选型 |
您所在的位置:网站首页 › hadoop开源平台jianjie › 新⼀代USDP开源套件,可替代CDH的免费大数据套件平台及架构选型 |
持续输出 敬请关注
大数据架构 湖仓一体化 流批一体 离线+实时数仓
各种大数据解决方案 各种大数据新技术实践
持续输出 敬请关注
【第一篇】⼤数据平台基础架构及解决⽅案![]() 目录 一、大开眼界,新⼀代USDP开源套件 1.1 USDP初识 1.2 USDP所支持的软件栈 1.3 USDP架构 1.4 USDP的优势 1.4.1 ⽆需担⼼业务绑定 1.4.2 傻⽠式部署⽅式 1.4.3 全⾯丰富的监控指标 1.4.4 灵活便捷的告警服务 1.4.5 专业的技术⽀持 1.4.6 反哺开源社区 1.5 USDP适用的业务场景 二、 大数据基础架构选型技巧 2.1 为啥要选择套件 2.2 主流发行版对比 2.2.1 回到Apache 原⽣版本 2.2.2 使⽤ Cloudera 的"社区版" 2.2.3 Apache Ambari + Apache BigTop Stack 2.2.4 采购云原⽣商业套件 2.2.5 选⽤思路 三、架构选型方面常见高频面试题 3.1、你们的团队组成和分⼯ 3.1.1 面试目的 3.1.2 参考答案 3.2、请介绍下您如何做服务器选型以及您公司的集群规模 3.2.1 面试⽬的 3.2.2 参考答案 3.3、基础架构选型 3.3.1 面试⽬的 3.3.2 参考答案 一、大开眼界,新⼀代USDP开源套件 1.1 USDP初识USDP是UCloud开发并提供免费版本的⼤数据软件套件。 USDP涵盖了HDFS、Hive、HBase、Spark、Flink、Presto、Atlas、Ranger 等众多开源大数据组件,并支持对这些组件进行运维、中台建设、数据开发、业务可视化等全栈式大数据开发运维管理。 USDP通过轻量、易用、傻瓜式的形态交付给用户,支持对不同模块进行拆分,从而实现高度定制化,灵活匹配各垂直行业场景下的需求。 1.2 USDP所支持的软件栈目前,UCloud一站式智能大数据平台USDP所支持的服务如表格所示,同时还在持续拓展更多开源生态组件服务。 USDP作为UCloud大数据团队自主研发的一站式智能大数据平台,其整体架构如下图所示:
(2)Agent为USDP从节点控制端服务,⽤于管理、操作所在节点以及所在节点上的⼤数据服务。(3)BigData Service为各类⼤数据服务(例如: HDFS、 YARN等)。 (4)InfluxDB、 Prometheus、 Grafana作为监控服务,⽤于汇总并展示整个集群的监控数据。 USDP⽀持最少3个节点,最多上千节点的集群规模,同时,允许Manager Server与Agent等相关服务部署在相同的节点上,这样满⾜⼤型业务的同时,也尽可能帮助⽤户使⽤较⼩的成本满⾜⼩型业务对数据分析的诉求。 1.4 USDP的优势 1.4.1 ⽆需担⼼业务绑定业务绑定是⽬前云原⽣商业软件的通病。 USDP中所包含的⼤数据服务、组件,均满⾜ Apache 2.0开源协议, UCloud⼤数据团队在做过⼤量兼容性测试后,积极回馈社区,并将编译后的兼容包全⾯公开发布。由于本身紧跟开源社区的步伐,⽤户可以随时进⾏⾃主替换、⾃主建设、⾃主数据迁移、集群迁移等,因此⽆需担⼼⼤数据业务与闭源服务绑定。 1.4.2 傻⽠式部署⽅式为了能让⽤户体验到极简的⼤数据部署、运维、管理⽅案, USDP提供了丰富详细的部署、操作⽂档,并且⽤户⽆需担⼼安装时需要准备众多内容,初始化环境只需要简单⼏步,即可⾃动完成配置。 (1)环境检查
USDP预置的监控指标主要包含三部分内容: (1)JMX全量指标采集 (2)Http常⽤指标采集 (3)⾃定义指标采集 以上三部分监控数据最终将汇总于USDP的 Promethues中,并在每个服务的概览⻚⾯中展示最常⽤的监控指标。同时,在Grafana中,通过 USDP官⽅预置的监控模板( Dashboard),⽤户可以查看最详细监控指标。如果USDP预置的监控图标⽆法满⾜业务需求,⽤户也可以⾃定义添加所需的监控图表。 1.4.4 灵活便捷的告警服务USDP提供预置的告警模板,⽤户只需要按照引导进⾏简单配置,即可实现向不同⽬标(微信、钉钉、邮件、接⼝调⽤等)发送集群指标告警的需求。与监控指标的设计相似,如果⽤户认为预置的告警模板⽆法满⾜业务需求,也可以⾃定义对告警模板进⾏修改,或添加新的告警规则。 1.4.5 专业的技术⽀持UCloud⼤数据团队积淀了多年公有云⼤数据运维和业务调优经验,通过持续更新的⽂档知识库,为⽤户提供专家级技术⽀持,解决使⽤USDP的后顾之忧。 1.4.6 反哺开源社区USDP免费版中所使⽤的开源、全⾯兼容优化后的服务包,将反哺回开源社区,为开发者提供免费的下载渠道。 1.5 USDP适用的业务场景(1)数据仓库 ⽬前国内常⽤的数仓模型为维度数仓,即按照事实表、维度表来构建数据仓库、数据集市。通过USDP⼀站式智能⼤数据平台,⽤户可以部署构建维度数仓所需的各项服务,帮助企业快速构建数据中台。 (2)机器学习 机器学习通过算法对⼤量数据进⾏分析,挖掘出其中蕴含的规律,并⽤于事物预测或者分类,有⼤量的计算需求。通过USDP⼀站式智能⼤数据平台⽀持的Spark、 Flink等分布式运算框架,可以⾼效的进⾏机器学习应⽤开发。 (3)信息检索 从海量数据中快速检索到所需信息,⼀直是数据应⽤的重要领域, USDP⼀站式智能⼤数据平台集成了分布式搜索和分析引擎ElasticSearch以及实时检索数据库HBase、数仓服务Kylin等,能够提供⾼效的数据检索能⼒,可⽤于构建企业级搜索引擎、⽇志管理系统等。 二、 大数据基础架构选型技巧 2.1 为啥要选择套件反思以下两个方面的问题就懂了。 (1)兼容性 ⼏⼗款软件,相互兼容性你准备怎么管控? (2)运维管理⼯具(配置、部署、管理、监控、告警) ⼏⼗款分布式软件⼿⼯部署?⼿⼯管理?⾃⼰搞定监控?⾃⼰搞定告警?这将是⼀场噩梦! 2.2 主流发行版对比CDH 6.3 的⽀持结束⽇期为 2022 年 3 ⽉, HDP 3.1的⽀持结束⽇期为 2021 年 12 ⽉。也就是说,在这个⽇期之前,这些最后的“免费午餐”依然是主流的版本。但过了这个⽇期之后呢? 之前也有不少同学问过我,我正式回答⼀下,⽬前有三条道可供选择,但是要⾛的路还长,⽼师也没办法提供实现⽅法,只能提供思路,如果我有实现⽅法我就发财了,中国版的CDP就出现了。 2.2.1 回到Apache 原⽣版本其实很多公司⼀直就是这么做的,但⾮常具有挑战性(后续成本⽐买个商业版可能还要⾼⼀些),没有⼀定实⼒的公司还真不敢玩,除⾮公司做不⼤。 2.2.2 使⽤ Cloudera 的"社区版"CM虽然收费了,但是CDH发⾏版的源码⼀直都是在 GitHub 上公开的,这意味着你完全可以使⽤其源码来进⾏编译和部署。但是,这条路的效果⼀般般,因为在商业发⾏版中最重要的组件是 Cloudera Manager,正是 Cloudera Manager 降低了集群的安装、部署、运维的难度,虽然 Cloudera 承诺会将 Cloudera Manager “开源”,但其实是⼀个有限制的“开源”,源代码只会向具有许可证的客户开放,所以不想花费⾦钱的话,是没有办法得到 Cloudera Manager 的。 如果只是⽤ Cloudera 版本的源码编译和部署组件,然后在繁琐的命令⾏下进⾏操作,那和使⽤ Apache 社区版本⼜有什么区别呢 ? 2.2.3 Apache Ambari + Apache BigTop Stack⽬前来看“Apache Ambari + Apache BigTop Stack”这种组合是⽐较好的选择⽅式。 Apache Ambari⼤家都⽐较熟悉,作为 Hortonworks 贡献给社区的项⽬, HDP虽然没了,但是Ambari是Apache的,不可能收费,所以完全可以使⽤Ambari 降低集群的安装、部署、运维的难度,且可以扩展Ambari去⽀持更多的组件。 什么是 Stack 呢?实际上就是⼀组预定义好的组件服务和命令脚本的集合。⽽ Apache Ambari 和 Cloudera Manager ⼀样,都属于⼀个“管理界⾯⼯具”,在 Apache Ambari 的架构中,实际上 Ambari Stack 是完全可以将HDP Stack 替换为第三⽅提供的 Stack,或者是你⾃⼰定义的 Stack 的。 ⾃⼰定义的 Stack是⾮常难的, Hadoop ⽣态圈的项⽬众多,各种编译依赖⼜特别复杂,并且不同组件版本之间还有乱作⼀团麻的版本兼容性问题,如果你再考虑到⽬标硬件平台的话,个⼈开发者肯定是没有办法从头去构建⼀个⾃定义的 Stack 的。这个时候就需要使⽤到 Apache BigTop ( https://bigtop.apache.org/)了。 2.2.4 采购云原⽣商业套件以下列出了各种常见大数据发行版的优缺点,可供选择参考。 如果想花更少的钱,依据公司的规模,数据业务复杂程度等因素,可参考如下技术选择方案。 不同岗位,考察⽬的不⼀样。如果⾯试的是普通⼤数据开发岗位,本问题主要是看你有没有说实话,判断有没有真实的⼤数据⼯作经验,如果⽀⽀吾吾,或者前后回答⽜头不对⻢嘴,⽴⻢就让⾯试官觉得你没有实际⼯作经验。如果⾯试的是⼤数据架构师, leader,负责⼈,总监,主要是考察你有没有带过团队,团队是如何分⼯的。 3.1.2 参考答案针对不同的企业规模,团队大小、组成、分⼯各不⼀样。 (1)⼩型公司( 3 ⼈左右):组⻓ 1 ⼈,剩余组员⽆明确分⼯,并且可能兼顾 JavaEE和前端。 (2)中⼩型公司( 3~6 ⼈左右):组⻓ 1 ⼈,离线 2 ⼈左右,实时 1 ⼈左右(离线⼀般多于 实时)组⻓兼顾、 JavaEE、前端。 (3)中型公司( 5~10 ⼈左右):组⻓ 1 ⼈,离线 3~5 ⼈左右(离线处理、数仓),实时 2 ⼈ 左右,组⻓或技术⼤⽜兼顾、JavaEE、前端。 (4)中⼤型公司( 5~20 ⼈左右):组⻓ 1 ⼈,离线 5~10 ⼈(离线处理、数仓),实时 5 ⼈ 左右,JavaEE1 ⼈左右(负责对接 JavaEE 业务),前端 1 ⼈。 (发展⽐较良好的中⼤型公司可能⼤数据部⻔已经细化拆分,分成多个⼤数据组,分别负责不同业务) 上⾯只是参考配置,因为公司之间差异很⼤,因此根据所选公司规模确定⼀个合理范围,在⾯试前提前将公司的⼈员配置想清楚,话术对好,回答时要⾃信。 3.2、请介绍下您如何做服务器选型以及您公司的集群规模 3.2.1 面试⽬的考察是否具有实际的项⽬经验,服务器配置说的离谱、集群规模明显跟公司的业务和数据量相悖⼀定是造假的⼯作经验。 3.2.2 参考答案1、服务器选型使⽤物理机还是云主机? (1)机器成本考虑 物理机 以 惠普品牌为例,128G 内存, 20 核物理 CPU, 40 线程, 8THDD 和 2TSSD 硬盘,单台 报价 4W 出头,还需考虑托管服务器费⽤。⼀般物理机寿命 5 年左右。 云主机 以阿⾥云为例,差不多相同配置,每年 5W (2)运维成本考虑 物理机:需要有专业的运维⼈员 云主机:很多运维⼯作都由阿⾥云完成,运维相对较轻松 ⽆标准答案,根据⾃⼰公司的实际情况来选择,如果公司处于起步阶段,可以采⽤云主机。 2、集群规模评估 这⾥以100万⽤户为例给⼤家⼀些模板,⼤家按照⾃⼰公司⽤户的规模类推,不⾄于太离谱,能够⾃圆其说即可。 (1) ⽤户⾏为数据(埋点采集的log, 比如Nginx⽇志) 1)每天⽇活跃⽤户100万,每⼈⼀天平均100条: 100万*100条=10000万条 2)每条⽇志1K左右,每天1亿条: 100000000 / 1024 / 1024 = 约100G 3)数仓ODS层采⽤LZO+parquet存储: 100g压缩为10g左右 4)数仓DWD层采⽤LZO+parquet存储: 10g左右 5)数仓DWS层轻度聚合存储(为了快速运算,不压缩): 50g左右 6)数仓ADS层数据量很⼩:忽略不计 7)保存3副本: 70g*3=210g 8)半年内不扩容服务器来算: 210g*180天=约37T 9)预留20%~30%Buf=37T/0.7=53T (2) Kafka中数据 1)每天约100G数据*副本( 2) =200g 2)保存7天*200g=1400g 3)预留30%buf=1400g/0.7=2000g=约2T (3)业务数据(从MySQL采集) 1)每天活跃⽤户100万,每天下单的⽤户10万,每⼈每天产⽣ 的业务数据10条,每条⽇志1k左右,10万*10条*1k=1g左右 2)数仓四层存储: 1g*3=3g 3)保存3副本: 3g*3=9g 4)半年内不扩容服务器来算: 9g*180天=约1.6T 5)预留20%~30%Buf=1.6T/0.7=2T (4)半年数据⼤约是: 53T+2T+2T=57T (5)保存半年数据所需集群规模: 100万⽤户,半年约60T数据,约8台数据节点,每台10T容量(实际可⽤不到10T) ⼤家可以⾃⼰适当夸张下,⽐如300⽤户,保存3年,⾃⾏类推。 3.3、基础架构选型 3.3.1 面试⽬的主要是考虑架构师的⼀些独⽴思考能⼒。 3.3.2 参考答案可以回答采⽤的CDH或者HDP基础套件。 为什么不选⽤阿⾥的产品? 阿⾥的产品虽然开箱即⽤,也免去了⼤量运维⼯作,但是存在⼏个⼤问题: (1)阿⾥云的⼤数据产品Hadoop版本⽐较⽼,很多上层的开源调度⼯具、数据治理⼯具不⽀持 (2)阿⾥云的版本是固定的,购买其他商业组件⽆法做版本的适配,只能购买阿⾥云的其他⼤数据商业软件,完全被绑死了 (3)数据安全性考量 所以我们最开始就选择了CDH或者HDP 为什么没选用Apache版本? Apache版本:运维麻烦,组件间兼容性需要⾃⼰解决,研发成本⾼。(⼀般⼤⼚技术实⼒雄厚, 有专业的运维⼈员才会采⽤) 也可参考本篇文章“大数据基础架构选型技巧”章节相关内容完善回答。 【下一篇】⼤数据中台架构及解决⽅案
|
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |