对离线数仓的整个数据流程架构整理

最新推荐文章于 2025-05-27 09:00:06 发布
最新推荐文章于 2025-05-27 09:00:06 发布
阅读量584 收藏 2
点赞数
CC 4.0 BY-SA版权
分类专栏： 后台指标分析应用搭建 文章标签： hadoop kafka hive flink
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/c_jhsp/article/details/117705764
该博客详细梳理了基于游戏数据分析业务的离线数仓架构，包括业务背景、技术选型（如CDH、Hadoop、Kafka、Hive、Flink等）、流程架构图，以及之前日志采集面临的问题，如存储格式、服务端和客户端架构，强调了日志服与游戏服的高耦合性。

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

对离线数仓的整个数据流程架构整理

业务背景

  1. 基于游戏的数据分析业务，对玩家的统计信息进行分渠道，分服务器的灵活即时查询。
  2. 并可以实时响应相关统计指标的明细查询，实现数据的钻取。

技术选型

  1. 整个大数据分析平台选用业内较为流行的CDH进行部署，相关组件的使用，根据业务需要，进行相应的添加。

预想时流程架构图在最开始时的预计架构图

当前流程架构图

当前流程架构图

游戏技术架构

  1. 服务端采用SpringBoot+Mybatis+Netty+Mysql+Redis进行架构，Mysql采用主备复制
  2. 客户端采用U3D+Netty
  3. 通讯协议采用ProtoBuf

之前日志采集面临的问题

之前的存储格式
最低0.47元/天 解锁文章

