新⼀代USDP开源套件，可替代CDH的免费大数据套件平台及架构选型

持续输出敬请关注大数据架构湖仓一体化流批一体离线+实时数仓各种大数据解决方案各种大数据新技术实践持续输出敬请关注

大数据研习社

7698人浏览 · 2022-03-21 16:50:57

大数据研习社 · 2022-03-21 16:50:57 发布

持续输出敬请关注

大数据架构湖仓一体化流批一体离线+实时数仓

各种大数据解决方案各种大数据新技术实践

持续输出敬请关注

【第一篇】⼤数据平台基础架构及解决⽅案https://blog.csdn.net/dajiangtai007/article/details/123473705

【下一篇】⼤数据中台架构及解决⽅案

新⼀代USDP开源套件，可替代CDH的免费大数据套件平台

及架构选型

二、大数据基础架构选型技巧

2.2.2 使⽤ Cloudera 的"社区版"

2.2.3 Apache Ambari + Apache BigTop Stack

3.2、请介绍下您如何做服务器选型以及您公司的集群规模

一、大开眼界，新⼀代USDP开源套件

1.1 USDP初识

USDP是UCloud开发并提供免费版本的⼤数据软件套件。

USDP涵盖了HDFS、Hive、HBase、Spark、Flink、Presto、Atlas、Ranger 等众多开源大数据组件，并支持对这些组件进行运维、中台建设、数据开发、业务可视化等全栈式大数据开发运维管理。

USDP通过轻量、易用、傻瓜式的形态交付给用户，支持对不同模块进行拆分，从而实现高度定制化，灵活匹配各垂直行业场景下的需求。

1.2 USDP所支持的软件栈

目前，UCloud一站式智能大数据平台USDP所支持的服务如表格所示，同时还在持续拓展更多开源生态组件服务。

1.3 USDP架构

USDP作为UCloud大数据团队自主研发的一站式智能大数据平台，其整体架构如下图所示：

（1）Manager Server为USDP管理端服务，需配备⼀个MySQL实例，用来存储集群相关的元数据信息。

（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）环境检查

（2）服务部署

1.4.3 全⾯丰富的监控指标

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 采购云原⽣商业套件

以下列出了各种常见大数据发行版的优缺点，可供选择参考。

2.2.5 选⽤思路

如果想花更少的钱，依据公司的规模，数据业务复杂程度等因素，可参考如下技术选择方案。

三、架构选型方面常见高频面试题

3.1、你们的团队组成和分⼯

3.1.1 面试目的

不同岗位，考察⽬的不⼀样。如果⾯试的是普通⼤数据开发岗位，本问题主要是看你有没有说实话，判断有没有真实的⼤数据⼯作经验，如果⽀⽀吾吾，或者前后回答⽜头不对⻢嘴，⽴⻢就让⾯试官觉得你没有实际⼯作经验。如果⾯试的是⼤数据架构师， 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）机器成本考虑
<1>物理机

以惠普品牌为例，128G 内存， 20 核物理 CPU， 40 线程， 8THDD 和 2TSSD 硬盘，单台报价 4W 出头，还需考虑托管服务器费⽤。⼀般物理机寿命 5 年左右。
<2>云主机

以阿⾥云为例，差不多相同配置，每年 5W
（2）运维成本考虑
<1>物理机：需要有专业的运维⼈员
<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版本：运维麻烦，组件间兼容性需要⾃⼰解决，研发成本⾼。（⼀般⼤⼚技术实⼒雄厚，有专业的运维⼈员才会采⽤）
也可参考本篇文章“大数据基础架构选型技巧”章节相关内容完善回答。