持续输出 敬请关注

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

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

持续输出  敬请关注

【下一篇】据中台架构及解决

新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、你们的团队组成和分/p>

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大数据团队自主研发的一站式智能大数据平台，其整体架构如下图所示：

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

1.4.3 全富的监控指标

        USDP预置的监控指标主要包含三部分内容：
        （1）JMX全量指标采集
        （2）Http常标采集
        （3）义指标采集
        以上三部分监控数据最终将汇总于USDP的 Promethues中，并在每个服务的概览中展示最常监控指标。同时，在Grafana中，通过 USDP官置的监控模板（ Dashboard），可以查看最详细监控指标。如果USDP预置的监控图标满务需求，也可以义添加所需的监控图表。

1.4.4 灵活便捷的告警服务

        USDP提供预置的告警模板，只需要按照引导进单配置，即可实现向不同（微信、钉钉、邮件、接）发送集群指标告警的需求。与监控指标的设计相似，如果认为预置的告警模板满务需求，也可以义对告警模板进改，或添加新的告警规则。

1.4.5 专业的技术

        UCloud据团队积淀了多年公有云据运维和业务调优经验，通过持续更新的知识库，为提供专家级技术，解决使SDP的后顾之忧。

1.4.6 反哺开源 区

        USDP免费版中所使开源、全容优化后的服务包，将反哺回开源 区，为开发者提供免费的下载渠道。

1.5 USDP适用的业务场景

（1）数据仓库
        国内常数仓模型为维度数仓，即按照事实表、维度表来构建数据仓库、数据集市。通过USDP式智能据平台，可以部署构建维度数仓所需的各项服务，帮助企业快速构建数据中台。
（2）机器学习
        机器学习通过算法对数据进析，挖掘出其中蕴含的规律，并事物预测或者分类，有的计算需求。通过USDP式智能据平台的Spark、 Flink等分布式运算框架，可以的进器学习应发。
（3）信息检索
        从海量数据中快速检索到所需信息，是数据应重要领域， USDP式智能据平台集成了分布式搜索和分析引擎ElasticSearch以及实时检索数据库HBase、数仓服务Kylin等，能够提供的数据检索能可构建企业级搜索引擎、管理系统等。

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

2.1 为啥要选择套件

        反思以下两个方面的问题就懂了。
（1）兼容性

         款软件，相互兼容性你准备怎么管控br> （2）运维管理(配置、部署、管理、监控、告警)

        款分布式软件部署理定监控定告警将是噩梦！

2.2 主流发行版对比

        CDH 6.3 的结束为 2022 年 3 HDP 3.1的结束为 2021 年 12 也就是说，在这个之前，这些最后的“免费午餐”依然是主流的版本。但过了这个之后呢br>         之前也有不少同学问过我，我正式回答，有三条道可供选择，但是要路还长，也没办法提供实现，只能提供思路，如果我有实现我就发财了，中国版的CDP就出现了。

2.2.1 回到Apache 原本

        其实很多公司就是这么做的，但具有挑战性（后续成本个商业版可能还要些），没有实公司还真不敢玩，除司做不

2.2.2 使Cloudera 的” 区版”

        CM虽然收费了，但是CDH发的源码都是在 GitHub 上公开的，这意味着你完全可以使源码来进译和部署。但是，这条路的效果般，因为在商业发中最重要的组件是 Cloudera Manager，正是 Cloudera Manager 降低了集群的安装、部署、运维的难度，虽然 Cloudera 承诺会将 Cloudera Manager “开源”，但其实是有限制的“开源”，源代码只会向具有许可证的客户开放，所以不想花费的话，是没有办法得到 Cloudera Manager 的。
        如果只是Cloudera 版本的源码编译和部署组件，然后在繁琐的命令进作，那和使Apache 区版本什么区别呢 /p>

2.2.3 Apache Ambari + Apache BigTop Stack

        来看“Apache Ambari + Apache BigTop Stack”这种组合是好的选择。

        Apache Ambari都熟悉，作为 Hortonworks 贡献给 区的项HDP虽然没了，但是Ambari是Apache的，不可能收费，所以完全可以使mbari 降低集群的安装、部署、运维的难度，且可以扩展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、你们的团队组成和分/h2>

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、服务器选型使理机还是云主机br> （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层采ZO+parquet存储： 100g压缩为10g左右
         4）数仓DWD层采ZO+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基础套件。

        为什么不选产品/strong>
        阿产品虽然开箱即也免去了运维，但是存在题：
（1）阿的据产品Hadoop版本很多上层的开源调度、数据治理不
（2）阿的版本是固定的，购买其他商业组件做版本的适配，只能购买阿的其他据商业软件，完全被绑死了
（3）数据安全性考量
        所以我们最开始就选择了CDH或者HDP

        为什么没选用Apache版本/strong>
        Apache版本：运维麻烦，组件间兼容性需要解决，研发成本（技术实厚， 有专业的运维才会采
        也可参考本篇文章“大数据基础架构选型技巧”章节相关内容完善回答。

【下一篇】据中台架构及解决