离线数仓项目之数据采集

本文介绍了大数据实时采集处理流程,采用Flume-Kafka-Flume架构,解释了选择该架构的原因,包括未来扩展性、数据缓冲、解决小文件问题和削峰填谷。Flume1使用taildirsource和kafkachannel,简化数据传输并避免额外header信息。Flume2通过kafkasource、filechannel和hdfssink将数据存储到HDFS,同时使用时间戳拦截器确保数据正确归档。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、采集数据

1.准备工作:hadoop安装

                     zookeeper安装

                     kafka安装

                     flume安装

                     sqoop安装

2.思想架构:

 3.架构解析

   1.使用flume->kafka->flume的原因?

在生产环境中我们使用架构不能局限于当下,在采集日志数据的时候采用flume->kafka->flume架构的好处有以下几点

(1)如果直接使用flume,按照现在来说也是可以的,但是公司需要发展,使用flume->kafka->flume架构方便以后做实时的时候可以直接连接kafka。

(2)kafka可以做一个缓冲,如果消费速度大于生产速率,kafka可以缓存更多的数据。防止把jvm挤爆。

(3)解决小文件问题。kafka有聚合作用,Kafka中消息是以topic进行分类的,生产者生产消息,消费者消费消息,都是面向topic的。生产者生产的消息是不断追加到log文件末尾,故在此时就会聚合小文件。

(4)削峰,在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用kafka消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。

2.两个flume使用的组件的选型。

flume1使用的组件:taildir source

                                 kafkachannel

                                 不使用sink

Source是负责接收数据到Flume Agent的组件。

查询官网:taildir source 解决了断点续传和实时监控的问题

Channel是位于Source和Sink之间的缓冲区。

 查询官网:使用kafka channel直接对接kafka,省略了sink组件,减少了take事务,提升了flume数据传输效率,并且将kafka channel的参数parseAsEvent设置为false,解决了flume数据传入到kafka,json日志信息前面多拼接个header信息的问题,保证kafka里面的数据都是一个个的flume body(单独的json日志字符串)

parseAsEvent:source上传数据一般是以event上传,但是在没有sink的时候,他是以字符串上传,而parseAsEvent默认是true,意思是以event上次,所以我们把它改成false。parseAsEvent是channel的参数。

拦截器:Flume1的source下面,挂了一个ETL拦截器,从数据源头对数据做ETL清洗,保证采集到的数据都是完整的json字符串,方便后续解析使用。


flume2使用的组件:kafka source

                                file channel

                                hdfs sink

F2:使用kafka source 对接kafka,获取kafka topic的数据,传给file channel,提高数据的安全性。最后利用hdfs sink将数据传入到hdfs上。
拦截器:F2的source下面挂了一个时间戳拦截器,给每条从kafka里获取到的数据加上一个header,key为timestamp,value为日志里面的ts字段的值(毫秒级时间戳)
这样做的目的有两个:
1:可以保证当天生成的日志数据一定会进入hdfs当天的目录下
2:造数据的时候,不需要再修改服务器的时间

<think>好的,用户想了解离线数据仓库项目的构建、设计和实现方案。首先,我需要整理一下离线数仓的基本概念和常见架构。通常离线数仓会采用分层设计,比如ODS、DWD、DWS等层,每层有不同的作用。然后,用户提供的引用内容提到了元数据管理、指标体系的重要性,还有分层重构的问题,这些都需要在回答中体现。 接下来,要确保回答结构清晰,分步骤说明构建方法。可能需要包括项目规划、架构设计、数据建模、技术选型、实现步骤和优化策略。每个部分需要结合用户提供的引用内容,比如在架构设计中强调分层的必要性,引用[3]提到的分层重构问题,可以说明如何设计灵活的分层以便后期优化。 数据建模部分,需要提到维度建模和事实表、维度表的设计,引用[2]中的指标体系,说明建立统一指标的重要性,避免需求膨胀。技术选型方面,Hadoop、Hive、Spark这些组件是常用的,可以列举出来,同时引用[1]提到的元数据管理工具,如Atlas。 实现步骤要详细,从数据采集到分层处理,再到数据应用,每个步骤需要具体说明。优化策略部分,可以引用分层重构和模型建设的建议,强调前期设计的重要性,避免后期调整困难。 最后,生成相关问题,要围绕离线数仓的设计挑战、技术选型考量、指标体系作用、元数据管理方法以及性能优化策略。确保问题覆盖用户可能感兴趣的各个方面,帮助他们深入理解。 检查是否遵循了系统级指令,数学公式用$...$,独立公式用$$...$$,但当前内容可能不需要数学公式。确保使用中文,回答结构清晰,引用正确添加。比如在提到分层设计时,引用[3],元数据应用引用[1],指标体系引用[2]。 现在,组织这些内容,确保逻辑连贯,步骤明确,引用自然融入,最后提出相关问题。</think>### 离线数据仓库项目构建与设计方案 #### 一、核心设计原则 1. **分层架构设计** 离线数仓通常采用经典分层模型: $$ODS \rightarrow DWD \rightarrow DWS \rightarrow ADS$$ 其中: - **ODS层**(操作数据存储)直接对接原始数据,保留业务系统原貌[^3] - **DWD层**(明细数据层)进行数据清洗、标准化和维度退化 - **DWS层**(汇总数据层)按主题域构建宽表 - **ADS层**(应用数据层)面向具体业务场景输出指标 2. **指标体系先行** 建立统一的业务指标定义规范,遏制需求膨胀问题。例如电商场景需明确"GMV=订单金额-退款金额+运费"等计算口径[^2]。 #### 二、实现方案关键步骤 1. **数据采集与存储** - 使用Sqoop/DataX完成结构化数据同步 - 通过Flume采集日志类非结构化数据 - 存储选择HDFS+Hive组合,支持大规模数据批处理 2. **分层建模实现** ```sql -- DWD层表示例(订单事实表) CREATE TABLE dwd_order_fact ( order_id STRING COMMENT '订单ID', user_id BIGINT COMMENT '用户ID', total_amount DECIMAL(16,2) COMMENT '订单金额', dt STRING COMMENT '分区日期' ) PARTITIONED BY (dt STRING); ``` 3. **元数据管理** 采用Apache Atlas实现: - 数据血缘追踪 - 指标口径版本管理 - 表生命周期监控[^1] #### 三、优化策略 1. **分层重构技巧** 在DWD层预置通用维度组合,后期通过视图实现逻辑分层剥离,降低物理重构成本。 2. **模型建设规范** - 事实表采用星型模型 - 维度表使用缓慢变化维类型2 - 重要指标实现跨层打标,保障一致性 #### 四、典型技术栈选型 | 层级 | 组件 | |------------|------------------------| | 数据采集 | Sqoop, Flume, Kafka | | 存储计算 | HDFS, Hive, Spark | | 任务调度 | Airflow, DolphinScheduler | | 元数据管理 | Atlas, DataHub |
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

qq_45688530

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值