持续输出 敬请关注

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

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

持续输出  敬请关注

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

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

新⼀代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所支持的服务如表格所示，同时还在持续拓展更多开源生态组件服务。

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版本：运维麻烦，组件间兼容性需要⾃⼰解决，研发成本⾼。（⼀般⼤⼚技术实⼒雄厚， 有专业的运维⼈员才会采⽤）
        也可参考本篇文章“大数据基础架构选型技巧”章节相关内容完善回答。

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