- 综合排序
- 最热优先
- 最新优先
- 来自专栏DevOps
实时数仓：实时数仓3.0的演进之路
实时数仓1.0 传统意义上我们通常将数据处理分为离线数据处理和实时数据处理。 从业界情况来看，当前主流的实时数仓架构基本都是基于Kafka+Flink的架构（为了行文方便，就称为实时数仓1.0）。 基于上图所示实时数仓架构方案，笔者整理了一个目前业界比较主流的整体数仓架构方案： 上图中上层链路是离线数仓数据流转链路，下层链路是实时数仓数据流转链路，当然实际情况可能是很多公司在实时数仓建设中并没有严格按照数仓分层结构进行分层 很显然，这种架构下数据存在两份、schema不统一、 数据处理逻辑不统一，整个数仓系统维护成本很高； （5）Kafka不支持update/upsert。目前Kafka仅支持append。 有的同学说了，这不，你直接解决了前4个问题嘛，还有第5个问题呢？对，第5个问题下文会讲到。
1.4K10编辑于 2024-03-29 - 来自专栏个人总结系列
实时数仓
背景说明 一方面互联网行业对实时化服务的要求日益增多，尤其在信息流，短视频应用最为显著，同时随着实时技术引擎的发展能够提供高效，稳定的实时数据服务能力。 另一方面初期实时计算都是以需求为导向，采用"一路到底"的开发模式，没有形成完整的，统一的，规范化的实时数据体系。 为了避免我们同事踩坑，总结自己的过往实时开发经验，梳理对应实时数据体系。 二. 实时数仓技术架构和应用 根据离线数据的开发，过往实时开发经验，对应实时计算架构和分层如下图所示： image.png 通常离线数仓，采用空间换取时间的方式，所以层级划分比较多从而提高数据计算效率 ；而对于实时数仓考虑时效，分层越少越好，减少分层也是为了减少中间流程出错的可能，主流的是数据接入 → 数据汇总 → 结果输出 这三层。 实时存储规范 实时数据输出是在线系统侧遵从业务方命名规范，如果是数据中心自己的存储，使用实时任务一致的命名规范。 四.
1.7K20发布于 2021-07-16 - 来自专栏腾讯云大数据
实时数仓：Iceberg
答案是肯定的，这就是本文要介绍的流批一体、仓湖融合的升级架构解决方案以及高效的数据入湖配套方案。 升级架构 升级之后的架构如下，我们引入了 Iceberg。 Transaction，否则会造成文件数量膨胀 Flink 写入以 Checkpoint 为单位，物理数据写入 Iceberg 之后并不能直接查询，当触发了 Checkpoint 之后才会写 Metadata 文件，这时数据由不可见变为可见 本地实操可参考 Flink CDC构建实时数据湖 [1]。企业级实战请使用 腾讯云流计算Oceanus [2]。 参考连接 [1] FlinkCDC构建实时数据湖: https://ververica.github.io/flink-cdc-connectors/release-2.2/content/quickstart
1.4K10编辑于 2022-05-16 - 来自专栏数据社
漫谈实时数仓
作者：数据一哥 全文共 2010个字，建议阅读需 5 分钟 什么是实时数仓 数据仓库大家非常熟悉，在1991年出版的“Building the Data Warehouse”，数据仓库之父比尔·恩门首次提出数据仓库的概念 实时数仓主要是为了解决传统数仓数据时效性低的问题，实时数仓通常会用在实时的OLAP分析、实时的数据看板、业务指标实时监控等场景。总之就是一句话：实时数仓是在离线数仓的基础上进一步满足时效性的要求。 实时数仓可能更偏向一个解决方案，不同行业不同业务场景，对实时数仓有不同选型。离线数仓与实时数仓都是数据仓库，离线分析一般会对大数据量进行批量处理，而实时一般会从大数据量中选小数据量进行处理。 实时数仓挺火，但是应用场景可能也没有那么多，实时数仓整体上还处在初级发展阶段，即便是一些中大型企业，实时业务场景也不是很多，有的企业可能没有专门的实时数仓技术团队，或者团队规模很小，几十甚至上百人做离线数仓 实时数仓的展望 实时数仓未来会有以下发展趋势，一是云会是实时数仓的重要发展趋势，公有云可能更有成本优势。
1.1K40编辑于 2023-01-04 - 来自专栏腾讯云流计算 Oceanus
实时数仓-Iceberg
答案是肯定的，这就是本文要介绍的流批一体、仓湖融合的升级架构解决方案以及高效的数据入湖配套方案。升级架构升级之后的架构如下，我们引入了 Iceberg。 Transaction，否则会造成文件数量膨胀Flink 写入以 Checkpoint 为单位，物理数据写入 Iceberg 之后并不能直接查询，当触发了 Checkpoint 之后才会写 Metadata 文件，这时数据由不可见变为可见 本地实操可参考Flink CDC构建实时数据湖[1]。企业级实战请使用腾讯云流计算Oceanus[2]。 参考连接 [1] FlinkCDC构建实时数据湖: https://ververica.github.io/flink-cdc-connectors/release-2.2/content/quickstart
1.6K30编辑于 2022-06-06 - 来自专栏桥路_大数据
实时数仓：Lambda架构
实时数仓：Lambda架构 在某些场景中，数据的价值随着时间的推移而逐渐减少。所以在传统大数据离线数仓的基础上，逐渐对数据的实时性提出了更高的要求。 于是随之诞生了大数据实时数仓，并且衍生出了两种技术架构Lambda和Kappa。 Lambda架构 其中Lambda架构是较早的解决方案，使用流处理和批处理两种架构进行数据处理。 其中流处理部分负责实时数据的处理，但流处理因为数据可靠性并不高，所以需要批处理部分定期进行运算稽查。 流处理相当于作为临时视图存在，满足数据实时性要求。而准确数据以批处理计算为主。 ?
2.5K22发布于 2021-01-06 - 来自专栏全栈程序员必看
数仓分层简介(实时数仓架构)
数仓分层简介 1.数仓分层好处：复杂问题简单化；减少重复开发；隔离原始数据。 2.数仓分层具体实现 ODS(Operation Data Store)层:原始数据层，存原始数据，直接加载原始日志、数据 DWD(Data Warehouse Detail)层：明细数据层也有叫DWI
1.2K30编辑于 2022-08-01 什么是实时数仓？实时数仓又有哪些应用场景？
这不，实时数仓就应运而生了。那它到底是个啥？能解决哪些实际问题？咱们今天就掰开了揉碎了好好讲讲。一、实时数仓的定义与特点1. 实时数仓是什么？ 简单来说，实时数仓就是让企业能秒级获取业务动态的数据系统。传统数仓隔天才能更新数据（比如T+1模式），而实时数仓能做到数据从产生到分析不超过1分钟。听着是不是很熟？ 核心特点拆解用过来人的经验告诉你，实时数仓的三大刚需是：秒级响应：订单支付、库存变动等数据10秒内可查，避免超卖或决策滞后；高并发支撑：5万+用户同时访问时，系统不卡顿（比如双11 交通物流调度：效率就是竞争力网约车平台用实时数仓匹配订单和司机位置，把平均接单时间从5分钟压缩到90秒。物流公司则用它实时优化路线，既省油又省时间。这些提升，传统数仓根本做不到。 Q：实时数仓的运维难不难？A:三招破局：用托管云服务减少运维压力；业务部门设数据专员（懂业务比懂技术重要）；重点监控数据延迟率（>5秒告警）。
49000编辑于 2025-07-14- 来自专栏韩锋频道
“实时数仓”若干问？
近期接受ITPUB的专访，谈到关于实时数仓的若干问题。下面挑选其精华分享如下： 实时数仓、数据库、湖仓一体傻傻分不清？ 5.实时数仓 那么今天我们谈到的实时数据仓库实际上就是从另外一个角度去谈，对我们数据仓库中的实时性部分的需求做了特殊加强的一种技术平台，它提供的是我们对于实时数据仓库领域里面，对于那种需要我们的数据的采集计算加工处理 尽管实时数仓的最终实现效果都是为了数据实时性要求，但实际表现形式却“五花八门”，很多企业用云数仓、湖仓一体架构解决实时数仓需求。您如何看待这种变化?到底什么才是实时数仓？？ 今天我们在这个场合会跟大家共同去探讨数仓技术以及实时数仓能给我们企业带来什么样的不同，什么样的价值。 实时数据仓库经历了哪几个重要发展阶段？从底层架构来看，实时数仓和离线数仓的最根本区别是什么？ 在互联网行业，实时数仓技术应用更加广泛些，其背后的原因是什么？ 5 首先，互联网企业其业务发展速度是比较快的，有大量的新兴业务存在，这就促生对数据计算的更多诉求，实时数仓在其中会发挥较大作用。
1.3K20编辑于 2022-11-24 - 来自专栏桥路_大数据
实时数仓：Kappa架构
上一期讲了Lambda架构，对于实时数仓而言，Lmabda架构有很明显的不足，首先同时维护两套系统，资源占用率高，其次这两套系统的数据处理逻辑相同，代码重复开发。 它是随着流处理引擎的逐步完善后，由LinkedIn公司提出的一种实时数仓架构。 ? 实时建模与离线建模类似，数据模型整体上分为5层（ODS、DWD、DWS、ADS、DIM）。 ? 其中ODS数据属于操作数据层，是直接从业务系统采集来的原始数据。在这一层上，数据与离线系统是一致的。 但T-1的数据，是在0点之后通过ETL抽取到离线系统进行计算，而计算过程需要一段时间，假设凌晨2点计算完成，那2点之前的实时数据在计算时，使用的依然是T-2的旧维度数据。 这里的计算流向是：Kafka作为ODS层，存储实时数据；实时流计算任务从ODS获取数据进行计算，计算结果作为DWD层数据，写入到Kafka中存储，供下游实时计算，并且为了与离线系统保持一致，也会推送到离线系统中进行存储
7.2K21发布于 2021-01-06 - 来自专栏Hadoop数据仓库
基于 HBase & Phoenix 构建实时数仓（5）—— 用 Kafka Connect 做实时数据同步
本篇演示安装配置 Kafka connect 插件实现 MySQL 到 Hbase 的实时数据同步。依赖环境见本专栏前面文章。 JDK 版本的环境中，可以使用 alternatives 命令选择需要的版本： [root@vvgg-z2-music-mysqld~]#alternatives --config java 共有 5 hbase:004:0> debezium-connector-mysql 默认会在启动时将存量数据写到 Kafka 中，这使得在构建实时数仓时 实时数据同步测试 MySQL 主库数据变更： insert into test.t1 (remark) values ('第四行：row4'); update test.t1 set remark 参考： Greenplum 实时数据仓库实践（5）——实时数据同步 Debezium MySQL Source Connector for Confluent Platform Apache HBase
1.1K10编辑于 2024-03-21 - 来自专栏Spark学习技巧
实时数仓|基于Flink1.11的SQL构建实时数仓探索实践
实时数仓主要是为了解决传统数仓数据时效性低的问题，实时数仓通常会用在实时的OLAP分析、实时的数据看板、业务指标实时监控等场景。 虽然关于实时数仓的架构及技术选型与传统的离线数仓会存在差异，但是关于数仓建设的基本方法论是一致的。 通过本文你可以了解到： 实时数仓的基本架构 实时数仓的数据处理流程 Flink1.11的SQL新特性 Flink1.11存在的bug 完整的操作案例 古人学问无遗力，少壮工夫老始成。 案例简介 本文会以电商业务为例，展示实时数仓的数据处理流程。另外，本文旨在说明实时数仓的构建流程，所以不会涉及太复杂的数据计算。为了保证案例的可操作性和完整性，本文会给出详细的操作步骤。 总结 本文主要分享了构建一个实时数仓的demo案例，通过本文可以了解实时数仓的数据处理流程，在此基础之上，对Flink SQL的CDC会有更加深刻的认识。
2.3K30发布于 2020-09-08 - 来自专栏桥路_大数据
实时数仓：流式数据建模
实时建模与离线建模类似，数据模型整体上分为5层（ODS、DWD、DWS、ADS、DIM）。 ? 其中ODS数据属于操作数据层，是直接从业务系统采集来的原始数据。在这一层上，数据与离线系统是一致的。 但T-1的数据，是在0点之后通过ETL抽取到离线系统进行计算，而计算过程需要一段时间，假设凌晨2点计算完成，那2点之前的实时数据在计算时，使用的依然是T-2的旧维度数据。 这里的计算流向是：Kafka作为ODS层，存储实时数据；实时流计算任务从ODS获取数据进行计算，计算结果作为DWD层数据，写入到Kafka中存储，供下游实时计算，并且为了与离线系统保持一致，也会推送到离线系统中进行存储
2.1K20发布于 2021-01-06 - 来自专栏得物技术
实时数仓混沌演练实践
一、背景介绍目前实时数仓提供的投放实时指标优先级别越来越重要，不再是单独的报表展示等功能，特别是提供给下游规则引擎的相关数据，直接对投放运营的广告投放产生直接影响，数据延迟或者异常均可能产生直接或者间接的资产损失 从投放管理平台的链路全景图来看，实时数仓是不可或缺的一环,可以快速处理海量数据，并迅速分析出有效信息，同时支持投放管理平台的手动控盘。 二、演练范围为了能更细致反应出混沌演练情况，根据演练的内容不同，将实时数仓混沌分为两部分：技术侧和业务侧。 本篇主要和大家分享基于业务侧的实时数仓混沌演练过程：1.编写演练SOPSOP是一种标准的作业程序，就是将某一事件的操作步骤和要求，进行细化、量化及优化，形成一种标准的操作过程，关于业务侧混沌，尤其是实时数仓数据相关的演练 5.异常注入通知在异常注入完成后，可以通过飞书群通知，告知红军，如收到告警，需第一时间群告知。
86620编辑于 2023-09-20 - 来自专栏肉眼品世界
实时数仓项目架构分层
一、滴滴实时数仓项目 在公司内部，我们数据团队有幸与顺风车业务线深入合作，在满足业务方实时数据需求的同时，不断完善实时数仓内容，通过多次迭代，基本满足了顺风车业务方在实时侧的各类业务需求，初步建立起顺风车实时数仓 数仓具体架构如下图所示： 从数据架构图来看，顺风车实时数仓和对应的离线数仓有很多类似的地方。例如分层结构；比如ODS层，明细层，汇总层，乃至应用层，他们命名的模式可能都是一样的。 但仔细比较不难发现，两者有很多区别： 与离线数仓相比，实时数仓的层次更少一些 从目前建设离线数仓的经验来看，数仓的数据明细层内容会非常丰富，处理明细数据外一般还会包含轻度汇总层的概念，另外离线数仓中应用层数据在数仓内部 ，但实时数仓中，app应用层数据已经落入应用系统的存储介质中，可以把该层与数仓的表分离。 * 与离线数仓相比，实时数仓的数据源存储不同 在建设离线数仓的时候，目前滴滴内部整个离线数仓都是建立在 Hive 表之上。但是，在建设实时数仓的时候，同一份表，会使用不同的方式进行存储。
1.5K30编辑于 2022-04-19 - 来自专栏大数据开发
大数据开发：离线数仓与实时数仓
数据仓库的概念，最早是在1991年被提出，而直到最近几年的大数据趋势下，实时数据处理快速发展，使得数据仓库技术架构不断向前，出现了实时数仓，而实时数仓又分为批数据+流数据、批流一体两种架构。 1、离线数仓 离线数仓，其实简单点来说，就是原来的传统数仓，数据以T+1的形式计算好放在那里，给前台的各种分析应用提供算好的数据。到了大数据时代，这种模式被称为“大数据的批处理”。 2、实时数仓 实时数仓最开始是在日志数据分析业务中被广泛使用，后来在各种实时战报大屏的推动，实时数仓开始应用。 实时数据计算好结果后，可以落地到各种数据库中，也可以直接对接到大屏进行展示。 3、大数据环境下的两种数仓架构 Lambda 架构 Lambda架构核心就三个：批数据处理层、流数据处理层和服务层。 批数据处理层应对历史长时间数据计算，流数据处理层应对短时间实时数据计算。如果一个需求要历史到当前所有数据的累加结果，那就在服务层将两部分数据进行累加。
5.5K11发布于 2021-06-09 - 来自专栏全栈程序员必看
离线数仓和实时数仓架构与设计
前言：离线数仓和实时数仓架构与设计讲解 离线数仓和实时数仓架构与设计 一、数仓架构演变（场景驱动） 二、离线大数据架构 三、离线数仓分层 四、离线大数据架构典型案例 1、Lambda架构 1.Lambda 架构 2.Lambda架构进一步了解 3.Lambda架构典型案例 4.Lambda架构典型案例（有赞广告团，基于Druid） 5.Lambda架构存在的问题 2、Kappa架构 1.Kappa架构典型案例 2.Kappa架构典型案例（一Kylin为例） 3.Kappa架构的重新处理过程 3、Lambda架构 vs Kappa架构的对比 4、实时数仓 vs 离线数仓 5、实际业务中如何选择呢 6、现状：混合架构大行其道 .Lambda架构进一步了解 3.Lambda架构典型案例 4.Lambda架构典型案例（有赞广告团，基于Druid） 5.Lambda架构存在的问题 2、Kappa架构 1.Kappa架构典型案例 2.Kappa架构典型案例（一Kylin为例） 3.Kappa架构的重新处理过程 3、Lambda架构 vs Kappa架构的对比 4、实时数仓 vs 离线数仓 5、实际业务中如何选择呢
1.9K31编辑于 2022-08-25 - 来自专栏大数据解决方案
打造轻量级实时数仓实践
Flink 和 ClickHouse 分别是实时计算和（近实时）OLAP 领域的翘楚，也是近些年非常火爆的开源框架，很多大厂都在将两者结合使用来构建各种用途的实时平台、实时数仓，效果很好。 关于两者的优点就不再赘述，本文来简单介绍笔者团队在点击流实时数仓方面的一点实践经验。 按照 Kimball 的维度建模理论，点击流数仓遵循典型的星形模型，简图如下。 点击流数仓分层设计 点击流实时数仓的分层设计仍然可以借鉴传统数仓的方案，以扁平为上策，尽量减少数据传输中途的延迟。 因此，我们采用了一种比较曲折的方法：将原表重命名，在所有节点上建立与原表 schema 相同的新表，将实时数据写入新表，同时用 clickhouse-copier 工具将历史数据整体迁移到新表上来，再删除原表
1.8K20发布于 2021-08-25 - 来自专栏肉眼品世界
实时数仓保障与治理实践
业务侧能拿到第一手准确的实时数据，就能根据准确，快速的数据做出业务策略调整，扩大收益。但是正向结果是我们预期的目标，开发所要做的就是解决达成预期目标过程中的各种不稳定因素，这些不稳定因素就是负向结果。 实时数仓相比于离线，还存在几个保障难点，具体体现在以下几个方面：高时效性。相比于离线的执行时间，实时情况下，延迟分钟级就要介入运维，对时效性要求很高。
64050编辑于 2023-02-12 - 来自专栏kwai
使用Docker安装实时数仓Postgres
Already exists e3dc51fa2b56: Pull complete f213b6f96d81: Pull complete 2780ac832fde: Pull complete ae5cee1a3f12 : Pull complete 95db3c06319e: Pull complete 475ca72764d5: Pull complete 8d602872ecae: Pull complete complete 25bb0be11543: Pull complete 4738c099c4ad: Pull complete Digest: sha256:8f7c3c9b61d82a4a021da5d9618faf056633e089302a726d619fa467c73609e4
3.2K81编辑于 2023-03-15
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号