阿里云离线数仓

1.项目流程图

使用框架说明:

ECS云服务器;
DataHub:类似于kafka的软件,可以做数据缓冲,削峰
MaxCompute: 类似于hadoop+hive+ 定时调度的大数据计算框架;
DataWorks: 是MaxCompute的视图管理框架;
Quick BI: 做最后的可视化视图展示,倾向于离线数据的展示;
DataV: 大屏幕视图展示框架, 倾向于实时的计算,更加的炫酷;
RDS: RDS是云数据库的统称

流程图

2. 框架的使用

说明: 上面几个软件都是阿里云的收费,都可以在视图上直接进行操作,非常好用,这里的话,直接上一个尚硅谷的文档链接,大家配置着观看使用,上手很简单的,上面的使用流程图可以看看

下载地址:
链接:https://pan.baidu.com/s/1L8QwMYyMjtyEMr6lHN_lhg
提取码:6666

问题: 有时候使用定时调度的时候会出现数据有问题,这一点大家要小心一点

一、项目简介 本项目教程以国内电商巨头实际业务应用场景为依托,同时以阿里云ECS服务器为技术支持,紧跟大数据主流场景,对接企业实际需求,对电商数仓的常见实战指标进行了详尽讲解,让你迅速成长,获取最前沿的技术经验。 二、项目架构 版本框架:Flume、DateHub、DataWorks、MaxCompute、MySql以及QuickBI等; Flume:大数据领域被广泛运用的日志采集框架; DateHub:类似于传统大数据解决方案中Kafka的角色,提供了一个数据队列功能。对于离线计算,DataHub除了供了一个缓冲的队列作用。同时由于DataHub提供了各种与其他阿里云上下游产品的对接功能,所以DataHub又扮演了一个数据的分发枢纽工作; 据上传和下载通道,提供SQL及MapReduce等多种计算分析服务,同时还提供完善的安全解决方案; DataWorks:是基于MaxCompute计算引擎,从工作室、车间到工具集都齐备的一站式大数据工厂,它能帮助你快速完成数据集成、开发、治理、服务、质量、安全等全套数据研发工作; QuickBI & DataV:专为云上用户量身打造的新一代智能BI服务平台。 三、项目场景 数仓项目广泛应用于大数据领域,该项目技术可以高度适配电商、金融、医疗、在线教育、传媒、电信、交通等各领域; 四、项目特色 本课程结合国内多家企业实际项目经验。从集群规模的确定到框架版本选型以及服务器选型,手把手教你从零开始搭建基于阿里云服务器的大数据集群。采用阿里云ECS服务器作为数据平台,搭建高可用的、高可靠的Flume数据采集通道,运用阿里云DateHub构建中间缓冲队列并担任数据分发枢纽将数据推送至阿里自主研发的DataWorks对数据进行分层处理,采用MaxCompute作为处理海量数据的方案,将计算结果保存至MySQL并结合阿里的QuickBI工作做最终数据展示。
<think>好的,用户想了解中小型公司在阿里云上搭建离线数仓所需的服务器规模及配置推荐。首先,我需要回顾一下相关知识,特别是关于数据仓库的服务器配置和规模规划。 记得参考引用[3]中提到的集群规模计算方法,用户可能需要类似的思路。根据案例,每天处理1亿条日志,每条1K,总数据量约100G,存储半年需要约77T,考虑三副本和缓冲区,大约需要10台8T磁盘的服务器。不过中小型公司的数据量可能更小,需要调整参数。 接下来,用户可能的数据量是多少呢?假设中小型公司日活用户是10万左右,每人每天产生100条日志,那么每天的数据量是10万*100=1000万条,每条1K的话,每天是约10G。半年下来是10G*180=1.8T,加上三副本和缓冲,总存储需求大约1.8T*3=5.4T,再除以0.7,约7.7T。这样磁盘需求大概是8T左右,可能只需要2-3台服务器,但需要考虑计算资源,比如内存和CPU。 另外,阿里云的产品选择也很重要。MaxCompute适合大数据处理,EMR可以管理Hadoop生态组件,OSS适合存储冷数据。需要推荐具体的ECS实例类型,比如计算优化型c6或内存优化型r6,根据数据处理需求选择。 还要考虑离线数仓的组件,比如Hive、HDFS、Spark等,这些组件对内存和CPU的要求。例如,Hive的元数据存储可能需要RDS MySQL,而HDFS需要足够的磁盘空间和网络带宽。 用户可能还关心成本优化,比如使用按量付费或预留实例,以及存储分层策略,将冷数据转移到OSS节省成本。同时,是否需要高可用配置,比如多可用区部署,但中小型公司可能可以适当降低这方面的要求以节省费用。 最后,需要给出一个具体的配置示例,比如使用4台ECS,计算型实例,搭配OSS和RDS,并给出分层的存储建议。同时提醒监控和弹性扩展的重要性,确保资源利用率。</think>### 中小型公司阿里云离线数仓服务器配置推荐 #### 1. **数据规模估算** 根据引用[3]的集群资源规划逻辑,假设中小型公司日活跃用户约 **10万**,每人每天产生 **50-100条日志**,则: - **日数据量**:$10万 \times 100条 \times 1KB = 10GB$ - **半年存储需求**(3副本 + 30%缓冲): $$ \frac{10GB \times 180天 \times 3}{0.7} ≈ 8TB $$ #### 2. **服务器配置建议** - **计算节点(ECS)**: - **实例类型**:推荐 **计算型 ecs.c6**(如4核16GB)或 **通用型 ecs.g6**(如8核32GB)[^3] - **数量**:**3-4台**,满足分布式计算(Hive/Spark)和存储(HDFS)需求 - **磁盘**:每节点挂载 **1-2TB高效云盘**(根据数据冷热分层) - **存储与计算分离**: - **热数据**:HDFS部署在ECS本地盘(高效云盘) - **冷数据**:迁移至 **OSS** 存储降低成本[^2] - **元数据管理**: - **RDS MySQL**:基础版(1核2GB)管理Hive元数据 - **MaxCompute**:按量付费处理ETL任务,减少本地计算压力 #### 3. **典型架构示例** ``` 数据采集层:Log Service(日志投递至OSS) 计算层:EMR集群(3台ECS.g6 + 1台Master节点) 存储层:OSS(原始数据) + HDFS(中间表) 调度层:DataWorks(任务编排) ``` #### 4. **成本优化策略** - **弹性伸缩**:非高峰时段缩容ECS节点 - **存储分层**:7天以上数据转存OSS低频存储 - **预留实例券**:长期运行节点使用RI降低成本 #### 5. **注意事项** - **网络带宽**:ECS节点建议选择 **1Gbps内网带宽** - **高可用**:Master节点部署在多个可用区(如生产环境) - **监控**:通过云监控(CloudMonitor)跟踪CPU/内存/磁盘利用率 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值