200万优质内容无限畅学
离线数仓-数据治理
爱吃辣条的博客
02-03 1728
离线数仓-数据治理
离线数仓（五）【数据仓库建模】
功不唐捐，玉汝于成
03-09 3025
离线数仓建模理论
离线数仓整体流程(面试必备)
weixin_42908473的博客
01-28 2175
系统数据流通过程： 电商数据来源分为两部分: (1)第一部分在网站做埋点，用户点击产生的日志数据，通过nginx,springboot将数据分发到日志服务器，logfile保存在日志服务器上。 (2)第二部分是网站的业务数据，一般保存在mysql数据库。 数据传输 日志数据通过flume收集，然后保存到kafka，再通过flume传输到hdfs。 业务数据直接通过sqoop导入到hdfs。 数据处理 编写hql以及脚本程序，放在azkaban上作为每日定时任务，将最后结果导入到mysql数据库。 数据展示.
离线数仓流程
qq_66563605的博客
07-21 709
离线数仓的整个过程
实时数仓和离线数仓的区别是什么？企业如何选择合适的数仓架构？
最新发布
qq_22201881的博客
05-27 962
随着业务的发展，随着业务的发展，人们对数据实时性提出了更高的要求。从1990年 Inmon 提出数据仓库概念到今天，数仓架构经历了最初的传统数仓架构、离线大数据架构、Lambda 架构、Kappa 架构以及由Flink 的火热带出的流批一体架构，数据架构技术不断演进，本质是在往流批一体的方向发展，让用户能以最自然、最小的成本完成实时计算。综上所述，数仓建设是企业数据管理和决策支持的关键环节，在实践中，企业需要根据自身业务需求和数据规模，选择合适的数仓建设方案和技术方案，以提高企业数据资产的价值和利用效率。
一百八十二、大数据离线数仓完整流程——步骤一、用Kettle从Kafka、MySQL等数据源采集数据然后写入HDFS
tiantang2renjian的博客
09-22 2515
大数据离线数仓完整流程——步骤一、用Kettle从Kafka、MySQL等数据源采集数据然后写入HDFS
1.离线数仓—全流程调度实现
yunweijie_cn的博客
03-07 1056
全流程调度前言一、数据准备1.用户行为日志2.业务数据二、工作流调度实操1.DolphinScheduler集群模式1.1启动和登录DolphinScheduler1.2上传脚本1.3组件分发1.4配置环境变量并分发1.5 创建工作流2.DolphinScheduler单机模式2.1 启动DolphinScheduler2.2 安全中心配置 前言 前面学习了工作流调度工具DolphinScheduler，下面对数仓项目进行应用。 一、数据准备 1.用户行为日志 1）启动日志采集通道，包括：Flume、Ka
数据仓库整体流程图（离线）
想练武，就得下功夫
10-22 2381
v1.0 v2.0
离线数仓-数据仓库系统
kkddd35的博客
03-10 4453
数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。只有将数据有序的组织和存储起来之后，数据才能得到高性能、低成本、高效率、高质量的使用。高性能：良好的数据模型能够帮助我们快速查询所需要的数据。低成本：良好的数据模型能减少重复计算，实现计算结果的复用，降低计算成本。高效率：良好的数据模型能极大的改善用户使用数据的体验，提高使用数据的效率。高质量：良好的数据模型能改善数据统计口径的混乱，减少计算错误的可能性。事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计。
音乐数据中心平台离线数仓综合项目-01 从ER建模到维度建模与分层架构全流程解析
yangwei2048的博客
06-27 1818
本文介绍了数据库与数据仓库的核心概念与应用。在数据库部分，重点阐述了关系型数据库设计的三大范式：第一范式强调字段原子性，第二范式要求非主键字段完全依赖主键，第三范式避免传递依赖。同时指出实际应用中可能需要反范式设计以提高查询效率。ER实体模型部分通过电商案例展示了实体、属性和关系的表示方法。
数据仓库-离线数据仓库架构-002
Code365
07-09 2390
切分多个Task之后，DataX Job会调用Scheduler模块，根据配置的并发数据量，将拆分成的Task重新组合，组装成TaskGroup(任务组)。对于sqoop和datax，如果只是单纯的数据同步，其实两者都是ok的，但是如果需要集成在大数据平台，还是比较推荐使用datax，原因就是支持流量控制，支持运行信息收集，及时跟踪数据同步情况。ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。
大数据模型、离线架构、实时架构
swebin的专栏
03-18 2482
用户分析模型是基础的分析模型。运营人员可以通过观察不同属性的用户群体（如新注册用户与老客户、不同渠道来源的客户）各环节转化率，各流程步骤转化率的差异对比，了解转化率最高的用户群体，分析漏斗合理性，并针对转化率异常环节进行调整。黏性分析是在留存分析的基础上，对一些用户指标进行深化，除了一些常用的留存指标外，黏性分析能够从更多维度了解产品或者某功能黏住用户的能力情况，更全面地了解用户如何使用产品，新增什么样的功能可以提升用户留存下来的欲望，不同用户群体之间存在什么样的差异，不同用户对新增的功能有何看法。
电商 实时数仓 简易架构图
u012914566的专栏
06-08 474
一个人走的很快，一群人走的更远。 扫描下面的QQ二维码加入Lark的数据中台开源社区，并为你提供全程免费服务，你也可以与其他伙伴交流大数据技术，如果觉得项目不错，可以star关注，LarkMidTable团队将十分感谢您的关注！ QQ群1群【678097205】已满 微信公众号 【LarkMidTable】 ...
离线数仓，实时数仓和准实时数仓的相关架构
wppwpp1的专栏
10-21 1300
1，离线数仓主要借助，hive去实现，相关的业务统计，实时也离不开离线 2，实时数仓模型，主要借助kafka，flink做些实时查询 3，准实时数仓，可能有分钟级的数据延迟，主要借助快速的olap数据库查询，比如 ClickHouse,Druid等实现。 ...
离线数仓——（用户活跃度，启动日志数据采集，事件日志数据采集）
qq_43408367的博客
01-14 696
给source增加自定义拦截器去掉本地时间戳 a1.sinks.k1.hdfs.useLocalTimeStamp = true根据header中的logtime写文件# 配置文件滚动方式（文件大小 32 M）
电商数据应用体系建设总结（三）—— 离线数据兜底方案
Viking的博客
05-14 915
背景 目前我们使用Lambda架构来处理数据，Flink处理实时数据，Spark处理离线数据。Spark离线任务在每天凌晨的0-8点调度执行，在这段时间内，用户是看不到昨日未产出的离线数据的，数据应用对这些未产出的指标进行了特殊...
二百二十九、离线数仓——离线数仓Hive从Kafka、MySQL到ClickHouse的完整开发流程
2401_84167046的博客
04-18 849
这里的ADS层，其实就是用Kettle把Hive的DWS层结果数据同步到ClickHouse中，也是一个Kettle任务而已。(img-WFyHGrKX-1713371724542)]这样用海豚进行调度每一层的任务，整个离线数仓流程就跑起来了。
大数据Flink电商数仓实战项目流程全解（一）
日句灬的博客
07-21 7750
项目整体思路和架构 本项目主要参考尚硅谷的Flink实时数仓项目完成，最近又重新跑了一遍，项目整体我会在后续上传到码云中， 也会同步更新到博客中来，里面不仅包含了整体代码和整个集群搭建过程，也包含了一些我自己的理解和测试过程 希望大家能喜欢，以后我也会把我整个的大数据学习过程和笔记做一个分享。非常欢迎一起学习大数据的朋友， 大家可以一起交流和学习。 实时数仓分层思想 这里采用的架构和离线数仓架构不同，整个项目共分为6个层来做，但注意：这些层级之间并不是纯粹的 上下关联关系：也不是一定非要有这6个层级；
重构实时离线一体化数仓，Apache Doris 在思必驰的应用实践
SelectDB
10-10 4296
Apache Doris 支持构建离线+实时统一数仓，一个 ETL 脚本即可支持实时和离线数仓，大大缩短开发周期，降低存储成本，避免了离线和实时指标不一致等问题。Apache Doris 1.1.x 版本开始全面支持向量化计算，较之前版本查询性能提升 2-3 倍。经测试，Apache Doris 1.1.x 版本在宽表场景的查询性能已基本与 ClickHouse 持平。功能强大，不依赖其他组件。
离线数仓和实时数仓的区别
03-15
<think>好的，我现在需要回答用户关于离线数据仓库和实时数仓的区别及适用场景的问题。首先，我要回顾一下用户提供的引用内容，看看里面有没有相关的信息可以提取。 根据引用[1]，离线数仓和实时数仓在实施上有相似之处，但也有显著差异。相同点可能包括数据建模、ETL流程等，但用户主要关心的是差异，所以需要详细展开不同点。引用提到了几个关键方面的对比，比如数据处理时效性、数据更新频率、技术架构、适用场景和数据质量保障等。这些是需要详细说明的方面。 接下来，引用[2]提到了菜鸟仓配的实时数仓案例，可能涉及全局设计、数据模型等，这可以作为实时数仓应用场景的例子。引用[5]提到Kappa架构在处理历史数据时的问题，这可能涉及实时数仓的技术架构，比如使用流处理引擎如Flink，而离线数仓可能使用Hadoop、Spark批处理。引用[4]提到了入库时间把控困难，可能涉及实时数仓在数据延迟方面的挑战，而离线数仓通常是定时批量处理，延迟较高。 我需要将这些信息组织起来，首先明确两者的定义，然后分点对比差异，比如数据处理时效性、技术架构、数据更新频率、适用场景。每个差异点需要结合引用中的内容，例如离线数仓处理T+1数据，使用Hadoop/Spark；实时数仓处理秒级/分钟级延迟，使用Flink/Kafka。适用场景方面，离线数仓适合报表分析、历史数据挖掘，而实时数仓适合监控、实时推荐等。 另外，引用[3]提到了元数据应用，可能涉及数据质量管理，但用户的问题可能更关注差异，所以可能在数据质量保障方面提到离线数仓更容易做数据校验，而实时数仓需要更复杂的保障机制。 然后要确保使用正确的LaTeX格式，行内公式用$...$，独立公式用$$...$$，但当前内容可能不需要太多数学公式，但如果有涉及变量或技术术语可能需要用。不过根据问题，可能更多的是文字描述，所以暂时可能不需要公式。不过需要注意如果有提到任何技术指标或数据频率，可能需要用行内公式，比如处理时间$T+1$，但根据引用内容，可能不需要。 最后生成相关问题，参考示例中的结构，问题应围绕差异、技术选型、适用场景、挑战等展开，例如询问核心技术组件、如何选择、实时数仓的挑战、结合两种数仓的架构等。 需要检查是否符合用户要求的结构：先回答差异，分点说明，然后适用场景，最后相关问题。同时确保引用标记正确，例如在提到数据时效性时引用[1]，提到技术架构时引用[5]和[2]，数据延迟问题引用[4]等。 现在整理回答的结构： 1. 核心差异分点：数据处理时效性、技术架构、数据更新频率、数据规模与质量保障、应用场景。 2. 每个点详细说明，并添加引用标记。 3. 适用场景分别说明离线和实时的典型应用。 4. 生成相关问题。 注意使用中文，避免Markdown格式，但用户给出的示例中在回答部分使用了正常段落，代码块用```包裹，但当前问题不需要代码，所以按普通文本处理。确保LaTeX语法正确，如果有变量或公式的话，但目前可能不需要。 现在开始组织内容，确保每个差异点明确，引用正确，语言通顺。</think>### 离线数据仓库与实时数据仓库的核心差异及适用场景 #### 一、核心差异 1. **数据处理时效性** - **离线数仓**：通常以$T+1$模式运行（例如每日凌晨处理前一天数据），数据延迟在小时或天级，适用于对实时性要求低的场景[^1]。 - **实时数仓**：支持秒级或分钟级延迟，数据从产生到可查询仅需极短时间，例如物流监控或实时风控[^2][^5]。 2. **技术架构** - **离线数仓**：基于批处理框架（如Hadoop、Spark），采用分层模型（ODS→DWD→DWS），依赖定时调度任务[^3]。 - **实时数仓**：依赖流处理引擎（如Flink、Kafka），采用Lambda或Kappa架构。Kappa架构通过流式重放弥补历史数据处理能力[^5]。 3. **数据更新频率** - **离线数仓**：数据按批次全量或增量更新，例如每日合并一次历史表。 - **实时数仓**：数据持续流入并实时更新，可能面临“多批次线程并发写入”的时序控制问题[^4]。 4. **数据规模与质量保障** - **离线数仓**：适合海量历史数据存储与复杂计算（如PB级数据聚合），可通过离线校验保障数据一致性[^3]。 - **实时数仓**：需权衡吞吐量与延迟，数据质量依赖端到端Exactly-Once语义等流式保障机制[^4]。 #### 二、适用场景 - **离线数仓典型场景** - 周期性报表生成（如月度销售分析） - 历史数据挖掘与长期趋势预测 - 复杂多表关联的OLAP查询。 - **实时数仓典型场景** - 实时监控（如服务器性能告警、物流轨迹追踪） - 实时推荐系统（如电商个性化推荐） - 金融反欺诈与风险控制。 ####
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值